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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 25 May 2023 21:13 UTC

Return-Path: <brian.e.carpenter@gmail.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 981FAC151549; Thu, 25 May 2023 14:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Level:
X-Spam-Status: No, score=-7.099 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 kUrEd3b8glI7; Thu, 25 May 2023 14:13:26 -0700 (PDT)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 4F12EC14CE36; Thu, 25 May 2023 14:13:26 -0700 (PDT)
Received: by mail-pf1-x42d.google.com with SMTP id d2e1a72fcca58-64f47448aeaso190337b3a.0; Thu, 25 May 2023 14:13:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685049206; x=1687641206; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=1ggGws9Izn6N8Zhw6BJXBKGANnQv+wQY1KqZ6dxsw6A=; b=Q5n40qv6W2+ldkWxTfH66DV/dUv5J8X6UJmiBsIIsQ6le84RDzNiRiMbZH47H4YzXg rEfSgp5FHoQUB2x16inIATMv9ydiQRyMsaItRmiikFbG0bGZLHLa07lDmc+60qkHZS++ OEg9Hio2iH/RNvTk6utmnEWgcTQ8fV9B4kzxKStnnkdmRXkD6YlFHpVLfoIhZLZziess jGiCTdXDXta1kCcDfjrU5asLVp/E8ouZ7TJ+fulGgBQWCFmJfQ+6Dzb2sKVvEI+lIz2O 9AE7i/VduLx9iwfVtdZcFRWBN/hCAwxw1e2gNF78tEv8SG5F+Ge6ugJp6YEyniVHzTHO IG7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685049206; x=1687641206; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1ggGws9Izn6N8Zhw6BJXBKGANnQv+wQY1KqZ6dxsw6A=; b=NSmGIaiGeShE+vbXwNZT99nHAe6gwD5NzHUhGJf1Sr6jfU/aNfBQ2/TJUFpMaCC3pF HwRCLnYvndOMQpaKCNLrsvJ8x8bm7t7Xr4gGeaSO+sZzw+4dzROZb+x4piFVwhCLhpWd Lm8aIt8cAXcrYYEuBRUtVsSigUw/S+PXojHSkCqrWyuKFzrHqZ5vQnqf7a5j/0QVp+Ot PAD4ZNyS2HINA9FNVHlQfO+fpdfKN5rBGI6/8V2ymYiaNN3gr6YlP/F3UbIV3sdqNUnV e5l7EJJteXSRGsY9wFvQ/GYEBp53mqw/Kwl8XssbZKuh6+oWtwAAKc8WDvRVT5qXrwxu maEA==
X-Gm-Message-State: AC+VfDyZAjLE6qkyvys0UZCANJy/9GfxxjRgqUaAKbyP0P7VLcV2bu9J jWOGVaEqCusd7lIlGw9O+qY=
X-Google-Smtp-Source: ACHHUZ67F0iB6RhkE1Ir5hK8o4cNRUmFUAsgDSBwgxtgoJ9JU1YyxBQ9iULrVJ+8yTAlGGsy4TOkPg==
X-Received: by 2002:a05:6a00:2194:b0:64f:7c9d:9c01 with SMTP id h20-20020a056a00219400b0064f7c9d9c01mr32759pfi.30.1685049205587; Thu, 25 May 2023 14:13:25 -0700 (PDT)
Received: from ?IPV6:2406:e003:1184:f001:9991:d1ad:8c20:42bd? ([2406:e003:1184:f001:9991:d1ad:8c20:42bd]) by smtp.gmail.com with ESMTPSA id u16-20020aa78490000000b0064e0c8e8b33sm1606592pfn.90.2023.05.25.14.13.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 May 2023 14:13:25 -0700 (PDT)
Message-ID: <dd61024e-1bd8-ff3d-216f-22cc7600ad10@gmail.com>
Date: Fri, 26 May 2023 09:13:19 +1200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>, Tom Herbert <tom@herbertland.com>
Cc: IPv6 Operations <v6ops@ietf.org>, 6man <ipv6@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>
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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <222731ea012b4b0ebd7a51f72b5bcd40@boeing.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/H4FjtbZPJXoJQmvQxr1fUx314wk>
Subject: Re: [v6ops] [EXTERNAL] Re: [IPv6] [OPSEC] 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: Thu, 25 May 2023 21:13:30 -0000

On 26-May-23 08:33, Manfredi (US), Albert E wrote:
> -----Original Message-----
> From: Tom Herbert <tom@herbertland.com>
> 
>> It's more than a preference to have host security, it is an absolute requirement that each host provides security for its applications and users. This requirement applies to SmartTVs, SmartPhones, home computers, and pretty much all the several billion end user devices connected to the Internet. No host device would ever assume that the network consistently provides any adequate level of security, for real security we need to assume that the host is the first and last line of defense (i.e. zero trust model).
> 
> I could not agree more, Tom. So, as Fernando and others have said, the impulse is to block everything coming in from the Internet that you figure you don't need **right now**. Such as weird complicated header extensions.

It's perfectly fine if a host chooses to block incoming packets for any reason whatever, including unknown extension headers. That's quite consistent with the *network* allowing permissionless innovation.

The problem arises when any upstream intermediate node drops a packet because it doesn't like it for some reason. There, you immediately create the tussle between transparency and security, and I strongly suspect that there is no universal way of avoiding that tussle. Not every new feature has backing from Google.

> 
> The ISP has its own concerns, to protect its network, but I, in my enterprise or household, have different concerns. I'm not going to trust the ISP's security mechanisms to provide my own security needs.
> 
> Honestly don’t see how IPv6 is going to change that. Over time, perhaps, some specific extensions used out in the wild will be seen as crucially important to my enterprise or household, and maybe those will not be blocked. But "trust me, you must accept all these EHs"? More likely, those potential innovations will go unused and maybe will eventually be implemented in a different way.

A well-implemented host will not be troubled by unkown extension headers or options. If my "smart" TV isn't capable of ignoring unkown extension headers, its vendor will have to give me my money back. I don't want my ISP or my CE router to block any extension headers.

> 
> Security evolved as it did, over IPv4, for a reason, methinks.

There is really no difference between the story of IPv4 options and IPv6 extension headers, except that extensibility was a sales argument for IPv6, so naturally people have tried to use them. And it would be exactly the same for IPvN where N>6.

    Brian