Re: [rtcweb] UDP transport problem

[Randell Jesup <[e-mail]>]

On 2/12/2014 10:06 PM, Cb B wrote:
> For about a year now, i have been very concerned about IPv4 UDP.  It
> has been increasingly associated with DDoS traffic [1], to the point
> that the protocol's reputation is akin to IPv4 PING in 2003 (widely
> blocked).  The material point here is that IPv4 UDP is being
> indiscriminately blocked and policed in access networks.  This is not
> something access networks are wantonly electing to do. This decision
> is made in the heat of the moment to restore service to customers and
> networks who are overrun with attack traffic [2].  And it is not
> simply DNS, NTP, and chargen for simple filtering.
>
> My suggestion is that draft-ietf-rtcweb-transports be updated to
> include SCTP as a transport type option.  I understand that SCTP is
> not supported on Windows (tm) and most NATs.

Side note: it would be ironic to end up using 
DataChannel-over-SCTP-over-DTLS-over-SCTP

> In general, we may find
> that TURN / TRAM is a required local trust anchor in access networks,
> just as local ISP-administered SMTP servers in access networks are
> frequently required relay points since access networks block SMTP. [3]

I certainly understand the reason for concern; but the idea that UDP 
would become limited to TURN-mediated is frightening and depressing (and 
whose TURN and how does the ISP know it's TURN-mediated unless it's an 
ISP's TURN?)

One significant piece of the value proposition of WebRTC is that through 
use of ICE (and TURN) it will usually bypass the need for relays, 
significantly improving media quality (delay), dramatically cutting the 
cost of operation for services, easing deployment, and avoiding a number 
of levels of control/ability-to-block/etc.

It's especially depressing in that we put significant effort into 
reducing the likelihood that WebRTC could be used for DDoS attacks.

I will note that blocking UDP (or massively-rate-limiting it) will have 
all sorts of nasty effects on all forms of VoIP.  TCP-entrained VoIP can 
evade that, but at a serious cost to call quality.  Surely the operators 
know this.

> This UDP concern is not an issue for IPv6, since IPv6 is not, as of
> yet, been associated with these massive attacks.  And when i say
> massive, i mean massive [4].  And because of the scale and risk,
> access networks are simply clamping IPv4 UDP throughput and moving on
> and not looking back.

Can the DNS amplification attack be used to hit any ports other than 
53?  Can clamps be limited to port 53

> I  understand predicting the demise of UDP is not a popular opinion in
> the IETF.  But as a network operator, and stakeholder in the internet
> / ietf / webrtc, i am hoping to share this information so that you all
> can make well informed protocol decisions.

Thank you


-- 
Randell Jesup
[e-mail]