Ola Liljedahl [mailto:[email protected]] wrote:
>
> 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).
Maybe it is, maybe it isn't. But in the spirit of being conservative
in what one sends to the network, it would not be so nice to have an
implementation that puts additional requirements like bigger
windows to the peers compared to an implementation that does not.
>
> > 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?
I am not aware of any such implementation (which does not mean that
they do not exist).
> 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?
No, ingress order is not relevant for sequence numbers. Sequence numbers
should follow the transmit order or at least try to be close to it to
minimize the required additional window at the peer, regardless of whether
the packets themselves got reordered prior to sequence number assignment.
Of course, one also wants to have the transmit order be the same as receive
order.
> 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).
Yes. And I think this discussion started from the point that there are
potentially important use cases for switching from ordered to atomic
contexts in ODP.
> Reordering between SN allocation and egress
> can be considered "part of the network".
>
Yes, but it is still undesirable.
> 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..
I can wish that, but sometimes the peer devices cannot be easily updated
or even reconfigured just because my new shiny IPsec GW wants to optimize
throughput by relaxing the order of sequence number assignment. So at least
I would want the option to turn some knob to trade some throughput for
more in-sequence sequence numbers in those cases where I cannot simply
enlarge the windows.
Janne
