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

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Thu, 10 Sep 2020 06:23:45 -0700

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.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Sep 2020 14:37:41 +0100

> On 10 Sep 2020, at 14:23, Magnus Westerlund via Datatracker <[email-masked]> wrote:
> 

Where the s/n is provided outside the MPLS domain, the security issues are by definition outside the scope of this text.

Once inside the MPLS domain the normal MPLS security rules and constrains apply. An attacker inside the MPLS domain can do many things to harm the network, of which this is just one. MPLS operators know that they need to secure their network dataplanes and control planes, but but they also know that no packet gets to enter their network without their explicit permission.

There is the potential for similar threats to pseudo wires, (interference with in flight packets) but no such issue has ever been reported to the PWE3/PALS WGs.

So I think that this is at best one of many theoretical attacks that could occur, but is unlikely to ever materialise in a practical network.

- Stewart

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 11 Sep 2020 19:44:23 -0700

Hi Stewart, Magnus,

> So I think that this is at best one of many theoretical attacks that could occur, but is unlikely to ever materialise in a practical network.

I agree -- an attacker that could inject a sequence number would have to be
able to control the contents of one or more labels, which would cause much
bigger problems than DoS by trashing the sequence-number window.  It's
pretty inherent in how MPLS works that everything is tightly orchestrated
and locked-down at the boundary, so this seems basically theoretical.

-Ben

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Sep 2020 06:33:34 +0000

Hi,

On Fri, 2020-09-11 at 19:44 -0700, Benjamin Kaduk wrote:
> > Where the s/n is provided outside the MPLS domain, the security issues are
> > by definition outside the scope of this text.
> > 
> > Once inside the MPLS domain the normal MPLS security rules and constrains
> > apply. An attacker inside the MPLS domain can do many things to harm the
> > network, of which this is just one. MPLS operators know that they need to
> > secure their network dataplanes and control planes, but but they also know
> > that no packet gets to enter their network without their explicit
> > permission.
> > 
> > There is the potential for similar threats to pseudo wires, (interference
> > with in flight packets) but no such issue has ever been reported to the
> > PWE3/PALS WGs.
> > 
> > So I think that this is at best one of many theoretical attacks that could
> > occur, but is unlikely to ever materialise in a practical network.
> 

Okay, so your view that this is so theoretical that it doesn't even need to be
mentioned? 
 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 14 Sep 2020 15:03:06 +0100

> On 14 Sep 2020, at 07:33, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> 

I think the standard precautions used to protect an MPLS network would prevent this attack, and so it serves no purpose to highlight the issue in the RFC.

Stewart

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Sep 2020 14:29:45 +0000

On Mon, 2020-09-14 at 15:03 +0100, Stewart Bryant wrote:
> I think the standard precautions used to protect an MPLS network would prevent
> this attack, and so it serves no purpose to highlight the issue in the RFC.
> 

Ok, then I will drop that aspect of the discuss. 
 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Mobile +46 73 0949079
Torshamnsgatan 23           |
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 14 Sep 2020 17:38:38 +0200

A bit of hopefully fun rante:

There has been a lot of opinion politics around how easily an MPLS vs. e.g.: an IPv6
domain can be isolated. In the past, some MPLS proponents liked to produce FUD against
SRv6 by claiming that an SRv6 domain would never be as easily isolated than an MPLS domain
because it is so much easier for IPv6 packets to be crossing isolation boundaries.

In todays realities, where MPLS is equally supported in linux for VMs in data centers
as IPv6/SRv6 is, i think one should not assume a pragmatic difference, and the
easy hardware isolation we might have had in the past in MPLS domains when all routers
where physical boxes do IMHO not exist today anymore when everything is a hidgepodge of
VMs/containes/lamdas orchestrated by SDN provisioning systems so complex, nobody
understand anymore how they work.

yada yada:

PREOF is _the_ core contribution of DetNet IMHO, so it actually makes that contribution
stronger if its security aspects are well documented. Especially given how attacks
against a state-machinery like the one that has to buffer & reorder packets is something
that really as not existed in the type of nodes we hope to get DetNet into, so its
novel, good information for the developer / deployment community. Even if ultimately
the main learning point is probably more about building PREOF that is resilient
against unintentional malfunctions than malicious attacks. 

Cheers
    Toerless

On Fri, Sep 11, 2020 at 07:44:23PM -0700, Benjamin Kaduk wrote:
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

-- 
---
[email-masked]