IETF Logo Mail Archive

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

"Manfredi (US), Albert E" <albert.e.manfredi@boeing.com> Thu, 25 May 2023 21:43 UTC

Return-Path: <albert.e.manfredi@boeing.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 116FFC1524A3; Thu, 25 May 2023 14:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.395
X-Spam-Level:
X-Spam-Status: No, score=-4.395 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_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.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 BUgKpSnZ3RYP; Thu, 25 May 2023 14:43:37 -0700 (PDT)
Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DA9C1522AA; Thu, 25 May 2023 14:43:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 34PLhY0L038460; Thu, 25 May 2023 14:43:35 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1685051015; bh=Lb7DlUZ9+rj6o7wTh+ujiGFHpdVQNyYrA2R9glx9P0E=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=GVPtZXn2ORgO9E0u9U2HGTYY2VE3yZii9S21SnHUHKU0hcs/Lz3B1Fi3J1pFc1SUH Vbjg60oSUMUbt7sa/ZgVdARvQwBdGFZsAmwUymTQCsY7bADsn8jWQMI/Yk5lOaQu16 k4ESbX6f5xEgfE1TZn7EBAmRSYlUoz4QXRUqX6FRwtRTc7Zq+Mw8ZO2lVgLObXYV6E WpOq9PBIY4VQRvZ/9vbE81iZ3C9dFnaEWmYHzwFVqI3EEJyWGBOGBBH7/IMXsYTDtn 0QzJZCo1GbwOlju2YLdbcmn/nOfwnPOz+VTzOpchMde1Y7KZNbk5WObadFtgwTQta1 erCssXuF50DCQ==
Received: from XCH16-08-03.nos.boeing.com (xch16-08-03.nos.boeing.com [137.137.111.42]) by ewa-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 34PLhVT0038437 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 May 2023 14:43:31 -0700
Received: from XCH16-08-01.nos.boeing.com (137.137.111.40) by XCH16-08-03.nos.boeing.com (137.137.111.42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.17; Thu, 25 May 2023 14:43:30 -0700
Received: from XCH16-08-01.nos.boeing.com ([fe80::e4ad:46fa:7f1a:20e4]) by XCH16-08-01.nos.boeing.com ([fe80::e4ad:46fa:7f1a:20e4%10]) with mapi id 15.01.2507.017; Thu, 25 May 2023 14:43:30 -0700
From: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: IPv6 Operations <v6ops@ietf.org>, 6man <ipv6@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>
Thread-Topic: [v6ops] [EXTERNAL] Re: [IPv6] [OPSEC] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
Thread-Index: AQHZjxS4rUKmcSGJ40CNRGJCvQwKLa9rbm8ggACENYD//4x7AA==
Date: Thu, 25 May 2023 21:43:30 +0000
Message-ID: <fb20cb79bb3b44378d25bd5ea65b89c5@boeing.com>
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>
In-Reply-To: <dd61024e-1bd8-ff3d-216f-22cc7600ad10@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [144.115.204.6]
x-tm-snts-smtp: 45AA76B5F756C468B571EB07748CBE981A019ED7D322D782A4822FBA621980BA2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/OmQUBFWxfgl-9OolvDC2bqrXEDs>
Subject: Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] 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: Thu, 25 May 2023 21:43:43 -0000

-----Original Message-----
From: Brian E Carpenter <brian.e.carpenter@gmail.com> 

> 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.

Right, but, as others mentioned, there are likely going to be IoT devices in my home, or in my enterprise, which are not as updatable as my smarter boxes. And those need protecting too. So the easiest approach is to keep out anything potentially harmful from the inside network.

Also, this same sort of security gateway model is used in the defense industry. Put the burden on some gateway box rather than relying too much on individual hosts. Why? Because "We don't necessarily trust the vendors of individual hosts, so we'll use a broader brush approach." This is real.

> 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.

Agreed, and my bet is, the tussle will favor not banking too much on header extensions, when security is an issue. And security is increasingly an issue, as we have seen over past decades.

> I don't want my ISP or my CE router to block any extension headers.

My bet is that over time, IPv6 CE routers will likely block anything unneeded by default, and then maybe permit users to go to "advanced options" to fine-tune the router to their special needs. And as we know, the very vast majority will never attempt any such thing. (Just as the very vast majority never even change the default name of their home WiFi access point.)

I understand your point about the IPv6 sales pitches. Skepticism about sales pitches is not unusual, however.

Bert

v2.23.0 | Report a Bug | By Email