In your previous mail you wrote:
- *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
=> in my English "before" is the opposite of "after", i.e., you are
clearly in the second case.
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.
=> queueing and shaping are done according to some kind of packet
classification: there is nearly nothing usable to perform classification
of encrypted packets. So what you say doesn't make sense for me.
- *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.
=> yes, they are the IPsec SAs on which traffic will be sent.
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.
=> please read the messages (*) you receive before arguing...
The issue you believe you discovered was already addressed: IPsec works
perfectly with (and without) QoS. The only concerns I ever saw about this
was about the fact QoS handling is a covered channel (some communities
are very paranoid about covered channels :-).
[email protected]
PS: (*) mine and Steve Kent's.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
