> Thanks for all your efforts!
Thanks for the kind words, Tom.
> I'd also point out that work is also underway to fix the protocol "bugs" with
>EH in> draft-ietf-6man-hbh-processing and draft-ietf-6man-eh-limits.
Great!
Thanks,
Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360
On Monday, May 22, 2023 at 10:11:28 AM PDT, Tom Herbert
<t...@herbertland.com> wrote:
On Mon, May 22, 2023 at 9:35 AM nalini.elk...@insidethestack.com
<nalini.elk...@insidethestack.com> wrote:
>
> Ole,
>
> >>> it might be time that we accept that this was a bad idea. Which
> >>> deployment status has confirmed.
>
> >> Is it your intent to submit a draft deprecating IPv6 Extension Headers?
>
> > Do you want me to?
> > A couple of them seem to have found some use within limited domains. Those
> > problems could likely have
> > been solved also with encapsulation and as it turns out the limited domains
> > end up with additional
> > encapsulation too. Encapsulation is in my a view a better way to reason
> > about these extensions than EHs.
>
> > If nothing else they have served as a way to extend the ip protocol name
> > space.
>
> No, it just seemed to be the logical extension of your thinking. Please
> correct me if I have misunderstood.
>
> I believe that EHs can provide a great deal of useful functionality and will
> do so even more in the future. We, ourselves, are working with a team in
> India to investigate DNS resiliency using our PDM Destination Options
> Extension Header.
>
> I believe that we need to find out exactly what the situation is as far as
> EH's. If there are bugs in network device code, then we need to fix them.
> We have found a number already and are working with the relevant vendors.
>
Nalini,
Thanks for all your efforts! I'd also point out that work is also
underway to fix the protocol "bugs" with EH in
draft-ietf-6man-hbh-processing and draft-ietf-6man-eh-limits.
> Once bugs are fixed, then we need to consider carefully what BCP around EHs
> should be done, taking into account various common topologies as well as
> devices such as proxies and load balancers. I mention those in particular as
> what we have found points to those devices in particular as posing problems
> rather than transit networks.
Agreed, IMO if a network provider disallows a protocol it should be
because there is an inherent risk or unfixable bug in the protocol
and, not because of a fixable implementation bug or because of an
"opt-in" model for IETF protocols. Of course, if IETF is publishing
protocols that are an inherent security risk then maybe they should be
deprecated! (I don't think that's generally the case for EH).
Tom
>
> Of course, our testing to date is absolute lack of transmission rather than
> lack of transmission based on EH length or type. We felt that was the
> logical first step.
>
> Thanks,
>
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
>
>
>
>
>
>
> On Monday, May 22, 2023 at 09:21:33 AM PDT, Ole Trøan <otr...@employees.org>
> wrote:
>
>
>
>
>
>
> Hi Nalini,
>
> >> it might be time that we accept that this was a bad idea. Which deployment
> >> status has confirmed.
> >
> > Is it your intent to submit a draft deprecating IPv6 Extension Headers?
>
> Do you want me to?
> A couple of them seem to have found some use within limited domains. Those
> problems could likely have been solved also with encapsulation and as it
> turns out the limited domains end up with additional encapsulation too.
> Encapsulation is in my a view a better way to reason about these extensions
> than EHs.
>
> If nothing else they have served as a way to extend the ip protocol name
> space.
>
> O.
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
