Re: Another field for traffic selector?

[Mark Duffy <mduffy@quarrytech.com>]

At 04:40 PM 3/12/2003 -0800, Yu-Shun Wang wrote:
>Hi,
>
>Some questions regarding the practice of VPN-ID inline.
>
>Mark Duffy wrote:
>>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.
>
>But how is that "global uniqueness" established in the first place?

Through a (hierarchical) regime of number assignment.

>How is making sure that different VPNs using unique VPN-IDs different
>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.


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

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.


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