The same is true in DNS. Recursive servers end up having to probe with different extensions set. Such probing is being turned off for basic EDNS because it leads to false positives about what the remote server support which in turn breaks DNSSEC which depends on EDNS and being able to set the DO flag bit. One source vendors are so fed up with this stupidity by firewall vendors that they are collectively going to stop shipping code that automatically attempts to work around this breakage. The big open recursive resolver operators are also turning off work arounds. This at least will mean that DNSSEC will become more reliable. https://dnsflagday.net https://ednscomp.isc.org/compliance/summary.html has lots of time series showing how different extension mechanisms are blocked / mis-handled. EDNS has stated from day 1 that unknown EDNS flags are to be ignored yet there are firewall vendors that seem to think it is a good idea to block them. It took years for DO to be allow through by most firewalls. EDNS has stated from day 1 that unknown EDNS versions are supposed to be responded to by BADVERS with the highest version supported but we still have firewall vendors block EDNS version != 0 requests. EDNS also says that unknown EDNS options are to be ignored by the server yet there are firewalls that block them by default. There are those that block NSID options in the request by default, but it something the DNS operator has to enable in the server for there to be a NSID in the response. None of this blockage provides any real security. Name servers handle all of these extensions and don’t fall over. There really is too much paranoia by firewall and other vendors. Just because something is using a extension mechanism it doesn’t mean that it is dangerous or abuse. Getting back to IPv6 headers ASIC’s that can’t skip over fragmentation headers are just plain broken. ASIC’s that can’t generate PTB responses are just plain broken. These are part of basic IPv6. Neither should require hitting the slow path. Mark > On 27 Nov 2018, at 2:18 am, Eric Rescorla <ekr@xxxxxxxx> wrote: > > Picking a random message to reply to. > > I'm not any kind of IPv6 expert, so I'm not taking a position on the goodness or badness of extension headers. > > With that said, we do have a fair amount of experience with trying to deploy new protocols in the face of significant levels of network-level filtering; TLS 1.3 was delayed by a year or so when we discovered that there were middleboxes which made incorrect assumptions about our extension points. At the end of the day, we got things working, but at the cost of some not very attractive hacks, and if you look at QUIC, a lot of the design is motivated by concealing extension points from network intermediaries in order to avoid a replay of this scenario. Otherwise, we're worried that we won't be able to extend the protocol in the future. > > So, at least from the endpoint's perspective, a situation in which network intermediaries block any new protocol features they don't recognize is not really great. > > -Ekr > > > > > > > On Mon, Nov 26, 2018 at 6:36 AM Joe Touch <touch@xxxxxxxxxxxxxx> wrote: > > > > On Nov 25, 2018, at 11:54 PM, Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote: > > > > What this doc tries to do is to analyze the possible effects of > > different types and options, and only advice to drop them when there is > > a clear reason to do so. > > It claims those actions based on security. This is not a security issue. It is a revenue preservation issue. > > There is a big difference between using a protocol feature and abusing it. The implication that merely using some of these features is a security issue and an abuse is the problem with this document - and the approach of similar documents. > > Joe -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx
