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

[Ca By <[e-mail]>]

On Tuesday, June 14, 2016, Brian Trammell <[e-mail]> wrote:

> hi Christian,
>
> > On 14 Jun 2016, at 21:47, Christian Huitema <[e-mail]
> <javascript:;>> 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.
>
>
Magic numbers do no work on existing router. Just like the constraint you
have that we must work with the intall base so we must use udp. The
solution space is "no change"


> 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.


>
Is there anyone from a middle box vendor here? Do you want to hear what
PLUS is telling you? Or will middleboxes keep doing what they want?

I am concerned plus is saying things nobody is listening to.


>
> 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
>