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

Re: Another field for traffic selector?




----- Original Message -----
From: "Radia Perlman - Boston Center for Networking" <Radia.Perlman@sun.com>
To: <ipsec@lists.tislabs.com>
Sent: Tuesday, March 11, 2003 2:15 PM
Subject: Another field for traffic selector?


> Sorry Charlie... (for what I'm about to bring up)
>
> 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.
> Other protocols need to solve this problem. The "VLAN tag"
> is used in 802. "Partition ID" is used in infiniband. I've
> heard the name "virtual router ID" for something, but I think
> that's a terrible name (since it's a virtual net, not a virtual
> router). If anyone can suggest an already-recognized name
> for this concept, an already-recognized size of the field,
> and an already-recognized numbering scheme, we should adopt it.
> Otherwise, I'd suggest the name "virtual net", size 2 bytes,
> and a numbering scheme that is local to F1 and F2 (someone
> would configure it compatibly at the two ends and map it
> to specific customer nets).
>
> So, there are two issues:
> a) I think we need to add this field to the traffic selector in IKE

While this is a very useful feature for the reasons you describe the thing
that bothers me is..

How are the packets coming out of a tunnel verified to ensure they match the
negotiated virtual net?

Virtual net field is negotiated along with the traffic selectors. However a
packet arriving in a SA can only be verified for a match with the traffic
selctor information since there is no information about the Virtual net
field in the packet. The only information available is the SA on which the
packet arrived. It implies the peer has to be trusted to send the packet in
the right tunnel for the negotiated virtual net. This seems to be at odds
with a long thread of arguments that occurred in the past regarding  strict
verification of SA selector information for packets coming out a tunnel.

Or am I missing something? Is Virtual net field expected to be part of ipsec
headers also?

-- sankar --

> b) If at this late date extra things (this plus the uniquifier)
> are coming up as needing to be in the traffic selector, perhaps
> the encoding of traffic selector should be more flexible, so
> that new fields can be added in the future.
>
> Radia
>
>
>