Subject: [rtcweb] UDP transport problem

From: Cb B <[email-masked]>
Date: Wed, 12 Feb 2014 22:06:56 -0800

Folks,

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/

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Feb 2014 09:47:31 -0800

On 12 February 2014 22:06, Cb B <[email-masked]> wrote:
> has been increasingly associated with DDoS traffic [1],

Is your concern that WebRTC will increase the potential for DoS (which
would presume the DoS mitigation measures in ICE [RFC 5245] are
insufficient), or is it just that UDP is so toxic to network operators
that you predict it will be turned off?

---

From: Cb B <[email-masked]>
Date: Thu, 13 Feb 2014 09:56:43 -0800

> that you predict it will be turned off?

My concern is that IPv4 UDP is so toxic it will be blocked.  It may be
wise to start SCTP in the standard from the start.

Cameron

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 13 Feb 2014 10:45:52 -0800

> wise to start SCTP in the standard from the start.

Why SCTP? Why not "Just like UDP only restricted to having SRTP inside" 
or even "just like UDP only a different protocol number that we like 
better"?

(Assuming that this is a good idea at all)

Matthew Kaufman

---

From: Cb B <[email-masked]>
Date: Thu, 13 Feb 2014 10:50:04 -0800

On Thu, Feb 13, 2014 at 10:45 AM, Matthew Kaufman <[email-masked]> wrote:
> Why SCTP? Why not "Just like UDP only restricted to having SRTP inside" or
> even "just like UDP only a different protocol number that we like better"?
>

UDP2 using a different protocol number would be sufficient to
differentiate from the "bad" traffic.

Cameron

> Matthew Kaufman
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 13 Feb 2014 21:36:01 +0100

> differentiate from the "bad" traffic.
... and would make sure that it does not pass NATs...
I guess this is the same problem as using SCTP/IP. For
NAT traversal through NATs not supporting SCTP one would
use SCTP/UDP/IP.

Best regards
Michael

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 13 Feb 2014 21:48:36 +0100

> wise to start SCTP in the standard from the start.

The bad guys will follow wherever the ports are open (and are usually
faster at writing code than the standards guys are at writing specs); so
will the traversal artists.

WebRTC over port 53, anyone?

(DNS is the one UDP-based service that's so important to the Internet,
it *cannot* be turned off unconditionally - so I expect that if UDP in
general gets blocked, port 53 will be the port 80 of UDP-land.)

-- 
Surveillance is pervasive. Go Dark.

---

From: Cb B <[email-masked]>
Date: Thu, 13 Feb 2014 13:20:33 -0800

> will the traversal artists.

Harald, the issue is not open ports. The issue is the entire transport
type is polluted.

> general gets blocked, port 53 will be the port 80 of UDP-land.)

DNS runs over TCP as well.

But that's not the point.  The question is can we include native SCTP
as an option in  draft-ietf-rtcweb-transports?  What is the downside?

CB

---

From: cowwoc <[email-masked]>
Date: Thu, 13 Feb 2014 17:28:04 -0500

On 13/02/2014 4:20 PM, Cb B wrote:
> DNS runs over TCP as well. But that's not the point. The question is 
> can we include native SCTP as an option in 
> draft-ietf-rtcweb-transports? What is the downside? CB

The biggest downside, as I see it, is that 90%+ of the world runs 
Windows and that platform does not support SCTP natively (a fact that 
you have mentioned before). I am all in favor of SCTP, but I think you 
need to solve the Windows problem before this solution become meaningful.

Gili

---

From: Ted Hardie <[email-masked]>
Date: Thu, 13 Feb 2014 14:32:32 -0800

> as an option in  draft-ietf-rtcweb-transports?  What is the downside?

Howdy,

Given previous decisions of the working group, you would need to describe
how to provide confidentiality.  At the moment, I know only of TLS over
SCTP (which would reverse the current mapping) and SCTP over IPSec (which
would likely actually be IPSec/UDP); do you know of other methods which
would keep SCTP at the top layer of the protocol stack and still provide
confidentiality?

regarsd,

Ted

---

From: Cb B <[email-masked]>
Date: Thu, 13 Feb 2014 14:37:39 -0800

On Thu, Feb 13, 2014 at 2:32 PM, Ted Hardie <[email-masked]> wrote:
> how to provide confidentiality.  At the moment, I know only of TLS over SCTP
> (which would reverse the current mapping) and SCTP over IPSec (which would
> likely actually be IPSec/UDP); do you know of other methods which would keep
> SCTP at the top layer of the protocol stack and still provide
> confidentiality?
>
> regarsd,
>
> Ted
>

I believe the cleanest would be to do TLS over SCTP.  I understand
that changes the top of the transport stack, and create variation.
But, i don't think current SCTP over DTLS plan has won any beauty
prizes.  If this is standards track work that must stand the test of
time, TLS over SCTP seems appropriate.

CB

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 13 Feb 2014 23:44:41 +0100

> Harald, the issue is not open ports. The issue is the entire transport

And I think that notion is bogus. Faced with the choice of dealing with
the devil they know (UDP) and the devil they don't have a clue about
(SCTP), firewall operators are going to stick with building out the
rulesets around UDP, and continuing to refuse all the "new stuff".

So I don't think the plan has legs - adding SCTP without the UDP wrapper
to our options will not help anyone do anything.

But this is trying to forecast the thinking and action of humans that
are not me, which is something I frequently get wrong - so other
opinions would be welcome.

> DNS runs over TCP as well.

For AXFR, yes. For daily lookups .... better not tell any root DNS
operator you're advocating that they should have all their lookups over
TCP; you wouldn't like the expletives that result.

> as an option in  draft-ietf-rtcweb-transports?  What is the downside?

Clutter.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 13 Feb 2014 14:45:49 -0800

On Thu, Feb 13, 2014 at 2:37 PM, Cb B <[email-masked]> wrote:

> SCTP
This requires a completely new method for providing channel abstractions.

If you would like the working group to consider a change of that magnitude,
a worked draft describing a solution that meets all of the use cases set
out in
draft-ietf-rtcweb-data-channel-07 seems to me the bare minimum to consider
overturning the established working group consensus on this point.

Speaking personally, I do not see sufficient SCTP/IP deployment to warrant
further discussion on this point.  The working group has invested
considerable
time and effort on this approach and the likely result of this change seems
to
me either a less deployable system or one which will deploy later because
of the
need to start discussions over.

regards,

Ted Hardie

---

From: Dave Taht <[email-masked]>
Date: Thu, 13 Feb 2014 17:46:51 -0500

On Thu, Feb 13, 2014 at 5:28 PM, cowwoc <[email-masked]> wrote:
>> DNS runs over TCP as well. But that's not the point. The question is can
>> we include native SCTP as an option in draft-ietf-rtcweb-transports? What is
>> the downside? CB
>
>
> The biggest downside, as I see it, is that 90%+ of the world runs Windows
> and that platform does not support SCTP natively (a fact that you have
> mentioned before). I am all in favor of SCTP, but I think you need to solve
> the Windows problem before this solution become meaningful.

The biggest downside, as I see it, is targeting advancements in the state of
the art, at windows. 98% of the world or so run non-windows based cell
phones and tablets, and in terms of total users, probably outnumber
the windows contingent at this point.

SCTP and MPTCP are quite feasible on android and IOS.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Cb B <[email-masked]>
Date: Thu, 13 Feb 2014 14:47:52 -0800

On Thu, Feb 13, 2014 at 2:45 PM, Ted Hardie <[email-masked]> wrote:
> a worked draft describing a solution that meets all of the use cases set out
> in
> me either a less deployable system or one which will deploy later because of
> the

Acknowledged.  That is approximately the story arc i expected before I
initiated the conversation.

CB

---

From: cowwoc <[email-masked]>
Date: Thu, 13 Feb 2014 17:51:46 -0500

> SCTP and MPTCP are quite feasible on android and IOS.

It doesn't matter how many smartphones there are. What matters is how 
many of them will be used to do meaningful video chat. The screen real 
estate on these devices is way too small.

So yes, mobile is huge, but from the point of view of WebRTC, Windows is 
still king.

Gili

---

From: Cb B <[email-masked]>
Date: Thu, 13 Feb 2014 14:57:56 -0800

> rulesets around UDP, and continuing to refuse all the "new stuff".

I never mentioned firewall operators.  I mentioned access networks and
internet backbone operators.

As many network operators know, there is a big issue with UDP going on
that is crushing some networks

http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack

https://puck.nether.net/pipermail/outages/2014-February/006651.html

This is the point in bring to the WG.

> to our options will not help anyone do anything.

it's a path out.

> TCP; you wouldn't like the expletives that result.

cute. But, TCP works.  Maybe you can ask someone at Android to support
EDNS0 so that TCP is used less.  Because for now, android required TCP
for any response over 512 bytes.

---

From: Dave Taht <[email-masked]>
Date: Thu, 13 Feb 2014 18:00:59 -0500

On Thu, Feb 13, 2014 at 5:51 PM, cowwoc <[email-masked]> wrote:
> It doesn't matter how many smartphones there are. What matters is how many
> of them will be used to do meaningful video chat. The screen real estate on
> these devices is way too small.

In my experience, everybody is using tablets and handheld devices for
video chat.
It is a natural extension of the usage of the device to extend it from
phone calls
to video calls.

The lack of a working camera on most desktops is a hindrance, and the placement
of cameras on most laptops is not ideal.

> So yes, mobile is huge, but from the point of view of WebRTC, Windows is

I am under the impression that this is actually backed by statistics, but am
interested in recent statistics for things like google hangouts and facetime.

-- 
Dave Täht

---

From: Dave Taht <[email-masked]>
Date: Thu, 13 Feb 2014 18:09:06 -0500

> for any response over 512 bytes.

Android, in part, uses dnsmasq, which we are busily adding dnssec support to.

https://www.internetsociety.org/deploy360/blog/2014/02/weekend-project-4/

EDNS0 is supported.

I would certainly like to see android's DNS handling to be improved.

>From a QoS standpoint I would not mind at all if it were possible to run
webrtc (and things like QUIC) over their own protocol numbers. I
realize this would
make webrtc more easily identifiable, but so long as the e2e encryption is good,
the ability for operators and edge devices to optimize for highly
interactive traffic
would be enhanced.

I don't have a lot of hope for SCTP, do have more hope for mptcp, and
the ipv6 rollout is seemingly accelerating.

https://www.internetsociety.org/deploy360/blog/2014/02/googles-ipv6-stats-pass-3-less-than-5-months-after-passing-2/

I am under the impression ipv6 support for webrtc landed in chrome recently.

-- 
Dave Täht

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 14 Feb 2014 00:39:17 +0100

Most important point of reality anchoring (DNS over UDP vs TCP) is at
the bottom.
Other comments are incidental.

> http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack
That's an UDP port 123 (NTP) matter. We've done several of these
exercises (live-fire updates of critical Internet infrastructure) over
the last few years.

> This is the point in bring to the WG.

Yes, thanks for bringing it.
I just happen to totally disagree with your conclusions.

>> to our options will not help anyone do anything.

I don't see any property of this path that makes it a) traversable, or
b) "out".

> for any response over 512 bytes.

I'm talking about
http://k.root-servers.org/statistics/ams-ix/ip_protocols.html

Note the relative width of the green (TCP) against the purple (UDP).
(I've been unable to find a green pixel on those graphs.)

---

From: cowwoc <[email-masked]>
Date: Thu, 13 Feb 2014 18:50:38 -0500

> of cameras on most laptops is not ideal.

All laptops and tablets come with decent cameras. I will agree that 
WebRTC on tablets will be strong, but smartphones is really pushing it. 
Most of the time I've seen people engage in video chat it was between 
family members; far less for business use. And in those cases, I've seen 
people jump on tablets and laptops instead of having to deal with a 
tiny, underpowered smartphone for video. These are just personal 
observations, not science, so please take them with a grain of salt.

Gili

---

From: Dave Taht <[email-masked]>
Date: Thu, 13 Feb 2014 18:54:56 -0500

On Thu, Feb 13, 2014 at 6:50 PM, cowwoc <[email-masked]> wrote:
>>>> The biggest downside, as I see it, is targeting advancements in the
>>>> state
>>>> of
>>> many
> All laptops and tablets come with decent cameras. I will agree that WebRTC
> on tablets will be strong, but smartphones is really pushing it. Most of the
> time I've seen people engage in video chat it was between family members;
> far less for business use. And in those cases, I've seen people jump on
> tablets and laptops instead of having to deal with a tiny, underpowered
> smartphone for video. These are just personal observations, not science, so
> please take them with a grain of salt.

I will clarify what I said above is that what I observe among the under 20s
is huge tablet and handheld use for videoconferencing. For business use
I see primarily things like dedicated hardware, webex and to a smaller
extent hangouts,
and facetime.

-- 
Dave Täht

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 14 Feb 2014 08:20:26 +0100

> time, TLS over SCTP seems appropriate.
Using TLS over SCTP as defined in
http://tools.ietf.org/search/rfc3436
doesn't support all features of SCTP, for example partial reliability,
and it doesn't scale well (It needs a TLS connection per bidirectional
stream, so per data channel in our case).
Using DTLS over SCTP resolves these issues:
http://tools.ietf.org/search/rfc6083

DTLS over SCTP is supported by OpenSSL.

Best regards
Michael

---

From: Randell Jesup <[email-masked]>
Date: Fri, 14 Feb 2014 02:20:54 -0800

On 2/12/2014 10:06 PM, Cb B wrote:
> 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

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.

> access networks are simply clamping IPv4 UDP throughput and moving on

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

> can make well informed protocol decisions.

Thank you

-- 
Randell Jesup
[email-masked]

---

From: Cb B <[email-masked]>
Date: Fri, 14 Feb 2014 06:42:44 -0800

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

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.

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)

> 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

---

From: cowwoc <[email-masked]>
Date: Fri, 14 Feb 2014 11:46:09 -0500

On 14/02/2014 9:42 AM, Cb B wrote:
> 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.
>

Which is why we will never be able to stop DDoS attacks:

 1. With dumb firewall rules that rely upon port numbers alone.
 2. Unless the destination address is able to communicate back to the
    source (or as close as possible to the source) that it does not wish
    to continue receiving (any) packets from it, and in so doing pushes
    the problem back as far as possible to the source.

Gili

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 14 Feb 2014 19:24:01 +0100

On 02/14/2014 03:42 PM, Cb B wrote:
> > 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.

---

From: Cb B <[email-masked]>
Date: Fri, 14 Feb 2014 10:54:06 -0800

> authentication). The main concern isn't DDOS attacks, it's being blamed

Spam is a type of attack.  It is an L7 attack as opposed to a volume attack.

The largest broadband ISP in the USA blocks port 25, i provided this
info in my first email.

http://customer.comcast.com/help-and-support/internet/email-port-25-no-longer-supported/

> surprising that I disagree with the conclusion.

That's fine.  It is not my goal to block UDP or save WebRTC.  I am
just submitting information that i have and connecting the dots that
are in front of me.  The future may show that i am too pessimistic or
not enough.

CB

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 14 Feb 2014 21:50:38 +0100

> http://customer.comcast.com/help-and-support/internet/email-port-25-no-longer-supported/

I believe this is consistent with what I said. They block it *for
residential customers*.

That's why I said "by backbone providers" above.

If port 25 was blocked by backbone providers, we would not be having
this conversation in this medium; from your message:

The occurences of the word "SMTP" in those header fields should tell you
something.

---

From: Tim Panton <[email-masked]>
Date: Sun, 16 Feb 2014 14:00:26 +0000

On 14 Feb 2014, at 16:46, cowwoc <[email-masked]> wrote:

>> 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.
>> 
> 
> With dumb firewall rules that rely upon port numbers alone.
> Unless the destination address is able to communicate back to the source (or as close as possible to the source) that it does not wish to continue receiving (any) packets from it, and in so doing pushes the problem back as far as possible to the source.

I don't agree, when we set up an ISP in the '90s we had egress filter rules that dropped any packets with From address that were not
routed as 'inside' our network.

At the time we were told to drop that (along with a pile of other security features which are slowly returning). 
I see no reason why anyone would peer with an ISP that refused to do that.

(We now return to your #rtcweb program).

T.

> Gili

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk

---

From: Tim Panton <[email-masked]>
Date: Sun, 16 Feb 2014 14:03:07 +0000

On 13 Feb 2014, at 23:50, cowwoc <[email-masked]> wrote:

> All laptops and tablets come with decent cameras. I will agree that WebRTC on tablets will be strong, but smartphones is really pushing it. Most of the time I've seen people engage in video chat it was between family members; far less for business use. And in those cases, I've seen people jump on tablets and laptops instead of having to deal with a tiny, underpowered smartphone for video. These are just personal observations, not science, so please take them with a grain of salt.
> 
> Gili

Again, I disagree, I often use a smartphone for video, but only if I can airplay/chromecast the video to a suitable TV.

T.

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Sun, 16 Feb 2014 14:57:26 +0000

Why would we assume anything about the devices this stuff will run on in the future? Technology change tells me we'll all be wrong and underestimate what's next. Assume WebRTC on everything, including my smarty ring. :-)

Jeremy

> On Feb 16, 2014, at 9:03 AM, "Tim Panton" <[email-masked]> wrote:
> 
>