Re: Another field for traffic selector?

[Mark Duffy <mduffy@quarrytech.com>]

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