[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Another field for traffic selector?

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 Eggert <larse@xxxxxxx>           USC Information Sciences Institute

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