Synonymous Flow Label Framework
draft-ietf-mpls-sfl-framework-11
Yes
(Alvaro Retana)
(Deborah Brungard)
No Objection
(Magnus Westerlund)
Note: This ballot was opened for revision 10 and is now closed.
Erik Kline
No Objection
Comment
(2020-09-19 for -10)
Sent
[[ nits ]] [ section 3 ] * "make packet loss measurement": perhaps "make packet loss measurements"? [ section 4.1.1 ] * "an applications need" -> "an application need" * "the SFL MAY be to some other value": perhaps "the SFL MAY be set to some other value"? [ section 5 ] * "invalidate the certain uses" -> "invalidate certain uses"
Murray Kucherawy
No Objection
Comment
(2020-09-21 for -10)
Sent
In Section 4.1.1, "LSE" should be expanded on first use. Also in that section, "the SFL MAY be to some other value" is missing the word "set".
Roman Danyliw
No Objection
Comment
(2020-09-23 for -10)
Sent
Thank you for responding to the SECDIR review (and thank you to Tero Kivinen for doing it) I had the same reaction as Martin Duke – I found one RFC2119/normative phrase in the document (Section 5). I’m not sure if this means it should be information or normative requirements should be articulated more clearly. The reviews TSVART and Ben Kaduk already capture my feedback on Sections 6 and 7. ** 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? ** Editorial Nits: -- Section 3. Typo. s/co-ordinating/coordinating/ -- Section 4.1. Typo. s/are present/is present/ -- Section 5. Typo. s/invalidate the certain uses/invalidate certain uses/
Éric Vyncke
No Objection
Comment
(2020-09-21 for -10)
Sent
Thank you for the work put into this document. Please find below a couple of non-blocking COMMENT points. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 1 -- I agree with other IESG review: this section could be expanded a little. Section 3 is the real introduction ;-) -- Section 3 -- "also causes an agreed action", when there is an agreement, there are usual parties agreeing together. It is a little unclear what are those parties here ? Also, I am not sure whether the 'action' is really agreed upon; i.e., one router could use a SFL to get more QoS but the routers on the path with use this SFL to also do IPFIX or DPI... For the sake of curiosity, I would have welcome some more words about how an PE router selects to use SFL or the 'normal' label: deep packet inspection ? or based on the ingress interface or ? (I may be completely wrong with this question)
Alvaro Retana Former IESG member
Yes
Yes
(for -10)
Not sent
Deborah Brungard Former IESG member
Yes
Yes
(for -10)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2020-09-18 for -10)
Sent
Thanks for a clear, well-written document that was an easy read. Just a few nits here: — Section 3 — would introduce network wide forwarding state. “network-wide” needs a hyphen Note that to achieve the goals set out above SFLs need to be allocated from the platform label table. A comma after “above” will help readability here (avoiding a reading of “above SFLs”). — Section 4.1 — The title says “applications label” and the first paragraph says “application label”. It seems that this should be consistent. function present runs over the "normal" stack, and SFL enabled flows “SFL-enabled” needs a hyphen (also in Section 4.2). — Section 4.1.1 — However it is recognised that, if there is an applications need, the SFL MAY be to some other value. I think “MAY be set to some other value” (add “set”) reads better. — Section 4.2 — If the LSP label is present, it processed exactly as it would normally processed and then it is popped. Missing words: “it is processsed” and “normally be processed”. This reveals the SFL which in the case of [RFC6374] measurements is simply counted and then Punctuation: “SFL, which, in the case of [RFC6374] measurements, is” system described in this document the behaviour of two approaches are indistinguishable and thus either may be implemented. Missing word: “of the two approaches”. And “behaviours”, needs to be plural. — Section 4.3 — application is large, and consequently the increase in the number of allocated labels needed to support the SFL actions consequently becomes too large to be viable. You have “consequently” twice, and should remove one of them. — Section 5 — The introduction to an SFL to an existing flow may cause that flow to Make it, “The introduction of an SFL to an existing flow”. This in turn may invalidate the certain uses Remove “the”. — Section 6 — This privacy threat may be mitigated by encrypting the control protocol packets, regularly changing the synonymous labels and by concurrently using a number of such labels. The second item isn’t parallel to the other two. Either make it “by regularly” (to make the second item match the third) or remove “by” before “concurrently” (to make the third match the second). Also, is “and” right? Would you do all three of these together? Or should it be “or”? I’m not sure, but I wanted to check.
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2020-09-18 for -10)
Sent
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.) 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". 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. 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. 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. 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".] 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. 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.) 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] 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 :) 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.) 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. Section 4.3 Is the Aggregate SFL also in some sense "synonymous with Explicit NULL" (as was mentioned in Figure 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. 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? 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 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. 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). 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. 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. 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).
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -10)
Not sent
Martin Duke Former IESG member
No Objection
No Objection
(2020-09-18 for -10)
Sent
I counted a total of three normative requirements in this document, none of them earth-shattering, and wonder if this could be changed to Informational and perhaps the important requirements moved into drafts that provide interoperable specs. ISTM that asking implementers to implement both this and a draft that describes an actual protocol is unnecessarily heavyweight.
Martin Vigoureux Former IESG member
No Objection
No Objection
(2020-09-24 for -10)
Not sent
Hi, thank you for this document. Interestingly you use ingress/egress LSR rather than LER. Nit: s/a existing label/an existing label/
Robert Wilton Former IESG member
No Objection
No Objection
(2020-09-24 for -10)
Not sent
Thanks for this document. I found it both easy to read and follow. Regards, Rob