Re: [mpls] draft-ietf-mpls-lspping-norao-03 - Review

[Gyan Mishra <[e-mail]>]

Hi Greg

Welcome!

Responses in-line Gyan2>

On Tue, Oct 3, 2023 at 5:46 AM Greg Mirsky <[e-mail]> wrote:

> Hi Gyan,
> thank you for the review and your helpful suggestions. Please find my
> notes below under the GIM>> tag.
>
> Regards,
> Greg
>
> On Tue, Oct 3, 2023 at 7:15 AM Gyan Mishra <[e-mail]> wrote:
>
>>
>> Dear authors
>>
>> Below is a review of this draft.
>>
>> I think it would be good to explain what a controlled versus not
>> controlled environment is and could be a simple sentence of single
>> administrative domain versus inter domain over public Internet.
>>
> GIM>> Would the following update in the Introduction make the text
> sufficiently clear:
> OLD TEXT:
>    Furthermore, [RFC6398] identifies security vulnerabilities associated
>    with the RAO in non-controlled environments, e.g., the case of using
>    the MPLS echo request/reply as inter-area OAM, and recommends against
>    its use outside of controlled environments.
> NEW TEXT:
>    Furthermore, [RFC6398] identifies security vulnerabilities associated
>    with the RAO in non-controlled environments, e.g., the case of using
>    the MPLS echo request/reply as inter-domain OAM over the public
>    Internet, and recommends against its use outside of controlled
>    environments, e.g., outside a single administrative domain.
>
>>
     Gyan> Perfect

>
>> There are three options available for the LSP ping so as we are
>> deprecating the use of LSP ping with ROA both the link local and TTL=1
>> should be valid options.
>>
> GIM>> As I understand the intent of IP/UDP encapsulation of MPLS echo
> request/reply messages, using the IP loopback address as the IP destination
> address serves as the exception mechanism. The TTL-based exception is used
> but for the MPLS underlay network.
>

Gyan2>  I think section 2.1 mentions those 3 options and that they are all
required to prevent route leaking past the egress LSR as defined in RFC
8029 which updates RFC 4379.  My understanding is that the link local
loopback is used in conjunction with TTL value to prevent the leaking of
packets beyond the egress LER and that is how it’s implemented by most
vendors example of link from Cisco and Juniper implementation both of which
don’t use RAO.   RFC 6424 talks about MPLS Ping and deprecation of DSMAP to
use DDMAP TLV which I think maybe relevant that with DDMAP TLV on the MPLS
Echo reply message and I believe with the DDMAP TLV the need for RAO
signaled in the control plane is not necessary.

https://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/200510-Trace-route-in-MPLS-network.html#anc7

https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/topic-map/troubleshooting-mpls.html


>> RFC 5082 GTSM talks about TTL spoofing and that 255 is hard to spoof
>> opposed to TTL 1.  It maybe a good idea to mention that link local is the
>> recommendation and reasons why TTL 1 is not recommended option due to
>> spoofing.
>>
> GIM>> It is not clear to me how a link-local address can be used in IP/UDP
> encapsulation of an MPLS echo request/reply message. Could you kindly give
> an example of the encapsulation?
>
>>
     Gyan>. See the two links from Cisco and Juniper implementations.  See
RFC 8029 section 3.

>
>> This draft below on deprecating IPv6 RAO option goes into more detail and
>> reason why due to issue with HBH EH and RAO bring a HBH option makes it a
>> security risk to use HBH.  This draft has some more detail about control
>> plane and forwarding plane Figure 1 that could be applicable to LSP ping
>> RAO depreciation draft as well.
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-bonica-6man-deprecate-router-alert-00
>>
> GIM>> It seems like replicating information may not be the most efficient
> WoW.  I'll discuss with Ron plans for the work in 6man and if referencing
> it in the MPLS draft is useful.
>
>>
>>
>> Thank you
>>
>> Gyan
>>
>>
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>