Re: Another field for traffic selector?

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

Hi Radia,

I gather my last post hadn't yet propagated through the list when you
composed this. I get it now. I think there are other ways to handle this
(e.g. routing encapsulation by the gateways), but I can see where folks
might like a solution with lower overhead. 

Sorry if I seemed dense.

Scott


Radia Perlman - Boston Center for Networking wrote:
> 
> When traffic is going from one part of the customer's
> intranet to another (as opposed to talking to a
> node off the intranet) there's no natting. A locally
> significant IP address is simply forwarded across
> to the other part of the intranet.
> The firewalls are just creating an "internal" wire
> on behalf of the customer nets. The issue is
> what happens if the same
> pair of firewalls are creating multiple internal
> wires for multiple customers. You can have two
> conversations going on, each looking, to IP,
> like the same locally significant IP addresses.
> 
> If there is some way to tell what "wire" things
> are coming on, as for instance if they are
> different MPLS tunnels, then there's no problem.
> But if they are forwarding simply with IP, then
> without this way of negotiating on SA creation,
> I don't see how the firewalls can do this.
> 
> Radia
> 
> "Scott G. Kelly" <scott@airespace.com> 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?
> >