Re: [OPSEC] [v6ops] [EXTERNAL] Re: [IPv6] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
On 26-May-23 21:13, Ole Troan wrote: A well-implemented host will not be troubled by unkown extension headers or options. Indeed. However, not all hosts are well-implemented. "Not be troubled by” == “drop”? Yes, discard as RFC 8200 says. I don’t agree that a well-implemented host and application should blindly accept any and all extension headers. Indeed. I wasn't arguing otherwise. If my application cannot use those extension headers why do you send them to me? Because that's what RFC 8200 describes as normal. If they are purely for the use in the network, then again why do you expose them to the application? That's a socket API function, isn't it? I don't think you'll find many apps that use it. If you can give some practical examples where it’s beneficial to “process” unknown extension headers by hosts/applications, then this may be a little easier to reason over. I never intentionally argued for that. 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)
Warren, On 26-May-23 21:03, Warren Kumari wrote: On Thu, May 25, 2023 at 11:13 PM, Brian E Carpenter mailto:brian.e.carpen...@gmail.com>> wrote: On 26-May-23 08:33, Manfredi (US), Albert E wrote: -Original Message- From: Tom Herbert mailto:t...@herbertland.com>> 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. Indeed. However, not all hosts are well-implemented. If my "smart" TV isn't capable of ignoring unkown extension headers, its vendor will have to give me my money back. Erm, have you ever tried this? I certainly haven't, but I'd assume that trying to contact [Vizio|Sony|LG|Sharp|Kenmore] and explain that e.g a packet with the "IOAM Destination Option and IOAM Hop-by-Hop Option" makes the TV turn off will not be particularly fruitful (or fun). No. I'd go to the retail outlet and say "That TV you sold me keeps crashing." And then I'd invoke a wonderful law we have here called "The Consumer Guarantees Act." I'd have a reasonable chance. But more seriously, our job here is surely to specify host behaviour correctly. There's not a lot more we can do to improve the situation. As I've said already, there's a tussle here that we (the IETF) probably can't abolish. Brian I don't want my ISP or my CE router to block any extension headers. Your ISP and CPE vendor are incentivized to reduce costs (people calling customer service to complain that their FoozleWhatzit TV keeps rebooting) and drama (press articles that bad people are turning on cameras on BarzleWerg baby monitors and posting "interesting" videos online). It's hard to write a breathless press article that Comcast doesn't allow Shim6 EH, and the number of people calling to complain that HIP EH doesn't pass through their CPE is likely to be very small. Until this changes, ISPs and CPEs are likely to continue blocking. Yup, from an architectural and purity standpoint this is not a good thing - but, sadly, principles don't pay the bills. Explaining to your enterprise security admin that allowing the mobility header it is the right thing do is hard, especially when she's pointing at the badge reader that keeps rebooting because it's IPv6 stack is awful. She has a clear and tangible story - random packets make this thingie reboot, why would you trust it to handle some potential new EH in a secure manner?! Your story is much harder and hand-wavy — some new EH might possibly be defined at some point in the future that might possibly allow some future feature that somehow improves things... 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. Yup - just like with e.g IPv4 source route options, the incentives need to be correct — the risk of allowing IPv4 source routed packets i
Re: [OPSEC] [v6ops] [EXTERNAL] Re: [IPv6] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
If only there were some *principle* to guide operators in better understanding when it might be worth spending their time blocking something that is not a *specific credible threat* Oh wait... https://en.m.wikipedia.org/wiki/Robustness_principle Now, where there is a specific, credible threat *absolutely* block what you know. Otherwise, kernels, even on lightbulbs, are really good at ignoring packets. Otherwise *you* are the DOS attack --ckg On Fri, May 26, 2023, 10:31 Andrew Campling wrote: > This is a really good thread! > > > > For me, it highlights that there appears to be a gulf in understanding, or > at least working assumptions, between developers and those responsible for > network (public or private) security. I suspect that gulf might narrow > somewhat if developers faced some of the same consequences that enterprises > and public network operators face in the event of security breaches – I’m > thinking here about those with compliance obligations such as the finance > sector, those in areas defined as part of critical national infrastructure > and those covered by more general regulations such as NIS2. > > > > Greater involvement by enterprise and public network CISOs would help > inject more understanding of current practice security and operational > considerations into protocol development activity to augment the input of > those within this community that also have that knowledge. For example, it > would be good to see the reaction of CISOs to suggestions that security > should be left to hosts / endpoints rather than using a defence-in-depth > approach which also employs network and perimeter defences, looks for > indicators of compromise etc. > > > > Given the relative lack of diversity within the IETF community, hindsight > suggests to me that it would have been great to see one or more > IETF-sponsored panel discussions at events like the recent RSA Conference > to debate some of the points raised on this thread with the wider security > practitioner community, many of whom don’t follow developments at the IETF > (I can confirm this latter point from personal experience as I asked other > attendees at RSAC 23 and found less than a handful of people that had > involvement in the IETF, either directly or via a team member). > > > > Andrew > > > ___ > 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)
On Fri, May 26, 2023 at 2:13 AM Ole Troan wrote: > > > A well-implemented host will not be troubled by unkown extension headers or > > options. > > > > Indeed. However, not all hosts are well-implemented. > > "Not be troubled by” == “drop”? > I don’t agree that a well-implemented host and application should blindly > accept any and all extension headers. Ole, Right, that's why RFC8504 and 6man-eh-limits allow hosts to set various limits on extension headers in packets-- if a host limit is exceeded then the packet is discarded. 6man-eh-limits also also intermediate devices to have similar limits and if those limits are exceeded then any items beyond the limit are forwarded and that is *not* a reason to discard packets. > If my application cannot use those extension headers why do you send them to > me? > If they are purely for the use in the network, then again why do you expose > them to the application? > > If you can give some practical examples where it’s beneficial to “process” > unknown extension headers by hosts/applications, then this may be a little > easier to reason over. Segment routing where the final destination is a VM. Tom > > O. ___ 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)
Hi, Warren, On 26/5/23 11:03, Warren Kumari wrote: On Thu, May 25, 2023 at 11:13 PM, Brian E Carpenter mailto:brian.e.carpen...@gmail.com>> wrote: [] A well-implemented host will not be troubled by unkown extension headers or options. Indeed. However, not all hosts are well-implemented. Indeed. Datapoint: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=IPv6+extension+header Smarter searching/keywords will at least double the results. -- Fernando Gont e-mail: ferna...@gont.com.ar PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E301 6F01 ___ 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)
This is a really good thread! For me, it highlights that there appears to be a gulf in understanding, or at least working assumptions, between developers and those responsible for network (public or private) security. I suspect that gulf might narrow somewhat if developers faced some of the same consequences that enterprises and public network operators face in the event of security breaches – I’m thinking here about those with compliance obligations such as the finance sector, those in areas defined as part of critical national infrastructure and those covered by more general regulations such as NIS2. Greater involvement by enterprise and public network CISOs would help inject more understanding of current practice security and operational considerations into protocol development activity to augment the input of those within this community that also have that knowledge. For example, it would be good to see the reaction of CISOs to suggestions that security should be left to hosts / endpoints rather than using a defence-in-depth approach which also employs network and perimeter defences, looks for indicators of compromise etc. Given the relative lack of diversity within the IETF community, hindsight suggests to me that it would have been great to see one or more IETF-sponsored panel discussions at events like the recent RSA Conference to debate some of the points raised on this thread with the wider security practitioner community, many of whom don’t follow developments at the IETF (I can confirm this latter point from personal experience as I asked other attendees at RSAC 23 and found less than a handful of people that had involvement in the IETF, either directly or via a team member). Andrew ___ 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)
On Fri, May 26, 2023 at 11:13 AM, Ole Troan wrote: > A well-implemented host will not be troubled by unkown extension headers > or options. > > Indeed. However, not all hosts are well-implemented. > > "Not be troubled by” == “drop”? > I had assumed "not troubled by" meant "doesn't explode, killing everyone inside". I'd assume that no-one is thinking that a host or application should try and process an extension header that it doesn't understand… but then again, I'm often wrong in my assuimptions. W > I don’t agree that a well-implemented host and application should blindly > accept any and all extension headers. If my application cannot use those > extension headers why do you send them to me? If they are purely for the > use in the network, then again why do you expose them to the application? > > If you can give some practical examples where it’s beneficial to “process” > unknown extension headers by hosts/applications, then this may be a little > easier to reason over. > > O. > ___ 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)
> A well-implemented host will not be troubled by unkown extension headers or > options. > > Indeed. However, not all hosts are well-implemented. "Not be troubled by” == “drop”? I don’t agree that a well-implemented host and application should blindly accept any and all extension headers. If my application cannot use those extension headers why do you send them to me? If they are purely for the use in the network, then again why do you expose them to the application? If you can give some practical examples where it’s beneficial to “process” unknown extension headers by hosts/applications, then this may be a little easier to reason over. O. ___ 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)
On Thu, May 25, 2023 at 11:13 PM, Brian E Carpenter < brian.e.carpen...@gmail.com> wrote: > 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. > Indeed. However, not all hosts are well-implemented. If my "smart" TV isn't capable of ignoring unkown extension headers, its > vendor will have to give me my money back. > Erm, have you ever tried this? I certainly haven't, but I'd assume that trying to contact [Vizio|Sony|LG|Sharp|Kenmore] and explain that e.g a packet with the "IOAM Destination Option and IOAM Hop-by-Hop Option" makes the TV turn off will not be particularly fruitful (or fun). I don't want my ISP or my CE router to block any extension headers. > Your ISP and CPE vendor are incentivized to reduce costs (people calling customer service to complain that their FoozleWhatzit TV keeps rebooting) and drama (press articles that bad people are turning on cameras on BarzleWerg baby monitors and posting "interesting" videos online). It's hard to write a breathless press article that Comcast doesn't allow Shim6 EH, and the number of people calling to complain that HIP EH doesn't pass through their CPE is likely to be very small. Until this changes, ISPs and CPEs are likely to continue blocking. Yup, from an architectural and purity standpoint this is not a good thing - but, sadly, principles don't pay the bills. Explaining to your enterprise security admin that allowing the mobility header it is the right thing do is hard, especially when she's pointing at the badge reader that keeps rebooting because it's IPv6 stack is awful. She has a clear and tangible story - random packets make this thingie reboot, why would you trust it to handle some potential new EH in a secure manner?! Your story is much harder and hand-wavy — some new EH might possibly be defined at some point in the future that might possibly allow some future feature that somehow improves things... 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. > Yup - just like with e.g IPv4 source route options, the incentives need to be correct — the risk of allowing IPv4 source routed packets into the network exceeded to benefit to the network, and so they got blocked. This is why we cannot have nice things - the incentive model prefers security, stability and cost over future extensibility and principles. W > Brian > ___ > 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)
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)
-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)
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)
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)
-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)
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, Man
Re: [OPSEC] [v6ops] [EXTERNAL] Re: [IPv6] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
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)
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)
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 matte
