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

Gyan Mishra <hayabusagsm@gmail.com> Wed, 04 October 2023 16:02 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285EEC15152D for <mpls@ietfa.amsl.com>; Wed, 4 Oct 2023 09:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcBsvlrHs8IM for <mpls@ietfa.amsl.com>; Wed, 4 Oct 2023 09:02:18 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [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 ietfa.amsl.com (Postfix) with ESMTPS id 4A395C15107E for <mpls@ietf.org>; Wed, 4 Oct 2023 09:02:18 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id d75a77b69052e-41959feaae2so14910891cf.0 for <mpls@ietf.org>; Wed, 04 Oct 2023 09:02:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696435337; x=1697040137; darn=ietf.org; 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; d=1e100.net; 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: <CABNhwV3veuOeyJS_C+fn5WuM7CqdwN1kacDitPMYHaq1su_ZbA@mail.gmail.com> <CA+RyBmX2Yw2NTuLc+vcJ99+hJrjYi3wGSxcFD5-ztwSzd+9OpA@mail.gmail.com> <CABNhwV08PBWJmVMJO5eDQbiXrNfMMmPcu0zgXicS-FKLbNLR1w@mail.gmail.com> <CA+RyBmVc+Qs1mYO_btsyr88pcw6Osuhki0eA9aRYpOT5_jvX3g@mail.gmail.com>
In-Reply-To: <CA+RyBmVc+Qs1mYO_btsyr88pcw6Osuhki0eA9aRYpOT5_jvX3g@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 04 Oct 2023 12:02:06 -0400
Message-ID: <CABNhwV2POKT7VTaUHALqiZ+4RQw6Jg7-P93Ehb-jy-QVBaUQuw@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: mpls <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a472ad0606e6214c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/ep0wB5A1ToYl5LRX88CAzhpM87Q>
Subject: Re: [mpls] draft-ietf-mpls-lspping-norao-03 - Review
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=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 <gregimirsky@gmail.com> 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 <hayabusagsm@gmail.com> wrote:
>
>>
>> Hi Greg
>>
>> Welcome!
>>
>> Responses in-line Gyan2>
>>
>> On Tue, Oct 3, 2023 at 5:46 AM Greg Mirsky <gregimirsky@gmail.com> 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 <hayabusagsm@gmail.com>
>>> 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
>>
> 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.
>>>>
>>>>
>>>> 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
>>>
>>
            Gyan3> Sounds good

>
>>>> Thank you
>>>>
>>>> Gyan
>>>>
>>>>
>>>> _______________________________________________
>>>> mpls mailing list
>>>> mpls@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>
>>>