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

Re: Another field for traffic selector?



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




> 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


-- 
____________________________________________________________________________
Yu-Shun Wang <yushunwa@isi.edu>               Information Sciences Institute
                                            University of Southern California