[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mutiple phase 1 tunnel and proxy ID issues

Steve,

It seems that both gateway needs to be informed the
two mobiles user's addresses. Otherwise you will
not be able to add the outbound SPD entry for client
traffic. Of cource when outbound SPD entry is there,
then traffic can be sent to the peer. The peer can use
inner header to get address in order to add inbound
SPD entry. But this creates a security hole since
you are using inbound traffic to generate inbound
SPD entry. I would think the inbound SPD entry
should be created before inbound IPsec
packet processing. Anyway it seems to me that when
user names are used in IKE phase 2 negotiations,
we need some mechanism to resolve the IDs to
IP addresses before SPD entries can be created
to process traffic. Unfortunately the usuage of IDs
in the IPsec is a a fairly complicated issue which
deserves more look into it.

Thanks,
cliff


kent@bbn.com on 05/20/98 04:47:34 PM
Please respond to kent@bbn.com
To: Cliff Wang/Raleigh/IBM@ibmus
cc: ipsec@tis.com
Subject: Re: mutiple phase 1 tunnel and proxy ID issues


Cliff,

>I totally agree what you have replied in the mail.  Actually
>my question is that if user name instead of IP address is
>used in the ID payload of phase 2 negotiation, even if
> a Phase 2 SA is negotiated successfully, we cannot
>create a SPD entry since user ID cannot be used to
>process packet. We need to turn that ID into address
>in order to create a SPD entry. But I am not sure how
>to map that ID into an IP address. This is a practical case
>when two mobile user logs into two different ISP box,
>get a dynamic address and they want to have their
>data traffic protected. The ISP boxes's policy can only be
>configured with the mobile user's ID, since their
>address are dynamically assigned. The ISP boxes
>can negotiate a Phase 2 SA with ID, but then they
>somehow need to exchange user ID to IP address
>mapping to each other. Otherwise SPD entry can not be
>created.

Sorry.  I forgot to address that important detail.  The address for the
remote peer should be acquired from the inner IP header (it's a security
gateway, so we must be using tunnel mode) of the client traffic. It would
be cleaner if IKE expressly stated the address, but lacking that one can
grab the first inbound packet for the SA (it must come from the remote peer
since the SG and the clients behind it don't know the address yet) and
extract the address to fill in the SPD and SAD entries re the IP address
selectors.  Other selectors, if applicable, could have been filled in from
the name-based SPD entry.

Steve