Hi,
Ola Liljedahl <mailto:[email protected]> wrote:
> Peltonen, Janne (Nokia - FI/Espoo) <mailto:[email protected]> wrote:
> > In an IPsec GW (as a use case example) one might want to do all
> > stateless processing (like ingress and egress IP processing and the
> > crypto operations) in ordered contexts to get parallelism, but the
> > stateful part (replay-check and sequence number generation) in
> > an atomic context (or holding an ordered lock) so that not only
> > the packets are output in ingress order but also their sequence
> > numbers are in the same order.
>
> To what extent does IPsec sequence number ordering have to equal actual
> transmission order? If an IPsec GW preserves ingress-to-egress packet order,
> does it matter that this order might not be the same as the IPsec sequence
> number order? If IPsec SN's are not used for reordering, just for replay
> protection, I don't see why the two number series have to match.
The sequence numbers of course do not need to fully match the transmission
order because the anti-replay window mechanism can tolerate out-of-sequence
packets (caused either by packet reordering in the network or by sequence
number assignment not quite following the transmission order.
But assigning sequence numbers out of order with respect to the packet
order (which hopefully stays the same between the ingress and egress of
an SGW) eats into the out-of-sequence tolerance budget (i.e. the window
size at the other end) and leaves less of the budget for actual
reordering in the network.
Whether out-of-sequence sequence number assignment is ok or problematic
depends on the peer configuration, network, possible QoS induced
packet reordering and the magnitude of the possible sequence number
(not packet) reordering with respect to transmission order in the sender.
Often the antireplay window is something like 32 or 64 packets and maybe
not all of that can be used by the IPsec sender for relaxed ordering of
the sequence number assignment. One issue is that the size of the replay
window is not negotiated so the sender cannot tell the receiver that
a bigger window than normal is needed.
> > That said, some might argue that IPsec replay window can take care
> > not only of packet reordering in the network but also of reordering
> > inside an IPsec GW and therefore the atomic context (or ordered lock)
> > is not necessarily needed in all implementations.
>
> Do you mean that the replay protection also should be responsible for
> end-to-end (IPsec GW to GW) order restoration?
No, I do not mean that and I think it is not in general correct for
an IPsec GW to reorder received packets to the sequence number order.
What I mean (but formulated sloppily) is that the window mechanism of
replay protection can tolerate out-of-sequence sequence numbers to some
extent even when the cause is not the network but the sending IPsec GW.
So, depending on the implementation and on the circumstances, one might
want to ensure that sequence number gets assigned in the transmission
order or one might decide not to worry about it and let the window
mechanism in the receiver handle it.
> It would be great if each QoS class would have its own IPsec SA but
> is that always the case?
Yes it would and that is what the RFC suggests but it is not often
the case. And since some antireplay window needs to be left for
QoS-caused out-of-order tolerance, it may not always be a good idea
to have the sender essentially consume a big chunk of the window even
before the IPsec packets enter the network.
Janne
