At 4:27 PM +0530 3/25/09, Prabhat Hegde wrote:
Hi,
In case we do QOS re-ordering (caused due to shaping &
queueing) for traffic classes after encryption, the encrypted pkts
get re-ordered thus changing the order of sequence numbers. At the
receiving end, such out-of-order pkts are droped by IPsec since they
do not fall under the anit-replay window range.
Is there any proposed solution/draft which caters to this
problem? If yes, it would be great if someone can point me to it.
--
With regards,
Prabhat
I agree with Frances's reply; we made explicit provisions for this in 4301:
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.
Steve
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
