Subject: [IPsec] New draft about issues in alternative Traffic Selectors in IPSec/IKEv2

From: Greg Daley <[email-masked]>
Date: Sat, 4 Jul 2009 10:09:18 +1000

Hi, 

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

Please feel free to comment on this draft, or direct me to a more
appropriate venue.

The draft may be accessed at: 

http://tools.ietf.org/html/draft-daley-mpsec-traffic-sel-ps-00

Sincerely,

Greg Daley

_________________________________________________________________
Looking for a new car this winter? Let us help with car news, reviews and more
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 25 Jul 2009 19:14:59 +0300

> (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-masked]

---

From: Greg Daley <[email-masked]>
Date: Mon, 27 Jul 2009 14:57:17 +1000

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: [email-masked]
> To: [email-masked]
> CC: [email-masked]
> Subject: [IPsec] New draft about issues in alternative Traffic Selectors in IPSec/IKEv2
>
> Greg Daley writes:

_________________________________________________________________
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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 27 Jul 2009 11:20:09 -0400

At 2:57 PM +1000 7/27/09, Greg Daley wrote:
...

>the example is helpful.  I will remove the example for clarity.

As Tero noted, RFC 4301 provides a discussion of how an 
implementation can, on a local basis, deal with mapping traffic of 
different priorities to different SAs, without the need to define 
additional traffic selectors.  That's why it has not been seen as 
necessary to create traffic selectors for this purpose.

>more like your example with regard to protocol numbers.

The protocol number example refers to the fact that we cannot express 
protocol  number ranges in IKE, and that caused us to remove support 
for this feature from IPsec. IO agree with Tero that, going forward, 
we should require support for ranges of values for ALL new TS values 
that we define.

If you are asking whether IPsec supports a policy where the basis for 
protecting traffic is exclusively a DSCP, the answer is no. It also 
is not clear that the ability to do so is a real requirement.

Steve

---

From: Greg Daley <[email-masked]>
Date: Tue, 28 Jul 2009 09:22:16 +1000

Hi Steve, 

Thanks for your feedback.

We will add focus on the ability to provide expression of ranges, and hold off
on any DSCP related issues until there is a solid use case.

Greg

> Date: Mon, 27 Jul 2009 11:20:09 -0400
> To: [email-masked]
> From: [email-masked]
> CC: [email-masked]; [email-masked]
> Subject: Re: [IPsec] New draft about issues in alternative Traffic Selectors in IPSec/IKEv2
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

_________________________________________________________________
What goes online, stays online Check the daily blob for the latest on what's happening around the web
http://windowslive.ninemsn.com.au/blog.aspx