Apologies for the top posting The degree of cognitive dissonance in this thread is quite high.
It seems that we are discussing a world where telcos aren’t still running IOS 12.x and won’t/can’t upgrade because of ITIL or where people don’t choose the version of networking OS that they run based on “the bugs my network can live with” Indeed we are also apparently living in a world where “limited domain” means something magical so that I don’t have to block RFC1918 IPv4 addresses from my network edge because ISPs are conforming to the SHALL NOT and SHOULD NOT in that particular RFC Also it seems that the core internet is also run on routers and switches that can totally manage punting packets to cpu off the fast path in order to process these extensions to a protocol that 1) works really well and solves the problems that it was designed to solve and 2) has been used in production for decades. I appreciate that a lot of these EHs are designed to get round limitations in the alternatives available as presumably doing facial rec/total take on sizeable populations is difficult but not taking into account of the reality of most of the world seems odd. If there are significant problems that need addressing and I’m sure there are, then the correct approach would be a new version of IP ( which will either lead to “triple stack” or would eventually replace v6) or encapsulate the traffic. Either way, repeating the same mistakes made with IPv4 like magical “limited domains” or not ignoring what is actually running the internets in terms of all the 20 year old kit on 20 year old software or thinking that my favourite network vendor is going to start releasing code that doesn’t contain bugs is dooming us all to more failure and more downtime, more chaos thus directly leading to even more stagnation. Mike > On 27 May 2023, at 23:06, Tom Herbert <[email protected]> > wrote: > > On Sat, May 27, 2023 at 2:16 PM Manfredi (US), Albert E > <[email protected]> wrote: >> >> -----Original Message----- >> From: Tom Herbert <[email protected]> >> >>> Correct, that's the fundamental problem. When public network providers >>> apply ad hoc protocol filtering, that limits the capabilities and >>> opportunities to provide value to the users. For instance, if someone came >>> up with a new transport protocol that improves user security by 10x, we >>> couldn't deploy it because some network providers would block it. So the >>> very security policies that are ostensibly in place to protect the users >>> can actually harm them. >> >> Potentially, I agree. Problem is, each of the players has to determine what >> is an acceptable risk. If an ISP wants to keep his infrastructure secure, >> he's got the responsibility to make it so, as best he can. He can’t trust >> mechanisms that either don’t exist yet or that might introduce their own new >> vulnerabilities. Someone says, trust me, these extensions will be for your >> own good, and yet he is fully cognizant that those extensions could also be >> used in ddos attacks, he'll say thanks but no thanks. Maybe I'll let those >> through after we're satisfied with testing and experience. >> > > Albert, > > Application developers and stack developers are also players in this > game. And while each network provider might have the luxury of only > focusing on their customer set, developers have to potentially address > the needs of all users across the Internet. This is why network > providers' attempts to protect the user are irrelevant to application > developers-- without consistency across the Internet this level of > security may as well not exist from their perspective. Obviously this > situation didn't materialize overnight and it shouldn't be surprising > that we've had to implement work-arounds to this problem. For > instance, encryption goes a long way in limiting the network's > visibility in the packet, but that does have its limits. > >>> As for what constitutes the "the greater good", like pretty much everything >>> else in IETF shouldn't that be something determined by "rough consensus"? >> >> Yes, but unfortunately, that does not absolve the players of their own >> responsibilities. In matters of security, no one will blindly follow "rough >> consensus." We are 180 degrees from the Postel principle: > > No, but it seems like providing reasonable guidance falls under the > auspices of IETF. > >> >> "Be conservative in what you do, be liberal in what you accept from others," >> is turned on its head, as we know. For system security, you cannot be >> liberal in what you accept from others. >> >>> Even if the consensus were that extension headers need to be deprecated, to >>> me that would be better than the current situation where we, specifically >>> application and host developers, need to deal with a patchwork of anonymous >>> and seemingly arbitrary network provider policies that degenerate the end >>> to end services we can provide to users to rely only on least common >>> denominator of protocols which we can only deduce by guess work. >> >> I get your point completely. We don’t have an IETF dictatorship though, so >> what happens is that over time, smart people have to decide how best to do >> their jobs, given the realities of today. There is a lot of infrastructure >> flexibility, and apps, thought really cool when they were developed, that go >> unused for just this reason. Such as, you might be better off, in your >> network, to use proxy-MLD and to block PIM-SM. Same goes for some or even >> much of ICMP. It's the tussle Brian C talks about. > > It's a proverbial "chicken and the egg" problem. Some network > providers will only allow them once there's deployment, but we can't > deploy them if they're not allowed through the network. The good news > is, we are starting to see deployment at least in limited domains. As > experience with them grows and issues are addressed, hopefully the > barriers will fall and the vision of an extensible Internet protocol > will be realized in time. > > Tom > >> >> Bert >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
