Subject: RE: Another field for traffic selector?

From: Mark Duffy <[email-masked]>
Date: Wed, 12 Mar 2003 18:35:31 -0500

Hi Radia and others,

I too would love to see a "VPN-ID" conveyable by IKEv2.

RFC 2685 style VPN-ID (7 bytes) would seem a fine format.

RFC 2547 Route Targets (8 bytes) are another possibility but given that RFC 
2547 allows them to be  a) different in one direction than in the other, 
and  b) not have a 1:1 correspondence to what Radia has dubbed "customer 
intranets, C1, C2, C3, C4", I suspect it would be difficult to use them.

Both types are (or can be) structured to be globally unique.
An encoding that could transparently carry either would probably be wise at 
this point.

On the question of verifying received packets to see that they match the 
VPN ID of the negotiated traffic selectors, this doesn't seem necessary to 
me, based on my motivations anyway :-).  Especially given that there is 
currently no VPN ID field in the AH/ESP packet to be verified.  The SPI can 
be used to deliver the received packets to the correct context, so this is 
an access control issue only.

Perhaps then VPN-ID shouldn't be a Traffic Selector at all but rather some 
other attribute that can be bound to an SA.  Sorry but I don't know enough 
about IKEv2 to know whether such a concept fits or not.  In my mind this 
would be analogous to the "Remote End ID" AVP in l2tpv3, which can be used 
to bind a VPN ID to an l2tp session at the time the session is 
created.  Just substitute "IPsec SA" for "l2tp session" to get the same 
ability with IPsec.

--Mark

---

From: Yu-Shun Wang <[email-masked]>
Date: Wed, 12 Mar 2003 16:40:21 -0800

Hi,

Some questions regarding the practice of VPN-ID inline.

Mark Duffy wrote:
> RFC 2547 Route Targets (8 bytes) are another possibility but given that 
> RFC 2547 allows them to be  a) different in one direction than in the 
> other, and  b) not have a 1:1 correspondence to what Radia has dubbed 
> "customer intranets, C1, C2, C3, C4", I suspect it would be difficult to 
> use them.
> 

But how is that "global uniqueness" established in the first place?
How is making sure that different VPNs using unique VPN-IDs different
than making sure they use non-overlapping private (virtual) IP addresses?

> An encoding that could transparently carry either would probably be wise 
> at this point.

A different aspect of this discussion is about the scope of IPsec or
IKE. The trend of "adding more fields for traffic selector" is like
chasing a moving target. We now have TCP/UDP port numbers. Why not
SCTP? Why not some other fields from some other transport protocols?
Why not IP src-dest for IP-IP packets? How about GRE? RDP? Pick your
favorite ones, they are all transport, aren't they?

If we want to do transport layer security, shouldn't we resort to
transport layer security protocols or mechanisms? Doing it in IP
not only violates layering, and we end up inventing firewall again,
only this time it's on routers (or "security gateways",) too!

Are we defining firewall inside IPsec in the disguise of "traffic
selectors"? If we are, it would not surprise me that advocates of
some other transport protocols will want to get on the "traffic
selector" thingy. (Well, we do IP-IP tunnels, so I think the
inner IP source-destination address pair should be part of the
"traffic selector", too. See how easy it is?)

Cheers,

yushun.

> VPN ID of the negotiated traffic selectors, this doesn't seem necessary 
> to me, based on my motivations anyway :-).  Especially given that there 
> is currently no VPN ID field in the AH/ESP packet to be verified.  The 
> SPI can be used to deliver the received packets to the correct context, 
> so this is an access control issue only.
> 
> Perhaps then VPN-ID shouldn't be a Traffic Selector at all but rather 
> some other attribute that can be bound to an SA.  Sorry but I don't know 
> enough about IKEv2 to know whether such a concept fits or not.  In my 
> mind this would be analogous to the "Remote End ID" AVP in l2tpv3, which 
> can be used to bind a VPN ID to an l2tp session at the time the session 
> is created.  Just substitute "IPsec SA" for "l2tp session" to get the 
> same ability with IPsec.
> 
> --Mark

-- 
____________________________________________________________________________
Yu-Shun Wang <[email-masked]>               Information Sciences Institute
                                            University of Southern California

---

From: Henry Spencer <[email-masked]>
Date: Thu, 13 Mar 2003 11:32:37 -0500 (EST)

On Wed, 12 Mar 2003, Yu-Shun Wang wrote:
> selectors"?

The IPsec SPD is deliberately meant as a specification of a minimal
firewall mechanism.  Firewalling is an important part of IP security,
after all.  (IPsec is more than just encryption, although encryption
tends to get most of the attention.)

                                                          Henry Spencer
                                                       [email-masked]

---

From: Mark Duffy <[email-masked]>
Date: Thu, 13 Mar 2003 13:14:32 -0500

>But how is that "global uniqueness" established in the first place?

Through a (hierarchical) regime of number assignment.

>than making sure they use non-overlapping private (virtual) IP addresses?

The customers of the sort we are talking about here are *already* using 
overlapping addresses.  Unique VPN-IDs can be applied now, after the fact 
so to speak, to create unique (VPN-ID + IP address)s.  Not only does it let 
them continue to use the addresses they are using, it lets them continue to 
have private to themselves the complete address space they have now.

>favorite ones, they are all transport, aren't they?

As far as your question here about IPsec supporting selectors for TCP, UDP 
and not for other protocols, I'll leave that to others.  The current issue 
about VPN ID is about something else entirely.  It is a about when there 
are multiple independent contexts of (TCP, UDP, whatever over) IP and we 
want to bind an SA to one of those contexts.

---

From: Lars Eggert <[email-masked]>
Date: Thu, 13 Mar 2003 10:49:23 -0800

Mark Duffy wrote:
> overlapping addresses.  Unique VPN-IDs can be applied now, after the 
> fact so to speak, to create unique (VPN-ID + IP address)s.  Not only 
> does it let them continue to use the addresses they are using, it lets 
> them continue to have private to themselves the complete address space 
> they have now.

The notion of VPN ID seems to be tied to the PPVPN view where your VPNs 
start and end at the first-hop gateway, and hosts connected to it are 
part of only one VPN at a given time. Routers have to change to support 
  VPN IDs (but that may be OK), current host implementations just work.

Once you extend the notion of VPN to include both hosts and routers, 
i.e. when your hosts can be part of more than one VPN at any given time, 
  EVERY node will need to be modified to understand VPN IDs. This is 
when the VPN ID becomes equivalent to an extended, unique, globally 
managed address space.

Lars
-- 
Lars Eggert <[email-masked]>           USC Information Sciences Institute

---

From: Yu-Shun Wang <[email-masked]>
Date: Thu, 13 Mar 2003 12:04:30 -0800

Mark Duffy wrote:

<snip>

(The part about the usage scenario probably belongs to ppvpn
  mailing list.)

> As far as your question here about IPsec supporting selectors for TCP, 
> UDP and not for other protocols, I'll leave that to others.  The current 
> issue about VPN ID is about something else entirely.  It is a about when 
> there are multiple independent contexts of (TCP, UDP, whatever over) IP 
> and we want to bind an SA to one of those contexts.

That may be true, but if the proposed solution is to "ADD" another
field to the IPsec traffic selector (can we call it IPsec-firewall?),
the my question stands: are we opening the door to let other
IP options and/or transport protocol fields to be considered
for IPsec traffic selectors? IMHO, this not only affects IKE, the
implication affects IPsec (2401bis?) as a whole.

yushun.