From nobody Fri Apr 14 15:23:45 2023 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBBFC14CE40; Fri, 14 Apr 2023 15:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 weWJX3U1MvX9; Fri, 14 Apr 2023 15:23:40 -0700 (PDT) Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) (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 243D0C14CF1B; Fri, 14 Apr 2023 15:23:40 -0700 (PDT) Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-54fc337a650so116932667b3.4; Fri, 14 Apr 2023 15:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681511019; x=1684103019; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mS9DbP7M7QnQE54rQ8nKAOoWuLGW259Hhi7WoZH+j1s=; b=ji+vuMV6Va+4ZSUwjozsDEG5w9xhvQ6r065Z3uMZ4OWbqb2zAcWpsxbIPZ6NLFCkix xrRjX8fIZnJAFU1gKKLTG3SertfCG6mioCLJuNHPd0/TR7/zMsPzbN8kctrqQre6HuX+ ldfzbokeRCe26weCKBZz9sIZZ/E/DVqYlUuZgpDsNg4j8ne6bTfr9cBoq+s2fu6ZK8nq uPoLJ8fIctXYQIG6CVpEf/yjuNCvyZOQ7iyt2obHSAUjVWmKzbguCTDwvnge5FO42XJp xVnufea6DOjt8yyPQAz0tmF1qToNNz8/76MoXMo1D0oYb/2HNG1jNPOlKmB6ZW3N/9r1 LkvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681511019; x=1684103019; 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=mS9DbP7M7QnQE54rQ8nKAOoWuLGW259Hhi7WoZH+j1s=; b=HuyDBzNaEgFKYNI21rUk9vujfSrGpf4cO/98kJfGo/8YOVe/eCC2vk5ibN2N2WykzN 9BlfYHwq1trGjkO5xvvJOKVNXVC/+Ncvo07yym4f7tIplmtiB/vdIxjVgbYFD1KrNURj CpsM3CmZdIQpnyhmmrpH6uQ+fdsshD1QTuDdR1NbOjKRWWpdjS/Yh2iTn8ToLODbiVWh 68BZs8fOKwvVR3i8maqFgSJZDuriUboPKMFm9lIGtk3A9fDcZlDHYkcD5xmG8R1OZd6N BrMLLTh4DYFLi2BFmZrOj7Ru2cT4c9HoJBrB5oDG8sN/d2FaN9m3yFOG9Kos0lue3Ctj 1avQ== X-Gm-Message-State: AAQBX9d37v3aKVsWFHUG8pnKCTzW24a9y4q6i0ceBeHSI2lkhxnsTQ/8 7fJQ/yGiMVRdv8f/606XEZAcEvwBEkkxwCm/7kst8k/7 X-Google-Smtp-Source: AKy350Y72AwT5nzFikJlz1HADDbAliDM+B5dU2isJ1dEZXUDsX/TG3P2D8Jpfd8xA8t9AM0CwQpuLUYGbMEnKVG/ye8= X-Received: by 2002:a81:4415:0:b0:54f:9718:1d39 with SMTP id r21-20020a814415000000b0054f97181d39mr4681319ywa.0.1681511018979; Fri, 14 Apr 2023 15:23:38 -0700 (PDT) MIME-Version: 1.0 References: <196C9D52-E144-4EFA-A25B-2453122DCB13@pfrc.org> <9D4C734F-2D1A-4A2C-B452-0920B7101618@pfrc.org> In-Reply-To: <9D4C734F-2D1A-4A2C-B452-0920B7101618@pfrc.org> From: Greg Mirsky Date: Fri, 14 Apr 2023 15:23:27 -0700 Message-ID: Subject: Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check To: Jeffrey Haas Cc: draft-ietf-bfd-unaffiliated-echo@ietf.org, rtg-bfd WG Content-Type: multipart/alternative; boundary="000000000000f8e83705f9534acc" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2023 22:23:44 -0000 --000000000000f8e83705f9534acc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jeff, thank you for your kind consideration of the proposal. Indeed, leaving a chunk of memory unchanged is a privacy issue. As I understand the proposal, none of the fields defined in RFC 5880 for the BFD Control message is used for demultiplexing BFD sessions and/or packet validation. Is that correct? If that is the case, what is the need to use the BFD Control message altogether? And one more step, What is the benefit of using a well-known BFD Echo UDP port number? I believe that using a well-known port increases the security risk rather than bringing any benefits. From what I understand in the application of the mechanism, the sender can use a UDP port number assigned from the dynamic/private range of port numbers. And the payload can be anything, i.e., filled with bit pattern randomly chosen by the Sender. Am I missing something? Regards, Greg On Thu, Apr 13, 2023 at 1:13=E2=80=AFPM Jeffrey Haas wrote= : > Greg, > > In general, I think your clarifications are helpful. > The one point I have minor disagreement is "SHOULD be > populated/initialized" ... to what? > One option is "an expected value". > Personally, I'd find "an expected value. A suggested value is ..." and us= e > the defaults below. > > That said, I don't have a strong opinion that we must use some magic > value. My desire is that we avoid unset values being a potential vector > for disclosure of uninitialized memory. > > -- Jeff > > On Apr 12, 2023, at 4:10 PM, Greg Mirsky wrote: > > Hi Jeff, > thank you for your response. It seems to me that the values of these > fields are implementation specific and don't impact interoperability. If > that is correct, then I propose the following updates: > OLD TEXT: > Within the BFD Unaffiliated Echo packet, the "Desired Min TX > Interval" and "Required Min RX Interval" defined in [RFC5880] SHOULD > be populated with a value of 1 second (1,000,000 microseconds). > These values, however, are ignored and not used to calculate the > Detection Time. > NEW TEXT: > Within the BFD Unaffiliated Echo packet, the "Desired Min TX > Interval" and "Required Min RX Interval" defined in [RFC5880], SHOULD > be initialized before the transmission and MUST be ignored on receipt. > Furthermore, these values MUST NOT be used to calculate the > Detection Time. > > OLD TEXT: > The "Required Min Echo RX Interval" defined in [RFC5880] MUST be set > to zero. > NEW TEXT: > The "Required Min Echo RX Interval" defined in [RFC5880] SHOULD be set > before the transmission and MUST be ignored upon receipt. > > Regards, > Greg > > > On Wed, Apr 12, 2023 at 8:00=E2=80=AFAM Jeffrey Haas wro= te: > >> Greg, >> >> Flipping the question around somewhat: >> >> These portions of the PDU will be serialized onto the wire. >> An implementation could choose values locally to help its own >> procedures. Perhaps for heuristic tuning of the session. So, there's >> argument for "these values are left to the implementation" - or as you n= ote >> "this value is ignored". >> >> What text would YOU want to see present in this draft? >> >> In the absence of an implementation having an opinion about the behavior >> for its own purposes, I believe we want some boring "expected" value >> minimally as implementation advice. IMO, that's one step nicer than >> whatever memory noise is left from your allocated buffer that might >> disclose something unexpected from your implementation internals. (See >> various virtualized host environment bugs relating to memory ownership.) >> >> -- Jeff >> >> >> >> >> On Apr 12, 2023, at 10:22 AM, Greg Mirsky wrote: >> >> Dear, Authors and all, >> my apologies for the belated comments. I greatly appreciate your >> consideration of the notes below: >> >> - Given that it is stated that the values of "Desired Min TX >> Interval" and "Required Min RX Interval" in an Unaffiliated BFD Echo >> message are ignored, what do you see as the value of using the normat= ive >> language in: >> >> Within the BFD Unaffiliated Echo packet, the "Desired Min TX >> Interval" and "Required Min RX Interval" defined in [RFC5880] SHOULD >> be populated with a value of 1 second (1,000,000 microseconds). >> >> >> - As I understand it, the "Required Min Echo RX Interval" value is >> not used in the Unaffiliated BFD Echo. If that is the case, what do y= ou see >> as the value of requiring it to be zeroed: >> >> The "Required Min Echo RX Interval" defined in [RFC5880] MUST be set >> >> to zero. >> >> Perhaps stating that the "Required Min Echo RX Interval" value is ignore= d >> in the Unaffiliated BFD Echo is sufficient. WDYT? >> >> >> Regards, >> Greg >> >> On Mon, Apr 10, 2023 at 8:27=E2=80=AFAM Jeffrey Haas wr= ote: >> >>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo >>> >>> Working Group, >>> >>> The Working Group Last Call for draft-ietf-bfd-unaffiliated-echo has >>> completed. My judgment is that it has weak, but positive support to >>> proceed to publication. This isn't atypical of BFD work at this point = in >>> the BFD Working Group's life. >>> >>> The next steps for the document: >>> >>> 1. Please continue to iterate through the issues raised during last >>> call. I will be summarizing them in the original WGLC thread. I suspe= ct >>> we can reach conclusion for them shortly. >>> >>> 2. Each of the authors needs to make an attestation as to whether >>> they're aware of any additional IPR applicable to this document. The r= est >>> of the Working Group, as per BCP 78/79[1] should also disclose of any >>> applicable IPR if they're aware of it. >>> >>> One thing that makes this document particularly interesting is that thi= s >>> work is covered partially under work done in BBF in TR-146. This will = be >>> noted in the shepherd writeup. >>> >>> >>> -- Jeff >>> >>> [1] https://www.rfc-editor.org/rfc/rfc8179.html#section-5.1 >>> >>> >>> >> > --000000000000f8e83705f9534acc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
thank you for your kind consideration of the = proposal. Indeed, leaving a chunk of memory unchanged is a privacy issue. A= s I understand the proposal, none of the fields defined in RFC 5880 for the= BFD Control message is used for demultiplexing BFD sessions and/or packet= =C2=A0validation. Is that correct? If that is the case, what is the need to= use the BFD Control message altogether? And one more step, What is the ben= efit of using a well-known BFD Echo UDP port number? I believe that using a= well-known port increases the security risk rather than bringing any benef= its. From what I understand in the application of the mechanism, the sender= can use a UDP port number assigned from the dynamic/private range of port = numbers. And the payload can be anything, i.e., filled with bit=C2=A0patter= n=C2=A0randomly chosen by the Sender. Am I missing something?
Regards,
Greg

On Thu, Apr 13, 2023 at 1:13=E2=80= =AFPM Jeffrey Haas <jhaas@pfrc.org= > wrote:
Greg,

In general, = I think your clarifications are helpful.
The one point I have min= or disagreement is "SHOULD be populated/initialized" ... to what?=
One option is "an expected value".
Personall= y, I'd find "an expected value. A suggested value is ..." and= use the defaults below.

That said, =C2=A0I don= 9;t have a strong opinion that we must use some magic value.=C2=A0 My desir= e is that we avoid unset values being a potential vector for disclosure of = uninitialized memory.

-- Jeff

On Apr 12, 2023, at 4:10 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Jeff,
thank you for your respo= nse. It seems to me that the values of these fields are implementation spec= ific and don't impact interoperability. If that is correct, then I prop= ose the following updates:
OLD TEXT:
=C2=A0 =C2=A0= Within the BFD Unaffiliated Echo packet, the "Desired Min TX
=C2=A0 =C2=A0Interval" and "Required Min RX Interval" defin= ed in [RFC5880] SHOULD
=C2=A0 =C2=A0be populated with a value of = 1 second (1,000,000 microseconds).
=C2=A0 =C2=A0These values, how= ever, are ignored and not used to calculate the
=C2=A0 =C2=A0Dete= ction Time.
NEW TEXT:
=C2=A0 =C2=A0Within th= e BFD Unaffiliated Echo packet, the "Desired Min TX
=C2=A0 = =C2=A0Interval" and "Required Min RX Interval" defined in [R= FC5880], SHOULD
=C2=A0 =C2=A0be initialized before the transmissi= on and MUST be ignored on receipt.
=C2=A0 =C2=A0Furthermore, thes= e values MUST NOT be used to calculate the
=C2=A0 =C2=A0Detection= Time.

OLD TEXT:
=C2=A0 =C2= =A0The "Required Min Echo RX Interval" defined in [RFC5880] MUST = be set
=C2=A0 =C2=A0to zero.=C2=A0=C2=A0
NEW TEXT= :
=C2=A0 =C2=A0The "Required Min Echo RX Interval"= defined in [RFC5880] SHOULD be set
=C2=A0 =C2=A0before the trans= mission and MUST be ignored upon receipt.=C2=A0=C2=A0

<= /div>
Regards,
Greg


On Wed, Apr 12, 2023 at 8:00=E2=80=AFAM Jeffrey Haas <jhaas@pfrc.org> wrote:
Greg,

Flipping the question around somewhat:=C2=A0

These portions of the PDU will be serialized onto the wire.
An i= mplementation could choose values locally to help its own procedures.=C2=A0= Perhaps for heuristic tuning of the session.=C2=A0 So, there's argumen= t for "these values are left to the implementation" - or as you n= ote "this value is ignored". =C2=A0

What= text would YOU want to see present in this draft?

In the absence of an implementation having an opinion about the behavior f= or its own purposes, I believe we want some boring "expected" val= ue minimally as implementation advice.=C2=A0 IMO, that's one step nicer= than whatever memory noise is left from your allocated buffer that might d= isclose something unexpected from your implementation internals. =C2=A0(See= various virtualized host environment bugs relating to memory ownership.)

-- Jeff



On Apr 12, 2023, at 10:22 AM, Greg= Mirsky <greg= imirsky@gmail.com> wrote:

D= ear, Authors and all,
my apologies for the belated comments. I greatly = appreciate your consideration of the notes below:
  • Given = that it is stated that the values of "Desired Min TX Interval" an= d "Required Min RX Interval" in an Unaffiliated BFD Echo message = are ignored, what do you see as the value of using the normative language i= n:
=C2=A0 =C2=A0Within the BFD Unaffiliated E= cho packet, the "Desired Min TX
=
=C2=A0 =C2=A0Interval" and "Required Min RX Interval" d= efined in [RFC5880] SHOULD
=C2= =A0 =C2=A0be populated with a value of 1 second (1,000,000 microseconds).
<= ul>
  • As I understand it, the=C2=A0"Required Min Echo RX Interval&quo= t; value is not used in the Unaffiliated BFD Echo. If that is=C2=A0the case= , what do you see as the value of requiring it to be zeroed:
    • =C2=A0 =C2=A0The "Required Min Echo RX Interval= " defined in [RFC5880] MUST be set
    =
    =C2=A0 =C2=A0to zero.=C2=A0=C2=A0
    = Perhaps stating that the "Required Min Echo RX Interval" value is= ignored in the Unaffiliated BFD Echo is sufficient. WDYT?

    Regards,
    Greg

    On Mon, Apr 10, 20= 23 at 8:27=E2=80=AFAM Jeffrey Haas <jhaas@pfrc.org> wrote:
    = https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo<= br>
    Working Group,

    The Working Group Last Call for draft-ietf-bfd-unaffiliated-echo has comple= ted.=C2=A0 My judgment is that it has weak, but positive support to proceed= to publication.=C2=A0 This isn't atypical of BFD work at this point in= the BFD Working Group's life.=C2=A0

    The next steps for the document:

    1. Please continue to iterate through the issues raised during last call.= =C2=A0 I will be summarizing them in the original WGLC thread.=C2=A0 I susp= ect we can reach conclusion for them shortly.

    2. Each of the authors needs to make an attestation as to whether they'= re aware of any additional IPR applicable to this document.=C2=A0 The rest = of the Working Group, as per BCP 78/79[1] should also disclose of any appli= cable IPR if they're aware of it.

    One thing that makes this document particularly interesting is that this wo= rk is covered partially under work done in BBF in TR-146.=C2=A0 This will b= e noted in the shepherd writeup.


    -- Jeff

    [1] https://www.rfc-editor.org/rfc/rfc8179.ht= ml#section-5.1




    --000000000000f8e83705f9534acc--