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

Warren Kumari <warren@kumari.net> Fri, 26 May 2023 09:57 UTC

Return-Path: <warren@kumari.net>
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 3C12EC151080 for <v6ops@ietfa.amsl.com>; Fri, 26 May 2023 02:57:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.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, 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, 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=kumari.net
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 tQ9xjIJwV9gI for <v6ops@ietfa.amsl.com>; Fri, 26 May 2023 02:57:27 -0700 (PDT)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 329DEC151525 for <v6ops@ietf.org>; Fri, 26 May 2023 02:57:27 -0700 (PDT)
Received: by mail-qt1-x833.google.com with SMTP id d75a77b69052e-3f6c6020cfbso1883891cf.2 for <v6ops@ietf.org>; Fri, 26 May 2023 02:57:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; t=1685095045; x=1687687045; h=cc:to:subject:message-id:date:in-reply-to:from:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=iKAUqI208ULFl3Siu3eIz5wIulS1ZfN70Hv/JQT3eP0=; b=JmyD9e+IAtd8XzjGOSWMnfbhKD/NLUvSq9+y1nhtcJ/YYOejmqr/zDH4ePQ8KDiX6B YDq0PJgeSWEOgCWtjsaDDZKiqyy2fIAGBQxdL5BYwFghiaXmICQihIjB5w9CCTVsQwWF wnAlrS7LlqKDN6lmAnhB0N80HKsbhFHxo8FKuuWv8RsSZKXY7oCdRRj/ei5bjC642CwP buUTNky96PqGWIUGPhyTQON7acUpuSQZC20Z4PiQs7kltekbzi9lg8P4qzHjmoHNvfQP oHsHhL0/VWbkwC/zyg5VymdPFXNSNXdwPLXFErbyKvk2xScCL53NF0+fZBVWSR/lCvTg bAqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685095045; x=1687687045; h=cc:to:subject:message-id:date:in-reply-to:from:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iKAUqI208ULFl3Siu3eIz5wIulS1ZfN70Hv/JQT3eP0=; b=k8n3zQ/OBJtlTdWkAerxstJm7JGuRzSPHBIq85dD1obLvxkM1KzK5lZF9S9GC00Pm0 p8/Q1GYCaDV8m8uZOGgTofmLn3lL9IefuEicoQCjk8cNvgUdnUJeCMGuOeUUU1VBWu0X gGpSU8YS3Xu4MmhlkKxXBE1Z2TJIR9gXnQXYQbl1WAL6if3DmoQyaxyKjhY2JpNhWlC0 EXK3vfpIlB2Yt+ALDlPRwWQiGwqJmajKDH/eoCIK/9gOaGtH1NFMGRATDAtFxvtLfpll dEprsGx+IjAnqUZUweDEWJVj8gMAOv4nwdlykF96vqvFRdOCW26o8/5Q6SPlUIe4i1xH DSKQ==
X-Gm-Message-State: AC+VfDylr8kBsIovtcF6/koIxTDmP7/LJLZzOlCeMgJjBXlAEk+4OSBw v9btbbInc6D2/LftIG5xFGKgjXeFwE0JfX4zQwCYYQ==
X-Google-Smtp-Source: ACHHUZ6jACz56clzTeL598LNrFF0Hh6eZv2KODhUn+j9uRoAOOHlsPNNlZX0Llh4C0gtpl9JKSgtubho3teJy1WcRvo=
X-Received: by 2002:ac8:57d3:0:b0:3f6:c392:93ee with SMTP id w19-20020ac857d3000000b003f6c39293eemr1225065qta.42.1685095045486; Fri, 26 May 2023 02:57:25 -0700 (PDT)
Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Fri, 26 May 2023 02:57:25 -0700
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>
From: Warren Kumari <warren@kumari.net>
X-Superhuman-ID: li4e2iey.69a27bf1-a184-449b-9f3e-85b3bfc406e2
X-Superhuman-Draft-ID: draft00331223f994c987
X-Mailer: Superhuman Desktop (2023-05-25T19:06:01Z)
In-Reply-To: <CC81C789-A751-43C6-9ABF-BC137B2E9803@employees.org>
Date: Fri, 26 May 2023 02:57:25 -0700
Message-ID: <CAHw9_iKhNSRX1DmUN_uXEPA95Ue9ofpbgOkxxKTtk6_k5XPXLw@mail.gmail.com>
To: Ole Troan <otroan@employees.org>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Albert E Manfredi <albert.e.manfredi@boeing.com>, Tom Herbert <tom@herbertland.com>, IPv6 Operations <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>, opsec@ietf.org
Content-Type: multipart/alternative; boundary="00000000000099747805fc95c3dc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Gdt_xb34ZVlJ28gvyIbqI9hiS-A>
Subject: Re: [v6ops] [OPSEC] [EXTERNAL] Re: [IPv6] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
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: Fri, 26 May 2023 09:57:31 -0000

On Fri, May 26, 2023 at 11: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 had assumed "not troubled by" meant "doesn't explode, killing everyone
inside".

I'd assume that no-one is thinking that a host or application should try
and process an extension header that it doesn't understand… but then again,
I'm often wrong in my assuimptions.

W


> I don’t agree that a well-implemented host and application should blindly
> accept any and all extension headers. 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.
>
> O.
>