Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why folks are blocking IPv 6 extension headers? (Episode 1000 and counting) (Linux DoS)
Bob Natale <RNATALE@mitre.org> Thu, 08 June 2023 13:51 UTC
Return-Path: <RNATALE@mitre.org>
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 761A3C14CE30; Thu, 8 Jun 2023 06:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.087
X-Spam-Level:
X-Spam-Status: No, score=-7.087 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 (1024-bit key) header.d=mitre.org
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 I_tPFbE_4xZI; Thu, 8 Jun 2023 06:51:48 -0700 (PDT)
Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 CACBCC14CE36; Thu, 8 Jun 2023 06:51:47 -0700 (PDT)
Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EAD8772E001; Thu, 8 Jun 2023 09:51:45 -0400 (EDT)
Received: from smtpxrhbv1.mitre.org (unknown [198.49.146.55]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtpvbsrv1.mitre.org (Postfix) with ESMTPS id 35496132E024; Thu, 8 Jun 2023 09:51:45 -0400 (EDT)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02lp2101.outbound.protection.outlook.com [104.47.64.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpxrhbv1.mitre.org (Postfix) with ESMTPS id 10A78413DC7; Thu, 8 Jun 2023 09:51:45 -0400 (EDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K6Q+NXw6aRGGB2N5HsVi9afwOI8vEY/nebB6PYVpg9sYJKsklyJLhOAF22ToPA1oVE4yYRYU+fez2VlBHbVUNpDQ5MHRzmrm9rAmNlmeqCVTWwsjAxyBbq819TTUAKr8xxOWW0F+BxYcKdgnr0AfMqN2oJQmVtLhaAnUIE4TW0EwiDjfa7R+/HQVE2pOEkgPS+OI9nqHhJ/4EGnznw2WyFRaQGLwFhm4khD3G62J4j7ozQ/2E7o6uHwpIxVEk2fbQqEr58E2FbLBpzEBz+wT4DBCY+7u7TTIXPAHZB4/Fc9XhXaTxNOJFWCVbqEga4iQmMcllDji+2jQIgjA0qDguQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xTMp2NbaThqMPDiLSj3ekTf8yD3+m+z1IVsMOc2ob9E=; b=V5VITT4G3F0sd8hWcpxcFgiLkVmLlennaqjJZez4bqUZhkhQHJg7zh4Jc2aevzyFYk69mBxPOoEAArXqTCWv5v804OG0KNB7UqMGQKjOSnCcCGDHwK4zpNsV9g6S+roT6xiELs9QQ6V3xMiw0aR5vqOkopaDUWlco1Wir4oOmRRJBIg5KjXKkBFPm9EYZNzdrbOmPtR8oqm6GsDV69Mwz3tX0o1TnKVnZ/a1/J+0VOGREiqdxOy2Q7y+MPw9WycHb5l0c6T3f7nik4vBG2c/yxrnGzn0g9ggmIm8G95C+A+4eFO9wsA2E763d+5XnWgySAPTAKonYLLRsZNhkr3GGg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none
Received: from MN2PR09MB4716.namprd09.prod.outlook.com (2603:10b6:208:216::19) by SA1PR09MB9654.namprd09.prod.outlook.com (2603:10b6:806:28b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6455.33; Thu, 8 Jun 2023 13:51:43 +0000
Received: from MN2PR09MB4716.namprd09.prod.outlook.com ([fe80::c867:73a8:88e3:de2]) by MN2PR09MB4716.namprd09.prod.outlook.com ([fe80::c867:73a8:88e3:de2%6]) with mapi id 15.20.6455.039; Thu, 8 Jun 2023 13:51:43 +0000
From: Bob Natale <RNATALE@mitre.org>
To: Nick Hilliard <nick@foobar.org>, "Haisheng Yu (Johnson)" <hsyu@biigroup.cn>
CC: "ipv6@ietf.org" <ipv6@ietf.org>, "tom=40herbertland.com@dmarc.ietf.org" <tom=40herbertland.com@dmarc.ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, "fgont@si6networks.com" <fgont@si6networks.com>
Thread-Topic: [OPSEC] [IPv6] [EXTERNAL] Re: [v6ops] Why folks are blocking IPv 6 extension headers? (Episode 1000 and counting) (Linux DoS)
Thread-Index: AQHZmfCUxFnieb2OH0CcGs76pqXCVK+A6MBw
Date: Thu, 08 Jun 2023 13:51:43 +0000
Message-ID: <MN2PR09MB47169829139A2A7A19C5EA73A850A@MN2PR09MB4716.namprd09.prod.outlook.com>
References: <11087a11-476c-5fb8-2ede-e1b3b6e95e48@si6networks.com> <27d28224-0cb0-eec2-8d54-f0d175596c85@gmail.com> <f5758380-9967-b67b-744d-dc36b7b599ab@si6networks.com> <4FCF75B585A1D068+7D9B99BB-B24B-4FE8-A3FD-54877C7C1131@cfiec.net> <375ea678-b05f-7bb6-5ae2-43c54cd271f4@si6networks.com> <CALx6S34u5=2UxEz3zeApv+_-W=PTj0PzMRHS1UC=zRchqVCDyQ@mail.gmail.com> <882610dc-cf8f-e08d-8d9e-0e786097f520@si6networks.com> <CALx6S34AnMaVyEVQxaO0b1JGbQetQvDC+xDHk6aH5vbXM-KT7A@mail.gmail.com> <2a02905427604fa6a4c95e2eaa1dd165@boeing.com> <CALx6S36pmsZighJVBLEZWvYqTh1tJtU4SH2Ym0V7oS87dPWAHQ@mail.gmail.com> <6b3a40ef922c47a483860468aac73502@boeing.com> <CALx6S36Vv57AZFr=2adfEMYnVSOECsowXw1c7pTo_E-FWokB6Q@mail.gmail.com> <CWXP265MB51535486342FD27A30CFEE6EC2459@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM> <CALx6S35VA7g95HA-HK1kAr4rehX6hmrzybGS-Hx8j6Mit5FBMg@mail.gmail.com> <79E4E13AA53D1956+88643FCA-56CF-4A3B-A7EC-571290B76A9C@biigroup.cn> <537896e9-ecaa-9a32-3c9d-60955182cecc@foobar.org>
In-Reply-To: <537896e9-ecaa-9a32-3c9d-60955182cecc@foobar.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=mitre.org;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: MN2PR09MB4716:EE_|SA1PR09MB9654:EE_
x-ms-office365-filtering-correlation-id: 6750f435-8ad0-46d1-3cdd-08db68277e47
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: GJm5jRjX/dY9v2mVELSRD+jXV0plg8ZkxD5eVpKxFxJYdmqPusuHCwZcorMMyuujNtJPzVtmZ1LnbEoFZy+Y1AzkGnu67bZHdI8Kw5kARkMIot/u9TWN/Qalmt9Ps/EIpohNB2mQ7MzT3AS/wNT/r6KWUaItuAdeY9L+bGkX1iYbdNgQQ/Lo4UG8quDBsdeK61KIkynt4JXzs0UjFdj4q1f8eLMAFJV/peOOF9Y5ohqlQOeKjNr5UrjbxtDpJsusNn+FAYbKAQEdric+7iejdrGTJ1I9Xb7vUSx6I/bY0CaI30jGTW15D+W8nFCVmQrwML/AcW1WwaieeMc8/iRsdf/XCstROhio/AbsNGEOqjCEOL0I82Hg55qn+pl/ye8LQNk5qR5AiHuyPfXeOKK28peAmsNQ69MtsVIpkXoIrfD6XToEcl0LxKUokb5dfGOrnbuRTryCO2QNtfLcJn/2zgH3fwqgHSruK8nyd01OvYWJ+xvYQU8OjSHbWRf6gOkEeJC2GZys2s67JC/gwB/PkpNKYy4TcSfi6pKhdEts8atTG4czlb+TgbUDgw/DMDChSf80+0/CABZ+vqjGiItYHM3z/0N7kcE1hSLeeT/4lGlL3Dw6Q4NLiqMen+fDOJkO
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR09MB4716.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(366004)(451199021)(1690799014)(52536014)(2906002)(5660300002)(8936002)(8676002)(4326008)(64756008)(66446008)(66556008)(66476007)(76116006)(66946007)(54906003)(66899021)(498600001)(110136005)(71200400001)(966005)(7696005)(186003)(53546011)(66574015)(55016003)(166002)(86362001)(83380400001)(9686003)(6506007)(26005)(38070700005)(33656002)(38100700002)(122000001)(221023011); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: oZG4bYrqLTZZFTrYt9HgUuhWiG25taaLLvXHE1vZrgfYWnszCV2NKF+uJznN8zNxgsRObi8ORbcKj90weA1V9b37WN8nBTr7163zox9naGY11ks8+1iXTnxWBeWiPh4AADBbGG4T2uy5dS1uj9aYL/Nu5c1FyHo1XD7uX+tMV5r70zere7Ptl+V5X2fcmXWTDuaawitVMoTmOTaTc/49Q92STYwJZF0/jpR/YYkzG2/0Gxmdw/82oEK0VGrUItgcACzJrX+FsGHXiR1g/ovb70aRmwkmCJ4A+1Nvqa/vYLVhj01AVjgBKUhxlBKvTLwPneVEkWv/7q9S2Aqf8lnya7dWFqa7GSCNP2g4L3YLPwNFmHklZv+pJHWHzI80oH3MQh8jmG0XXKtPtNpHSu+NwVjdclzTH90aqqTM/SCvJaTCxnMsX4aD53HBtr/GzU+Pnz4Bn9QntvD3gZXlsdX5JWFEdRryznN/kR53GEJNsqpWjjCaQPHJbO3MdADonLvSieppq05RAJ6M9lJg9VaiTu3OJNqG3BN9srMTxYN31UKG5pa40w7bX4S4a16nOlnc05kXKmObWl3yvO9eFLrGkdQgTw5PwCbGadzu1WiWdpCjlZ/Jfa/4SzxgzILuERbWyc9ytw/ExiACGXSZKCKvQ6GTghBLH6j9x1qQkKoBqKBSJY6pchSHZ62A8WLFjLXDxJQq5ds01vCuFQkwacrS09u9H1s++ug/OluWIH/8kLmUSZ0dCQCLo8s9HNPw6xQQ07v9cZgW0SyVStP9Ypar1QrwasIqjfwch+agq+DOlnt9uYPt+o8KX9uejmR4uZy604eTfFVMOM7jhRynZSml3fM9kL8c4a2KOq3I0sMUXGtMycxqJDyGFk2as1Lx5t3XOFtkNmX5BZ2Xay6O/QB+mtMAckadva400HsDIokJ1ShHOXFzl5WUcdhiqpHSM0Rh3k3942T2vFn6a9W1xHBUVlvMPVmnFT4CM44663aMSPRgKddz6USsHd3YL3ngqyWnVjKfVdHlBRhJMYpnCcHiR/A5O41s5nVd7Im/nadXYX72WUMKdVaNQbnAjGzDAny7QljPIjqX1V4VqcaFA6GgylK0b/zPE7PL0Mw6BO60iP9DEko65Kp6SN6TdX33MD682Tih2Bh60RgQQVei7MxqNi/vteeuk/6SiwhEJ5GK9FqVHy1y5POXA23j47orIx1AAIoxjuTft/joufK+1YaRv7jc8pi+og0cCzHiZ0Ey67sO13PoDCAyY+ZeBPuQt+cI+0/ZQuGUUlaEBvzPdOkPVDbBJKrRRdpnSzUbsOrmi5EVqsgsUrYa5GcK9/mivMaqhSeMzhk3BAY9so8bJsoc4oQqoEkZR9HEkkhnByH8ZzhstUXU59gnGyR1LdlJPPQi2cayuZ4LK/z2eHVyVPml2qLQPnAhuosi69eLvCwIdi0ltW8XfN4Kkupwe6HaYAemzXSJ2ntmoZbXKGjl6eq4BepHf/qHLDk+NecQfyrF1hXLeLNHROgjZn3taMrKK/c3ItXpjp2Eybkmi1vdpA5kIkwdFRMxQIRzW4pzng88oaOWwKEIL7oQ+ozrf4OBq6F+
Content-Type: multipart/alternative; boundary="_000_MN2PR09MB47169829139A2A7A19C5EA73A850AMN2PR09MB4716namp_"
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: +sNeqWIiZLfRMMsXJJ4iISONjzG/Nqk4QYoKGOGX9dIxKKmtCMiAVug+03MxGSqCb2ckjrguzZ9bJnbnIibNFvWS0NhOdHQ3gVV4uISKJpc7h3TXhnprcBsXz+p5s6GlLvgbWfxPb2jqBmoWLrw5aIJYKrRMf5fKAPR0CcvlHxPvczzIRhpUfmZsNS6I7BR3aHrS3coSKLcG+0A4W/cAR3P6YVi1Cc/73nP4YiTPDocbfjkZ1TNKnwPfFHWb5CulSNrXockqa+193WbLA6vybHC5RxevTJxn5QNnFwvEXpdF5sMJe/b3JQlsIDWmeug7qsq/fi9Zq+Llft7aaPSc/kb9AkB1+mwMlMdUF2nzt5NJguu6sd8lqkq1LQFKonszL52yGZ3Kd2Y2GcmkYt2NDUGvCEoAtRa7MEkQoAsco2zLix6WSVy7kbmB9TQ1+oicuNlLUiUjsEqzUHtXdzeWSljSw1zWtST7kfnPse7Lp1nY29VuaSoT5mwgQkixGo7MQa7Y3NuwSqkqEJNmsClGYkNhk6n3rbpEKon4ruq6bwdjJGNmS3qShjXCWKH20SRmd6XXPKutm+6/aiYLGTDpIQo2HUzgOQ9JnzvAyri+wVDi6nF/XyfJmV1MODFxLRfWcvsR+NUlI3+9iwta7F6vYf74Dfe98wqn7XLOMnJ7NZNolI33w0B4nYKulwdvECE9zj3vbzthjYqLDOeUFLwSu0Z7EZAajTmnes0d/cBrxPSCS9tsE7vxPUQKKl/rC5/NVV0Xgfb/IQfBpE2lbka1uCqPE450rIGuUmYD7SC9WX1ua8VVsvxMmyC7wJarYSnNo74pVcDESwd+oVETGDQItUMhSGp2O5RoXw1/wFudzDM4FtjD6xK/fxFamAuBQVqoK+zWvGJ71IUUW6sYPEmv1RGN0hNIE+GIs20X2H8gkKI=
X-OriginatorOrg: mitre.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB4716.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6750f435-8ad0-46d1-3cdd-08db68277e47
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2023 13:51:43.4137 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR09MB9654
X-MITRE: 8GQsMWxq66rxk57w
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:cc:subject:date:message-id:references:in-reply-to:content-type:mime-version; s=mZkevYdL; bh=xTMp2NbaThqMPDiLSj3ekTf8yD3+m+z1IVsMOc2ob9E=; b=nvpIm0pCvgiXhOhr7xdbzlHV07woRCH4OAap7hAZE5hlCbadP8/OMkx1u9LRyk8HErSHvjj8TQK/tmx+oqn77cIkbFH7wLwDcDSAuGxEViwBpWXaeMt8agEwRufbmwPCjIDFKddbqbo3rIsf9TBnpDmsCogkpyLjMjF1Haxfi6Q=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mZ_K-9LiCvW_s7epaGy4uAbU6Tc>
Subject: Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why folks are blocking IPv 6 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, 08 Jun 2023 13:51:52 -0000
Agreed, and suggest that this assertion in Johnson’s proposal needs further examination too: > We should not refrain from using IPv6 extension headers simply out of fear of the potential effects on efficiency and security. Considerations: - “fear” is an inappropriate term there, I believe. - If people/organizations have concerns based on risk assessment relative to cost-benefit, resolution of those concerns needs to be covered. - And perspectives on those concerns and resolutions differ across the service provider, product vendor, and user domains. - Based on past and present experience, a “fearful” posture towards security concerns might be reasonable. Not intended to be critical with the above … just suggesting that these points – already expressed in some form by more knowledgeable people earlier in this thread – be considered in the proposed document. BobN From: OPSEC <opsec-bounces@ietf.org> On Behalf Of Nick Hilliard Sent: Thursday, June 8, 2023 6:03 AM To: Haisheng Yu (Johnson) <hsyu@biigroup.cn> Cc: ipv6@ietf.org; tom=40herbertland.com@dmarc.ietf.org; v6ops@ietf.org; opsec@ietf.org; fgont@si6networks.com Subject: Re: [OPSEC] [IPv6] [EXTERNAL] Re: [v6ops] Why folks are blocking IPv 6 extension headers? (Episode 1000 and counting) (Linux DoS) there's a discussion, and an extensive bibliography, about operational problems associated with EHs in rfc9098. This document should provide some context about the real-world problems associated with EHs. Nick Haisheng Yu (Johnson) wrote on 08/06/2023 09:01: Hi, Fernando and Tom, I have been contemplating Fernando's questions lately, what exactly hinders the development of extension headers? Is it because IPv6 adoption is not widespread enough? Or do IPv6 extension headers themselves serve little purpose? Or is it because the use of IPv6 extension headers could potentially decrease network efficiency and security? I believe all of these reasons have some validity, but none of them are the primary cause. In my opinion, the main reason is that we lack a comprehensive understanding of the current development status and application scenarios of IPv6 extension headers. Only by thoroughly understanding the benefits and drawbacks of IPv6 extension headers can we make better use of them. In the current RFC 8200, extension headers are only recommended for use, and many service providers are concerned that handling unfamiliar extension headers could impact the efficiency and security of control-plane devices, as Fernando mentioned in his email example. Additionally, because many routing devices forward packets with unknown processing requirements to control-plane devices for handling, these impacts exist simultaneously at the forwarding and control layers. However, as Tom mentioned, the most secure network in the world is one that is turned off. We should not refrain from using IPv6 extension headers simply out of fear of the potential effects on efficiency and security. Therefore, I suggest that we consider drafting a document specifically focused on studying the current development status of IPv6 extension headers. This document should provide guidance on how IPv6 extension headers should be handled, when they are useful, and how to correctly use and process them. Alternatively, we can iterate on the foundation of 6man-eh-limits, and I would be glad to contribute in this regard. Best regards Johnson [https://mail-online.nosdn.127.net/997bfaaa29267122f3b7334a5d4895ce.jpg] 喻海生 Haisheng Yu(Johnson) 下一代互联网关键技术和评测北京市工程研究中心有限公司 hsyu@biigroup.cn<mailto:hsyu@biigroup.cn> 13654947748 ---- Replied Message ---- From Tom Herbert<tom=40herbertland.com@dmarc.ietf.org> <mailto:tom=40herbertland.com@dmarc.ietf.org> Date 5/30/2023 02:32 To Andrew Campling<andrew.campling@419.consulting> <mailto:andrew.campling@419.consulting> Cc Tom Herbert<tom=40herbertland.com@dmarc.ietf.org> , <mailto:tom=40herbertland.com@dmarc.ietf.org>v6ops@ietf.org<v6ops@ietf.org> , <mailto:v6ops@ietf.org>ipv6@ietf.org<ipv6@ietf.org> , <mailto:ipv6@ietf.org>opsec@ietf.org<opsec@ietf.org> <mailto:opsec@ietf.org> Subject Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why folks are blocking IPv 6 extension headers? (Episode 1000 and counting) (Linux DoS) On Sun, May 28, 2023 at 10:13 AM Andrew Campling <andrew.campling@419.consulting><mailto:andrew.campling@419.consulting> wrote: On Sat, May 27, 2023 at 11:05 PM Tom Herbert <tom@herbertland.com><mailto:tom@herbertland.com> wrote: Application developers and stack developers are also players in this game. And while each network provider might have the luxury of only focusing on their customer set, developers have to potentially address the needs of all users across the Internet. This is why network providers' attempts to protect the user are irrelevant to application developers-- without consistency across the Internet this level of security may as well not exist from their perspective. Obviously this situation didn't materialize overnight and it shouldn't be surprising that we've had to implement work-arounds to this problem. For instance, encryption goes a long way in limiting the network's visibility in the packet, but that does have its limits. Tom Let's not forget that some of those same developers are responsible for implementing surveillance capitalism, one of the most egregious invasions of user privacy and surely contrary to RFC 7258 - I know that people generally seem to focus on network-based monitoring, however application-based monitoring is potentially far more invasive. Some of the application-based "work-arounds" to network security measures you reference could be helpful in allowing those applications to exfiltrate user data; if applications behave increasingly like malware then it should not come as a surprise if they are treated as such by networks in an effort to protect users. Andrew, That's a very general statement. Can you give a specific example? Maybe one possibility is STT (draft-davie-stt) which was designed to repurpose TCP protocol number 6 as a tunneling protocol to circumvent some networks that filter UDP. But that proposal was rejected by IETF and never accepted into Linux. But even if a network assumes responsibility to protect the user from malware, its ability to offer any reasonable protection to users is extremely limited and becoming more limited. Network devices don't have the E2E visibility or context to properly filter application malware-- this is both true architecturally and in practice given the prevalence of TLS deployment. As noted elsewhere, I believe that it would be beneficial to the IETF community if greater efforts were made to engage with enterprise and public network CISOs, as well as more network operators. This would help inject more understanding of current operational security practices and considerations into protocol development activity, which might help to avoid puzzlement when new developments are unleashed, only to find them blocked or only greeted with luke-warm enthusiasm by those that have operational responsibility for security, customer service etc. "those that have operational responsibility for security, customer service etc." is not limited to network operators, application developers, server operators, and OS providers also assume that operational responsibility-- so if there is a conversation it should include all the players. Also, I'm not sure that "understanding of current operational security practices" would be of use here. As far as I can tell, there are no uniform security practices amongst network providers on the Internet. For instance, with respect to extension headers, some providers allow all of them, some allow none, and some seem to allow a subset. Besides that there's already RFC9098 that highlights some reasons why packets with extension headers might be discarded, but doesn't quantify the practices (exactly who is dropping packets and why). Tom Tom Andrew -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org<mailto:ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org<mailto:ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org<mailto:ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- [IPv6] Why folks are blocking IPv6 extension head… Fernando Gont
- Re: [IPv6] Why folks are blocking IPv6 extension … Tom Herbert
- Re: [IPv6] Why folks are blocking IPv6 extension … Ted Lemon
- Re: [IPv6] Why folks are blocking IPv6 extension … David Farmer
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… nalini.elkins@insidethestack.com
- Re: [IPv6] Why folks are blocking IPv6 extension … Jen Linkova
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Vasilenko Eduard
- Re: [IPv6] Why folks are blocking IPv6 extension … Fernando Gont
- Re: [IPv6] Why folks are blocking IPv6 extension … Fernando Gont
- Re: [IPv6] Why folks are blocking IPv6 extension … Tom Herbert
- Re: [IPv6] [OPSEC] Why folks are blocking IPv6 ex… Andrew Campling
- Re: [IPv6] [OPSEC] Why folks are blocking IPv6 ex… Andrew Campling
- Re: [IPv6] Why folks are blocking IPv6 extension … Tom Herbert
- Re: [IPv6] [OPSEC] Why folks are blocking IPv6 ex… Tom Herbert
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Nick Buraglio
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… nalini.elkins@insidethestack.com
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Dale W. Carder
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Nick Buraglio
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Nick Buraglio
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Ackermann, Michael
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Xipengxiao
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Michael McBride
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Ackermann, Michael
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Fernando Gont
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Brian E Carpenter
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Ole Troan
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Haisheng Yu
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Andrew Campling
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Bob Natale
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Tom Herbert
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Ole Troan
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… nalini.elkins@insidethestack.com
- Re: [IPv6] [EXT] Re: [OPSEC] [v6ops] Why folks ar… Bob Natale
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… David Farmer
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… nalini.elkins@insidethestack.com
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Tom Herbert
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Michael Richardson
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Ole Trøan
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… nalini.elkins@insidethestack.com
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… David Farmer
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Ole Troan
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Tom Herbert
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Fernando Gont
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… nalini.elkins@insidethestack.com
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Tom Herbert
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… nalini.elkins@insidethestack.com
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Ole Troan
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Fernando Gont
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Fernando Gont
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Tom Herbert
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Tom Herbert
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Brian E Carpenter
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Michael Richardson
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Brian E Carpenter
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Brian E Carpenter
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… hsyu
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Fernando Gont
- Re: [IPv6] [EXTERNAL] Re: [v6ops] [OPSEC] Why fol… Manfredi (US), Albert E
- Re: [IPv6] [EXTERNAL] Re: [v6ops] [OPSEC] Why fol… Fernando Gont
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Arnaud Taddei
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Vasilenko Eduard
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Arnaud Taddei
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Vasilenko Eduard
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Arnaud Taddei
- Re: [IPv6] [v6ops] [OPSEC] [EXTERNAL] Re: Why fol… nalini.elkins@insidethestack.com
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Tom Herbert
- Re: [IPv6] [v6ops] [OPSEC] [EXTERNAL] Re: Why fol… Tom Herbert
- Re: [IPv6] [v6ops] [OPSEC] [EXTERNAL] Re: Why fol… nalini.elkins@insidethestack.com
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Manfredi (US), Albert E
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Tom Herbert
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Brian E Carpenter
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Manfredi (US), Albert E
- Re: [IPv6] [OPSEC] [v6ops] [EXTERNAL] Re: Why fol… Bob Natale
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Haisheng Yu
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Warren Kumari
- Re: [IPv6] [OPSEC] [v6ops] [EXTERNAL] Re: Why fol… Ole Troan
- Re: [IPv6] [OPSEC] [v6ops] [EXTERNAL] Re: Why fol… Warren Kumari
- Re: [IPv6] [OPSEC] [v6ops] [EXTERNAL] Re: Why fol… Andrew Campling
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Fernando Gont
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Fernando Gont
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Fernando Gont
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Fernando Gont
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Tom Herbert
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Tom Herbert
- Re: [IPv6] [OPSEC] [v6ops] [EXTERNAL] Re: Why fol… Tom Herbert
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Fernando Gont
- Re: [IPv6] [v6ops] [OPSEC] [EXTERNAL] Re: Why fol… Clark Gaylord
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Tom Herbert
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Fernando Gont
- Re: [IPv6] [EXTERNAL] Re: [v6ops] [OPSEC] Why fol… Manfredi (US), Albert E
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Brian E Carpenter
- Re: [IPv6] [OPSEC] [v6ops] [EXTERNAL] Re: Why fol… Brian E Carpenter
- Re: [IPv6] [EXTERNAL] Re: [v6ops] [OPSEC] Why fol… Tom Herbert
- Re: [IPv6] [EXTERNAL] Re: [v6ops] [OPSEC] Why fol… Manfredi (US), Albert E
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Andrew Alston
- Re: [IPv6] [EXTERNAL] Re: [v6ops] [OPSEC] Why fol… Tom Herbert
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Andrew Campling
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Tom Herbert
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Dirk Trossen
- Re: [IPv6] [EXTERNAL] Re: [v6ops] [OPSEC] Why fol… Mike Simpson
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Haisheng Yu
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Nick Hilliard
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Fernando Gont
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Bob Natale