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

Re: mutiple phase 1 tunnel and proxy ID issues

Steve,

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.

Thanks,
cliff



kent@bbn.com on 05/20/98 04:02:45 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'll address this last issue, and leave the former 2 to the IKE experts.

>3)Phase 2 Proxy ID
>For Phase 2 negotiation, the ID payload can be of
>type "fully qualified user name string", such as
>piper@foo.com. Even we can negotiated the phase 2
>SA successfully, the negotiated SA can not be used
>to protect packets until the user name is turned into
>some IP address(host, range, subnet). How do we
>solve this user name to IP address mapping? Assuming
>the user is mobile, this mapping can be quite dynamic.

When an SA is established and a name form other than an IP addres is used
to authenticate the peer, it will be necessary to create a dynamic SPD
entry (as well as the usual SAD entry) that specifies the
(dynamically-assigned) address of the peer.  For inbound traffic, the SAD
entry (selected by the SPI/dest addr/protocol triple) is used to perform
the necessary selector checks after IPsec primary processing.  For outbound
traffic, the newly created SPD entry is used to vector traffic to the right
SA (SAD entry).  There needs to be a housekeeping function to remove the
SAD entry afterwards, but there does not seem to be a security problem if
the same dynamic address is assigned to a new peer, since the keying
material would be different and the SA establishment procedure should
detect the SPD reuse.

Steve
Follow-Ups: