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

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 22 May 2023 23:41 UTC

Return-Path: <brian.e.carpenter@gmail.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 4BCEEC14CF0D; Mon, 22 May 2023 16:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.097
X-Spam-Level:
X-Spam-Status: No, score=-0.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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, URI_DOTEDU=1.999] autolearn=no 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 FgmqK0_TNXTx; Mon, 22 May 2023 16:41:45 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 9E314C14F749; Mon, 22 May 2023 16:41:45 -0700 (PDT)
Received: by mail-pg1-x52a.google.com with SMTP id 41be03b00d2f7-5289cf35eeaso2889371a12.1; Mon, 22 May 2023 16:41:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684798905; x=1687390905; 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=ZjKG8yI6OlzvYNVrxz9Fv0zGKC6zVhBAcTp9oUM/i+g=; b=UNuMn2zEXeQ+iZcNf4DH7VXntqjOSVBJChZ0bxb2xjFq/Y8Y2dvYc0SFYNfc+8D3yF QfpZsuPP9ssW6mNgAy1NdaJeVt2UD2NvBpjBsC/mVZz2bk7BjAn91cTZCq7rKpN1GH00 R685enGTGWs3oxL+VSPEisMmIX2BDzdAAkHCtHmCW8aScIduGQ20itT7RWN9xbl9hz2X GFaFk6W5byA3R7udj10cioMj5yaiZYbiXjrDar1bjiuPXclu/ey5IkBZ8aevBmhdXDHN dFXIIiebxteI9V8OdeL7SGEMVsWbJ1+32SsEj+MpZsmI9EvxercHCUHxzjDTn96FvbwI wqgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684798905; x=1687390905; 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=ZjKG8yI6OlzvYNVrxz9Fv0zGKC6zVhBAcTp9oUM/i+g=; b=NOneI0zBgoEowSmrNSbN3cPpV1fCOVCmcuU6iZ32xiFh3e+kJmhPT0AK8p6ks9+4Sk RBJJYgg/bYpTo9RcBKfshI9ULN4nzTO0Gs3R9mamCpb5n6H2CxhLMEy983HKjwZWkXkK y1k4twegmKXfzByDPNCadZZl9O0XkM+KxamCTT2BJsep6wil7yuNa9o0hd+S6erPZX39 lJ5ol89ul/h8AGvSYHxpX/9mowjeQ9NsKaF1wNghvrJoBV/8iKbsOyK+bOptbt5mrI12 Q08/ds7Mi+zEHQFq7PsAJw7hov6qj9oLabzT79MS76RhHM5xJ1vedXso3Gq4GHPllXgh ahfQ==
X-Gm-Message-State: AC+VfDyIU4lbVL9/meqyhTWmRTDjWHlaB/YUEpsVkHl98vY77uyC/Kf2 GRFn3SlToP/FiKf3VqAgx2Y=
X-Google-Smtp-Source: ACHHUZ5NAarUeWJRUOKVbYV/YOg3iBV5rANUC6QstEXoLhLKMg98AfNfT1K4sh/HN41iHJJqJ8/ojw==
X-Received: by 2002:a17:902:c942:b0:1ae:52ea:416a with SMTP id i2-20020a170902c94200b001ae52ea416amr14022623pla.2.1684798904363; Mon, 22 May 2023 16:41:44 -0700 (PDT)
Received: from ?IPV6:2406:e003:1184:f001:abb6:ea4f:cf8e:1d0d? ([2406:e003:1184:f001:abb6:ea4f:cf8e:1d0d]) by smtp.gmail.com with ESMTPSA id b21-20020a170902d31500b001acaf7e22bdsm5403008plc.14.2023.05.22.16.41.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 May 2023 16:41:43 -0700 (PDT)
Message-ID: <27d28224-0cb0-eec2-8d54-f0d175596c85@gmail.com>
Date: Tue, 23 May 2023 11:41:38 +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: Andrew Campling <andrew.campling@419.consulting>, Fernando Gont <fernando@gont.com.ar>
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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <CWXP265MB5153E4687BE45480DBC5A531C2439@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-ga2p2kzWhVXlPF41dyLEZ-dSZA>
Subject: Re: [IPv6] [OPSEC] [v6ops] 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: Mon, 22 May 2023 23:41:49 -0000

Andrew,

On 22-May-23 23:28, Andrew Campling wrote:
> On 21-May-23 10:29 PM, Brian E Carpenter wrote:
> 
>> And there's the problem. The operator of a large network cannot possibly
>> know which extension headers every host on the network needs. It's called
>> permissionless innovation, and is supposed to be one of the main success
>> factors for the Internet.
> 
> I think the problem with this approach, which I'm interpreting as "allow everything", is that people responsible for the security of public, and especially private, networks need to consider whether any such innovations might introduce new vulnerabilities.  Remember that, for example, CISOs looking after the security of some enterprises may fall foul of regulatory obligations if they cannot show that their networks are as secure as is practical.

Sure. So it's our job to document the best way to secure networks...
  
> More generally, anyone operating zero trust principles would surely only allow those features that they deem necessary, selected extension headers in this case.  This would seem consistent with the point that Fernando made earlier in the thread.

That depends where you choose to apply the zero trust model. As Steve Bellovin argued many years ago in his distributed firewalls paper, distributing the trust model to the end systems is best, because you no longer have to trust any intermediate systems.

https://www.cs.columbia.edu/~smb/papers/distfw.pdf

   Brian