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

Clark Gaylord <cgaylord@vt.edu> Fri, 26 May 2023 21:18 UTC

Return-Path: <cgaylord@vt.edu>
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 B5F30C15109E for <ipv6@ietfa.amsl.com>; Fri, 26 May 2023 14:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vt-edu.20221208.gappssmtp.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 evmkigeHVxrG for <ipv6@ietfa.amsl.com>; Fri, 26 May 2023 14:18:29 -0700 (PDT)
Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 1C3C7C151538 for <ipv6@ietf.org>; Fri, 26 May 2023 14:18:29 -0700 (PDT)
Received: by mail-il1-x12f.google.com with SMTP id e9e14a558f8ab-3381e9ec12bso8126475ab.3 for <ipv6@ietf.org>; Fri, 26 May 2023 14:18:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vt-edu.20221208.gappssmtp.com; s=20221208; t=1685135908; x=1687727908; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=53oehcZHWMgMABRqpCdvH7ONJzqvKxYAuu+oDUdkDQs=; b=04YIlJiMGDdFay8bQfGXKtHdt7kNs0xYPrYVRBjRHU3bWc6rGfHwX8DURNQsozc9qd wR+ZfhPOTVxq7bZ3voRte2P5fnpMkD1xBatHr4u4w5xOdiifmRq3D7tZNrwUhYJVhvu5 EXWGjZDT5VJw4ri1jfEu/DYORLf5shjEuFAfb8YpYPa59EHXzLCKMhTMrfVScD1aT8lg WUQ1d0TFfCXk/YEUWw4B9Q+oi8sDIvBP5kaSkgoi1TG1/tR274EQKHToze0gChyookSx OL58cd6wVq8haFjb2wI8lz3LaGPAS25GSobgZ7KHEPriEWMHFwLiEmOeB+/gfEJi8+Lk KkwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685135908; x=1687727908; h=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=53oehcZHWMgMABRqpCdvH7ONJzqvKxYAuu+oDUdkDQs=; b=OtoSpn3VjI8QVlQVzDNj+O2tAw3O9spR9m2ryDOeHLQ+ouhE4lvx1gwoq9fJL4q+ev ipAZoOs9Mg9acJ6Rg7aoPJCG0kmZpy3c3CZjCTQqG3T82BFmVsGgO2a6tBlp6sONl/H2 fBX+9mqwzfV+Gxn58jCxROvmx2kDHOdHPruqiKYzbkZ0+uhvNXtCPlNe8pIMq9FthFt/ 0QAZFvSggoXypSnFXLNDzgEgM0XOSxSNuUBxLIZ9BUPrlov0m3Xqse/l401AHKNP7MGk CTLn1DXdtZtKC2IHvi+Sdt4pnThismRDTv+UbrGDjItpAEVjEQ9UUBPKo4n5orA2jGl4 xbhg==
X-Gm-Message-State: AC+VfDyk6Pa2evYoQQzrodXfisvlZ4Qq+HcX1kQF/ehIOrp90GUvpFkv xHXeqAat/V8yWEdAetJlZf1xvc1/zExa8yT2GnHtfQ==
X-Google-Smtp-Source: ACHHUZ6RsKjxMqYaiKznkLBYh9Ns5VgNDy5PSDFoslBpA2r+ctNzPwZc6LZXlYGv0kZrTYtv1B7GZEdlXObpw7wxnw8=
X-Received: by 2002:a92:c989:0:b0:338:1b0f:28ec with SMTP id y9-20020a92c989000000b003381b0f28ecmr490778iln.15.1685135907703; Fri, 26 May 2023 14:18:27 -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> <CAHw9_iKhNSRX1DmUN_uXEPA95Ue9ofpbgOkxxKTtk6_k5XPXLw@mail.gmail.com> <CWXP265MB5153AE85D5952AAEF8419329C2479@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM>
In-Reply-To: <CWXP265MB5153AE85D5952AAEF8419329C2479@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM>
From: Clark Gaylord <cgaylord@vt.edu>
Date: Fri, 26 May 2023 17:18:16 -0400
Message-ID: <CADzU5g5ORU9r6zZumX2CUUObH5-OFuLB-VNPeYe1tGVG1V=Mgw@mail.gmail.com>
To: Andrew Campling <andrew.campling@419.consulting>
Cc: Warren Kumari <warren@kumari.net>, Ole Troan <otroan@employees.org>, opsec@ietf.org, Albert E Manfredi <albert.e.manfredi@boeing.com>, IPv6 Operations <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002d72ff05fc9f4762"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/RbUPzadKibbDQR9OTMn1j3Hpr1A>
Subject: Re: [IPv6] [v6ops] [OPSEC] [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 21:18:32 -0000

If only there were some *principle* to guide operators in better
understanding when it might be worth spending their time blocking something
that is not a *specific credible threat*

Oh wait... https://en.m.wikipedia.org/wiki/Robustness_principle

Now, where there is a specific, credible threat *absolutely* block what you
know. Otherwise, kernels, even on lightbulbs, are really good at ignoring
packets. Otherwise *you* are the DOS attack



--ckg

On Fri, May 26, 2023, 10:31 Andrew Campling <andrew.campling@419.consulting>
wrote:

> This is a really good thread!
>
>
>
> For me, it highlights that there appears to be a gulf in understanding, or
> at least working assumptions, between developers and those responsible for
> network (public or private) security.  I suspect that gulf might narrow
> somewhat if developers faced some of the same consequences that enterprises
> and public network operators face in the event of security breaches – I’m
> thinking here about those with compliance obligations such as the finance
> sector, those in areas defined as part of critical national infrastructure
> and those covered by more general regulations such as NIS2.
>
>
>
> Greater involvement by enterprise and public network CISOs would help
> inject more understanding of current practice security and operational
> considerations into protocol development activity to augment the input of
> those within this community that also have that knowledge.  For example, it
> would be good to see the reaction of CISOs to suggestions that security
> should be left to hosts / endpoints rather than using a defence-in-depth
> approach which also employs network and perimeter defences, looks for
> indicators of compromise etc.
>
>
>
> Given the relative lack of diversity within the IETF community, hindsight
> suggests to me that it would have been great to see one or more
> IETF-sponsored panel discussions at events like the recent RSA Conference
> to debate some of the points raised on this thread with the wider security
> practitioner community, many of whom don’t follow developments at the IETF
> (I can confirm this latter point from personal experience as I asked other
> attendees at RSAC 23 and found less than a handful of people that had
> involvement in the IETF, either directly or via a team member).
>
>
>
> Andrew
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>