Subject: [mpls] IESG comments on draft-ietf-mpls-sfl-framework - first tranche (security)

From: Stewart Bryant <[email-masked]>
Date: Wed, 30 Sep 2020 11:07:38 +0000

Dear All,

I am working my way through the various IESG comments on  draft-ietf-mpls-sfl-framework.

I have looked at the comments by Roman and Benjamin, but need to pause for a few days to do other work. My proposed disposition of the comments is as follows.

I thank all of the reviewers and will address the other comments and upload a new version of the text shortly.

Bets regards

Stewart

From Roman Danyliw

** Section 3.  What is “triggering IPFIX inspection”?  I wasn’t familiar with this phrasing.  Is the intent to trigger more in-depth analysis of header information, as opposed to “triggering … DPI”, which will do content inspection?

SB> I have changed this to

"triggering an IP Flow Information Export (IPFIX) {{RFC7011}} capture"

** Editorial Nits:
-- Section 3.  Typo. s/co-ordinating/coordinating/

SB> Fixed

-- Section 4.1.  Typo. s/are present/is present/

I think the original is correct (there is a plurality of cases), I will leave it to the RFC Editor.

-- Section 5.  Typo. s/invalidate the certain uses/invalidate certain uses/

SB> Fixed

===========

Benjamin Kaduk

I agree with the TSV-ART reviewer that some discussion of how/why the
RFC 8372 requirements are met would have been welcome.

Other than that, I basically only have nits and minor comments; this is
pretty straightforward and well-specified.

Section 1

The Introduction is essentially a verbatim copy of the Abstract with
formatting changes.  It seems likely that the Introduction could be
expanded slightly if desired.

   [RFC8372] (MPLS Flow Identification Considerations) describes the
   requirement for introducing flow identities within the MPLS

nit: "requirement" singular or "requirements" plural?  (It itself seems
to only claim to give "considerations" relevant for flow identification.)

SB> I think in this context singular is correct, but will discuss with RFC Editor.

   architecture.  This document describes a method of accomplishing this

nit: the second "this" that is to be accomplished doesn't have a
terribly precise referent -- it is in some sense "accomplishing the task
of meeting the requirements" but not "accomplishing the requirements”.

SB> Changed to "This document describes a method of providing the required identification by using a"

   by using a technique called Synonymous Flow Labels (SFL) in which
   labels which mimic the behaviour of other labels provide the
   identification service.  These identifiers can be used to trigger
   per-flow operations on the packet at the receiving label switching
   router.

nit: we currently introduce the LSR acronym in Section 3 but this seems
to be the first non-Abstract usage.

SB> I qualify labels by adding MPLS - "behaviour of other MPLS labels"

Section 3

   An SFL is defined to be a label that causes exactly the same
   behaviour at the egress Label Switching Router (LSR) as the label it
   replaces, but in addition also causes an agreed action to take place
   on the packet.  There are many possible additional actions such as

nit: is this "agreed action" on the path or also at the egress?  If at
the egress, then "exactly the same behavior" is debatable, in a pedantic
sense.

SB> I think technically the English is correct, but five years after I first wrote it
I think it could be polished. It now says:

"An SFL is defined to be a label that causes exactly the same
behaviour at the egress Label Switching Router (LSR) as the label it
replaces, but except that it also causes anone or more additional agreed actions to take place
on the packet.  "

   the measurement of the number of received packets in a flow,
   triggering IPFIX inspection, triggering other types of Deep Packet

nit: while IPFIX appears on

https://www.rfc-editor.org/materials/abbrev.expansion.txt
 it is not
marked as "well-known", thus probably merits expansion.

SB> Expansion added

   acceptable for scaling reasons.  We therefore have no choice but to
   introduce an additional label.  Where penultimate hop popping (PHP)
   is in use, the semantics of this additional label can be similar to
   the LSP label.  Where PHP is not in use, the semantics are similar to
   an MPLS explicit NULL [RFC3032].  In both of these cases the label
   has the additional semantics of the SFL.

[I note that here we weaken the statement to be only "similar to", not
"exactly the same”.]

SB> It cannot be exactly the same as it has the additional SFL properties, so I think “similar" is correct.

   Finally we need to consider the case where there is no MPLS
   application label such as occurs when sending IP over an LSP.  In

nit/editorial: I would consider mentioning the application label
earlier, to accentuate the contrasting case being introduced here.

SB> Good point, I have changed the start of the PW text to

"To illustrate the use of this technology, we start by  considering
the case wwhere there is an "application" label in the MPLS label stack.
As a first example, let us consider a
pseudowire (PW) {{RFC3985}} on which it is desired to make
packet loss measurement."

Section 4

   As noted in Section 3 it is necessary to consider two cases:
   [...]
   2.  Single label stack

(editorial) Some minor rewording in Section 3 to specifically mention
the "single label stack" case in such terms would probably help the
document feel more cohesive.  (I assume it's meant to be the converse of
the "application label present" case, i.e., the "there is no MPLS
application label such as occurs when sending IP over an LSP" case.)

SB> Changed the text to "Finally we need to consider the case where there is no MPLS
application label such as occurs when sending IP over an LSP, i.e. there is a single label in the MPLS label stack."

Section 4.1

   At the egress LSR the LSP label is popped (if present).  Then the SFL
   is processed in exactly the same way as the corresponding application
   label would have been processed.

[Just noting that "exact" is used here; I have no specific comment]

SB> On reflection changed this to :" At the egress LSR the LSP label is popped (if present).  Then the SFL
is processed executing both the synonymous function and the corresponding application function.

Section 4.1.1

   that the SFL is synonymous with.  However it is recognised that, if
   there is an applications need, the SFL MAY be to some other value.

(nit) Barry already noted the missing "set", but I think it's also "the
TTL and TC bits in the SFL" and not the SFL itself -- the SFL itself is
inherently a different value, otherwise it would be called the
"identical flow label" and we probably wouldn't be writing a document
about it :)

SB> Good catch. I have changed the text to

"However, it is recognised that if there
is an applications need  these fields in the SFL Label Stack Entry (LSE) MAY be set these to some other value."

Section 4.2

I wondered to myself for Figure 1, and wonder out loud here for Figure
2, if we can make some indication that the "May be PHPed" applies to
both the "Normal" label stack as well as to the "with SFL" label stack.
(For Figure 1 it was vertically aligned, but is not so, here.)

SB> In Fig 1 and Fig 2 added PHP note inside the stack diagrams
SB> to make it clear where it applied. Also make clear BoS applies
SB> to both sides.

   If the LSP label is present, it processed exactly as it would
   normally processed and then it is popped.  This reveals the SFL which
   in the case of [RFC6374] measurements is simply counted and then
   discarded.  In this respect the processing of the SFL is synonymous

nit: it's not entirely clear to me why this specific case merits mention of
RFC 6374 measurement but we don't want to mention it anywhere earlier.

SB> We originally put it in because this we wanted to show that in some important cases
SB> SFL behaviour was simple and in some cases already supported by the natural
SB> behaviour of the existing h/w.

Section 4.3

Is the Aggregate SFL also in some sense "synonymous with Explicit NULL"
(as was mentioned in Figure 2)?

SB> It’s behaviour is similar, but as I remember an explicit NULL must be BoS.
SB> So am reluctant to  add that note.
SB> Aligned Fig 3 with the changes made to Fig 1 & 2

Section 5

   2.  The operator can elect to use [RFC6790] Entropy Labels in a
       network that fully supports this type of ECMP.  If this approach
       is adopted, the intervening MPLS network MUST NOT load balance on
       any packet field other than the entropy label.  Note that this is
       stricter than the text in Section 4.2 of [RFC6790].  In networks

Is Section 4.2 ("Ingress LSR") really the best reference in RFC 6790?
Section 4.3 seems much more relevant, to me.

SB> Good catch, 4.3 is the correct reference.

       in which the ECMP decision is independent of both the value of
       any other label in the label stack, and the MPLS payload, the
       path of the flow with the SFL will be congruent with the path
       without the SFL.

(side note) what would the ECMP decision be made on, in that case?  A
random number generator?

SB> The background is that some P routers load balance a number of
SB> fields rather than on just the EL. I will clarify. It now says:

   "In networks in which the ECMP decision is based solely
    on the entropy lable, and ignores the value of all other labels
    in the label stack, and ignores all field in the MPLS payload,
    the path of the flow with the SFL will be congruent with
    the path without the SFL. "

Section 6

Thank you for noting the privacy considerations even though the
incremental exposure is fairly small!

I might note that whenever IPFIX or other DPI techniques are used, their
relevant privacy considerations apply.

   The inclusion of originating and/or flow information in a packet
   provides more identity information and hence potentially degrades the
   privacy of the communication.  Whilst the inclusion of the additional

SB> Note added.

At risk of banality, I suggest "potentially degrades the privacy of the
communiation to an attacker in position to observe the added
identifier", to subtly emphasize that the relevant attacker here has
capabilities that already allow for similar types of attack.  That is,
what's new for the attacker here is that they get some signal as to how
the ingress decides to classify traffic -- they already have all the
traffic in the first place and could be doing their own classification
on it.

SB> change made.

   granularity does allow greater insight into the flow characteristics
   it does not specifically identify which node originated the packet
   other than by inspection of the network at the point of ingress, or
   inspection of the control protocol packets.  This privacy threat may

nit: I suggest
s/other than by/unless the attacker can/;
s/inspection of/inspect/

(since the attacker needs to both observe the labeled
traffic and obtain the origination-mapping information in order to
effectuate the identification).

SB> yes that is cleared - change made.

Section 7

I think that the type of attack opened up by having multiple synonyms
for conceptulaly "the same traffic", that Tero noted in the secdir
review, would be in cases where the attacker is sending traffic over the
LSP in question and knows both the classification algorithm used to
apply the SFL and the nature of the DPI performed on SFL-marked traffic,
and is thus able to ensure that whatever nefarious things they are doing
that would have been noticed by the DPI instead take the non-DPI path
and remain undetected.  Now, AFAICT the type of DPI envisioned here is
mostly not going to be looking for nefarious things, and even the
existence of such nefarious things that need to be going over this LSP
that the attacker can already send traffic over seems a bit contrived,
but that's my take on the additional incremental attack that this
mechanism opens up.

SB> Yes, if an attacker can avoid the DPI triggers by disguising the traffic
SB> they can do that regardless of the SFL mechanism, so I don’t think
SB> there is an SFL specific risk.

   There are no new security issues associated with the MPLS dataplane.
   Any control protocol used to request SFLs will need to ensure the
   legitimacy of the request.

I'd suggest mentioning authorization checks as well -- a request can in
some sense still be "legitimate" even if the requestor is not currently
authorized to receive the service.

SB> I have extended the text to say: "Any
control protocol used to request SFLs will need to ensure the
legitimacy of the request, i.e. that the requesting node is authorised
to make that SFL request by the network operator."

Section 10.2

Hmm, in some reading "can elect to use [RFC6790] Entropy Labels" [..]
MUST NOT load balance on any packet field other than the entropy label"
makes 6790 a normative reference (required reading for an optional
feature).

SB> Yes, I have moved it.

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 30 Sep 2020 12:59:25 +0000

Hi Stewart!

Thanks for the status update.  Inline about non-Section 6 and 7 text …

From: Stewart Bryant <[email-masked]>
Sent: Wednesday, September 30, 2020 7:08 AM
To: [email-masked]; [email-masked]; mpls <[email-masked]>; Roman Danyliw <[email-masked]>; Benjamin Kaduk <[email-masked]>
Cc: Stewart Bryant <[email-masked]>
Subject: IESG comments on draft-ietf-mpls-sfl-framework - first tranche (security)

Dear All,

Bets regards

Stewart

From Roman Danyliw

** Editorial Nits:

SB> Fixed

SB> Fixed

[Roman] These changes all look good.  Thanks for making them.

Regards,
Roman