Re: [Maprg] Is UDP a trash heap?

Brian Trammell <ietf@trammell.ch> Tue, 24 May 2016 08:50 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: maprg@ietfa.amsl.com
Delivered-To: maprg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3E112D09D for <maprg@ietfa.amsl.com>; Tue, 24 May 2016 01:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.328
X-Spam-Level:
X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3K_eSRZZhsnD for <maprg@ietfa.amsl.com>; Tue, 24 May 2016 01:50:44 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3553B12D0EB for <maprg@irtf.org>; Tue, 24 May 2016 01:50:44 -0700 (PDT)
Received: from [IPv6:2001:67c:64:42:552e:8a9f:18db:58c6] (unknown [IPv6:2001:67c:64:42:552e:8a9f:18db:58c6]) by trammell.ch (Postfix) with ESMTPSA id C49C51A13C3; Tue, 24 May 2016 10:50:11 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_ADECA1F8-3C8C-4BF2-B88D-A9A201B9FB54"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.6b2
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <8EBBDE7D-C6A9-446B-84B2-67459257F591@gmail.com>
Date: Tue, 24 May 2016 10:50:10 +0200
Message-Id: <0F1C206A-FF46-4AC1-ACD4-0AE89194036C@trammell.ch>
References: <8EBBDE7D-C6A9-446B-84B2-67459257F591@gmail.com>
To: Aaron Falk <aaron.falk@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/maprg/BuHmag9WtAoSl00vw4Kgy_JuHDA>
Cc: maprg@irtf.org
Subject: Re: [Maprg] Is UDP a trash heap?
X-BeenThere: maprg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" <maprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/maprg>, <mailto:maprg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/maprg/>
List-Post: <mailto:maprg@irtf.org>
List-Help: <mailto:maprg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/maprg>, <mailto:maprg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2016 08:50:47 -0000

hi Aaron,

"Is UDP a trash heap" is, I think, really two questions: one of connectivity, and one of traffic quality. Your second question goes to connectivity, so let's look at that one first.

I don't know of a lot of data for connectivity, blocking, and impairment other than for port 53, either in raw or aggregate form. Our talk at the last maprg meeting looked into RIPE Atlas based UDP differential connectivity and incidence of complete blocking on networks with RIPE Atlas probes on them, and we're presently working on measuring differential treatment between UDP and TCP at relatively low (single flow) data rates, and hope to have something we can share on this shortly. (As an aside, searching for related work for the paper under submission on this was an enlightening activity. Academia seems to find this question uninteresting.)

As noted over on the spud@ietf.org list, there are other questions about UDP vs TCP treatment that we need answers to as well: distribution of NAT timers on UDP NAT, prevalence and distribution of UDP rate limiting. (The second question is of course hard to answer with active measurement unless you're willing to run DoS attacks.)

As to traffic quality, that's an entirely separate question, answerable only by passive measurement, with all the caveats associated therewith. A simple number "n% of UDP is crap" is useless without knowing how much productive UDP traffic there is on a given network, and different links and different networks look wildly different in this respect. I don't have a lot of answers here, but will think about how to get them.

Thanks, cheers,

Brian






> On 23 May 2016, at 22:06, Aaron Falk <aaron.falk@gmail.com> wrote:
> 
> See thread and cited draft below.  I’ve heard “UDP is a trash heap” invoked multiple times.  Are there any broad based measurements of UDP loss rates for ports other than 53?  Is IPv6 different than IPv4 in this regard?
> 
> --aaron
> 
> From: Spud <spud-bounces@ietf.org> on behalf of Ca By <cb.list6@gmail.com>
> Date: Monday, May 23, 2016 at 11:51 AM
> To: Tom Herbert <tom@herbertland.com>
> Cc: Toerless Eckert <eckert@cisco.com>, Michael Welzl <michawe@ifi.uio.no>, Joe Touch <touch@isi.edu>, "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>, "spud@ietf.org" <spud@ietf.org>, Jana Iyengar <jri@google.com>, Christian Huitema <huitema@microsoft.com>
> Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.txt
> 
>> 
>> 
>> On Monday, May 23, 2016, Tom Herbert <tom@herbertland.com> wrote:
>>> On Sun, May 22, 2016 at 1:06 PM, Ca By <cb.list6@gmail.com> wrote:
>>> >
>>> >>
>>> >> Now all this being said, I also don’t fully get why some folks have such a
>>> >> big problem with running stuff over UDP. I’m not against doing that, if only
>>> >> as a temporary solution that would serve to convince people that the
>>> >> transport (option, ..) is useful.
>>> >> In a TAPS world, it’s just another option to try…
>>> >>
>>> >
>>> > The fact that udp is mostly (by volume) internet attack traffic  is my
>>> > concern with udp.
>>> >
>>> > If legitimate traffic starts using udp in volume, it will make distiguishing
>>> > and thwarting voulmetric attacks very difficult at scale. Without currently
>>> > curbing n * 100g blasts of udp traffic with blanket policers, i would not be
>>> > able to keep my network up... This is a daily issue.  For example, my usual
>>> > udp volume is about 1%. If it goes to 10% suddenly, it is likely smart to
>>> > drop 11% and onwards as a 10x increase in udp is 100% certainly not legit.
>>> >
>>> > My request to quic and spud is simply use a different transport protocol
>>> > number so that their interesting and innovative traffic does not run up
>>> > against the many network policers that are required to enforce well known
>>> > baselines of good normal udp traffic. The quic folks say that they cannot do
>>> > that since 10 year old cpe only passes udp and tcp, then they rant about
>>> > ossified stacks and how we need to put everything on udp to make progess ...
>>> > Seems like they are just choosing to ossify on udp ...  And udp is already
>>> > considered trash (reflection attacks) ...So we agree to disagree, i guess
>>> >
>>> Isn't any other protocol besides TCP also considered trash right now?
>>> 
>> 
>> My network only "manages" udp.  Ymmv.
>> 
>>> UDP based transport protocols would use well know port numbers. A
>>> firewall can allow UDP port X that carries a
>> 
>> A "firewall" is a enterprise solution that does not scale for large national internet providers in the usa
>> 
>> Yes, the bulk of the trash is less than 20 source ports (chargen, ntp, snmp, ntp, dns, ....). But we also get very large bot swarms doing straight packet attacks with udp.  Even a novice like me can write to udp sockets in python on any port and stuff data through it.
>> 
>>> properly congestion
>>> controlled protocols not subject to reflection attacks, but disallow
>>> other UDP ports.
>>> 
>>> Tom
>>> 
>>> > https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00
>>> >
>>> >
>>> >
>>> >> Cheers,
>>> >> Michael
>>> >>
>>> >
>> _______________________________________________ Spud mailing list Spud@ietf.orghttps://www.ietf.org/mailman/listinfo/spud
> _______________________________________________
> Maprg mailing list
> Maprg@irtf.org
> https://www.irtf.org/mailman/listinfo/maprg