On 10 April 2017 at 10:56, Peltonen, Janne (Nokia - FI/Espoo) <[email protected]> wrote: > 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 That seems like very small window(s). I understand the simplicity enabled by such small windows but is it really enough for modern high speed networks with multiple L2/L3 switch/router hops (possibly with some link aggregation in there as well).
> 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. The receiver should be able to adapt the size of antireplay window by monitoring the amount of (supposedly) stale packets (SN's). Has such a design been tried? Do you have any "quality" requirements here, how large proportion of packets is allowed to be dropped due to limited size of antireplay window? I assume there are higher level SLA's that control packet loss, perhaps it is up to the service provider to use that packet loss budget as it sees fit. > >> > 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. If order restoration adds latency, it can definitively do harm. And even if it could be done without adding latency (e.g. in some queue), we don't know if the SN order is the "real" order and order restoration actually is beneficial. > > 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. Well you could consider (parts of) the IPsec GW itself to be part of the network... Where does the network start? You can consider the transmitting NIC or the cables the start of the network but what if you have link aggregation with independent NIC's? The network must have started at some earlier shared point where there is an unambiguous packet order. Is there always such a point? > > 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. Isn't it really the sending IPsec GW's *ingress* order that is interesting? Ideally IPsec SN allocation and then egress (transmission) order follows the ingress order. The SN cannot be allocated until the proper SA has been identified so there is some potential for early reordering (unless atomic queue or ordered queue+ordered lock is used). Reordering between SN allocation and egress can be considered "part of the network". Sometimes reordering can be beneficial (prioritise packets with low-latency QoS), sometimes it can be detrimental (reorder packets for the same (layer-4) flow which may confuse the terminating node). > >> 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. Make the window bigger. And bigger. And bigger.. > > Janne > >
