[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: mutiple phase 1 tunnel and proxy ID issues
If the mobile client didn't send its ID again in phase 2, then only one
ID would be sent (the destination's ID). This is illegal in the
specification since it states that both IDs are sent (tunnel) or no IDs
are sent (transport).
Because the two ID payloads do not have any distinguishing fields to
denote which one is the initiator and which one is the responder, except
for their order, it would be difficult to introduce a rule that says not
to include the ID payload if your source is the same in phase 1 and
phase 2.
I guess I don't understand what the problem is by sending two ID
payloads in phase 2? Its only an extra 8 bytes isn't it?
> -----Original Message-----
> From: Bronislav Kavsan [mailto:bkavsan@ire-ma.com]
> Sent: Thursday, May 28, 1998 10:54 AM
> To: Roy Pereira
> Cc: ipsec@tis.com
> Subject: Re: mutiple phase 1 tunnel and proxy ID issues
>
>
> Roy,
>
> I understand the reason for sending destination's ID in the Phase 2
> tunneling topology. I also understand the reason for sending
> source ID in
> host-GW-GW-host topology. But it is not clear to me why mobil
> user has to
> send its Phase 2 it's ID again when he already did it in
> Phase 1 in the
> Mobil-GW-Host situation?
>
> Roy Pereira wrote:
>
> > You always have to send IDs in phase 2 if you are
> tunneling. If we are
> > talking about a mobile user, then they are tunneling into a gateway,
> > thus they have to send their and the destination's IDs in phase 2.
> > Otherwise, the SA is between them and the gateway and not
> between them
> > and their destination behind the gateway.
> >
> > > -----Original Message-----
> > > From: Bronislav Kavsan [mailto:bkavsan@ire-ma.com]
> > > Sent: Tuesday, May 26, 1998 5:58 PM
> > > To: Roy Pereira
> > > Cc: Cliff Wang; kent@bbn.com; ipsec@tis.com
> > > Subject: Re: mutiple phase 1 tunnel and proxy ID issues
> > >
> > >
> > > Why mobil user has to send ID (IP address or anything else)
> > > in Phase 2?
> > > Isn't it already unquely identified (and policy-matched) by
> > > the gateway in
> > > Phase 1 by its e-mail, FQDN or DN?
> > >
> > > Roy Pereira wrote:
> > >
> > > > For a mobile client, its phase 1 ID will be something
> like an email
> > > > address since its IP address is not static. For its phase
> > > 2 ID though,
> > > > it will need to send an IP address. This IP address is its
> > > dynamically
> > > > assigned IP address that it recieved through PPP, DHCP,
> > > ISAKMP-CFG or
> > > > any other means. The trick is that the gateway must be
> > > able to remember
> > > > the phase 1 ID to get policy for the phase 2 negotiation.
> > > >
> > > > Although, not in any internet draft, I really don't believe
> > > that all ID
> > > > types are valid for phase 1 and phase 2. Phase 1, for
> > > instance, doesn't
> > > > really support subnets and ranges. While phase 2 doesn't
> > > really support
> > > > email, DN & GN.
> > > >
> > > > > 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.
> > >
> > >
> > >
> > > --
> > > Bronislav Kavsan
> > > IRE Secure Solutions, Inc.
> > > 100 Conifer Hill Drive Suite 513
> > > Danvers, MA 01923
> > > voice: 978-739-2384
> > > http://www.ire.com
> > >
> > >
> > >
>
>
>
> --
> Bronislav Kavsan
> IRE Secure Solutions, Inc.
> 100 Conifer Hill Drive Suite 513
> Danvers, MA 01923
> voice: 978-739-2384
> http://www.ire.com
>
>
>
Follow-Ups: