[IPsec] is there any proposed solution to solve the anti-replay problem for IPsec pkts when subject to QOS classification

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-repl

Re: [IPsec] is there any proposed solution to solve the anti-replay problem for IPsec pkts when subject to QOS classification

RFC 4306 specifically requires implementations to support multiple parallel child SAs. If you use a different SA for each QoS class, you should not have problems with the replay window From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Pr

Re: [IPsec] is there any proposed solution to solve the anti-replay problem for IPsec pkts when subject to QOS classification

In your previous mail you wrote: 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

Re: [IPsec] is there any proposed solution to solve the anti-replay problem for IPsec pkts when subject to QOS classification

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

[IPsec] Slides uploaded

Hi, The Friday meeting's agenda, as well as (almost all) the slides are available at http://tools.ietf.org/wg/ipsecme/agenda. Thanks, Yaron smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org