> 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!
+1 to a EH use case document. Some of us, for instance, have been trying to standardize a bitstring in an EH. It would be good to at least document as a use case. thanks, mike Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com<http://www.insidethestack.com/> (831) 659-8360 On Thursday, May 18, 2023 at 07:49:50 AM PDT, Nick Buraglio <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> wrote: On Thu, May 18, 2023 at 7:24 AM Andrew Campling <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> on behalf > of Fernando Gont <[email protected]<mailto:[email protected]>> > Sent: Thursday, May 18, 2023 2:19 pm > To: David Farmer <[email protected]<mailto:[email protected]>>; Tom Herbert > <[email protected]<mailto:[email protected]>> > Cc: [email protected]<mailto:[email protected]> > <[email protected]<mailto:[email protected]>>; V6 Ops List > <[email protected]<mailto:[email protected]>>; opsec WG > <[email protected]<mailto:[email protected]>> > 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 > > <[email protected]<mailto:[email protected]> > > <mailto:[email protected]<mailto:[email protected]>>> > > 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: [email protected]<mailto:[email protected]> > PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494 > > _______________________________________________ > OPSEC mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/opsec _______________________________________________ v6ops mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
