Re: [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06

[Eric Rescorla <[e-mail]>]

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 <[e-mail]> wrote:

>
>
> > On Nov 25, 2018, at 11:54 PM, Fernando Gont <[e-mail]>
> 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
>