[Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-12: (with DISCUSS)

[Magnus Westerlund via Datatracker <[e-mail]>]

Magnus Westerlund has entered the following ballot position for
draft-ietf-detnet-mpls-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I like to thank  TSV-ART reviewer Michael Tüxen for helping me consider one
aspect of the issue I see needing some discussion for this document.

Updated and extended discuss to clarify the issues I see. Please note that D
below is new and a consequence in my trying to clarify C. why it matters.

A. The need for latency bounding the POF to enable the MPLS S-Label path to be
bounded if reordering protection service is needed.

To my understanding in an MPLS network the controller can determine an upper
bound of the latency for a path by adding together the path latencies, the
packet buffer depths based on the forwarding behavior applied, and the POF
buffer depth. However, as currently described it is not made clear that the POF
needs to have a configuration for an upper bound of how long a packet may
maximum remain in the buffer since arrival. This requirement is somewhat
discussed in

So https://datatracker.ietf.org/doc/draft-ietf-detnet-data-plane-framework/:

3.5.2.2.  Path Differential Delay

   In the preceding example, proper working of duplicate elimination and
   reordering of packets are dependent on the number of out-of-order
   packets that can be buffered and the delay difference of arriving
   packets.  DetNet uses flow-specific requirements (e.g., maximum
   number of out-of-order packets, maximum latency of the flow) for
   configuration of POF-related buffers.  If the differential delay
   between paths is excessively large or there is excessive mis-ordering
   of the packets, then packets may be dropped instead of being
   reordered.  Likewise, PEF uses the sequence number to identify
   duplicate packets, and large differential delays combined with high
   numbers of packets may exceed the ability of the PEF to work
   properly.

So this configuration needs to be required on the MPLS POF implementation to
enable the controller to bound the latency between ingress and egress when POF
is used. And it needs to be done in time, per the below paragraph.

So given that the buffer is specified in either bytes or simply packets to be
buffered will result in that the POF buffering time becomes packet flow
dependent and not bounded in time. So if you make the calculation for a DETNET
flow thinking it will send 500 packets per second evenly spaced. Then the a
buffer of 5 packets would represent an upper limit 1/100th of second. If then
the flow sends only 100 packet per second then suddendly the 5-packet buffering
would represent 1/20th of a second. Thus defining it in packets or size doesn't
work, the upper buffering time needs to be defined in time to provide a bounded
latency.

I would note that soley configuring an upper bound between arrival in POF
buffer until latest release is more fragile than actually having actual
timestamp applied at egress to each packet. But, it can ensure bounded delay as
long as the other functions do keep to their boundary.

However, I think the solution here is to clarify the configuration requirement
on the POF in Section 4.2.2.3.

B. On the relation of the PEF to the POF.

The document does not discuss this, and maybe this is fairly obvious but a
relation ship exists. The PEF state needs to be deeper than the POFs when both
are used. Otherwise duplicates may be forwarded. If the PEF is at least as deep
as the POF, then any duplicate that is more out of order than what the POF
allows will be discarded. However, as the POF is not that explicitly specified,
even if the information document do define that is what should be done.

I would recommend that the text is made more clear on this relationship and
also are explicit about the discard of out of order in the POF.

C. On the implementation details of the PEF and POF in regards to how they
accept packets.

So the PEF is likely implemented with a basic data structure which tracks the N
latest received packets and keep state if these packets have been seen or not.
However, an important implementation detail for this is how this handles when a
packet received are significantly higher than previous seen. So does that
result in that highest seen are advanced forward to this value? So the 16-bit
and 28-bit sequence numbers define a circular space. I assume one tracks the
highest sequence number received (H_SN). Based on that one usually consider
packets in the range [(H_SN-2^15) MOD 2^16, HSN-1] as older packets not
updating the H_SN (for 16-bit sequence numbers) and can consider packets in the
range [H_SN+1, H_SN + 2^15-1] as newer. However as N (number of actually
tracked packets) are only a sub-set of the fully sequence number the PEF will
consider a packet that falls into the range of older packets but outside of the
N packets where one have state as to old, and will discard as one lack
information about if it is a duplicate or not.

As you may seen this implementation would cause packet loss in the event that
packets for this S-Label has passed the ingress and the PRF have put in
sequence number and duplicating them and then the packet have been lost due to
failure in forwarding the traffic. Then when the network have recovered from
this failure there are a significant risk that the packets are outside of the
window of validity that would trigger the H_SN to be updated and instead cause
all packets to be dropped.

Thus in case of failures there appear to exist a need to be able to reset this
state and require the sequence number that is current. And if the details of
how these filters are impelementation specific and do not use the ranges I
specify the controller would have to potentially cause a reset of the functions
for any disturbance as the impact is unknown.

Maybe this is a minor risk in this environment, but the need to reset the POF
and PEF state appears necessary for recovery.

D. Denial of service risk with attacker modifying sequence number or performing
packet injection between ingress and egrees.

Based on what is written in C I would also note that there exist a serious
Denial of Service attack on the Detnet flow.

If the attacker is capable of either periodically modify the sequence number of
an MPLS packet for a particular S-label or inject a MPLS packet into the system
that will traverse to the S-Labels PEF or POF at egress with a crafted sequence
number. In either of these cases the attacker can advance the acceptance window
periodically so that the actual traffic falls into the range that is discarded
by the PEF and POF. Thus, cheaply accomplishing a total denial of service.

I think this risk due to the PEF and POF should be made explicit in the
security considerations. Mitigations needs to be in place to prevent packet
modification or injection inside the MPLS network. Some of these appears to be
already discussed.