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

Gyan Mishra <> Wed, 04 October 2023 16:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 285EEC15152D for <>; Wed, 4 Oct 2023 09:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gcBsvlrHs8IM for <>; Wed, 4 Oct 2023 09:02:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 4A395C15107E for <>; Wed, 4 Oct 2023 09:02:18 -0700 (PDT)
Received: by with SMTP id d75a77b69052e-41959feaae2so14910891cf.0 for <>; Wed, 04 Oct 2023 09:02:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1696435337; x=1697040137;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tOE6mpo44PLHXw9MmH0kZt71gvw4eR+ODhB79+2ZLco=; b=Zyxkx2JhgBUAznFJ3zBWlAT9z0T1BWwxUxxVWCP6X1paE32FoP5pVDsndPphDG/bmp bgfHf112JCLZspHE+M+gjRpjPN6eNCLAhWn5ioXJknN6MndSCZuBh6hVSR5fUIhF5hyK UQYOaLzQVDNWZRX3Tz7qmpRQPoZ/czHxF4p/s6F/3FpD3BtbeMU1Dt4+r236ckbJf0XE cbgd1QkeXCgIz6rslunWejpuaDi76l843JLfN6CnNCKnkFZOG4Yk/GCh9QrwefJO7e4Q ilB4ACgwhEUJ0rkLBy7QpIr8ldKToB23f+e4L38vcQ2/pXBKYqYLKBDoava27noe4f1+ nRJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1696435337; x=1697040137; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tOE6mpo44PLHXw9MmH0kZt71gvw4eR+ODhB79+2ZLco=; b=ptH0dsUv+1nCKZ9y42eJecXAlWSmrd++iPW3kcguJfc+oAC2rmISkbAhdW98UfGPxm V5H9s/R6FZQALNCgpufr53ubnIW8oBwcEt18iSavkdBJ81+3tzPabI4NqI1fCnvPxgxg Dzzd6bxg7dT7/LvVbilGB8XYByBcKKoVXZvAGQmBCCvUH0V5MzNSxdKCHpSV1mdUgxvZ m+DaSxltjlJS7fRviNA3KMUkInu70OjPHQP15ZJ6r8X0ScDdNLtCRd+fntac08/BSCod 873Ug9Wba2/pM0Uj/Sj/ENQHjkqfnzDf8cYMLCvvqwUrr/9AmPpbJRyqxEGveKsMpQp5 CoYg==
X-Gm-Message-State: AOJu0YxN/3Ejn5WNFZXRnJu0ZLTs80uZ6HHbcUSSMCIcjnFQP4UNVMhl EBvU98tORvHFIyUjeSlqRsFeU3XsyepD+l3s+BEysDhLgjc=
X-Google-Smtp-Source: AGHT+IEFU3iyIdGQG+2U3aE2s24mSN+90A6sO00TJFK1ZyL4zQAvwHkck47w58yMDa9BYodgDSbPlYRdS5xly+Q7PhI=
X-Received: by 2002:ac8:7f86:0:b0:418:111e:7910 with SMTP id z6-20020ac87f86000000b00418111e7910mr2837990qtj.43.1696435336932; Wed, 04 Oct 2023 09:02:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Wed, 04 Oct 2023 12:02:06 -0400
Message-ID: <>
To: Greg Mirsky <>
Cc: mpls <>
Content-Type: multipart/alternative; boundary="000000000000a472ad0606e6214c"
Archived-At: <>
Subject: Re: [mpls] draft-ietf-mpls-lspping-norao-03 - Review
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Oct 2023 16:02:22 -0000

Hi Greg

Most welcome.  See Gyan3>

On Wed, Oct 4, 2023 at 3:41 AM Greg Mirsky <> wrote:

> Hi Gyan,
> thank you for the abundant information you've shared with me; most
> helpful. Please find my follow-up notes in-lined below under the GIM2>> tag.
> Regards,
> Greg
> On Tue, Oct 3, 2023 at 5:53 PM Gyan Mishra <> wrote:
>> Hi Greg
>> Welcome!
>> Responses in-line Gyan2>
>> On Tue, Oct 3, 2023 at 5:46 AM Greg Mirsky <> 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 <>
>>> 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:
>>>    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.
>>>    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.
> GIM2>> Thank you for pointing to Section 2.1 of the
> draft-ietf-mpls-lspping-norao. Indeed, using a loopback address as the IP
> destination (although IPv6 is not a real IPv6 loopback address), TTL/Hop
> count == 1, and RAO are all required, despite the fact that each one is
> sufficient to prevent the leaking of the IP/UDP encapsulated MPLS echo
> request/reply message. As you've noted, it seems like Cisco and
> Junper implementations do not use RAO.

     Gyan3> Minor point to note that both Cisco and Juniper implementations
use both loopback 127/8 along with TTL to control the route leak past the
egress LSR.  However as you mentioned if TTL=1 were used by itself that
would suffice and even if the loopback 127/8 were used that would suffice
and prevent the leakage of packets.  So definitely no need for RAO
additional is overkill and as well it’s adverse control plane impact.

>>>> 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.
> GIM2>> Indeed, GTSM recommends setting TTL/Hop Count value to 255 for an
> encapsulated packet. On the other hand, IP TTL expiration is one of the
> triggers to punt MPLS echo request message to the control plane. As I
> understand it, RFC 8029 requires that IP TTL/Hop Count value is set to 1.
> This draft does not change that but only removes the required use of RAO in
> the IP/UDP encapsulation, leaving two other mechanisms in tact. I am not
> sure that changing the setting of the IP TTL value to 1 would not cause
> some significant interoperability issues.

     Gyan3>  Agreed.

>>>> 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.
>>> 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
            Gyan3> Sounds good

>>>> Thank you
>>>> Gyan
>>>> _______________________________________________
>>>> mpls mailing list