Re: Another field for traffic selector?

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

Okay, I think I understand a bit better now. In the case where customers
don't have access to one another's networks, you will not want (or need)
to nat traffic. However, I think Sankar's point is an important one: the
provider must strictly control the boxes at both ends, or else you lose
the access controls provided by ipsec, and are open to spoofing attacks.
As an aside, I believe that some vendors support a "virtual router"
concept which might permit the tunnels to be handled independently, but
I'm not sure if this would work for your scenario or not.

Scott

Mark Duffy wrote:
> 
> Hi Scott,
> I'm not sure if I understand what you mean but let me try to answer.
> 
> I think you are assuming that the plaintext packets would be NAT'ed before
> they arrive at the "shared" security gateway.  I think this is an incorrect
> assumption, at least for the types of scenarios I envision.  Plenty of
> people won't want NATs in the middle of their private intranets - it breaks
> too many things.  The other suggestion, encapsulating the plaintext packets
> before they arrive at the "shared" security gateway, seems to me equally
> improbable.
> 
> The problem we are trying to solve here IMHO is where some sort of service
> provider is providing security gateway services to multiple independent
> customers, using a shared IPsec box.  But the customers will want it to
> work just as transparently as if they were being served by a dedicated
> IPsec box.  This transparency is not consistent with placing extra NAT or
> encapsulation boxes in the path.
> 
> -Mark
> 
> At 05:54 PM 3/13/2003 -0800, Scott G. Kelly wrote:
> >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