Re: mutiple phase 1 tunnel and proxy ID issues

[Bronislav Kavsan <[e-mail]>]

Roy,

Thank you for clarification.
Also, ID could my much longer than 8 bytes - consider Distringuished Name,
for example.

Roy Pereira wrote:

> 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:[e-mail]]
> > Sent: Thursday, May 28, 1998 10:54 AM
> > To: Roy Pereira
> > Cc: [e-mail]
> > 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:[e-mail]]
> > > > Sent: Tuesday, May 26, 1998 5:58 PM
> > > > To: Roy Pereira
> > > > Cc: Cliff Wang; [e-mail]; [e-mail]
> > > > 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
> >
> >
> >



--
Bronislav Kavsan
IRE Secure Solutions, Inc.
100 Conifer Hill Drive  Suite 513
Danvers, MA  01923
voice: 978-739-2384
http://www.ire.com