Re: [rtcweb] UDP transport problem

[Cb B <[e-mail]>]

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

https://puck.nether.net/pipermail/outages/2014-February/006651.html

This is the point in bring to the WG.

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

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

>>
>> But that's not the point.  The question is can we include native SCTP
>> as an option in  draft-ietf-rtcweb-transports?  What is the downside?
>>
>
> Clutter.
>
>