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

"nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com> Mon, 22 May 2023 14:48 UTC

Return-Path: <nalini.elkins@insidethestack.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 B17D1C151064 for <ipv6@ietfa.amsl.com>; Mon, 22 May 2023 07:48:35 -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_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=yahoo.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 IbHCVU1PCyrR for <ipv6@ietfa.amsl.com>; Mon, 22 May 2023 07:48:32 -0700 (PDT)
Received: from sonic316-26.consmr.mail.ne1.yahoo.com (sonic316-26.consmr.mail.ne1.yahoo.com [66.163.187.152]) (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 063BFC14CE29 for <6man@ietf.org>; Mon, 22 May 2023 07:48:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684766911; bh=3LJ+cuKisPPYIpQDOzFHb2x7juZq3RdnC4MRRnUYBd8=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=Xzk62S91xjizPBSwsKsU4beC7ke98If/qyKv6uAZPgPXp7eeWRCT2dXoxHamru/HM0xiUip3IKYIY3o7tB8QqYibflRM3I3eZOJUHWLgAI6jGyDLTS+F6WZxguzhUhSVOjiyHA8GjagcJbQvvpcfBrHD3ho4M8qSKZKaHzjlW2hghRK0a8Ivd6qRVoSlmRcheK/PVOVs71jVmdhTKMffPV9SQggpFRCtCuAlp9qUTZUAEM+x+F9uA+fGG5+vF5I4l0ufJZkEcxECY/9KgNhCKmoEZuYdUiQziXTDFQlMUQu4Pq1AvNI5CitN8uTU+G1KDABlMbKc8YoSoAWMTo3T8Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684766911; bh=/uuDulnqlWZHMrxVbjeW1YITeioBSPrE84nIap9EZmi=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=mjAX9mMKc7UtFkyznCO4NYzVPXS9X0eEqFm4qaxo9ByuVshSnd94Yw4kwvBGAd0IpHHB+sxWdTyVHN/usiTNkrccPh/EJt32mS0dAA25WI0Vyf+nd05zFwU2gMqqSbAOTPbb9tM+9o18cKX0QYkcfIQ5ok8CwpkXyNqAA4jLg4+s37kALxblYAzOVeyZViIo9f3CDIejsZl2djF734Y/yZRhW66uBRovdZWul+ikopNMeP0hF4qRVpC1yO1E2s0QO50gP+GNwmreN00o5F3FgMZ1WeL6nUunvl9CX70blG2EXU3yZuHJBQxfAqPUmzPwTB9RQr4bbaFwrgzfenCPpg==
X-YMail-OSG: Wgtx8fEVM1m9DvUHQAnKpQ5pw_R6I0bDiRMxiFmNVSbto9mHh78Nys3igC9nBNF ammUGQBapU8XKIhU4iWvWIs4pxiweFIOlI3Y_AWsubDE2Oc9HJJL.i6nrwEMuvUadtXb9Fu15jTS OnjnC6s9UXhOuyMwfoSBAKldKuAmnIvxzzlw4h.Syx6FnDzwwpN9vKW4PH8Zbg4twOkXBbf4vgKY RQO3cLC0Vcxz5CKloBT2Qfs_7iD8tqiuJYDCnOqzZiE4MH44SHU8H6ybV9o6AM0pl7OuR5o6YaQN sGNe4R3Vs0nbU0f0uXwcw6z_7HTqODTEDjL0N9xMYvfW8cBKlkZ2Wl4_yepHZUX3wSwjhH80.9Si ZKw7nWYES3kE5P1cd1S8oufOILOUgfwZvay1vODFy0IGghOW_lcSgnHBkXKO9.kxNHI9cQBOSrdS wcMhDnGVG_q7a0ovDp1mBQkVMtgg6zaG3zegyDRN5RMqhGlqe2GS6OaRyppjOfp45njIwN2i6Jh9 xSpDwMYa855TBALuGM7Ww5RU4Pon9RXtHo4ZOpkmmF.AJ1Hq1UvKulZon3POE5hQdKuzl.dYYUb6 Wre6VFx.s3_NLCiEDF3u3nl71Ann86Gv6.3D6QUlRD5HP7QX3hmEtEUq8c_W.w6D4.BMEAeEwzH6 UZcRyBHh19hHpi5XSky5vNN08hyp5foNvzmqjib9W7usfg9T7ZVyfZZYkhWcSkGXAT.KO6mWFEMB RVpPFlq3P3xy5zSdJCzKFffN9scbs3y6z7qcuzjL_28A9dw5r6yKH6EWru2VfCUSZvxCbNv8oY8O nsF6Y3sn3BqEVSc83wCEc7GQM4N2D1L7I0Nb3Vd_JkdXqReYYMGR__1yggAko1GmqNSGSxAPm73Y m7YO6fBX2DadKsYVaRERrbU9.DZL7lpy3y2YSbpKxcQw1ZS4Lt6sn9Ikv8c2PZFt1Q7oIH8p9uSw 837rpW7t3wuGMCh4tcEUXpy2WMV59y6aYcUg67eTirqLnlM3FJeyZ0CDqqXQWWDNFufaOa3d3pPD okzcjEgOTewn1lue_gUlEBff_7EUV3QWwTDKszUnzUo7BVda7txeotfgBc4Tl2SU1939ARXp_.6n IXLTC.BlQ2zNR1kxGak_3rwT4ZRncqbM96SwZZLf.SVZNqGDRMmgRLqBCFVfLgEbIIZZClIKv8sY m_DgyDFZX_ypYDKXDZY8joFd2fE_h5wi7WQ3p8eVXsg3FGlpyVDHXiar5YHP2Koim4AMiIMRgCnV U4xlnY.6fqc3xdArXOjtiJh3Jj_PgUD9t4KuQb7iSpv1q58Z3iXJJXtCP9vplcnXrbpPLQZxUilc LpHepxuwD.8_cRzuLQwx3.kt4RqOckKV.CGZ3KQx5LjPDgz_xND.CVJVqRUe5SbpAgl197e7FQke SPPjABui_yBCJNyAIf.1mvc3YYocYE5FZbndK51oAOIAkr9LkhfeIUPsxDE5e0GpD0DSbril28K1 HOrIBB02OXgjneOJ989QzooSD0yaMEMR1cv9.a2i7oikDJtuLKtPbhgWJJzco5JEyaDJ937nSeYd MVnJktN0G1IsEDephfvzTrNvPwel4o8GXnab8wukwgaUn_VBmQCG.NlDD9ZDDpdF9hYbntlYefGY j7jlkZvqt06UkOvOGgKczJ4xMiNzdCBv7VAmPcssOhpJdlkvNrAn8KoJVaZEaPbuI5PVoK4B_Nby ZCX4o1DzIlWiL3eksTq_Lvb7QpDLUlLlzYbfLWE63RpmKfVAEPmm_cTDLLialU3YEpT431NgxBnh IU2oU11cOebay9dNhUmecPYuvrs6ddFxG_bchO_pCxBNJVaXjQUOhb5T0RMq9I5Q077A4RShnD_9 bHd4MQUd98sZHtG__DkdKAVSUyqqTA8nn8noybpYgfEb2G5h8yMe0WAJZ1vygKp_S_ImIIM6xxzs OQm2GWMOMEWLxkEw9Fy2SNt5NclHF3ATlKIJmL6ordLaV4I1khWTPl7wz.KXNFNqdEP.MrdfNylv Vr0EmxJnYNtux2qWkLOfFHy_QPOdYswvo7CN0PCWOdTvW_PDN80rxuMlABtECSNrUicNHOgezNal MsnxiUSRpPmDpxW_lc4NSlbQPzmByeb.krF5fGpSeyJ4btMeurhkkFL3iXTnoaec2kwJGIgqF.0P ywa_wOaIGe6UeaDjJtladIp0ucAA.1EC.Z2cefwxSTymghXX_MlIm.5rwmRgwzjJzwF6NvIWa2ol xRiCVElvUyUxVuxbO2A--
X-Sonic-MF: <nalini.elkins@insidethestack.com>
X-Sonic-ID: 4a3336aa-6c1d-441d-95da-4129a0645702
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Mon, 22 May 2023 14:48:31 +0000
Date: Mon, 22 May 2023 14:38:27 +0000
From: "nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com>
To: Tom Herbert <tom=40herbertland.com@dmarc.ietf.org>, Nick Buraglio <buraglio@forwardingplane.net>, Bob Natale <RNATALE@mitre.org>
Cc: Fernando Gont <fgont@si6networks.com>, "6man@ietf.org" <6man@ietf.org>, V6 Ops List <v6ops@ietf.org>, opsec WG <opsec@ietf.org>
Message-ID: <1029391748.856548.1684766307360@mail.yahoo.com>
In-Reply-To: <MN2PR09MB471666DBA6479BB3076B3E55A8439@MN2PR09MB4716.namprd09.prod.outlook.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> <CWXP265MB515321A0E0A91CD66260C26CC27F9@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM> <CALx6S35py1b6EyS3UeT8JvgwN-w8wBtprCn9OJSCS-nvfQ_L-A@mail.gmail.com> <CAGB08_djDtrFRY37ZTH_draGLTxM3vO7bMfT6YyyKFrTH_Tx5w@mail.gmail.com> <17955_1684421652_64663C14_17955_115_1_1200504588.3592661.1684421597958@mail.yahoo.com> <MN2PR09MB471666DBA6479BB3076B3E55A8439@MN2PR09MB4716.namprd09.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_856547_848494271.1684766307355"
X-Mailer: WebService/1.1.21495 YMailNorrin
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/dT_UukJPBQf9UHFovskwsGg3dXU>
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 14:48:35 -0000

Bob,
I am not sure of what you are saying.
> New uses should require protocol updates via the standard process or new protocols

Of course, protocol updates will go through the IETF process.  All I am saying is that sitting here in 2023, we cannot tell what "new uses" will be found in 2033.   I would expect that someone who has a new option will submit it to the IETF as an internet draft, etc. 
Hope that is more clear.

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360 

    On Monday, May 22, 2023 at 07:17:49 AM PDT, Bob Natale <rnatale@mitre.org> wrote:  
 
  
>From way up in the nose-bleed section for lurkers:
 
>Although, IMHO one of the points of extension headers is that they can be used to extend the protocol for purposes which we cannot think of today!
 
  
 
Something tells me that’s a bad idea for Internet-grade (and similar) standard protocols … just sounds “looser” (i.e., congenitally riskier and ultimately “messier”) than defined options or profiles. New uses should require protocol updates via the standard process or new protocols. Is that an utterly naïve position and the Internet cannot live without protocols that do not include undefined “extensions” for purposes we cannot think of at the time the protocols are standardized?
 
  
 
Lurking with a bit of vertigo now😊,
 
BobN
 
  
 
From: OPSEC <opsec-bounces@ietf.org> On Behalf Of nalini.elkins@insidethestack.com
Sent: Thursday, May 18, 2023 10:53 AM
To: Tom Herbert <tom=40herbertland.com@dmarc.ietf.org>; Nick Buraglio <buraglio@forwardingplane.net>
Cc: Fernando Gont <fgont@si6networks.com>; 6man@ietf.org; V6 Ops List <v6ops@ietf.org>; opsec WG <opsec@ietf.org>
Subject: [EXT] Re: [OPSEC] [v6ops] [IPv6] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
 
  
 
Nick,
 
  
 
> neither really have use cases
 
  
 
I think a use cases document is a great idea!  Although, IMHO one of the points of extension headers is that they can be used to extend the protocol for purposes which we cannot think of today!
 
  
 
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360
 
  
 
  
 
On Thursday, May 18, 2023 at 07:49:50 AM PDT, Nick Buraglio <buraglio@forwardingplane.net> wrote:
 
  
 
  
 
Is there any document that details the current operational best practices or explains the EH options and use cases in a succinct document? I didn't find one (although I did not look terribly hard). If not, that sounds like an opportunity to work through them and create one, perhaps? 
 
Nalani has a deep dive study here https://www.ietf.org/archive/id/draft-elkins-v6ops-eh-deepdive-fw-01.html and https://datatracker.ietf.org/doc/draft-elkins-v6ops-eh-deepdive-cdn/ but I wasn't able to find a list with some use cases akin to the ND considerations draft here https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-considerations/ 
 
RFC7045 has a decent, and RFC2460 explains what they are but neither really have use cases. 
 
  
 
nb
 
  
 
On Thu, May 18, 2023 at 9:33 AM Tom Herbert <tom=40herbertland.com@dmarc.ietf.org> wrote:
 

On Thu, May 18, 2023 at 7:24 AM Andrew Campling
<andrew.campling@419.consulting> wrote:
>
> I wonder if part of the issue here is that insufficient attention is being given to operational security matters and too much weight is given to privacy in protocol development, irrespective of the security implications (which is of course ultimately detrimental to security anyway)?

Andrew,

There is work being done to address the protocol "bugs" of extension
headers. See 6man-hbh-processing and 6man-eh-limits for instance.

Tom

>
> Andrew
>
>
> From: OPSEC <opsec-bounces@ietf.org> on behalf of Fernando Gont <fgont@si6networks.com>
> Sent: Thursday, May 18, 2023 2:19 pm
> To: David Farmer <farmer@umn.edu>; Tom Herbert <tom=40herbertland.com@dmarc.ietf.org>
> Cc: 6man@ietf.org <6man@ietf.org>; V6 Ops List <v6ops@ietf.org>; opsec WG <opsec@ietf.org>
> Subject: Re: [OPSEC] [IPv6] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
>
> Hi, David,
>
> On 18/5/23 02:14, David Farmer wrote:
> >
> >
> > On Wed, May 17, 2023 at 13:57 Tom Herbert
> > <tom=40herbertland.com@dmarc.ietf.org
> > <mailto:40herbertland.com@dmarc.ietf.org>> wrote:
> [...]
> >
> > Maximum security is rarely the objective, I by no means have maximum
> > security at my home. However, I don’t live in the country where some
> > people still don’t even lock there doors. I live in a a city, I have
> > decent deadbolt locks and I use them.
> >
> [....]
> >
> > So, I’m not really happy with the all or nothing approach the two of you
> > seem to be offering for IPv6 extension headers, is there something in
> > between? If not, then maybe that is what we need to be working towards.
>
> FWIW, I[m not arguing for a blank "block all", but rather "just allow
> the ones you really need" -- which is a no brainer. The list you need
> is, maybe Frag and, say, IPsec at the global level? (from the pov of
> most orgs).
>
> (yeah... HbH and the like are mostly fine for the local link (e.g. MLD).
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
>
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
 

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops