Subject: [mpls] Secdir last call review of draft-ietf-mpls-sfl-framework-08

From: Tero Kivinen via Datatracker <[email-masked]>
Date: Thu, 02 Jul 2020 15:30:25 -0700

Reviewer: Tero Kivinen
Review result: Has Issues

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document describes a way to make synonyms for MPLS flows so those
flows can be processed differently. It does include privacy considerations
which says that depending on how the synonyms are used there might
be privacy issues. 

It does claim in the security considerations section that there is no new
security issues associated with the MPLS dataplane. I think that is not true.
If there is any kind of different processing depending which synonym
is used that can be used to bypass that processing by using the another
synonym instead of the intended one. For example if attacker knows 
that specific synonym causes deep packet inspection (one of the examples
given), and he might want to use the synonym which bypasses this 
inspection, in case he is sending things he does not want to be 
inspected. This could be some kind of malicious code somehow
loaded to the sending device or something.

On the other hand my understanding that trust model of MPLS
is mostly we blindly trust everything other end says, so someone
able to use different synonyms are most likely also able to do 
other even worse things, but I think there are new things caused
by this addition than what is already present in the MPLS now.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 8 Jul 2020 12:18:02 +0100

> On 2 Jul 2020, at 23:30, Tero Kivinen via Datatracker <[email-masked]> wrote:
> 
> 
> 
> synonym instead of the intended one.

> For example if attacker knows 
s/he/they/
> loaded to the sending device or something.

The sending device is always an LSR owned by the provider, there is no way for a random device to do this. Equally the P routers are owned and managed by the provider.

> by this addition than what is already present in the MPLS now.

If you can articulations them, we will look at the level of threat and how we might mitigate them. However we are not aware of any such new threats. As you say, if you compromised the ingress PE in a MPLS network you are pretty much dead in the water anyway. These environments are well managed and tend to be secure.

Thus, I do not propose to add any text unless there is a well articulated and specific threat that is not already considered within the existing MPLS design.

Many thanks for the review.

Stewart