Re: [IPv6] [OPSEC] [v6ops] [EXTERNAL] Re: Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)

Tom Herbert <tom@herbertland.com> Fri, 26 May 2023 16:38 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5661C17B35F for <ipv6@ietfa.amsl.com>; Fri, 26 May 2023 09:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 e9ixfo0IHrEg for <ipv6@ietfa.amsl.com>; Fri, 26 May 2023 09:38:35 -0700 (PDT)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 18F76C1519A6 for <ipv6@ietf.org>; Fri, 26 May 2023 09:38:31 -0700 (PDT)
Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1ae85b71141so9187455ad.0 for <ipv6@ietf.org>; Fri, 26 May 2023 09:38:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1685119111; x=1687711111; 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=2qpor3kZYKmy3d99oPzzrsdcNh/gwdDs977TgKNAquM=; b=DwhAIIxEFH8hN2zShmed+OaUROe046rsQah8zQKKg/6YXifyQS0e9XOfXdpgfxKp/h FowCdz7In/UinvejmNdDyu/Gn3tqGj/6PirJO/TC7sozVTdqf31I6UaF5iKZqwR0eOc7 pKTv38jN9Az3CYnf47oOG+W2/b5OXuU13KXIkZ0KjUuO0HFBrH6tGnr9SaDSRXlnjwS2 zj3inYtGmtekm2SX/XpoCesPId+QoyJbIMpgqx0oW7eth+tsV/PcfcsTE97OnzZO9Qgf UmLKoNMfSVrdt3ZAB1nk8ond4dxWLgcMwtEnDGZq7v2HJJs6F/1DAtLlZOnypX+uBLWM lvqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685119111; x=1687711111; 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=2qpor3kZYKmy3d99oPzzrsdcNh/gwdDs977TgKNAquM=; b=Ky+6Vdfchuk6ycefyS7KhZXQq+WNMnBQKfOqNA/lIEG18Dj8xU1F5Ej3MvRFDqbuhQ XgAXDc1QRm/ogmWc7dDtbnrWCweQpZG19PTPf73k13YgzeCgy/IyvhEhqylkLU5UiX5k 5y1vB8/AC8tAYlFfgL0C6jbodjsE5trvuJr/hrHwU5iAqLIpCmH0JeRgY9ZLGvZfUwIe yDNq7je5GOJucC1fb2NRpFhzTFFCVfQQ2mRsSMu/+KTm4jSbgFJ7BL9Sf7j7Qxu6oNb3 GKLGkR5KtQrfWSx1S4nNebemVxP1+TYCbfTBjc7h6HgmXqspYp+UYOPfC1jqq7m0WcO7 zKTA==
X-Gm-Message-State: AC+VfDzbclMPbsCtXzNa3NwiJ69wDd4P1AOarSoJCIqCWEJQXOom30fs lLAmb7CdQiMaggmYesQStysD1/TbK9EnDeM74mnd5g==
X-Google-Smtp-Source: ACHHUZ4mTndl6xoUiXOx2P10YwiR58UFsFkzutghg18Qij3Zao8Dp8qRE5Gi2pQc1B8KHiXR/766hqqk+wI0UvF5f6k=
X-Received: by 2002:a17:902:7084:b0:1a5:2760:74ef with SMTP id z4-20020a170902708400b001a5276074efmr2827178plk.25.1685119110777; Fri, 26 May 2023 09:38:30 -0700 (PDT)
MIME-Version: 1.0
References: <11087a11-476c-5fb8-2ede-e1b3b6e95e48@si6networks.com> <CALx6S343f_FPXVxuZuXB4j=nY-SuTEYrnxb3O5OQ3fv5uPwT8g@mail.gmail.com> <CAN-Dau1pTVr6ak9rc9x7irg+aLhq0N8_WOyySqx5Syt74HMX=g@mail.gmail.com> <a087b963-1e12-66bf-b93e-5190ce09914b@si6networks.com> <CALx6S349nNA8L5+_1hrbWayqp8GfTYypWy_SP57c_Xxams=csg@mail.gmail.com> <51a066b3-4b4c-d573-ffbe-d6b44a4f193f@gont.com.ar> <a411a1b0-c521-c456-3d44-d99a1cc0975b@gmail.com> <CWXP265MB5153E4687BE45480DBC5A531C2439@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM> <27d28224-0cb0-eec2-8d54-f0d175596c85@gmail.com> <f5758380-9967-b67b-744d-dc36b7b599ab@si6networks.com> <72784f8e65f34bcc9f5652c0a553c70c@boeing.com> <CALx6S373P2X-JRbCNpOCGuq_Cum0+OzJFRBkuQ64h5R52B7Dhw@mail.gmail.com> <222731ea012b4b0ebd7a51f72b5bcd40@boeing.com> <dd61024e-1bd8-ff3d-216f-22cc7600ad10@gmail.com> <CAHw9_iJyXiT=O5cMyy08bVq+U7VTtKTkR_60OfvrcCng8Joe5w@mail.gmail.com> <CC81C789-A751-43C6-9ABF-BC137B2E9803@employees.org>
In-Reply-To: <CC81C789-A751-43C6-9ABF-BC137B2E9803@employees.org>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 26 May 2023 09:38:18 -0700
Message-ID: <CALx6S36aUxZCEbhEuga111JWwUQUF22mMYOOss-jwKEthAirhQ@mail.gmail.com>
To: Ole Troan <otroan@employees.org>
Cc: Warren Kumari <warren@kumari.net>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Albert E Manfredi <albert.e.manfredi@boeing.com>, IPv6 Operations <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>, opsec@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/NF9baweimxaw1w6RsVMTlpDxDOE>
Subject: Re: [IPv6] [OPSEC] [v6ops] [EXTERNAL] Re: Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 May 2023 16:38:39 -0000

On Fri, May 26, 2023 at 2:13 AM Ole Troan <otroan@employees.org> wrote:
>
> > A well-implemented host will not be troubled by unkown extension headers or options.
> >
> > Indeed. However, not all hosts are well-implemented.
>
> "Not be troubled by” == “drop”?
> I don’t agree that a well-implemented host and application should blindly accept any and all extension headers.

Ole,

Right, that's why RFC8504 and 6man-eh-limits allow hosts to set
various limits on extension headers in packets-- if a host limit is
exceeded then the packet is discarded. 6man-eh-limits also also
intermediate devices to have similar limits and if those limits are
exceeded then any items beyond the limit are forwarded and that is
*not* a reason to discard packets.

> If my application cannot use those extension headers why do you send them to me?
> If they are purely for the use in the network, then again why do you expose them to the application?
>
> If you can give some practical examples where it’s beneficial to “process” unknown extension headers by hosts/applications, then this may be a little easier to reason over.

Segment routing where the final destination is a VM.

Tom

>
> O.