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

[Benjamin Kaduk <[e-mail]>]

Hi Stewart,

Thanks for the updates.
Your proposals look fine to me modulo typos ("anone", "wwhere").

-Ben

On Wed, Sep 30, 2020 at 11:07:38AM +0000, Stewart Bryant wrote:
> 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.
> 
>