Re: [rtcweb] UDP transport problem

[Harald Alvestrand <[e-mail]>]

Most important point of reality anchoring (DNS over UDP vs TCP) is at
the bottom.
Other comments are incidental.

On 02/13/2014 11:57 PM, Cb B wrote:
> On Thu, Feb 13, 2014 at 2:44 PM, Harald Alvestrand <[e-mail]> wrote:
>> On 02/13/2014 10:20 PM, Cb B wrote:
>>> On Thu, Feb 13, 2014 at 12:48 PM, Harald Alvestrand
>>> <[e-mail]> wrote:
>>>> On 02/13/2014 06:56 PM, Cb B wrote:
>>>>> On Thu, Feb 13, 2014 at 9:47 AM, Martin Thomson
>>>>> <[e-mail]> wrote:
>>>>>> On 12 February 2014 22:06, Cb B <[e-mail]> wrote:
>>>>>>> For about a year now, i have been very concerned about IPv4 UDP.  It
>>>>>>> has been increasingly associated with DDoS traffic [1],
>>>>>> Is your concern that WebRTC will increase the potential for DoS (which
>>>>>> would presume the DoS mitigation measures in ICE [RFC 5245] are
>>>>>> insufficient), or is it just that UDP is so toxic to network operators
>>>>>> that you predict it will be turned off?
>>>>> My concern is that IPv4 UDP is so toxic it will be blocked.  It may be
>>>>> wise to start SCTP in the standard from the start.
>>>> The bad guys will follow wherever the ports are open (and are usually
>>>> faster at writing code than the standards guys are at writing specs); so
>>>> will the traversal artists.
>>>>
>>> Harald, the issue is not open ports. The issue is the entire transport
>>> type is polluted.
>> And I think that notion is bogus. Faced with the choice of dealing with
>> the devil they know (UDP) and the devil they don't have a clue about
>> (SCTP), firewall operators are going to stick with building out the
>> rulesets around UDP, and continuing to refuse all the "new stuff".
>>
> I never mentioned firewall operators.  I mentioned access networks and
> internet backbone operators.
>
> As many network operators know, there is a big issue with UDP going on
> that is crushing some networks
>
> http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack
That's an UDP port 123 (NTP) matter. We've done several of these
exercises (live-fire updates of critical Internet infrastructure) over
the last few years.

>
> https://puck.nether.net/pipermail/outages/2014-February/006651.html
>
> This is the point in bring to the WG.

Yes, thanks for bringing it.
I just happen to totally disagree with your conclusions.

>
>> So I don't think the plan has legs - adding SCTP without the UDP wrapper
>> to our options will not help anyone do anything.
>>
> it's a path out.

I don't see any property of this path that makes it a) traversable, or
b) "out".

>
>> But this is trying to forecast the thinking and action of humans that
>> are not me, which is something I frequently get wrong - so other
>> opinions would be welcome.
>>
>>>> WebRTC over port 53, anyone?
>>>>
>>>> (DNS is the one UDP-based service that's so important to the Internet,
>>>> it *cannot* be turned off unconditionally - so I expect that if UDP in
>>>> general gets blocked, port 53 will be the port 80 of UDP-land.)
>>>>
>>> DNS runs over TCP as well.
>> For AXFR, yes. For daily lookups .... better not tell any root DNS
>> operator you're advocating that they should have all their lookups over
>> TCP; you wouldn't like the expletives that result.
>>
> cute. But, TCP works.  Maybe you can ask someone at Android to support
> EDNS0 so that TCP is used less.  Because for now, android required TCP
> for any response over 512 bytes.

I'm talking about
http://k.root-servers.org/statistics/ams-ix/ip_protocols.html

Note the relative width of the green (TCP) against the purple (UDP).
(I've been unable to find a green pixel on those graphs.)

-- 
Surveillance is pervasive. Go Dark.