Re: [rtcweb] UDP transport problem

Cb B <cb.list6@gmail.com> Fri, 14 February 2014 14:42 UTC

Return-Path: <cb.list6@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3191A026C for <rtcweb@ietfa.amsl.com>; Fri, 14 Feb 2014 06:42:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6wEiyY2NTEE for <rtcweb@ietfa.amsl.com>; Fri, 14 Feb 2014 06:42:47 -0800 (PST)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id B21391A0253 for <rtcweb@ietf.org>; Fri, 14 Feb 2014 06:42:46 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id hi5so533364wib.2 for <rtcweb@ietf.org>; Fri, 14 Feb 2014 06:42:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2CUFOAJAcJmBtI82IcmS81LnBklHOKQPKFtR6ZuseaQ=; b=Dgbs6lkJkdHKxMb6ANE+Zavqb58i6jhfbwfXOPoRPvIldR83Aw300hAe+wINoGFisz ZcNCumV3iPCrJxDLNIGT0SJGlMAzgjBd2rZUGSqlG64KRsY0DYkfWkuVFquUxEHvuCi+ jCx+VX2iEMRpKaoW2MGgTkdiFiwDj+bAIe1PnmJHbIy2bvw8i985mpdNn2iDi083a3JO qBFExZ2eyMb1eq6p0sHn6ho4AQdFI/CvLQa5jBRWM8QSM7+5YAA2X061ImicxLpt9cvl tbauqyoIfW96akIvhjpUmhz69XR3l5Tx2PtQNhLwHyijuFW+bUhqQIZS2JY8hlpi071J kqog==
MIME-Version: 1.0
X-Received: by 10.181.12.16 with SMTP id em16mr2601126wid.3.1392388964467; Fri, 14 Feb 2014 06:42:44 -0800 (PST)
Received: by 10.194.133.169 with HTTP; Fri, 14 Feb 2014 06:42:44 -0800 (PST)
Received: by 10.194.133.169 with HTTP; Fri, 14 Feb 2014 06:42:44 -0800 (PST)
In-Reply-To: <52FDEE06.1030003@jesup.org>
References: <CAD6AjGRiQ1UF5n3JG9HPRQFM+TD54Xz-dpTn5u9bX+__BMfesQ@mail.gmail.com> <52FDEE06.1030003@jesup.org>
Date: Fri, 14 Feb 2014 06:42:44 -0800
Message-ID: <CAD6AjGRSVHTK7apQ1x3j0pE=dkeFeXBKc0U3z4GkCTywVvckTA@mail.gmail.com>
From: Cb B <cb.list6@gmail.com>
To: Randell Jesup <randell-ietf@jesup.org>
Content-Type: multipart/alternative; boundary="f46d0434c0a09dc9b804f25ed11a"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kiKg-aIBJ2Ip9vPingaGve5_Q2I
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] UDP transport problem
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 14:42:49 -0000

On Feb 14, 2014 2:20 AM, "Randell Jesup" <randell-ietf@jesup.org> wrote:
>
> 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
>

The history of p2p applications such as skype have shown history favors the
nimble.

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

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

Right. The source port will be a function of the amp server such as 53,
123, 19... all very common. The destination port is of the spoofers
choosing.

But, as the us-cert advisory notes, there are several impacted appilication
ports. Well-known webrtc fixed ports would help for a white list.

Creating a blacklist of just 53, 123, 19 makes us still behind the curve on
whatever is next.

CB

>
>> 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
> randell-ietf@jesup.org
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb