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