Subject: Another field for traffic selector?

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Tue, 11 Mar 2003 17:15:51 -0500 (EST)

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
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

---

From: "sankar ramamoorthi" <[email-masked]>
Date: Tue, 11 Mar 2003 23:40:01 -0800

----- Original Message -----
From: "Radia Perlman - Boston Center for Networking" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 11, 2003 2:15 PM
Subject: Another field for traffic selector?

> 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 --

---

From: [email-masked]
Date: Wed, 12 Mar 2003 09:18:44 +0100

> to specific customer nets).

For some VPN approaches, the PPVPN WG refers to the "Virtual Private
Networks Identifier" defined in RFC 2685.

> a) I think we need to add this field to the traffic selector in IKE

1. I support this idea, and 
2. if it is accepted by the ipsec community, I propose to allign with
the ppvpn wg.

thanks,
Jeremy.

---

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 12 Mar 2003 09:15:37 -0800

Hi Radia,

I'm a little confused about this (sorry, not a ppvpn person). I have
some questions interspersed below.

> traffic based on IP addresses, ports, or protocol types.

I don't have a clear picture of this in mind. Are you saying that the
customers are using overlapping private address spaces, e.g.

C1: 10.1.1.0-10.1.2.255

C2: 10.1.1.0-10.1.1.255

C3: 10.1.2.0-10.1.2.255

C4: 10.1.1.0-10.2.1.255

or do you mean something else?

> service to different offices of customers C1, C2, C3, C4.

This leads me to think of implementations which sit just inside the
cloud between the customer networks - is this what you mean?

Thanks for your indulgence,

Scott

---

From: Michael Thomas <[email-masked]>
Date: Wed, 12 Mar 2003 11:46:40 -0800 (PST)

Radia,

This strikes me as opening Pandora's box and then
some. There are many possible ways that you might
want to influence traffic on the egress side of
the tunnel including VLAN's as you mention, but
also MPLS and other fell creatures. Also: this
seemingly overlaps with other ways of signaling in
the QoS domain (RSVP) which is another way of
thinking about this problem.

My big question is this: why does it need to go
into IKEv2 instead of considering it separately?
At the very least, the requirements would need to
be fleshed out and that sounds like a very deep
rathole.

		Mike

---

From: Lars Eggert <[email-masked]>
Date: Wed, 12 Mar 2003 09:54:17 -0800

> 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 <[email-masked]>           USC Information Sciences Institute