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

[Toerless Eckert <[e-mail]>]

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:
> Hi Stewart, Magnus,
> 
> On Thu, Sep 10, 2020 at 02:37:41PM +0100, Stewart Bryant wrote:
> > 
> > 
> > > On 10 Sep 2020, at 14:23, Magnus Westerlund via Datatracker <[e-mail]> wrote:
> > > 
> > > 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.
> > 
> > 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.
> 
> 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
> 
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet

-- 
---
[e-mail]