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

From: Brian E Carpenter <[email-masked]>
Date: Sun, 02 Jan 2005 10:41:34 +0100

Stephen Kent wrote:
> At 8:02 PM -0800 12/28/04, Vishwas Manral wrote:
> 
>> 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
> 
> 
> 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

This is certainly reasonable.

Let's try to construct an example where it
might conceivably happen: a video stream with two types of packet, i.e.
coarse and fine resolution. A possible reason for varying the DSCP
is to favor the coarse packets under congestion, so that they get
through promptly even if the fine detail is lost. But for that to happen
en route requires deep packet inspection (of non-encrypted packets) by a
device that magically knows that the data packets are a video stream. This
seems pretty unlikely. The normal scenario is that it's the video source
itself that marks the coarse and fine packets appropriately - and that
would lead to two SAs, not to an SA with a varying DSCP value.

     Brian

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