Hi Francis,
- *after encryption there should be no reason to classify (then
reorder) packets in different ways *
-> There are two cases here:
1. QOS policies being applied on the logical tunnel interfaces
Here, classification & marking take place before the crypto
accelerator & the actual queueing & shaping of the resulting encrypted pkts
happen on the physical interface facing the ISP. For queing & shaping to
happen before the crypto engine we would have to change the driver code,
equip the h/w accelerator with different set of queues, etc since the crypto
engine serves mulitple interface each which can hold different QOS policies.
2. QOS policies being applied on the physical interface (or in addition to
the one being applied in the logical interfaces)
Here pkts destined to the physical interface matching an ipsec ruleset
have to proceed to the crypto engine & then back to the physical interface
after encryption.
So in both of the above cases, the queueing & shaping happen on the
physical interface which would cause re-ordering of encrypted pkts.
- *before encryption you can setup with IKEv2 different SAs between the
same end-points and then apply different QoS.*
You mean IPSec SAs here. I am taking a look into this. But I must see how it
affects the existing scalability.
*In both cases the anti-replay window should not drop "old packets" from QoS
reordering.*
Work around would be to increase the size of the replay window, but I
feel this is not a clean solution.
On Wed, Mar 25, 2009 at 8:04 PM, Francis Dupont
<[email protected]>wrote:
> 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 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.
>
> => this issue is well known in the IPsec community but:
> - after encryption there should be no reason to classify (then reorder)
> packets in different ways
> - before encryption you can setup with IKEv2 different SAs between the
> same end-points and then apply different QoS.
> In both cases the anti-replay window should not drop "old packets" from
> QoS reordering.
>
> Regards
>
> [email protected]
>
--
With regards,
Prabhat
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
