Re: [rtcweb] UDP transport problem

Harald Alvestrand <> Fri, 14 February 2014 18:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5DDDB1A03C8 for <>; Fri, 14 Feb 2014 10:24:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.344
X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XGltAEw1gjTv for <>; Fri, 14 Feb 2014 10:24:06 -0800 (PST)
Received: from (unknown [IPv6:2001:700:1:2::117]) by (Postfix) with ESMTP id 1916C1A03CC for <>; Fri, 14 Feb 2014 10:24:06 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33EA07C4CF1 for <>; Fri, 14 Feb 2014 19:24:04 +0100 (CET)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zkba+25YVKI0 for <>; Fri, 14 Feb 2014 19:24:04 +0100 (CET)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id B140A7C4CF0 for <>; Fri, 14 Feb 2014 19:24:03 +0100 (CET)
Message-ID: <>
Date: Fri, 14 Feb 2014 19:24:01 +0100
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] UDP transport problem
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Feb 2014 18:24:07 -0000

On 02/14/2014 03:42 PM, Cb B wrote:
> > 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.
> >
> Agreed on all points. My view is one related to the basic requirement
> of keeping the network up.  I hope i have provided enough reference
> points to make the magnitude of the problem clear as well as how
> history has shown protocols get blocked (smtp)
This SMTP example doesn't match what I've seen happen.

SMTP is not blocked by any backbone service provider I know of.

Outgoing SMTP on port 25 is commonly blocked by firewalls that think
they don't have servers behind them (hotels are notorious in this
aspect). That's why the submit port is popular (and deployed with
authentication). The main concern isn't DDOS attacks, it's being blamed
for spam.

I've not seen any report of a DDOS attack that used port 25 for a
traffic-volume-based attack (although intentional or unintentional DDOS
attacks on mail servers are too common to care about).

Given that I still haven't seen a report that leads me to belive we'll
ever see a proposal that seriously proposes blocking all UDP traffic on
the Internet - I continue to disbelieve the premise, so it's not
surprising that I disagree with the conclusion.

Surveillance is pervasive. Go Dark.