Re: [mpls] Working Geoup Adoption poll on draft-kompella-mpls-lspping-norao

[Adrian Farrel <[e-mail]>]

Hi,

There seems to be a bit of silence about this document, so here are my
thoughts.

Tl;dr - Yes we should adopt this document

I did an early review for Loa, which I believe he shared with the
authors. So it shouldn't be a surprise if I now find fewer issues.

BTW, and not really relevant for the current content of the document,
I believe the reason for the "belts and braces" use of the RAO was to
protect against "pop-and-go" implementations where an encapsulated IP
packet might be exposed and forwarded without checks made on the IP TTL.
Whether or not this was a real concern can be left as an exercise for
the reader.

Happy New Year,
Adrian

===

Please settle on "LSP ping" or "LSP Ping"

---

The title makes clear the purpose of the document. However...

   This document also recommends the use of an IPv6 loopback address
   (:::1/128) and discourages the use of an IPv4 loopback address mapped
   to IPv6.

That fact is lost to people who read document titles and apply filters!

Perhaps...

     LSP Ping: Deprecating the Use of Router Alert and Recommendations
                for the use of IPv6 Loopback Address

---

Abstract has:
   The rationale for including an
   RAO is questionable.  Furthermore, RFC6398 identifies security
   vulnerabilities associated with the RAO.

I don't believe that the reason for deprecating RAO in this case is the
"questionable" rationale for its use. Who cares whether it is
questionable, and who wants to have that debate? The reason to deprecate
is the security vulnerabilities.

That no implementation relies on the RAO is an indication that
deprecation is safe.

A throw-away comment is that we don't believe including RAO adds any
value.

So, I'd suggest to focus on the main event...

   LSP ping messages (RFC 8029) are encapsulated in IP headers that
   include a Router Alert Option (RAO).  However, RFC6398 identifies
   security vulnerabilities associated with the RAO, and it is believed
   that no implementation relies on the presence of the RAO to add any
   functional value.

---

Abstract should not just say, "It updates RFCs 7506 and 8029," but
should also indicate in what way it makes an update. I think this can be
achieved by rewriting the paragraph as...

   Therefore, this document updates 8029 to remove the RAO from LSP ping
   message encapsulations and reclassifies RFC 7506 as Historic.

--

Interesting that, despite the assertion that the document makes
recommendations on the use of IPv6 loopbacks, the text uses SHOULD and
not RECOMMENDS. Not important, but a nice-to-have.

---

1.

   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.

Given what this document sets out to do, you should phrase this as...

  RFC 8029 specifies that, the IP header....

---

1.

Same issue as mentioned for the Abstract.

OLD
   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.
NEW
   However, [RFC6398] identifies security vulnerabilities associated
   with the RAO and recommends against its use outside of controlled
   environments. Further, it is believed that no implementation relies
   on the presence of the RAO to add any functional value.
END

---

1.

Similar issue to in the Abstract, but we can also give some more details
about the updated RFCs.

OLD
   Therefore, this document removes the RAO from both LSP ping message
   encapsulations.  It updates RFCs 7506 [RFC7506] and 8029.
NEW
   [RFC7506] discusses the use of the IPv6 ROA for MPLS Operations,
   Administration, and Maintenance (OAM) and allocates a new, generic
   IPv6 RAO value that can be used by MPLS OAM tools, including the MPLS
   Echo Request and MPLS Echo Reply messages for LSP ping in IPv6
   environments.

   Therefore, this document updates 8029 to remove the RAO from LSP ping
   message encapsulations, and reclassifies RFC 7506 as Historic.
END

---

2.1

   To achieve this, RFC 8029 proposes the following:

To be fair, 8029 is a little more direct. It "specifies".

---

2.1

To make the relationship to 7506 clearer...

OLD
   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.
NEW
   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 as defined by RFC 7506.
END

---

2.1

"ALL" is not a 2119 word, and the use of "therefore" is not a logical
progression. So...

OLD
   Currently, ALL of these are required.  However, any one is sufficient
   to prevent forwarding the packet beyond the egress LSR.

   Therefore, this document changes RFC 8029 in that Requirement 3 is
   removed.
NEW
   RFC 8029 states that all of these four behaviors must be implemented.
   However, it can be observed that any one of them is sufficient to 
   prevent the packet being forwarded beyond the egress LSR. Therefore,
   the third requirement (use of the RAO) does not add any value, and 
   so, in view of the security concerns outlined in RFC 6398, this 
   document updates RFC 8029 to remove this third requirement.
END

---

2.1

   The authors are not aware of any implementation that relies on the
   RAO to prevent packets from being forwarded beyond the egress LSR.

This is fine for now.
Obviously, before we request publication, it needs to be strengthened
into something like...

   An ad hoc survey of implementers conducted by MPLS Working Group has
   not revealed any implementation that relies on the RAO to prevent
   packets from being forwarded beyond the egress LSR.

---

2.2

I'd suggest some re-wording to avoid debate...

OLD
   The rationale for mode 3 is questionable, if not wholly misguided.
   According to RFC 8029, "If the normal IP return path is deemed
   unreliable, one may use 3 (Reply via an IPv4/IPv6 UDP packet with
   Router Alert)."

   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.
NEW
   In the case of mode 3, this uses the IPv6 RAO defined in RFC 7506.

   RFC 8029 states: "If the normal IP return path is deemed unreliable,
   one may use 3 (Reply via an IPv4/IPv6 UDP packet with Router Alert)." 
   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 RFC 8020 in that mode 3 is removed.
END

---

2.2

   The authors are not aware of any implementations of mode 3.

Again, this is fine for now, but it will need to be strengthened before
publication.

---

3.

It's good, but could be a little clearer. Suggest...

   [RFC7506] defines the IPv6 Router Alert Option for MPLS Operations,
   Administration, and Management.  With the changes to RFC 8029 
   described in Section 2, that RAO is no longer required.  Therefore,
   this document reclassifies RFC 7506 as Historic and requests IANA to
   mark the IPv6 RAO value of MPLS OAM as Deprecated (see Section 6).

---

4.

s/in[RFC1122]/in [RFC1122]/

---

I found sections 2 and 4 to be confusing in content. From the section 
titles, it looks like 2 is just descriptive and 4 includes all of the 
updates to 8029. But that's not the case.

Further, it is not clear in 4 whether...
   LSP Ping implementations SHOULD ignore RAO options when they arrive
   on incoming echo request and echo reply messages.
...is original text, an update, or new text.

I suggest three actions:

1. Make the section titles clearer:

   2.  Updates to RFC 8029 for Router Alert for LSP Ping 
   3.  Reclassifying RFC 7506 as Historic
   4.  Update to RFC 8029 for IPv6 Loopback Addresses

2. Move...

   LSP Ping implementations SHOULD ignore RAO options when they arrive
   on incoming echo request and echo reply messages.

   ...to Section 2 where it better fits with the content

3. In Sections 2 and 4 make it abundantly clear what text is replaced
   with what. This can either be, "The entirety of Section x.y is 
   replaced with the following text," or use OLD/NEW notation.

---

5.

s/tha that/that/

---

5.

AFAICS, section 5 doesn't talk about backward compatibility directly!
And, while it is delightful to know how you interpret "DEPRECATED":
- You have only used "Deprecated" in the text
- You have (correctly) noted in section 6 that 8126 provides the 
  definition.

You should have something like:

   According to the update to RFC 8029 set out in Section X, LSP Ping
   implementations should ignore RAO options when they arrive on
   incoming echo request and echo reply messages.  As well as using the 
   RAO, RFC 8029 requires echo requests have the destination address set
   to a loopback address and that the IP TTL/Hop Limit be set to 1.
   Therefore, echo requests sourced by a legacy implementation will
   still be captured and not forwarded even if the RAO they carry is
   ignored, and echo requests sourced by an implementation conformant to
   this document will be correctly captured by legacy end points. 
   Furthermore, in the case of an echo reply, the only option in which a
   legacy implementation may use an RAO is option 3, and with the RAO
   ignored, this looks like option 2 which must, in any case be
   supported by a receiver.  Thus, backwards compatibility is not impeded
   by this document.   

   This document requests that the IPv6 RAO value for MPLS OAM (69) in
   [IANA-IPV6-RAO] is marked as "Deprecated".  It also requests that
   Reply Mode 3 ("Reply via an IPv4/IPv6 UDP packet with Router Alert")
   in [IANA-LSP-PING] is marked as "Deprecated".  The term "Deprecated"
   is defined in [RFC8126] and means that deprecated values should not
   be used in new implementations, and that deployed implementations
   that use these values continue to work seamlessly.  This is
   consistent with the non-use and ignoring of RAO as described above.

---

6.

This section needs to be more pithy about what it is asking IANA to do
and also not tell IANA what their own terms mean!

   IANA maintains the "IPv6 Router Alert Option Values" registry.  IANA
   is requested to mark value 69 ("MPLS OAM") as Deprecated and include
   a reference to this document.  IANA should continue to include the
   reference to RFC 7506.

   IANA maintains the "Reply Modes" registry within the "Multiprotocol
   Label Switching Architecture (MPLS)" registries.  IANA is requested to
   mark value 3 ("Reply via an IPv4/IPv6 UDP packet with Router Alert")
   as Deprecated and include a reference to this document.  IANA should
   continue to include the reference to RFC 8029.

---

7.

Given that one of your motivations for this work is the security 
concerns expressed in RFC 6398, I think that this section should spend
some characters to state that you believe that this improves the
security of IP-over-MPLS systems, and why.

---

8.

Not appropriate to include the URLs of the IANA registries as references
because they are not long-term stable (compared to the names of the 
registries).  See my proposed text in section 6.

-----Original Message-----
From: mpls <[e-mail]> On Behalf Of Loa Andersson
Sent: 15 December 2022 23:43
To: [e-mail]
Cc: [e-mail]
Subject: [mpls] Working Geoup Adoption poll on
draft-kompella-mpls-lspping-norao

Working Group,

This is to start a two week poll on adopting
draft-kompella-mpls-lspping-norao
as a MPLS working group document.

Normally we do the two weeks wgap's pretty strict, however in this case 
I keep the right to extend the wgap, if there has not been enough
reactions and discussion, the wgap might be extended into 2023.

Please send your comments (support/not support) to the mpls working
group mailing list ([e-mail]). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

For this poll we also want to point at text in section 2.1 and 2.2.

Section 2.1 have the following:

    The authors are not aware of any implementation that relies on the
    RAO to prevent packets from being forwarded beyond the egress LSR.

Section 2.2 have the following:

    The authors are not aware of any implementations of mode 3.

We'd like to confirm that we don't have such implementations. If you 
have additional information, or agree with the statements above, please 
include this in your response on the wgap.

There are no IPR disclosures against this document.

All the authors have stated on the MPLS wg mailing list that they are
unaware of any IPRs that relates to this document.

The working group adoption poll ends December 29, 2022.

/Loa
-- 
Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]

_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls