Re: [mpls] Rtgdir last call review of draft-ietf-mpls-lspping-norao-02

[Greg Mirsky <[e-mail]>]

Hi Carlos,
thank you for your thorough review, thoughtful comments, and helpful
suggestions. The authors discussed and prepared responses inlined below
under the GIM>> tag. I prepared the new version (attached). Also, you can
find attached the diff that highlights all the updates.

Regards,
Greg

From: Carlos Pignataro via Datatracker <[e-mail]>
Date: Mon, Sep 4, 2023 at 7:30 AM
Subject: Rtgdir last call review of draft-ietf-mpls-lspping-norao-02
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <
[e-mail]>


Reviewer: Carlos Pignataro
Review result: Has Issues

Hi,

Please find below the Routing Area Directorate (rtgdir) review for
draft-ietf-mpls-lspping-norao-02. I'll be happy to provide further
clarifications or provide text as appropriate. I hope these are useful and
clear.

More Substantive:

Abstract

   The echo request and echo response messages, defined in RFC 8029
   "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures"

CMP> In the first line, the messages are misnamed. I suggest:

   The MPLS echo request and MPLS echo response messages, defined in
   RFC 8029 "Detecting MPLS Data-Plane Failures"...

GIM>> Thank you for the suggestion, I agree. These changes applied
throughout the document.

CMP> While this might seem, on the surface, an editorial, I feel it
CMP> is important for two main reasons.
CMP> First, the actual name of the messages is "MPLS echo request"
CMP> and "MPLS echo reply".
CMP> Second, as it was discussed during RFC 8029, it disambiguates
CMP> from ICMP homonyms.

   The rationale for having an RAO is
   questionable.

CMP> As this is the whole justification for this document, I do not
CMP> believe that the "rationale is questionable". Maybe its
CMP> effectiveness, or the applicability of the rationale to RAO as
CMP> a solution. But the rationale (intercept packets) is key...

GIM>> Would the following update address your concern:

OLD TEXT:

   The rationale for having an RAO is

   questionable.

NEW TEXT:

   The rationale for using an

   RAO as the exception mechanism is questionable.


   Furthermore, RFC 6398 identifies security
   vulnerabilities associated with the RAO.

CMP> This loose sentence feels handwavish -- as RFC 6398 has
CMP> no-use recommendations for the open Internet end-to-end,
CMP> while allows use in controlled environments.



GIM>> This refers to the analysis of the security concerns in Section 3 and
recommendations that are based on the analysis, e.g., Section 4.1. As LSP
Ping may be used in inter-area cases, recommendations in Section 4.1 of RFC
6398 are relevant. Would the following clarification address your concern:

OLD TEXT:

   Furthermore, RFC 6398 identifies security

   vulnerabilities associated with the RAO.

NEW TEXT:

   Furthermore, [RFC6398]

   identifies security vulnerabilities associated with the RAO and

   recommends against its use outside of controlled environments.


CMP> Overall, I feel the rationale for this doc needs some
CMP> tightening in the Abstract.

1.  Introduction

   RFC 8029 - "Detecting Multiprotocol Label Switched (MPLS) Data-Plane
   Failures" (aka LSP Ping) [RFC8029] detects data-plane failures in
   MPLS Label Switched Paths (LSPs).  It can operate in “ping mode” or
   “traceroute mode”. When operating in ping mode, it verifies end-to-
   end LSP continuity.  When operating in traceroute mode, it can
   localize failures to a particular node along an LSP.

CMP> I would keep the definition of ping and traceroute modes aligned
CMP> with RFC 8029, that says
   "ping mode is used for connectivity checks,
   and traceroute is used for hop-by-hop fault localization as well as
   path tracing."
CMP> note "continuity" vs. "connectivity", and addition of "path tracing"

GIM>> Please consider the following update:

OLD TEXT:

   When operating in ping mode, it verifies end-to-

   end LSP continuity.  When operating in traceroute mode, it can

   localize failures to a particular node along an LSP.

NEW TEXT:

   When operating in ping mode, it checks LSP

   connectivity.  When operating in traceroute mode, it can trace an LSP

   and localize failures to a particular node along an LSP.


   The echo request message is
   further encapsulated in an MPLS label stack.

CMP> This should be a global check on the document, "The MPLS echo request"

GIM>> Thank you for pointing that.Done.

CMP> Also, this sentence implies that it is always encapsulated in an MPLS
CMP> label stack -- whereas that would not be the case for Implicit Null.
CMP> This is in Section 4.3 of RFC 8029, in:
   "If all of the FECs in the
   stack correspond to Implicit Null labels, the MPLS echo request is
   considered unlabeled...""

GIM>> A very helpful observation, thank you. The following update is
proposed to clarify:

OLD TEXT:

   The echo request message is

   further encapsulated in an MPLS label stack.

NEW TEXT:

   The MPLS echo request

   message is further encapsulated in an MPLS label stack, except when

   all of the FECs in the stack correspond to Implicit Null labels.




   When operating in ping mode, LSP ping sends a single echo request
   message, with the MPLS TTL set to a high value (e.g., 255).  This

CMP> Is this TTL set to any "high value" (and what exactly is high??),
CMP> Or to "255" as in S4.3 of RFC 8029?

GIM>>  The text in RFC 8029 seems open to an interpretation (in the way it
uses the normative language):

   In "ping" mode (end-to-end connectivity check), the TTL in the

   outermost label is set to 255.

Would using wording close to RFC 8029 address your concern:

OLD TEXT:

   When operating in ping mode, LSP ping sends a single echo request

   message, with the MPLS TTL set to a high value (e.g., 255).

NEW TEXT:

   When operating in ping mode, LSP ping sends a single MPLS echo

   request message, with the MPLS TTL set to 255.


   When operating in traceroute mode, MPLS ping sends multiple echo
   request messages.

CMP> This paragraph above is potentially ambiguous: can traceroute
CMP> send lots of "MPLS echo requests" messages all at once in a
CMP> concurrent fashion (like concurrent algo in Paris Traceroute)?
CMP> Not really due to the DDSMAP. I'd suggest pointing to RFC 8029
CMP> as much as possible on this, instead of re-writing it.
CMP> And for this sentence, add that subsequently increasing TTL, etc.

GIM>> I think that rather than repeating it, we can refer to the traceroute
process defined in Section 4.3 of RFC 8029, e.g.,

NEW TEXT:

   When operating in traceroute mode, MPLS ping sends multiple

   MPLS echo request messages as defined in Section 4.3 of [RFC8029].


   The IP header that encapsulates an echo request message must include
   a Router Alert Option (RAO), while the IP header that encapsulates an
   echo reply message may include an RAO.

CMP> It is not that the *MPLS* (keeps being missed) echo reply "may"
CMP> include a RAO. It is that there are cases in which it MUST and
CMP> cases in which it doesn't -- as per reply-modes. See S4.5 of
CMP> RFC 8029.

GIM>> It seems as if the use of the non-normative "may" is reasonable since
the use of RAO in the MPLS echo reply message is dependent on the value of
the Reply Mode in the corresponding MPLS echo request message. Would the
following clarification address your concern:

OLD TEXT:

   The IP header that encapsulates an echo request message must include

   a Router Alert Option (RAO), while the IP header that encapsulates an

   echo reply message may include an RAO.

NEW TEXT:

   The IP header that encapsulates an MPLS echo request message must

   include a Router Alert Option (RAO), while the IP header that

   encapsulates an MPLS echo reply message must include an RAO if the

   value of the Reply Mode in the corresponding MPLS echo request

   message is "Reply via an IPv4/IPv6 UDP packet with Router Alert".


   In both cases, the rationale
   for including an RAO is questionable.  Furthermore, [RFC6398]
   identifies security vulnerabilities associated with the RAO and
   recommends against its use outside of controlled environments.

CMP> All same comments as with the Abstract, plus, "MPLS LSP Ping"
CMP> is not used end-to-end in the open Internet, right? As such,
CMP> the applicability (as this justification) of 6398 is questionable.

GIM>> MPLS LSP ping can be used in inter-area cases. As the boundary
between "open Internet" and "inter-area" is blurred, recommendations of
Section 4.1 of RFC 6398 seems like applicable in the case analyzed in the
document.

2.1.  Echo Request

   ...
   To achieve this, RFC 8029 proposes the following:

CMP> This section and enumeration is very useful.
CMP> Nit: RFC 8029 doesn't "propose" but "specifies" maybe.

GIM>> s/propose/specifies/
CMP> There's one important element missing, however, which
CMP> is the "MPLS Router Alert Label". See Section 4.4 of
CMP> RFC 8029, first paragraph.

GIM>> Thank you for pointing this out. The goal of the list is to enumarate
all mechanisms to prevent leaking MPLS echo request message that are used
concurrently. MPLS Router Alert is an optional exception mechanism and
because of that it is not included in the list. I hope that is reasonable.

   3.  When the echo request message is encapsulated in IPv4, the IPv4
       header must include an RAO.  When the echo request message is
       encapsulated in IPv6, the IPv6 header chain must include a Hop-
       by-hop extension header and the Hop-by-hop extension header must
       include an RAO.

CMP> This is slightly incomplete, given RFC 7506 (specifying the
CMP> actual RAO value)

GIM>> Would the following clarification address your concern:

OLD TEXT:

       When the echo request message is

       encapsulated in IPv6, the IPv6 header chain must include a Hop-

       by-hop extension header and the Hop-by-hop extension header must

       include an RAO.

NEW TEXT:

       When the MPLS echo request

       message is encapsulated in IPv6, the IPv6 header chain must

       include a Hop-by-hop extension header and the Hop-by-hop

       extension header must include an RAO with the option value set to

       MPLS OAM [RFC7506].


2.2.  Echo Reply

   An LSP ping replies to the MPLS echo message with an MPLS echo reply
   message.  It has four reply modes:

CMP> There are 4 reply modes specified in RFC 8029, but there's more, see
CMP>
https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#reply-modes
<https://urldefense.com/v3/__https:/www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml*reply-modes__;Iw!!NEt6yMaO-gk!C8hk0XiRMPpIbOKHgirKH3KyCX4uT-FrcLHyDngYqEC3ih9AehssKFew_Oiqq4xhkY9NYuy571zc7K6AxZoZ$>

GIM>> Will adding the reference to RFC 8029 makes it unambiguos:

NEW TEXT:

   An LSP ping replies to the MPLS echo request message with an MPLS

   echo reply message.  Four reply modes are defined in [RFC8029]:


3.  Update to RFC 7506

   RFC 7506 defines the IPv6 Router Alert Option for MPLS Operations,
   Administration, and Management.  This document reclassifies RFC 7506
   as Historic.

CMP> A question: since RFC 7506 defines the IPv6 RAO value as "MPLS OAM",
CMP> and not as "MPLS LSP Ping", are other MPLS OAM potential uses of it?
CMP> An ICMPv6 over MPLS with RAO, would it use this value?

GIM>> I am not aware of the specification that requires use of MPLS OAM
option in case of ICMPv6 over MPLS.

4.  Update to RFC 8029

CMP> This section changes subject to focus on the loopback address for
CMP> IPv6. Given how many pieces of RFC 8029 include the RAO text,
CMP> I'd suggest this section to specifically enumerate all places
CMP> in RFC 8029 that it's updating.
CMP> For example, how would these sections of RFC 8029 be re-written?
CMP> Sections 2.2, 3, 4.3, 4.4 (what if a RAO is *received*?), and
CMP> the "Label Operation Check", 4.5, 6.2.1, etc.

   *  For IPv6, the IPv6 loopback address ::1/128 SHOULD be used.

CMP> The issue of ::1/128 is a bit more complex than a single sentence,
CMP> because it is swapping a range for an address. This is documented
CMP> in https://www.rfc-editor.org/rfc/rfc7439#section-3.4.2
<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc7439*section-3.4.2__;Iw!!NEt6yMaO-gk!C8hk0XiRMPpIbOKHgirKH3KyCX4uT-FrcLHyDngYqEC3ih9AehssKFew_Oiqq4xhkY9NYuy571zc7POLgtz_$>,
and
CMP> that analysis should be referenced/cited and addressed.
CMP> Further, RFC 7439 Section 3.4.2 should be Updated by this doc.

GIM>> Section 3.4.2 of RFC 7439 explains use of an IPv4-mapped IPv6
address as IPv6 destination address as mechanism to excersise multiple
paths. In the draft, for the ECMP environment use of alternative sources of
entropy is recommended:

   *  To exercise all paths in an ECMP environment, the entropy other

      than the IP destination address SHOULD be used.

Furthermore, use of the IPv4-mapped IPv6 range of addresses is not
prohibited, it remains an option. Thus, it appears that everything
discussed in Section 3.4.2 of RFC 7439 is not affected by this draft.


CMP> Further, what happens to RFC 8029's Section 3.4.1.1.1,  "Multipath
CMP> Information Encoding"?

GIM>> Section 4 of draft-ietf-mpls-lspping-norao makes use of IPv6 address
from the 0:0:0:0:0:FFFF:7F00/104 range optional

   *  The sender of an echo request MAY select the IPv6 destination

      address from the 0:0:0:0:0:FFFF:7F00/104 range.

As the use of that range is allowed, there's no apparent need updating
Section 3.4.1.1.1. Would you agree?




7.  Security Considerations

   The recommendations this document makes do not compromise security.

CMP> Given that security was one of the cited rationales mentioned,
CMP> I'd think that this section should discuss how the security
CMP> posture is improved with this document.

GIM>> Thank you for your suggestion. Please consider the follwoing updated
text:

NEW TEXT:

   The recommendations this document makes do not compromise security.

   In case of using IPv6 loopback address ::1/128 strengthens security

   for LSP Ping by using the standardized loopback address with well-

   defined behavior.


More Editorial:

Abstract

   The echo request and echo response messages, defined in RFC 8029
   "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures"
   (aka LSP ping messages), are encapsulated in IP headers that include

CMP> ^^^ suggest "AKA" or "usually referred to as" instead of "aka".

CMP> Same comment on the Introduction.

GIM>> Done*2

1.  Introduction

   RFC 8029 - "Detecting Multiprotocol Label Switched (MPLS) Data-Plane
   Failures" (aka LSP Ping) [RFC8029] detects data-plane failures in
   MPLS Label Switched Paths (LSPs).  It can operate in “ping mode” or

CMP>                                                    ^^^^^^^^^^^
CMP> There's a number of non-ascii characters, as for example the use of
CMP> “” instead of "". Suggest global replacement.

GIM>>

   Therefore, this document removes the RAO from both LSP ping message
   encapsulations.  It updates RFCs 7506 [RFC7506] and 8029.

CMP> Missing citation for RFC 8029.

GIM>> Thank you for another great catch. Done.

2.1.  Echo Request

CMP> "When the *MPLS* echo request message" ("MPLS" is missing in each
CMP> one of the number list elements)

GIM>> Per your earlier suggestion, applied global update. I hope I caught
all of them.

   2.  When the echo request message is encapsulated in IPv4, the IPv4
       TTL must be equal to 1.  When the echo request message is
       encapsulated in IPv6, the IPv6 Hop Limit must be equal to 1.  For
       further information on the encoding of the TTL/Hop Limit in an
       echo request message see Section 4.3 of [RFC8029].

CMP> Missing comma, "...echo request message, see Section..."

GIM>> Done, thx.

2.2.  Echo Reply

   However, it is not clear that the use of the RAO increases the
   reliability of the return path.  In fact, one can argue it decreases
   the reliability in many instances, due to the additional burden of
   processing the RAO.  This document changes RGC 8020 in that mode 3
   are removed.

CMP> Typo, "RGC 8020" instead of "RFC 8029".

GIM>> Changed to reference to RFC 8029. Would you agree?

5.  Backwards Compatibility

   This document requests that the IPv6 RAO value for MPLS OAM (69) in
   [IANA-IPV6-RAO] is marked as "Deprecated".  It also requests tha that

CMP> Typo, "tha that" should be "that the"                      ^^^^^^^^

GIM>> Thank you for catching this. Done.

I hope these help and are clear and useful.

Thanks!

Carlos.