Re: [v6ops] WGLC for draft-ietf-v6ops-hbh-05

Tom Herbert <tom@herbertland.com> Tue, 28 November 2023 18:13 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA74C151525 for <v6ops@ietfa.amsl.com>; Tue, 28 Nov 2023 10:13:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland.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 eftKeikrsGQD for <v6ops@ietfa.amsl.com>; Tue, 28 Nov 2023 10:13:07 -0800 (PST)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 246F9C151539 for <v6ops@ietf.org>; Tue, 28 Nov 2023 10:13:06 -0800 (PST)
Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-54917ef6c05so7728653a12.1 for <v6ops@ietf.org>; Tue, 28 Nov 2023 10:13:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1701195185; x=1701799985; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=R17qlBIK/sgeTATFMuTihD5B5NezBOL1yScXGwQ7pYo=; b=gbQgHLvv8oG2DuGdOj6Bo+XB1ZAlSyQno8CQ6ODLtFp1VSBrvp7sfVCQpkDfboKx4+ n+DokeN/Ak4E4mONCvZ3Aj0PuDLklbI9IAw9uJjoYByA12XmHPRLZODBsqeJ2Tq4UAYN rfMqgdSiTkNA+isjC4J08LOgMis/crw7njFR2dUfgTcUQMwr9dhpgVjSmmv0s+lofCMo SSWes57y6KJ+MwG8RrWbyBXWpN1bmbE3BxM+VHbSlf7keBuAJCNonlV/vzxH3tEHQLe8 sxLhM2iY1Emxw+TkwrttLxP0lLi7vlVKhovZ/s4bbGJnb36OQIg/EAlQZ0aJZNGh5/Zi 7qOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701195185; x=1701799985; h=content-transfer-encoding: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=R17qlBIK/sgeTATFMuTihD5B5NezBOL1yScXGwQ7pYo=; b=BGj1RzzQ7+HfF+ycifO5fBVuBiKf6EujfizzIg81AVNaXW9Eik11Rj4OcoQoC3blCF YpFYmZcOB0v3n4ukXjoqbAUY338LntlIvxMlSlIcJ/5WTEN+kUWzdCdJrpnXNuuwsa8G RwtNw8OMcIL0SP0JmZfROml5+ibtZywgtlNhF/BkfoZWinXJbnTO94XOIVz39vM+K1Jw s1w39XIjlrkGAByC5FaiEbwGLvKDAksJ13Nsj/uUFCuomAyw3FvfdpwBVSNxuyRdMztB KUwjMliVUqaTj5QichDPH486jsIDNooQozT+smiMV68nyS+lwPFSziJtWo2c7RIpcic8 4aRA==
X-Gm-Message-State: AOJu0YzIlV3G8MDIGihCyxPuCKFntR9nJTxsRUbiN/y9hoeDSgUckVvL T2OIrvBMZsmUKm0tsNWZTVriBHCE4ELJJbPiCmnvYg==
X-Google-Smtp-Source: AGHT+IGh5o0llTnTG4xUDeOPR8paL0N6r9z/G8gIHsKlEuPt5+UAWkrOj9YPsqFRPNlxx0QOPDfQoHEBZimVyxSwjgE=
X-Received: by 2002:a05:6402:2207:b0:54b:25e8:c009 with SMTP id cq7-20020a056402220700b0054b25e8c009mr7685035edb.0.1701195184608; Tue, 28 Nov 2023 10:13:04 -0800 (PST)
MIME-Version: 1.0
References: <1d22666296d545a7b36898adf300c700@huawei.com> <CALx6S37g9kyvokw9UpMcbp7M_K9UPUeHFeH654r60+QRAvxq2Q@mail.gmail.com> <0fdb7e4fb5cd4c5983370f80af24de10@huawei.com> <CALx6S36uL8o3E0cX+40WgTGB8dt+AgfXS23DB6Ofv6nR3_RwpA@mail.gmail.com> <6b298e71f0454ac289af02d13da3babf@huawei.com> <CALx6S37W3oxMWuO-P=moAp6_qdcH=Rg0OQ=3DQSF=foiT+AF9A@mail.gmail.com> <587d42738b4540168c66730fef853aa9@huawei.com>
In-Reply-To: <587d42738b4540168c66730fef853aa9@huawei.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 28 Nov 2023 10:12:53 -0800
Message-ID: <CALx6S37=HZA8osEjqWNwv19OCXRBWF0XJ=Xx7sqz3DqNcc+Mvw@mail.gmail.com>
To: "Pengshuping (Peng Shuping)" <pengshuping=40huawei.com@dmarc.ietf.org>
Cc: Xipengxiao <xipengxiao@huawei.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/obSkZnNagvkJP0n_Omqwbges5S0>
Subject: Re: [v6ops] WGLC for draft-ietf-v6ops-hbh-05
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Nov 2023 18:13:11 -0000

On Fri, Nov 24, 2023 at 7:20 PM Pengshuping (Peng Shuping)
<pengshuping=40huawei.com@dmarc.ietf.org> wrote:
>
> Hi Tom,
>
> Thank you for the comments and suggestions. Please find the responses in line.

Hi Shuping, please see my responses in line.

>
> -----Original Message-----
> From: Tom Herbert <tom=40herbertland.com@dmarc.ietf.org>
> Sent: Saturday, November 25, 2023 12:11 AM
> To: Pengshuping (Peng Shuping) <pengshuping@huawei.com>
> Cc: Xipengxiao <xipengxiao@huawei.com>; v6ops@ietf.org
> Subject: Re: [v6ops] WGLC for draft-ietf-v6ops-hbh-05
>
> Hi Shuping,
>
> Thanks for the updated draft. Here are some comments...
>
> In the terminology section I think it's better to provide the definitions even if it's just copying from another document.
>
> >From the draft: "Many of the packet-processing devices employed in
> current router designs are fixed-function ASICs that handle common
> functions."-- I believe this landscape may be changing with the emergence of programmable datapaths like P4 offers. These offer more flexibility than an ASIC, but we still want to allow pragmatic limits on processing-- while TLV processing becomes programmable, it is still pretty costly since it is inherently serialized processing, variable length, and combinatorial.
>
> Shuping>
>
> OLD: Many of the packet-processing devices employed in current router designs are fixed-function ASICs that handle common functions.
>
> NEW: Besides programmable datapaths, many of the packet-processing devices employed in current router designs are fixed-function ASICs that handle common functions.

How about: Many of the packet-processing devices employed in current
router designs are fixed-function ASICs that handle common functions,
however there is a trend towards programmable device datapaths such as
P4.

with a reference to P4.

>
> >From the draft: "[RFC8504] defines the IPv6 node requirements and how
> to protect a node from excessive header chain and excessive header options with various limitations that can be defined on a node."-- The
> RFC8504 requirements only apply to hosts. The eh-limits draft is applicable to routers. I suggest you reference that draft instead here.
>
> Shuping>
>
> OLD: [RFC8504] defines the IPv6 node requirements and how
> to protect a node from excessive header chain and excessive header options with various limitations that can be defined on a node.
>
> NEW: [I-D.ietf-6man-eh-limits] defines the IPv6 router requirements and how to protect a router from excessive header chain and excessive header options with various limitations that can be defined on a router, while [RFC8504] defines the requirements of a host.

Okay

>
> >From the draft: "Each Option is encoded in a TLV and so processing of
> a long list of TLVs is expensive. Zero data length encoded options TLVs are a valid option. A DOS vector could be easily generated by encoding 1000 HBH options (Zero data length) in a standard 1500 MTU
> packet."-- Minimum length of a TLV is two bytes, so we couldn't fit
> 1000 of those into a 1500 byte packet. I believe the maximum number is
> 728 in that case. Still plenty to be an effective DOS attack!
>
> Shuping>
>
> OLD: Each Option is encoded in a TLV and so processing of a long list of TLVs is expensive. Zero data length encoded options TLVs are a valid option. A DOS vector could be easily generated by encoding 1000 HBH options (Zero data length) in a standard 1500 MTU packet.
>
> NEW: Each Option is encoded in a TLV and so processing of a long list of TLVs is expensive. Zero data length encoded options TLVs are a valid option with a minimum length of two bytes. A DOS vector could be easily generated by encoding around 700 HBH options (Zero data length) in a standard 1500 MTU packet.
>
Okay

> >From the draft: "Because of these likely uncertain processing
> behaviors, new hop-by-hop options are not recommended."-- not recommended by whom? Seems like the purpose of this draft is to address the issues so we can undo that recommendation. Maybe a reference is needed here?
>
> Shuping> It is RFC8200, the 3rd paragraph in Section 4.8 https://datatracker.ietf.org/doc/html/rfc8200#section-4.8
>
> OLD: Because of these likely uncertain processing behaviors, new hop-by-hop options are not recommended.
>
> NEW: Because of these likely uncertain processing behaviors, new hop-by-hop options are not recommended and requires very clear justifications of their needs [RFC8200].

I missed that in RFC8200. Personally, I think that's a somewhat weak
recommendation as there are a number of proposals for new Hop-by-Hop
Options including one by an author of RFC8200 :-). Also, the part
about any new Hop-by-Hop Options requiring "very clear justifications
of their needs" would be true of any protocol in IETF I would think. I
suggest just removing this sentence altogether.

>
> >From the draft: "Current routers deployed by operators usually process
> an IPv6 packet that has a Next Header field set to 0 by directly forwarding it to the control plane of the node."-- is there a reference for this? On the Internet at least the data seems to show that HBH is universally dropped more as a matter of policy not necessarily device limitiations.
>
> Shuping> This information is provided by operators, that is, when those devices find that the incoming packet is an IPv6 packet with HBH options header it will directly send the packet to the control plane. That is why they then have the policy at the edge to block such packets.

It's still lacking a reference. RFC9098 states "The Hop-by-Hop Options
header has been particularly challenging since, in most circumstances,
the corresponding packet is punted to the control plane for
processing.", although that doesn't really have a reference or data
supporting "in most circumstances" So minimally, that RFC could be
referenced here.
>
> >From the draft: "the IPv6 HBH options could be used as a DOS attack
> vector for both the operator nodes, adjacent inter-AS peer nodes as well as customer nodes along a path."--  I believe that's why HBH are dropped on the Internet. It's enforcing a security policy where operators are protecting their network infrastructure since HBH targets routers and not just end hosts. Given the apparent pervasiveness of this policy, I believe it's unlikely we'll be able to roll it back to HBH ever make it completely usable over the Internet.
> However, HBH options are going to be most useful in limited domains so we do need to address the router issues with them described in the draft (IOAM is a great example of a useful HBH option that only makes sense in a limited domain).
>
> Shuping> Agree.
>
> >From the draft" "Due to such behaviors observed and described in these
> specifications, [RFC8200] did not recommend new HBH Options"-- I don't see where this is stated in RFC8200, maybe I'm missing it.
>
> Shuping> The 3rd paragraph in Section 4.8 https://datatracker.ietf.org/doc/html/rfc8200#section-4.8

See my comments above

>
> >From the draft: "Besides service providers' networks, other sectors
> such as industrial IoT networks are slowly replacing a dozen of semi-proprietary protocols in industrial automation into IP. The proper processing of the HBH options header is also required."-- this seems a little bit vague and no specific protocols are mentioned.
> Probably could be removed.
>
> Shuping> I can add this draft as reference, draft-pthubert-detnet-ipv6-hbh.
> https://datatracker.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh-07

Okay

>
> >From the draft: "Here are some design principles for HBH Options
> Header and its carrying Options."-- IMO, these are pretty generic design principles and a little on the vague side, For instance: "HBH Options need to be designed in a manner so that they don't reduce the probability of packet delivery." What does this mean to someone designing a HBH option? Also, considering that RFC8200 allows routers to ignore HBH options, adding a new option with 00 in the upper bits of type shouldn't impact the probability of delivery any more than any existing option that can be ignored.
>
> The exception is that length does matter and defining a new option with a big length potentially could reduce probability of delivery even if it's unsupported by all nodes (contributes to the IPv6 header chain length and packet headers not fitting in parsing buffers). If we apply the limits in eh-limits, we could recommend that new options SHOULD have a data length of 60 bytes or less.
>
> Shuping>
>
> OLD: HBH Options need to be designed in a manner so that they don't reduce the probability of packet delivery.
>
> NEW: HBH Options need to be designed in a manner so that they don't reduce the probability of packet delivery, especially in length limit

Okay. Also, please change "an HBH Option MUST NOT cause control plane
state to be created" to "an HBH Option must not cause control plane
state to be created"-- design principles are not normative
requirements

Tom

>
> Best Regards,
> Shuping
>
>
>
> Tom
>
>
> On Thu, Nov 23, 2023 at 11:34 PM Pengshuping (Peng Shuping) <pengshuping=40huawei.com@dmarc.ietf.org> wrote:
> >
> > Hi Tom,
> >
> > Please find the new version of the draft and the changes have been made according to your suggestions.
> >
> > HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-hbh
> > Diff:
> > https://author-tools.ietf.org/iddiff?url2=draft-ietf-v6ops-hbh-06
> >
> > 1. The following sentences are added in the 4th paragraph into the Section “Modern Router Architecture”, “Parsing buffers with a limited size are commonly used in router implementations. The parsing buffer contains the headers of a packet that can be processed in the fast path and typically have sizes like 128, 256, 284 bytes.”
> > 2. The title of the Section 8 “Requirements” is changed to “Design Principles”.
> >
> > Thank you!
> >
> > Best Regards,
> > Shuping
> >
> >
> > -----邮件原件-----
> > 发件人: Tom Herbert <tom=40herbertland.com@dmarc.ietf.org>
> > 发送时间: 2023年11月23日 3:13
> > 收件人: Pengshuping (Peng Shuping) <pengshuping@huawei.com>
> > 抄送: Xipengxiao <xipengxiao@huawei.com>; v6ops@ietf.org
> > 主题: Re: [v6ops] WGLC for draft-ietf-v6ops-hbh-05
> >
> > On Wed, Nov 22, 2023 at 4:12 AM Pengshuping (Peng Shuping) <pengshuping=40huawei.com@dmarc.ietf.org> wrote:
> > >
> > > Hi Tom,
> > >
> > > Thank you for your suggestions.
> > >
> > > To me it is a good suggestion to change the title of Section 8 "Requirements" to "Design principles", which also follows the logics among the current related on-going drafts.
> > >
> > > How about we add the following sentences in the paragraph starting with " The maximum length of an HBH Options..." in Section 3 where the draft-ietf-6man-eh-limits is also referenced?
> > >
> > > "Parsing buffers with a limited size are commonly used in router implementations. The parsing buffer contains the headers of a packet that can be processed in the fast path and typically have sizes like 128, 256, 284 bytes."
> > >
> >
> > Yes. Please make a new version and I can reviewthe draft again.
> >
> > Tom
> >
> > > Best Regards,
> > > Shuping
> > >
> > >
> > >
> > > -----邮件原件-----
> > > 发件人: v6ops <v6ops-bounces@ietf.org> 代表 Tom Herbert
> > > 发送时间: 2023年11月9日 0:51
> > > 收件人: Xipengxiao <xipengxiao=40huawei.com@dmarc.ietf.org>
> > > 抄送: v6ops@ietf.org
> > > 主题: Re: [v6ops] WGLC for draft-ietf-v6ops-hbh-05
> > >
> > > Hi,
> > >
> > > Thanks for the draft.
> > >
> > > Even though it's informational, the requirements listed in section 8 seem to be a bit vague. For instance:
> > >
> > >  *  HBH Options need to be designed in a manner so that they don't reduce the probability of packet delivery.
> > >
> > > That's good as a general principle, but I'm not sure how useful that
> > > is to a protocol developer (what does "designed in a manner" mean?)
> > >
> > > Also, section 8 contains only one normative requirement and it's not clear that that is an operational requirement. For the rest of section 8, these seem more like design principles and not requirements, so maybe the section should be titled "Design Principles" or something without the word "requirements"
> > >
> > > In section 3 or 6, it would be good to mention parsing buffers with a limited size that are commonly used in router implementations. The parsing buffer contains the headers of a packet that can be processed in the fast path and typically have sizes like 128, 256, 284 bytes.
> > > It's problematic for routers when the headers a router wants to
> > > inspect don't fit into the parsing buffer (in particular, if they
> > > need to access the transport layer to perform port filtering). In
> > > turn, for extension headers, including HBH, there is motivation for
> > > the sender to limit their size to increase the probability of
> > > successful delivery (ietf-6man-eh-limits suggests defines limits
> > > with suggested defaults)
> > >
> > > Tom
> > >
> > >
> > > On Wed, Nov 1, 2023 at 7:40 AM Xipengxiao <xipengxiao=40huawei.com@dmarc.ietf.org> wrote:
> > > >
> > > > Hi folks,
> > > >
> > > >
> > > >
> > > > Because 6man has issued WGLC for draft-ietf-6man-hbh-processing, this message starts the WGLC for its companion draft-ietf-v6ops-hbh-05. Because next week is IETF 118, to allow sufficient time for people to review and comment, the WGLC will end on Nov 22.  Thank you.
> > > >
> > > >
> > > >
> > > > Ron and XiPeng
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > v6ops mailing list
> > > > v6ops@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/v6ops
> > >
> > > _______________________________________________
> > > v6ops mailing list
> > > v6ops@ietf.org
> > > https://www.ietf.org/mailman/listinfo/v6ops
> >