Re: [Marnew] my summary

[Brian Trammell <[e-mail]>]

(Catching up on the Marnew threads; really sorry I couldn't make it to Atlanta for the workshop... let me jump in here)

> On 29 Sep 2015, at 01:10, 🔓Dan Wing <[e-mail]> wrote:
> 
> 
> On 28-Sep-2015 03:40 pm, Jana Iyengar <[e-mail]> wrote:
>> Cameron,
>> 
>> I do not believe UDP is the only path to evolve the transport layer.
>> 
>> It is unfortunate that you believe that.
>> 
>> It's not a matter of belief -- SCTP is being deployed over UDP for WebRTC, and so's QUIC, and these are the most significant evolution of deployed end-to-end protocols today. I think this is largely consensus at this point, and I don't think debating this point is particularly interesting. If UDP-based protocols are doomed to fail, we're only going to find out by trying and failing to deploy, and I'm happy to change my perspective at that point. Until then, I'd like to focus conversations on how to get them deployed.
> 
> A distinguisher between 'attack traffic' and 'non attack traffic' is necessary.

We are helped here by the fact that there are bit-strings that are valid in commonly-compromised UDP protocols, and there are bit strings that are invalid. If (1) we presume that the set of commonly-compromised UDP protocols stays constant -- i.e. you can use old, broken stuff to mount amplifying reflection attacks but new protocols will be built with care to avoid amplification -- and (2) we carefully design UDP-based encapsulations and transport protocols such that are guaranteed to contain a string of bits in the first n bits which will not appear on one of the commonly-compromised protocols, then simple bit-string comparison can be used to distinguish SPUD/QUIC'/whatever from "possibly garbage UDP".

This does nothing against compromised machines sending UDP garbage with the SPUD/QUIC'/whatever magic bits, but nothing keeps them from SYN flooding, either. Except perhaps BCP38, which I note has already been mentioned.

>  For the WebRTC data channel there are consent packets (draft-ietf-rtcweb-stun-consent-freshness) and for TCP there are ACKs.

And we presume other transports over UDP will have similar mechanisms; see section 3.7 of https://tools.ietf.org/html/draft-trammell-stackevo-explicit-coop-00 for some initial reflections on this.

Cheers,

Brian


>  If we can't get new protocols into the the OS kernel and thus trust the kernels to prevent attacks, something similarly low level needs to exist for other protocols to enabling filtering of attack traffic versus good traffic.
> 
> -d
> 
> 
> _______________________________________________
> Marnew mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/marnew