Tom,
> We've already had an attempt at IPv10 :-)
Indeed, we have!
Thanks,
Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360
On Thursday, May 25, 2023 at 08:15:33 AM PDT, Tom Herbert
<t...@herbertland.com> wrote:
On Thu, May 25, 2023 at 7:05 AM nalini.elk...@insidethestack.com
<nalini.elk...@insidethestack.com> wrote:
>
> Arnaud,
>
> First, nice to hear from you.
>
> Next, I think blocking EH without nuance or care is throwing out the baby
> with the bathwater.
>
> IMHO, if we have problems with EH because people have not carefully
> considered their use. I think if we do not make IPv6 an extensible and
> flexible protocol, we will be looking at creating a new version - IPv8?
> IPv10? before we know it.
Nalini,
We've already had an attempt at IPv10 :-)
>
> There are many problems with, for example, some TCP packets, and we do not
> say "just block TCP".
Also, look at how much effort was required to get network providers to
allow QUIC/UDP to pass. Not all network providers blocked it, but
enough did that it impeded deployment for a while. The good news is
that the providers and protocol developers worked together to address
any issues and it's now deployed, the bad news is it took a behemoth,
i.e. Google, to motivate these providers to facilitate innovation on
the Internet.
Tom
>
> Thanks,
>
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
>
>
> On Thursday, May 25, 2023 at 12:23:02 AM PDT, Arnaud Taddei
> <arnaud.taddei=40broadcom....@dmarc.ietf.org> wrote:
>
>
> Ok Eduard I recognise a bit of the epidermic reaction (after all I am half
> latin blood) and missed the telco context because I see the drama in
> enterprise context every single day!
>
> Now ironically the example I took below was a telco!
>
> But I buy your point … all good
>
> On 25 May 2023, at 07:58, Vasilenko Eduard
> <vasilenko.eduard=40huawei....@dmarc.ietf.org> wrote:
>
> Hi Arnaud,
> It is a good point that Enterprises have much more serious attention to
> security. But Telco is not so much paranoid about security.
> The last initiative in this WG is about “to push Telco to tolerate all EHs”.
> The context of this discussion is more about Telco.
>
> > The additional cost you can find ways to write them off
> In the majority of cases “No”. Because tests could not be free, support could
> not be free either. Performance penalty may be close to Zero (only a small
> loss of bandwidth) – depending on the EH type (maybe a 2x drop of performance
> because of recirculation).
>
> > the ‘additional cost’ and the ’security risk’ are not symmetric at all.
> Yes, it is an apple and orange comparison. But both exist, and both may be
> discussed.
>
> Ed/
> From: Arnaud Taddei [mailto:arnaud.taddei=40broadcom....@dmarc.ietf.org]
> Sent: Thursday, May 25, 2023 8:47 AM
> To: Vasilenko Eduard <vasilenko.edu...@huawei.com>
> Cc: Fernando Gont <fg...@si6networks.com>; Manfredi (US), Albert E
> <albert.e.manfr...@boeing.com>; IPv6 Operations <v6...@ietf.org>; 6man
> <i...@ietf.org>; opsec@ietf.org
> Subject: Re: [OPSEC] [EXTERNAL] Re: [IPv6] [v6ops] Why folks are blocking
> IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
>
> +1 just that the ‘additional cost’ and the ’security risk’ are not symmetric
> at all.
>
> The additional cost you can find ways to write them off
>
> The security risk is much more damaging because it is a compliancy risk
> (think DORA for the FSI in EU), a reputation risk that is now captured by
> credit rating agencies, a revenue risk, a stock rating agencies (your stock
> will drop), insurance ratings, etc. and 1) it is getting substantial and 2)
> it is even existential with a few examples that some organizations literally
> lost e.g. an MNO of €1.3B and 30 years of existence (only survived by 1
> backup link), etc
>
>
> On 25 May 2023, at 07:21, Vasilenko Eduard
> <vasilenko.eduard=40huawei....@dmarc.ietf.org> wrote:
>
> IMHO: Fernando comes here with a good example (EH DoS). Security is a good
> reason to block EHs.
> But for business, every feature should be tested, supported, and somebody
> should pay an additional performance penalty.
> I am not sure which reason is bigger: additional cost or security risk. It
> depends on the organization type.
> Ed/
> -----Original Message-----
> From: OPSEC [mailto:opsec-boun...@ietf.org] On Behalf Of Arnaud Taddei
> Sent: Thursday, May 25, 2023 8:12 AM
> To: Fernando Gont <fg...@si6networks.com>
> Cc: Manfredi (US), Albert E <albert.e.manfr...@boeing.com>; IPv6 Operations
> <v6...@ietf.org>; 6man <i...@ietf.org>; opsec@ietf.org
> Subject: Re: [OPSEC] [EXTERNAL] Re: [IPv6] [v6ops] Why folks are blocking
> IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
>
> Would like to support Fernando again, and not just because I have a Sony TV
> too.
>
> Cybersecurity is in such a bad state that I can only plea for a sense of
> realism and pragmatism vs dogmatism to get real solutions at hand to the
> defenders practitioners
>
> If not I will ask people here to consider spending a week in a Security
> Operation Center when there is a Ransomware breaking up
>
> Fernando’s paper intentions will be appreciated by the defenders
>
>
>
>
> On 25 May 2023, at 03:07, Fernando Gont <fg...@si6networks.com> wrote:
>
>
>
> On 25/5/23 02:01, Manfredi (US), Albert E wrote:
>
> -----Original Message-----
> From: ipv6 <ipv6-boun...@ietf.org> On Behalf Of Fernando Gont
>
> Given the amount of things that get connected to the Net (smart bulbs,
> refrigerators, etc.) -- and that will super-likely never receive security
> updates, you may have to **rely on your own network**.
>
> For instance, I wouldn't have my smart TV "defend itself".
>
> Agreed, "on your own network." >From the viewpoint of a household, whatever
> network defense has to be behind that household's router, for it to be
> credible, and preferably right in each host. Yeah, some IoT devices may not
> be updated regularly.
>
>
> So, that's why people block them at the edge.
>
> (just the messenger)
>
>
>
>
> The ISP has to worry about protecting that ISP's own network.
>
>
> That's e.g. where RFC9098 comes in, with notes on why they are dropped in
> places other than the edge network.
>
>
>
>
> Households have to be responsible for protecting their household's
> network. (And connected TVs do get regular software updates, as a
> matter of fact.)
>
>
> I guess it all depends on the TV? e.g., I for one I'm not planning to throw
> it out just because Sony decided to quit pushing updates (which were never
> automatic for my set).
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fg...@si6networks.com
> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
>
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.ietf.org/mailman/listinfo/ops&source=gmail-imap&ust=1685596906000000&usg=AOvVaw1SaRszq_Trn0SZdoxCGfAf
> ec&source=gmail-imap&ust=1685581681000000&usg=AOvVaw2CR1KLp2V-YO9ZOvhw
> rWtn
>
>
>
> --
> This electronic communication and the information and any files transmitted
> with it, or attached to it, are confidential and are intended solely for the
> use of the individual or entity to whom it is addressed and may contain
> information that is confidential, legally privileged, protected by privacy
> laws, or otherwise restricted from disclosure to anyone else. If you are not
> the intended recipient or the person responsible for delivering the e-mail to
> the intended recipient, you are hereby notified that any use, copying,
> distributing, dissemination, forwarding, printing, or copying of this e-mail
> is strictly prohibited. If you received this e-mail in error, please return
> the e-mail to the sender, delete it from your computer, and destroy any
> printed copy of it.
>
>
>
> This electronic communication and the information and any files transmitted
> with it, or attached to it, are confidential and are intended solely for the
> use of the individual or entity to whom it is addressed and may contain
> information that is confidential, legally privileged, protected by privacy
> laws, or otherwise restricted from disclosure to anyone else. If you are not
> the intended recipient or the person responsible for delivering the e-mail to
> the intended recipient, you are hereby notified that any use, copying,
> distributing, dissemination, forwarding, printing, or copying of this e-mail
> is strictly prohibited. If you received this e-mail in error, please return
> the e-mail to the sender, delete it from your computer, and destroy any
> printed copy of it.
>
>
> This electronic communication and the information and any files transmitted
> with it, or attached to it, are confidential and are intended solely for the
> use of the individual or entity to whom it is addressed and may contain
> information that is confidential, legally privileged, protected by privacy
> laws, or otherwise restricted from disclosure to anyone else. If you are not
> the intended recipient or the person responsible for delivering the e-mail to
> the intended recipient, you are hereby notified that any use, copying,
> distributing, dissemination, forwarding, printing, or copying of this e-mail
> is strictly prohibited. If you received this e-mail in error, please return
> the e-mail to the sender, delete it from your computer, and destroy any
> printed copy of it.
> _______________________________________________
> v6ops mailing list
> v6...@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6...@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
