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 <[email protected]> wrote: > > > > On Nov 25, 2018, at 11:54 PM, Fernando Gont <[email protected]> > 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 >
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
