Re: Another field for traffic selector?

[Yu-Shun Wang <yushunwa@ISI.EDU>]

Mark Duffy wrote:

<snip>

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

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

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.



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