Re: [Spud] updated draft PLUS charter, rev. 1 June

[Brian Trammell <[e-mail]>]

hi Christian,

> On 14 Jun 2016, at 21:47, Christian Huitema <[e-mail]> wrote:
> 
> On Tuesday, June 14, 2016 5:46 AM, Ca By wrote:
> 
>> 
>> All my concerns with spud and quic would be solved by using a
>> new protocol number since it would allow for the network to,
>> at scale, identify good spud/quic traffic from the known bad  udp ddos mess
> 
> I think we need to dig a bit further there. Botnets could issue spud/quic traffic just fine. Granted, it will take them some time to adapt, but history shows that they will adapt. So, I don't see how painting a fixed set of bits in the packets would help in the long run. Botnets engaged in DOS will just set the same bits, be it a protocol number or a header field.

Agreed.

> There may be something specific to do about differentiation from UDP reflection attacks. I am aware that a lot of these are DNS packets. There may be some other UDP services as well.

Reflection attacks tend to follow the amplification factor: more amplification, bigger win. NTP (due, I think, to a widely deployed configuration that was amplification-friendly) was the champion here; DNS with DNSSEC looms as the next one (see the work of Roland van Rijswijk-Deij, Anna Sperotto, and Aiko Pras here: [1, 2]).

> But the general characteristic is that such attacks reuse a deployed infrastructure to their benefits, and thus have specific markers. The infrastructure is not going to change, so the markers will stay. The new protocols should certainly try to differentiate from these existing attacks.

This is the rationale behind the selection of the magic number in the SPUD prototype, and the presence of a magic number in the requirements derived therefrom.

I am also intrigued by Tom's earlier suggestion that using IPv6 DO headers might have reflection-reducing properties, given the installed base. We should look into that more deeply.

None of this does *anything* against direct botnet attacks -- there are maybe things you could do in a world with ubiquitous PLUS-speaking middleboxes that distinguished a PLUS magic number flood from a bot from real PLUS-encapsulated traffic. But relying on both ubiquitous deployment (a decade out in the wildly optimistic case) and the kindness of strangers to actually deploy egress filtering (which has worked oh so well in the past) isn't what I'd call a security plan.

>> This network operator concern has been repeatedly ignored since
>> it is easier to access udp in userspace.
> 
> As many said, user space is just one of the problems. The other is the installed base of NATs that won't pass anything else than TCP and UDP. Do we have studies indicating whether that changes with IPv6?

No direct numbers, in part because the measurement infrastructures available to us give us much smaller population sizes for v6 measurement. Anecdotally, taken from analysis of the data in [3, 4, 5], I can say that the magnitude of brokenness on v6 in general is lower, but the kinds of brokenness you run into is weirder. Slide 9 in [5] is v4 only because we still haven't been able to explain anomalies in the MTU curve for UDP on IPv6; in both [3] and the detailed analysis linked from [4] we see ECN negotiation anomalies five times more often for v6 than v4.

If I had to make up an explanation for that, I'd say that v6 traffic does indeed tend to pass through fewer middleboxes, but that the v6 functionality in those middleboxes is far less well tested. Happy eyeballs works so well because it quite effectively hides a multitude of sins.

Cheers,

Brian


[1] DNSSEC and its potential for DDoS attacks at IMC '14 https://wwwhome.ewi.utwente.nl/~rijswijkrm/pub/imc101-vanrijswijk.pdf

[2] Making the case for elliptic curves in DNSSEC in CCR, Oct '15 https://wwwhome.ewi.utwente.nl/~rijswijkrm/pub/ccr-ecdsa-2015.pdf

[3] Enabling Internet-wide deployment of ECN, PAM '15
http://ecn.ethz.ch/ecn-pam15.pdf

[4] 70% of popular Web sites support ECM, blog post
https://mami-project.eu/index.php/2016/06/13/70-of-popular-web-sites-support-ecn/

[5] Can we run the Internet over UDP, MAPRG presentation
https://www.ietf.org/proceedings/95/slides/slides-95-maprg-3.pdf