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

["Brian Trammell (IETF)" <[e-mail]>]

hi Brian, all,

> On 6 Dec 2018, at 01:14, Brian E Carpenter <[e-mail]> wrote:
> 
> On 2018-12-05 21:52, Gert Doering wrote:
>> Hi,
>> 
>> On Tue, Dec 04, 2018 at 10:57:43PM -0500, Christopher Morrow wrote:
>>> HA! ok. As gert/nick noted ... we have Nx100G links today (at the edge) and
>>> coming nx400G ... there's just not a reasonable story for "dpi" there. (I
>>> suppose: "yet" and "without paying the approximate value Coca-Cola
>>> Companies yearly advertising budget")
>> 
>> Indeed.
>> 
>> Unfortunately, there *is* a story for being able to rate-limit incoming
>> crap by protocol type - "give me no more than 200 Mbit/s of UDP packets
>> coming from source port 53".
>> 
>> Which implies that as soon as the evil guys out there find a way to
>> generate DDoS streams carrying EHs that our border routers will (have to)
>> apply very strict rate limiting to everything they do not understand.
>> 
>> - pass TCP
>> - rate-limit UDP on well-known reflective attacks port
>> - pass rest of UDP
>> - rate-limit ICMP
>> - rate-limit fragments
>> - rate-limit all the rest to something which can never exceed a customer's
>>   access-link
>> 
>> game over, EH
> 
> Just to point out that this is equivalent to saying "game over, any new layer 4 protocol" too. For example, you just killed SCTP. And the same goes for new protocols over IPv4.

Indeed, it is, and I think it's a nice honest assessment of the current state of the Internet.

We lost the ability to deploy new layer 4 protocols (in terms of the value of the protocol or next header fields in the network layer) universally within the Internet at least a decade ago. The argument here seems to be whether we, as the IETF, want to acknowledge this fact, or not -- and all of the evidence I've seen would seem to confirm the situation is the same for HbH (and to a lesser extent, DO) EH for v6 -- and whether there are degrees of freedom to be won from said acknowledgment.

I note that current work in TSV on transport evolution pretty much seems to acknowledge this, if tacitly, for layer 4, and to actively design for this situation:

- the original concept behind TAPS, runtime transport stack agility, was designed to make "new" protocols deployable (whether over v4 or over v6) when not impaired by the network, and to fall back to less impaired protocol stacks when they are the only ones available.

- QUIC explicitly uses UDP in part because only protocols 6, 17, and to a lesser extent 1 are assumed to be widely passed in the network (and numbers from Google and RIPE Atlas, presented in MAPRG, show that even here there's about a one-in-thirty chance that a given path won't support QUIC over UDP, necessitating TCP fallback), and the primary utility of encryption of the QUIC protocol header is avoiding the deployment of in-network functions using any part of the QUIC header not explicitly designed for on-path use, thereby (we hope) keeping this decay from impairing our ability to change QUIC as it has our ability to change L4 otherwise.

Cheers,

Brian