Re: Another field for traffic selector?

[Lars Eggert <larse@xxxxxxx>]

Radia Perlman - Boston Center for Networking wrote:
> I was just talking to someone about some routing thing,
> and realized that IPsec might need another traffic selector
> field, for "virtual network number".
>
> Suppose you have several customer intranets, C1, C2, C3, C4,
> all using local IP addresses, so there's no way to distinguish
> traffic based on IP addresses, ports, or protocol types.
>
> And you have two firewalls F1 and F2 that are providing VPN
> service to different offices of customers C1, C2, C3, C4.
>
> These customers are not talking to each other. They are only
> talking between their own nodes, but they are all utilizing
> IPsec tunnels between F1 and F2.
>
> What would solve the problem is for F1 and F2 to create 4 different
> SAs, one for each of C1, C2, C3, and C4. But they have to negotiate
> which is which. So if there were another traffic selector field for
> "virtual network", 4 different child-SAs could be created, and
> F2 then would know, when it received a packet, which customer net
> it belonged to based on which SA it was received on.
>
> I'm not sure what to call it, or what size it ought to be.

This is very similar to the VPN ID that was proposed a while ago.

Adding a VPN ID of N bits is equivalent to increasing the address space 
by N bits. The VPN ID will still need to be globally unique, otherwise a 
site may be connected to two VPNs that happen to use the same VPN ID and 
address space, resulting in the same issues they have now.

Making sure that VPN IDs are unique for all overlays connected to a site 
is the same overhead as making sure that their address spaces do not 
overlap, which makes VPN IDs seem rather ineffective.

(I'm ready to be convinced otherwise.)

Lars
--
Lars Eggert <larse@xxxxxxx>           USC Information Sciences Institute

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature