Hi Tero, Thanks for your feedback. As you pointed out, there are no formats defined in this document (and perhaps the Abstract needs to be updated to reflect that).
At this stage, we were much more interested in getting feedback as to which problems are real and solvable. Apologies about misleading with respect to the DSCP example. I think what I was trying to identify with DSCP is that there's an underlying lack of expression of QoS related policy in the existing Traffic Selectors, which mismatches the expression permissible in some SPDs. Your reference to 4301 regarding the use of multiple parallel SAs solving the example is helpful. I will remove the example for clarity. My feeling is that the selectors cannot express the case where specific traffic is to be encrypted/authenticated and others are not though. For example, if EF and AF31 are to be encrypted but other data is to travel clear. Do you think this is sufficiently covered by the current definitions? This seems more like your example with regard to protocol numbers. I will try to cover your concerns on ensuring decorrelated selectors in the next revision. With respect to defining formats, we will probably look at a separate follow up document to identify any specific Traffic Selectors. This would probably be clearer. Please let me know if you think the definitions should be held within this document instead. Thanks again, Greg Daley ---------------------------------------- > Date: Sat, 25 Jul 2009 19:14:59 +0300 > From: kivi...@iki.fi > To: hosk...@hotmail.com > CC: ipsec@ietf.org > Subject: [IPsec] New draft about issues in alternative Traffic Selectors in > IPSec/IKEv2 > > 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. > -- > kivi...@iki.fi _________________________________________________________________ View photos of singles in your area Click Here http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau%2Fsearch%2Fsearch%2Easpx%3Fexec%3Dgo%26tp%3Dq%26gc%3D2%26tr%3D1%26lage%3D18%26uage%3D55%26cl%3D14%26sl%3D0%26dist%3D50%26po%3D1%26do%3D2%26trackingid%3D1046138%26r2s%3D1&_t=773166090&_r=Hotmail_Endtext&_m=EXT _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
