Re: Another field for traffic selector?

["Scott G. Kelly" <scott@airespace.com>]

I guess I don't see why you can't have multiple tunnels between the
devices, since the tunnel selectors (the nat'd network addresses) are
unique. Alternatively, you can use an encapsulation of some sort (GRE,
UDP, L2TP, etc), which permits unique per-customer selectors. This can
be done cleanly without modifying the ipsec protocols, can't it?

Mark Duffy wrote:
> 
> I think this is in fact *specifically* so that we can have per-customer
> tunnels.  That is, per-customer tunnels, for multiple customers at once,
> that terminate in the same IPsec device.  Without this proposed feature
> there is no  attractive alternative for the security gateways to agree on
> which tunnels are for which customers.
> 
> I also believe that "everyone's ipsec implementation" need not be modified
> to do anything with a VPN-ID attribute.  Devices that support only one VPN
> context would presumably ignore this.
> 
> Mark
> 
> At 01:27 PM 3/13/2003 -0800, Scott G. Kelly wrote:
> >Aside from the question of deferring this, I think there's a larger
> >question pertaining to whether the spec needs to solve this at all. I've
> >seen this problem (overlapping address space) solved by using
> >per-customer tunnels, and static nat'ing the private addresses at either
> >end when the customers want to interact (extranet scenarios). I really
> >don't see why everyone's ipsec implementation must be modified to
> >accommodate someone's aversion to per-customer tunnels.
> >
> >If I'm missing something, please let me know.
> >
> >Scott
> >
> >Michael Thomas wrote:
> > >
> > > Radia Perlman - Boston Center for Networking writes:
> > >  > 2) Why does it need to go into IKEv2?...because otherwise there's
> > >  > no way to route the packets, if the IP addresses in the customer
> > >  > nets overlap.
> > >
> > > This evades the real question. Why does this need
> > > to be part of the base spec? There's lots of world
> > > hunger that IKEv2 doesn't solve. Why can't this be
> > > deferred for later consideration, rather than an
> > > ill-advised last minute addition?  If IKEv2 does
> > > not lend itself to such additions, maybe we asking
> > > ourselves how we can make IKEv2 more amenable to
> > > these kinds of additions rather than loading up
> > > the kitchen sink blindly.
> > >
> > >             Mike