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

Tom Herbert <tom@herbertland.com> Mon, 22 May 2023 14:23 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 E9790C17D667 for <v6ops@ietfa.amsl.com>; Mon, 22 May 2023 07:23:18 -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 dGh4ujvtwAhl for <v6ops@ietfa.amsl.com>; Mon, 22 May 2023 07:23:13 -0700 (PDT)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 E8F56C15152E for <v6ops@ietf.org>; Mon, 22 May 2023 07:23:13 -0700 (PDT)
Received: by mail-pl1-x62f.google.com with SMTP id d9443c01a7336-1ae557aaf1dso52502745ad.2 for <v6ops@ietf.org>; Mon, 22 May 2023 07:23:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1684765393; x=1687357393; 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=Klq8Bq1FuBIxUmJTRmR/wViY+Cs2r+J7jPi9TDTxPDU=; b=FMcJml3WT/s9/lGe0azpFvTkWHYCSJ8MyDGFmesqzyU+fe4GHNKaEZtHaCwpe4VNoi ilwHTliKpyDKqQaaK1XLopTr7AEMTXwNgVhHE/bD6QX6wxWW1UjqYzDTfWWI6JRx4IGS urL3PjHqY+WiA2DBFQxmf7BinKaSoemBbd6N5YLdVJBm5HOeADGvbtKa3G1WKtGY+JzQ KdHtH1btUEqGq1VoBUmCZjGSQnC33KuFLhmK4jT/OYa5tUFHhJqt6DAzftpJiYJwv9rg DuvWXq0GUpYX6XG5UxmfZBc55ye5t65qVKV6R+6IbOfgwTuFNI9+YRE4Of5datRrsMNb vkWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684765393; x=1687357393; 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=Klq8Bq1FuBIxUmJTRmR/wViY+Cs2r+J7jPi9TDTxPDU=; b=DYzWjR73wSR9ARU7SuDBNYd6qI547vNOAmHvpBj23qzi8f9hNtoFCyFwiwxRIop1Dj 0Lu0pLKXtkliwvtHOyzzQNJuW1mcjt9SqpAfZs3nHTNXJpawYvUOYgxgbXjspXgqbggQ NgOZX6SAF1bz3s3sJw4nXnnF4LSjwxKLmKkwu2OiREsxrDKglLr88saeCZIeiQoDJihQ rrT0W1H2jllu+RPns95wACGzrklI+ZZhXxnOmvOExDWXibpfmYJaH9xapwYt3TpjcRuI 2d/u1FJP2EZWPuyzRoSXQp5HPGnVr3omNZcLMX3LpHRJvf5g7PfovJ/ftDowSY6JV4jI XEnA==
X-Gm-Message-State: AC+VfDzfRUMPvUGI5qq3oZdG9XsIpbY08vwfXyMUpJANt8JpJ4LL6EPM tjpijZ5omod9Oic6IpMKl8nxwIrpXFUONY9BOfWFWg==
X-Google-Smtp-Source: ACHHUZ5LB6b689C4ERc4i6h3Rl3IByP6/039kzqio/Ro6D/wi8yzaGPFUYGQ8McdAsAa0cc4ecsI/nJh9sDlgPAlK/I=
X-Received: by 2002:a17:902:e5c8:b0:1aa:e425:2527 with SMTP id u8-20020a170902e5c800b001aae4252527mr11238395plf.21.1684765393143; Mon, 22 May 2023 07:23:13 -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>
In-Reply-To: <CWXP265MB5153E4687BE45480DBC5A531C2439@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 22 May 2023 07:22:59 -0700
Message-ID: <CALx6S35aUNqgyO+8H_QnP4FPp6eRi6aAUfi38AF16SXWAqa6UQ@mail.gmail.com>
To: Andrew Campling <andrew.campling@419.consulting>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Fernando Gont <fernando@gont.com.ar>, IPv6 Operations <v6ops@ietf.org>, 6man <ipv6@ietf.org>, "opsec@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/v6ops/6AQzshaUQWJaKO3K_p1QRr_c5zI>
Subject: Re: [v6ops] [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: Mon, 22 May 2023 14:23:19 -0000

On Mon, May 22, 2023 at 4:29 AM Andrew Campling
<andrew.campling@419.consulting> 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.
>
> 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.
>
Andrew,

Enterprises are private networks and can enforce whatever security
policies they want.

The problem is in public networks where the service provider acts as
"anonymous big brother" to enforce its concept of security to
"protect" the users. While I'm sure they'd like us to think that they
are acting for the benefit of the users and it's for the "good of the
Internet", the reality is that having a patchwork of random security
policies across the Internet is counterproductive, and, frankly, some
of these policies are driven more by localized business interests
rather than the users' best interests.

As a host and networking stack developer, I view the network and these
arbitrary inconsistent security policies as the problem not as the
solution to application and host security. The best tool developers
have is to encrypt as much of the packet as possible to keep network
providers from meddling in protocol layers they shouldn't be, but
unfortunately that isn't applicable to all protocols like EH for
instance (although, given that IPsec was on Fernando's approved list
of extension headers, I suppose we could hide all the extension
headers we want in IPsec :-) )

Tom


> Andrew
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------