[rtcweb] UDP transport problem

Cb B <cb.list6@gmail.com> Thu, 13 February 2014 06:07 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 2E2BE1A00F5 for <rtcweb@ietfa.amsl.com>; Wed, 12 Feb 2014 22:07:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id T_4N9ryvSgIf for <rtcweb@ietfa.amsl.com>; Wed, 12 Feb 2014 22:06:59 -0800 (PST)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7B31A0102 for <rtcweb@ietf.org>; Wed, 12 Feb 2014 22:06:58 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id u56so7021443wes.16 for <rtcweb@ietf.org>; Wed, 12 Feb 2014 22:06:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6mT3zt8FutaGIVIF/hoBjL0LzQNTmoarFh9JoueleDI=; b=S4gvTFvzi/SYzXawHCfabFRoMOdLQ3SQD1XI16fLazsJduz4ULPnTMnEJ/VJmWQlE2 0/YGUQyMcpYUos4j3slx+GcsIwXh1YC2oeY1Y2qUggVcdhfTtguJXP9wxmkqXQAtT+B8 605QQe7z7w0is+bl6GkRmfjVKlqt3CazgbD/xE1oRYeqIbQeHMtWjmWAMskUSdk27+9V 9bFG1hd23AC3qxkflkjZi66q6Ms5PFcdtdo3AKblJYsUtd+N+Flm0BEW6HRe16E12Xlr suV95l2new9TityOrDSUkpITU28zgVmUsKpJvitAWesoK66zQvnkBIfTizYL9bOPuT9T XXIA==
MIME-Version: 1.0
X-Received: by with SMTP id gj9mr4976788wib.28.1392271616998; Wed, 12 Feb 2014 22:06:56 -0800 (PST)
Received: by with HTTP; Wed, 12 Feb 2014 22:06:56 -0800 (PST)
Date: Wed, 12 Feb 2014 22:06:56 -0800
Message-ID: <CAD6AjGRiQ1UF5n3JG9HPRQFM+TD54Xz-dpTn5u9bX+__BMfesQ@mail.gmail.com>
From: Cb B <cb.list6@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [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: Thu, 13 Feb 2014 06:07:01 -0000


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

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.

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.

[1] http://www.us-cert.gov/ncas/alerts/TA14-017A
[2] http://www.gossamer-threads.com/lists/nanog/users/168576
[3] http://customer.comcast.com/help-and-support/internet/email-port-25-no-longer-supported/
[4] http://rt.com/news/biggest-ddos-us-cloudflare-557/