Re: mutiple phase 1 tunnel and proxy ID issues
Bronislav Kavsan <bkavsan@ire-ma.com> Thu, 28 May 1998 14:41 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27489 for ipsec-outgoing; Thu, 28 May 1998 10:41:22 -0400 (EDT)
Message-ID: <356D7A6A.18D92675@ire-ma.com>
Date: Thu, 28 May 1998 10:53:30 -0400
From: Bronislav Kavsan <bkavsan@ire-ma.com>
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: Roy Pereira <rpereira@TimeStep.com>
CC: ipsec@tis.com
Subject: Re: mutiple phase 1 tunnel and proxy ID issues
References: <319A1C5F94C8D11192DE00805FBBADDF124393@exchange.timestep.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
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
- mutiple phase 1 tunnel and proxy ID issues Cliff Wang
- Re: mutiple phase 1 tunnel and proxy ID issues Stephen Kent
- Re: mutiple phase 1 tunnel and proxy ID issues Cliff Wang
- Re: mutiple phase 1 tunnel and proxy ID issues Stephen Kent
- Re: mutiple phase 1 tunnel and proxy ID issues Cliff Wang
- RE: mutiple phase 1 tunnel and proxy ID issues Roy Pereira
- Re: mutiple phase 1 tunnel and proxy ID issues Bronislav Kavsan
- Re: mutiple phase 1 tunnel and proxy ID issues Cliff Wang
- Re: mutiple phase 1 tunnel and proxy ID issues Bronislav Kavsan
- Re: mutiple phase 1 tunnel and proxy ID issues Raul Miller
- Re: mutiple phase 1 tunnel and proxy ID issues Kai Martius
- Re: mutiple phase 1 tunnel and proxy ID issues Cliff Wang
- RE: mutiple phase 1 tunnel and proxy ID issues Roy Pereira
- Re: mutiple phase 1 tunnel and proxy ID issues Bronislav Kavsan
- RE: mutiple phase 1 tunnel and proxy ID issues Roy Pereira
- Re: mutiple phase 1 tunnel and proxy ID issues Bronislav Kavsan
- Re: mutiple phase 1 tunnel and proxy ID issues Will Fiveash