Greg Daley writes: > A new draft has been published regarding the use of non-traditional > traffic selectors in IPsec. This document discusses some of the > issues of relevance if one is to define new Traffic Selectors > (TS Type other than 7 and 8).
I quickly read the draft, but as it didn't seem to have any actual protocol content, it is hard to give any direct feedback. The first example using Diffserv is completely bogus, and does not need any changes to the traffic selectors we already have, as IPsec architecture asnd IKEv2 already supports that. Traffic selectors are only needed if the responder is REQUIRED to check that the incoming traffic matches the traffic selectors. This is not the case of the diffserv. If implementations does what RFC4301 document describes in section 4.1 i.e. put different QoS levels to different SAs, there will not be loosing of packets or packet reordering. The responder does not need to know which SA is picked for which traffic to process them correctly and everything will just work. For returninging traffic other end picks again some different SA for different QoS levels, and the selection can be different than what was in other direction and everything still works, as replay windows etc are separate in each direction. Here is relevant text from RFC4301: ---------------------------------------------------------------------- If different classes of traffic (distinguished by Differentiated Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the same SA, and if the receiver is employing the optional anti-replay feature available in both AH and ESP, this could result in inappropriate discarding of lower priority packets due to the windowing mechanism used by this feature. Therefore, a sender SHOULD put traffic of different classes, but with the same selector values, on different SAs to support Quality of Service (QoS) appropriately. To permit this, the IPsec implementation MUST permit establishment and maintenance of multiple SAs between a given sender and receiver, with the same selectors. Distribution of traffic among these parallel SAs to support QoS is locally determined by the sender and is not negotiated by IKE. The receiver MUST process the packets from the different SAs without prejudice. These requirements apply to both transport and tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in question appear in the inner IP header. In transport mode, the DSCP value might change en route, but this should not cause problems with respect to IPsec processing since the value is not employed for SA selection and MUST NOT be checked as part of SA/packet validation. However, if significant re-ordering of packets occurs in an SA, e.g., as a result of changes to DSCP values en route, this may trigger packet discarding by a receiver due to application of the anti-replay mechanism. ---------------------------------------------------------------------- So the first example does not require any changes to the traffic selectors. The second example about using MPLS label stack entry as traffic selector would be correct use of creating new traffic selector, in which case the new MPLS specific traffic selector could be created. The current document does not list any format for it. When defining traffic selectors it should be noted, at as RFC4301 supports decorrelated policies all the traffic selectors should be such that they can be used to express full ranges. The current traffic selectors are not doing that and that has caused problems as there is no way to explain hole without lots of entries. I.e. if you have two overlapping traffic selectors which one is very specific (down to ip, protocol and port) and other is more generic (for example any port) the current traffic selector set cannot efficently express that, as the more generic traffic selector will have one hole in the middle, and as formats 7 and 8 do not have protocol ranges, there is no way to efficiently express protocols 0 .. n-1 and n+1 .. 255. This SHOULD NOT be repeated in any new traffic selectors. All new traffic selectors should have ranges for all fields. I do not think the current document yet "extendes traffic selectors to allow more generic definitions of interesting traffic", as it does not define any actual formats yet. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
