Subject: RE: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]]

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 28 Dec 2004 20:02:24 -0800

Hi Steve,

As you said "such behavior by intermediate routers would tend to cause
havoc with the traffic anyway, so I would hope that this would not be a
common occurrence". 

Would we however want to put a comment regarding the same? The text to
add could be "Changing DSCP values en-route can result in different
class of packets on the same SA and SHOULD be avoided."

Sorry for the confusion caused.

Thanks,
Vishwas

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, December 28, 2004 9:21 PM
To: Vishwas Manral
Cc: Brian E Carpenter; Stephen Kent
Subject: RE: [Ipsec] Re: [Fwd: Review of
draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call
Documents]]

At 8:24 PM -0800 12/27/04, Vishwas Manral wrote:
>Hi Steve,
>
>I understand (and you have repeated the point) that at the receiver we
>do
>not use DSCP to demultiplex traffic. I was coming more from the point
>of the following: -
>
>"If different classes of traffic (distinguished by Differentiated
>Services CodePoint (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 QoS appropriately."
>
>If we are changing DSCP values en-route wouldn't we still have the
>issue
>"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."
>
>Thanks,
>Vishwas

I think I see what question you are trig to ask, although an example 
would have helped, vs. just repeating the quotes from 2401bis.

Assume two SAs between A and B, carrying traffic that exhibit the 
same traffic selectors but different DSCP values.  Call these SA1 and 
SA2, both going from A to B. Assume that these are tunnel mode SAs. 
The inner header has the original DSCP values, and the outer header 
has these values copied to it.

So, now we can look at what may happen due to changes in external 
DSCP values. For example, along the path from A to B, the DSCP value 
in the outer header of some of the packets on SA1 may be changed, but 
not on SA2. Or maybe both traffic streams have changes to the outer 
DSCP values. Such changes may cause traffic on an affected SA to 
arrive in a different order that the inner DSCP values would suggest, 
relative to the traffic on the other SA. But, since the traffic is 
carried on different SAs, this will not affect the sequence number 
checking that takes place on each SA separately.

However, if the DSCP values change for traffic carried on one of the 
SAs,  e.g., flipping back and forth in a way that causes some packets 
to speed along, and other packets to lag behind, then yes, that could 
cause problems for traffic on that SA. Severe packet reordering 
caused by inconsistent DSCP value changes applied to packets bound to 
a single SA could cause rejection of packets by the anti-replay 
mechanism.  However, even in the absence of IPsec, such behavior by 
intermediate routers would tend to cause havoc with the traffic 
anyway, so I would hope that this would not be a common occurrence.

Steve

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Wed, 29 Dec 2004 14:52:35 -0500

>Sorry for the confusion caused.

We could add an advisory statement that warns folks, e.g.,

"If significant reordering 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."

Steve