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

From: [email-masked]
Date: Wed, 29 Dec 2004 09:31:00 -0500

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

Not in that form - the proposed text is too broad.  There are a number
of situations in which DSCP values need to be changed en-route in a
fashion that does not affect packet ordering - AF drop precedence
remarking, and changing domain-specific DSCP usage when a tunnel
crosses a diffserv domain boundary are two examples.

The real concern here is not just DSCP changes, but rather that
the anti-reply mechanism is (deliberately) not designed to support
significant packet reordering within a single SA, hence reordering
(from whatever cause) should be avoided and minimized if unavoidable.
As Steve noted, significant reordering "would tend to cause havoc with
the traffic anyway" - in particular, TCP is likely to react poorly.

It ought to be obvious that significant packet reordering within a
single SA will interact poorly with the small windows used for
anti-replay.  I'm not opposed to adding a statement to this effect,
but as it expresses a requirement on network elements other than
the IPsec implementation, an RFC 2119 "SHOULD" is not appropriate -
a lower case "should" ought to be used instead.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Vishwas Manral
> Sent: Tuesday, December 28, 2004 11:02 PM
> To: Stephen Kent
> Cc: [email-masked]; Brian E Carpenter
> Subject: RE: [Ipsec] Re: [Fwd: Review of 
> draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last 
> Call Documents]]
> 
> 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
> 

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

---

From: "William Dixon" <[email-masked]>
Date: Wed, 29 Dec 2004 10:06:07 -0800

Perhaps also add a comment that "If DSCP marking or remarking of IPsec
packets is performed, attention must be given to also marking IKE packets
appropriately to ensure successful negotiation of new IPsec SA pairs prior
to the expiration of current IPsec SA lifetimes."

> On Behalf Of [email-masked]
> Sent: Wednesday, December 29, 2004 6:31 AM
> To: [email-masked]
> Cc: [email-masked]
> Not in that form - the proposed text is too broad.  There are 
> a number of situations in which DSCP values need to be 
> changed en-route in a fashion that does not affect packet 
> ordering - AF drop precedence remarking, and changing 
> domain-specific DSCP usage when a tunnel crosses a diffserv 
> domain boundary are two examples.
> 
> The real concern here is not just DSCP changes, but rather 
> that the anti-reply mechanism is (deliberately) not designed 
> to support significant packet reordering within a single SA, 
> hence reordering (from whatever cause) should be avoided and 
> minimized if unavoidable.
> As Steve noted, significant reordering "would tend to cause 
> havoc with the traffic anyway" - in particular, TCP is likely 
> to react poorly.
> 
> It ought to be obvious that significant packet reordering 
> within a single SA will interact poorly with the small 
> windows used for anti-replay.  I'm not opposed to adding a 
> statement to this effect, but as it expresses a requirement 
> on network elements other than the IPsec implementation, an 
> RFC 2119 "SHOULD" is not appropriate - a lower case "should" 
> ought to be used instead.
> 
> Thanks,
> --David
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Vishwas Manral
> would not be 
> > a common occurrence".
> > >issue "if the receiver is employing the optional 
> anti-replay feature 
> > 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.
> > 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 
> > 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