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

[Johnson]

Hi, Fernando 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).I don't have a Sony TV, so I have a slightly different perspective.The essence of the extension header issue is determined by the competition between operators and equipment vendors. For most internet users, they rely on the default configurations provided by the operators or equipment vendors. Operators always want devices from vendors that offer powerful features (e.g., in SRv6, equipment vendors aim to support as many layers of Segment Routing lists as possible). However, during actual deployment, only a portion of these features is used due to security concerns. Equipment vendors are motivated to innovate as they seek to outperform their competitors and gain profits in the market.The extension headers in IPv6 provide a significant advantage beyond the address space of IPv4, enabling flexible and programmable network transmissions. Looking at the current applications of IPv6 extension headers, notable achievements have been made (such as SRv6). Perhaps it's time to consider reducing restrictions on extension headers and allow for more innovation and application.Johnson Yu








 


喻海生Haisheng Yu (Johnson)下一代互联网关键技术和评测北京市工程研究中心有限公司h...@cfiec.net13654947748


 

  
 Replied Message 
  
  

  

 From 


Fernando Gont


  
  

 Date 


5/25/2023 08:49

  
  

 To 


 
  
Brian E Carpenter
,
  
  
Andrew Campling
,
  
  
Fernando Gont

  

  
  

 Cc 


  
IPv6 Operations
,
  
  
6man
,
  
  
opsec@ietf.org

  

  
  

 Subject 


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

  

  
  Hi, Brian,On 23/5/23 00:41, Brian E Carpenter wrote:[...]  That depends where you choose to apply the zero trust model. As Steve  Bellovin argued many years ago in his distributed firewalls paper,  distributing the trust model to the end systems is best, because you no  longer have to trust any intermediate systems.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".Cheers,-- Fernando GontSI6 Networkse-mail: fg...@si6networks.comPGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494___v6ops mailing listv6...@ietf.orghttps://www.ietf.org/mailman/listinfo/v6opsÿ




___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

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

[Bob Natale]

Speaking of sales pitches (and IMHO): "Zero trust" is an oxymoron in all but 
trivial operating environments.

(That's a blasé assertion anyway ... we're on to "observability" now!)

BobN

-Original Message-
From: OPSEC  On Behalf Of Manfredi (US), Albert E
Sent: Thursday, May 25, 2023 5:44 PM
To: Brian E Carpenter 
Cc: IPv6 Operations ; 6man ; opsec@ietf.org
Subject: Re: [OPSEC] [v6ops] [EXTERNAL] Re: [IPv6] Why folks are blocking IPv6 
extension headers? (Episode 1000 and counting) (Linux DoS)

-Original Message-
From: Brian E Carpenter  

> It's perfectly fine if a host chooses to block incoming packets for any 
> reason whatever, including unknown extension headers. That's quite consistent 
> with the *network* allowing permissionless innovation.

Right, but, as others mentioned, there are likely going to be IoT devices in my 
home, or in my enterprise, which are not as updatable as my smarter boxes. And 
those need protecting too. So the easiest approach is to keep out anything 
potentially harmful from the inside network.

Also, this same sort of security gateway model is used in the defense industry. 
Put the burden on some gateway box rather than relying too much on individual 
hosts. Why? Because "We don't necessarily trust the vendors of individual 
hosts, so we'll use a broader brush approach." This is real.

> The problem arises when any upstream intermediate node drops a packet because 
> it doesn't like it for some reason. There, you immediately create the tussle 
> between transparency and security, and I strongly suspect that there is no 
> universal way of avoiding that tussle. Not every new feature has backing from 
> Google.

Agreed, and my bet is, the tussle will favor not banking too much on header 
extensions, when security is an issue. And security is increasingly an issue, 
as we have seen over past decades.

> I don't want my ISP or my CE router to block any extension headers.

My bet is that over time, IPv6 CE routers will likely block anything unneeded 
by default, and then maybe permit users to go to "advanced options" to 
fine-tune the router to their special needs. And as we know, the very vast 
majority will never attempt any such thing. (Just as the very vast majority 
never even change the default name of their home WiFi access point.)

I understand your point about the IPv6 sales pitches. Skepticism about sales 
pitches is not unusual, however.

Bert
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

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

[Manfredi (US), Albert E]

-Original Message-
From: Brian E Carpenter  

> It's perfectly fine if a host chooses to block incoming packets for any 
> reason whatever, including unknown extension headers. That's quite consistent 
> with the *network* allowing permissionless innovation.

Right, but, as others mentioned, there are likely going to be IoT devices in my 
home, or in my enterprise, which are not as updatable as my smarter boxes. And 
those need protecting too. So the easiest approach is to keep out anything 
potentially harmful from the inside network.

Also, this same sort of security gateway model is used in the defense industry. 
Put the burden on some gateway box rather than relying too much on individual 
hosts. Why? Because "We don't necessarily trust the vendors of individual 
hosts, so we'll use a broader brush approach." This is real.

> The problem arises when any upstream intermediate node drops a packet because 
> it doesn't like it for some reason. There, you immediately create the tussle 
> between transparency and security, and I strongly suspect that there is no 
> universal way of avoiding that tussle. Not every new feature has backing from 
> Google.

Agreed, and my bet is, the tussle will favor not banking too much on header 
extensions, when security is an issue. And security is increasingly an issue, 
as we have seen over past decades.

> I don't want my ISP or my CE router to block any extension headers.

My bet is that over time, IPv6 CE routers will likely block anything unneeded 
by default, and then maybe permit users to go to "advanced options" to 
fine-tune the router to their special needs. And as we know, the very vast 
majority will never attempt any such thing. (Just as the very vast majority 
never even change the default name of their home WiFi access point.)

I understand your point about the IPv6 sales pitches. Skepticism about sales 
pitches is not unusual, however.

Bert
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

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

[Brian E Carpenter]

On 26-May-23 08:33, Manfredi (US), Albert E wrote:

-Original Message-
From: Tom Herbert 


It's more than a preference to have host security, it is an absolute 
requirement that each host provides security for its applications and users. 
This requirement applies to SmartTVs, SmartPhones, home computers, and pretty 
much all the several billion end user devices connected to the Internet. No 
host device would ever assume that the network consistently provides any 
adequate level of security, for real security we need to assume that the host 
is the first and last line of defense (i.e. zero trust model).


I could not agree more, Tom. So, as Fernando and others have said, the impulse 
is to block everything coming in from the Internet that you figure you don't 
need **right now**. Such as weird complicated header extensions.


It's perfectly fine if a host chooses to block incoming packets for any reason 
whatever, including unknown extension headers. That's quite consistent with the 
*network* allowing permissionless innovation.

The problem arises when any upstream intermediate node drops a packet because 
it doesn't like it for some reason. There, you immediately create the tussle 
between transparency and security, and I strongly suspect that there is no 
universal way of avoiding that tussle. Not every new feature has backing from 
Google.



The ISP has its own concerns, to protect its network, but I, in my enterprise 
or household, have different concerns. I'm not going to trust the ISP's 
security mechanisms to provide my own security needs.

Honestly don’t see how IPv6 is going to change that. Over time, perhaps, some specific 
extensions used out in the wild will be seen as crucially important to my enterprise or 
household, and maybe those will not be blocked. But "trust me, you must accept all 
these EHs"? More likely, those potential innovations will go unused and maybe will 
eventually be implemented in a different way.


A well-implemented host will not be troubled by unkown extension headers or options. If 
my "smart" TV isn't capable of ignoring unkown extension headers, its vendor 
will have to give me my money back. I don't want my ISP or my CE router to block any 
extension headers.



Security evolved as it did, over IPv4, for a reason, methinks.


There is really no difference between the story of IPv4 options and IPv6 extension 
headers, except that extensibility was a sales argument for IPv6, so naturally 
people have tried to use them. And it would be exactly the same for IPvN where 
N>6.

   Brian
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

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

[Tom Herbert]

On Thu, May 25, 2023 at 1:34 PM Manfredi (US), Albert E
 wrote:
>
> -Original Message-
> From: Tom Herbert 
>
> > It's more than a preference to have host security, it is an absolute 
> > requirement that each host provides security for its applications and 
> > users. This requirement applies to SmartTVs, SmartPhones, home computers, 
> > and pretty much all the several billion end user devices connected to the 
> > Internet. No host device would ever assume that the network consistently 
> > provides any adequate level of security, for real security we need to 
> > assume that the host is the first and last line of defense (i.e. zero trust 
> > model).
>
> I could not agree more, Tom. So, as Fernando and others have said, the 
> impulse is to block everything coming in from the Internet that you figure 
> you don't need **right now**. Such as weird complicated header extensions.
>
> The ISP has its own concerns, to protect its network, but I, in my enterprise 
> or household, have different concerns. I'm not going to trust the ISP's 
> security mechanisms to provide my own security needs.
>
> Honestly don’t see how IPv6 is going to change that. Over time, perhaps, some 
> specific extensions used out in the wild will be seen as crucially important 
> to my enterprise or household, and maybe those will not be blocked. But 
> "trust me, you must accept all these EHs"? More likely, those potential 
> innovations will go unused and maybe will eventually be implemented in a 
> different way.

Bert,

It's your prerogative to block all EH on your home router. But not
everyone does that. And even if you do, when you leave home and
connect to WIFI at the local coffee shop do you verify that the
network provider for the coffee shop has properly blocked the
extension headers that are "insecure"? Have you verified that your
mobile carrier properly blocks EH, or whatever carrier you connect to
when roaming? Or for that matter, when you attend IETF do you demand
that the NOC team blocks extension headers? (I don't believe that they
are blocked, but it would be quite ironic if they were :-) ).

As Johnson Yu said, the security of the entire network depends on the
weakest part within it. If we extrapolate that logic to Internet
scale, then the security of the Internet depends on the weakest part;
so if extension headers really are the threat that some are making
them out to be, then we need more than ad hoc secuity policies applied
across the Internet with no consistency.

Tom

>
> Security evolved as it did, over IPv4, for a reason, methinks.
>
> Bert

___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

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

[Manfredi (US), Albert E]

-Original Message-
From: Tom Herbert  

> It's more than a preference to have host security, it is an absolute 
> requirement that each host provides security for its applications and users. 
> This requirement applies to SmartTVs, SmartPhones, home computers, and pretty 
> much all the several billion end user devices connected to the Internet. No 
> host device would ever assume that the network consistently provides any 
> adequate level of security, for real security we need to assume that the host 
> is the first and last line of defense (i.e. zero trust model).

I could not agree more, Tom. So, as Fernando and others have said, the impulse 
is to block everything coming in from the Internet that you figure you don't 
need **right now**. Such as weird complicated header extensions.

The ISP has its own concerns, to protect its network, but I, in my enterprise 
or household, have different concerns. I'm not going to trust the ISP's 
security mechanisms to provide my own security needs.

Honestly don’t see how IPv6 is going to change that. Over time, perhaps, some 
specific extensions used out in the wild will be seen as crucially important to 
my enterprise or household, and maybe those will not be blocked. But "trust me, 
you must accept all these EHs"? More likely, those potential innovations will 
go unused and maybe will eventually be implemented in a different way.

Security evolved as it did, over IPv4, for a reason, methinks.

Bert
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

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

[nalini.elk...@insidethestack.com]

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 
 wrote:  
 
 On Thu, May 25, 2023 at 7:05 AM 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 
>  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 
>  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 
> Cc: Fernando Gont ; Manfredi (US), Albert E 
> ; IPv6 Operations ; 6man 
> ; 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 
>  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 
> Cc: Manfredi (US), Albert E ; IPv6 Operations 
> ; 6man ; 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  wrote:
>
>
>
> On 25/5/23 02:01, 

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

[Tom Herbert]

On Thu, May 25, 2023 at 7:05 AM 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 
>  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 
>  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 
> Cc: Fernando Gont ; Manfredi (US), Albert E 
> ; IPv6 Operations ; 6man 
> ; 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 
>  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 
> Cc: Manfredi (US), Albert E ; IPv6 Operations 
> ; 6man ; 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  wrote:
>
>
>
> On 25/5/23 02:01, Manfredi (US), Albert E wrote:
>
> -Original Message-
> From: ipv6  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 

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

[Tom Herbert]

On Wed, May 24, 2023 at 6:02 PM Manfredi (US), Albert E
 wrote:
>
> -Original Message-
> From: ipv6  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.

Bert,

It's more than a preference to have host security, it is an absolute
requirement that each host provides security for its applications and
users. This requirement applies to SmartTVs, SmartPhones, home
computers, and pretty much all the several billion end user devices
connected to the Internet. No host device would ever assume that the
network consistently provides any adequate level of security, for real
security we need to assume that the host is the first and last line of
defense (i.e. zero trust model).

Tom


>
> The ISP has to worry about protecting that ISP's own 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.)
>
> No one would trust their online banking transactions on an ISP's network 
> protections, for example.
>
> Bert
>
> ___
> 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

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

[nalini.elk...@insidethestack.com]

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.
There are many problems with, for example, some TCP packets, and we do not say 
"just block TCP".
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 
 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 
 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 offIn 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 
Cc: Fernando Gont ; Manfredi (US), Albert E 
; IPv6 Operations ; 6man 
; 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 
 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 
Cc: Manfredi (US), Albert E ; IPv6 Operations 
; 6man ; 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  wrote:



On 25/5/23 02:01, Manfredi (US), Albert E wrote:


-Original Message-
From: ipv6  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 

[OPSEC] Last Call: (Attribution of Internet Probes) to Informational RFC

[The IESG]

The IESG has received a request from the Operational Security Capabilities
for IP Network Infrastructure WG (opsec) to consider the following document:
- 'Attribution of Internet Probes'
   as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2023-06-08. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   Active measurements can target either collaborating parties or non-
   collaborating ones.  Sometimes these measurements are viewed as
   unwelcome or aggressive.  This document proposes some simple
   techniques allowing any party or organization to understand what this
   unsolicited packet is, what is its purpose, and more importantly who
   to contact.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsec-probe-attribution/



No IPR declarations have been submitted directly on this I-D.





___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

[OPSEC] Fwd: I-D Action: draft-ietf-opsec-probe-attribution-05.txt

[Justin Iurman]

Hi Warren,

The new version is online, hope it addresses all your comments 
(especially the security question).


Thanks again,
Justin

 Forwarded Message 
Subject: [OPSEC] I-D Action: draft-ietf-opsec-probe-attribution-05.txt
Date: Thu, 25 May 2023 02:52:05 -0700
From: internet-dra...@ietf.org
Reply-To: opsec@ietf.org
To: i-d-annou...@ietf.org
CC: opsec@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Operational Security
Capabilities for IP Network Infrastructure (OPSEC) WG of the IETF.

   Title   : Attribution of Internet Probes
   Authors : Éric Vyncke
 Benoît Donnet
 Justin Iurman
   Filename: draft-ietf-opsec-probe-attribution-05.txt
   Pages   : 10
   Date: 2023-05-25

Abstract:
   Active measurements can target either collaborating parties or non-
   collaborating ones.  Sometimes these measurements are viewed as
   unwelcome or aggressive.  This document proposes some simple
   techniques allowing any party or organization to understand what this
   unsolicited packet is, what is its purpose, and more importantly who
   to contact.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsec-probe-attribution/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsec-probe-attribution-05.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsec-probe-attribution-05

Internet-Drafts are also available by rsync at 
rsync.ietf.org::internet-drafts



___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

[OPSEC] I-D Action: draft-ietf-opsec-probe-attribution-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Operational Security
Capabilities for IP Network Infrastructure (OPSEC) WG of the IETF.

   Title   : Attribution of Internet Probes
   Authors : Éric Vyncke
 Benoît Donnet
 Justin Iurman
   Filename: draft-ietf-opsec-probe-attribution-05.txt
   Pages   : 10
   Date: 2023-05-25

Abstract:
   Active measurements can target either collaborating parties or non-
   collaborating ones.  Sometimes these measurements are viewed as
   unwelcome or aggressive.  This document proposes some simple
   techniques allowing any party or organization to understand what this
   unsolicited packet is, what is its purpose, and more importantly who
   to contact.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsec-probe-attribution/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsec-probe-attribution-05.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsec-probe-attribution-05

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

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

[Arnaud Taddei]

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 
>  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 
> Cc: Fernando Gont ; Manfredi (US), Albert E 
> ; IPv6 Operations ; 6man 
> ; 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 
>  > 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 mailto:fg...@si6networks.com>>
> Cc: Manfredi (US), Albert E  >; IPv6 Operations  >; 6man mailto: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  > wrote:
> 
> 
> 
> On 25/5/23 02:01, Manfredi (US), Albert E wrote:
> 
> -Original Message-
> From: ipv6 mailto: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