Subject: [Marnew] my summary

From: Jari Arkko <[email-masked]>
Date: Fri, 25 Sep 2015 23:10:35 -0400

Had posted this to the chat room, but not everyone was there.
(This is obviously my summary from my limited point of view.
Other people will probably have wildly different thoughts.)

MAIN OBSERVATIONS

- The world does not end when there's more encryption, but
   some current solutions may need to change to work better
   with encrypted traffic
- The problem is not just about enryption, the issue is how
   do we optimise customer experience across a number
   of players?
- Identified a number of potential technical items to pursue
  in the short-term
- Co-operative resource management ideas gained a lot
  of interest in the workshop, along some other ideas
- Various CDN improvements were also popular
- 5G is an opportunity to do things better, together,
  more long-term

TECHNICAL ITEMS TO PURSUE

- Develop co-operative resource management by sending
  data up or down. Attempt to match or improve past
  cleartext-based resource management algorithms in
  with encrypted traffic, while revealing nothing or at
  most benign information (e.g., interactive vs.
  non-interactive bit).
- Create a new protocol for keyless SSL to make
  distributed CDN deployments easier
- Make other CDN improvements: CDNI, blind caches,
  certs, etc.
- Build better testing and debugging tools
- On the 3GPP/GSMA side, there may be other things to
  work on. I’m personally interested in improving identity
  privacy and deal with some of the recent surveillance
  attacks on SIM cards, for instance. But this is all non-IETF
  work.

IMMEDIATE ACTIONS

- Figure out what information would be useful to get as data
  to drive the discussion on the co-operative resource
  management solution. The goal should not to be to prove
  that there is a problem - we all understand that under
  limited resources optimisation can improve things. But
  we need data to understand what kind of optimisation
  results we were getting in non-encrypted world,
  and a base for comparing alternative solutions.
- Use the Marnew list for discussion, no need to wait for
  IETF meetings to get some further discussion going.
- Hold CROWN as a BOF in Buenos Aires (IETF-95)
  on co-operative resource management
- Create a new working group for Keyless SSL,
   start by creating a mailing list, plan to have the
   WG in place (probably no BOF needed) in Buenos
   Aires.
- TBD actions for other CDN improvements
- TBD actions for testing and debugging

---

From: Dirk Kutscher <[email-masked]>
Date: Sun, 27 Sep 2015 22:57:06 +0000

Here is my (public) summary:

http://dirk-kutscher.info/publications/managing-radio-networks-in-an-encrypted-world-2/

Best regards,
Dirk

-----Original Message-----
From: Marnew [mailto:[email-masked]] On Behalf Of Jari Arkko
Sent: Samstag, 26. September 2015 05:11
To: [email-masked]
Subject: [Marnew] my summary

MAIN OBSERVATIONS

  work on. I'm personally interested in improving identity

IMMEDIATE ACTIONS

---

From: Ca By <[email-masked]>
Date: Sun, 27 Sep 2015 20:27:31 -0700

> http://dirk-kutscher.info/publications/managing-radio-networks-in-an-encrypted-world-2/
Thanks for this.

I did not attend the event, so I find read-outs helpful.

Reading between the lines...

At the end of the day, people say video is taking too many resources and
starving out other services.

TCP and adaptive bit rate video try to fill the pipe, and the video
providers want high def, high def means more minutes of use, ....Spectrum
and back haul are scarce resources, videos changes this network utilization
model ... Sky is falling.

This is not a technology problem, it is a policy and business relationship
problem.   The right solution  is for wireless providers and big video
providers to agree on acceptable profiles, this fits the e2e design goal .
Then, none  of this middle box arms race and undermining of crypto is
required because the parameters are well known and accommodated from an e2e
view.  No surprises. No panacea technology.

But then vendors do not get to sell middle boxes based on fear the sky is
falling.....

I think the gsma / Isoc could broker a best practice view / consensus for
e2e video that allows a proper e2e approach that meets the needs ( but not
wants) of all parties (content, network, consumer )

The alternative is an arms race where video get encrypted (done), heavier
dpi,  quic, block quic, install root certs on devices, regulators get
involved ...

 Just my personal 2 cents.

Also , I am not optimistic on spud / udp solving anything since udp is
heavily rate limited

https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00

CB

> From: Marnew [mailto:[email-masked] <javascript:;>] On Behalf Of
> Jari Arkko
> To: [email-masked] <javascript:;>
> _______________________________________________
> Marnew mailing list
> [email-masked] <javascript:;>
> https://www.iab.org/mailman/listinfo/marnew
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 28 Sep 2015 11:01:24 -0700

> Also , I am not optimistic on spud / udp solving anything since udp is 

+1 on this. UDP is heavily metered on most mobile networks. Except for 
the known/accurately classified UDP traffic

Vijay

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 28 Sep 2015 11:49:34 -0700

On 28-Sep-2015 11:01 am, Vijay Devarapalli <[email-masked]> wrote:
>> Also , I am not optimistic on spud / udp solving anything since udp is heavily rate limited
> 
> +1 on this. UDP is heavily metered on most mobile networks. Except for the known/accurately classified UDP traffic

SPUD wouldn't need to go end-to-end to coordinate accepted video profiles between endpoint (client or server) and network.  And it wouldn't need to be a UDP protocol, either, if everyone is in the mood for HTTP REST this protocol development season.

-d

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 28 Sep 2015 12:58:44 -0700

> known/accurately classified UDP traffic

I would love to see more data on this. I'm looking for:
(i) Specific reasons that make UDP particularly more problematic on mobile
networks than on wireline networks.
(ii) Specific reasons for limiting UDP on mobile networks, and I would
really like operators to speak to this point *with data*. What are the DDoS
attack vectors? What do the classification filters look like?
(iii) What are common thresholds for DDoS attacks?

I am looking forward to engaging actively with anyone who is interested,
willing, and able to constructively work on solutions together. End-to-end
protocol evolution today depends on UDP not being a blackhole, and if
you're metering it, let's talk about how to not meter it.

- jana

---

From: Ca By <[email-masked]>
Date: Mon, 28 Sep 2015 14:45:12 -0700

> you're metering it, let's talk about how to not meter it.
I do not believe UDP is the only path to evolve the transport layer.

It is unfortunate that you believe that.

CB

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 28 Sep 2015 15:40:42 -0700

Cameron,

> It is unfortunate that you believe that.

It's not a matter of belief -- SCTP is being deployed over UDP for WebRTC,
and so's QUIC, and these are the most significant evolution of deployed
end-to-end protocols today. I think this is largely consensus at this
point, and I don't think debating this point is particularly interesting.
If UDP-based protocols are doomed to fail, we're only going to find out by
trying and failing to deploy, and I'm happy to change my perspective at
that point. Until then, I'd like to focus conversations on how to get them
deployed.

- jana

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 28 Sep 2015 16:10:23 -0700

On 28-Sep-2015 03:40 pm, Jana Iyengar <[email-masked]> wrote: 
> It's not a matter of belief -- SCTP is being deployed over UDP for WebRTC, and so's QUIC, and these are the most significant evolution of deployed end-to-end protocols today. I think this is largely consensus at this point, and I don't think debating this point is particularly interesting. If UDP-based protocols are doomed to fail, we're only going to find out by trying and failing to deploy, and I'm happy to change my perspective at that point. Until then, I'd like to focus conversations on how to get them deployed.

A distinguisher between 'attack traffic' and 'non attack traffic' is necessary.  For the WebRTC data channel there are consent packets (draft-ietf-rtcweb-stun-consent-freshness) and for TCP there are ACKs.  If we can't get new protocols into the the OS kernel and thus trust the kernels to prevent attacks, something similarly low level needs to exist for other protocols to enabling filtering of attack traffic versus good traffic.

-d

---

From: Christian Huitema <[email-masked]>
Date: Mon, 28 Sep 2015 23:19:37 +0000

On Monday, September 28, 2015 4:10 PM, Dan Wing wrote:
>
> A distinguisher between 'attack traffic' and 'non attack traffic' is necessary.  For the WebRTC 
> data channel there are consent packets (draft-ietf-rtcweb-stun-consent-freshness) and for 
> TCP there are ACKs.  If we can't get new protocols into the OS kernel and thus trust the 
> kernels to prevent attacks, something similarly low level needs to exist for other protocols
> to enabling filtering of attack traffic versus good traffic.

I was with you until you mentioned "OS Kernel." Yes, having some form of return verification helps distinguishing regular traffic from attack traffic. But kernel or not does not make much difference. The source of attack traffic are typically bot nets and compromised servers. In such systems, the kernel is very likely under the control of the attacker. Kernel or application space makes very little difference.

By the way, TCP ACK only gives you so much. I remember studying the code of some of the old worms. It included some simple code like: spin many threads, then in each thread loop on an HTTP GET of some target resource. There was no attempt to hide the origin, or to use anything but the kernel's implementation of TCP...

-- Christian Huitema

---

From: Ca By <[email-masked]>
Date: Mon, 28 Sep 2015 16:27:38 -0700

On Monday, September 28, 2015, Jana Iyengar <[email-masked]> wrote:

> and so's QUIC, and these are the most significant
>
>
Regarding webrtc, the WG had the charter to ship 1.0 quickly and the
associated transport choices reflected that.

Operationally, you will likely see webrtc relayed via TRAM/TURN since udp
"has problems"

There is no WG, charter, or viable draft or consensus on quic -- so I don't
think it is appropriate to say what was done for webrtc in a rushed p2p use
case could be applied to quic

>
> evolution of deployed end-to-end protocols today. I think this is largely
> consensus at this point, and I don't think debating this point is
> particularly interesting. If UDP-based protocols are doomed to fail, we're
> only going to find out by trying and failing to deploy, and I'm happy to
> change my perspective at that point. Until then, I'd like to focus
> conversations on how to get them deployed.
>
>
I am afraid you are not in position to call consensus. And, it is generally
a poor approach to close off discussion in such a way.

That said, udp filtering is being discussed in opsec around
draft-byrne-opsec-udp-advisory-00

---

From: Ted Hardie <[email-masked]>
Date: Mon, 28 Sep 2015 16:28:47 -0700

On Mon, Sep 28, 2015 at 4:10 PM, 🔓Dan Wing <[email-masked]> wrote:

>
>
> A distinguisher between 'attack traffic' and 'non attack traffic' is
> necessary.  For the WebRTC data channel there are consent packets
> (draft-ietf-rtcweb-stun-consent-freshness) and for TCP there are ACKs.
>

WebRTC consent freshness checks are a verification to an originating peer
of its corresponding peer's willingness to receive packets.  The threat
model is malicious JavaScript which might other
​wise be able to send an attack stream to the peer, and the verifier is the
browser or web framework in which that JavaScript lives.  It's true that as
a request/response it demonstrates that a handshake has taken place to a
network observer in many conditions, but it is not necessarily going to be
so for all time.  In some multipath conditions, for example, the browser
may be satisfied with a statement of ongoing consent over all N paths even
if the consent freshness packets are received over only one.

>  If we can't get new protocols into the the OS kernel and thus trust the
> kernels to prevent attacks, something similarly low level needs to exist
> for other protocols to enabling filtering of attack traffic versus good
> traffic.
>
>
​I think a great deal depends on where you intend to do this filtering for
us to discuss what solutions make sense.  If you are talking about within
the networking stack of the host, for example, the set of solutions is very
different from a filter in a local firewall or an AS edge filter.

regards,

Ted

> [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Mon, 28 Sep 2015 16:37:26 -0700

> Operationally, you will likely see webrtc relayed via TRAM/TURN since udp
​It's not clear from this whether you mean the SRTP media streams, the data
channels, or both.

regards,

Ted

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 28 Sep 2015 16:44:00 -0700

> I was with you until you mentioned "OS Kernel." Yes, having some form of return verification helps distinguishing regular traffic from attack traffic. But kernel or not does not make much differenc…

You're saying the server (victim) of the attack is under control of the attacker?  That isn't my experience.  My experience is the client is under (some) control of the attacker, and that the attacker is using the OS's TCP stack in almost all cases (for TCP attacks) and is generating their own UDP packets (for UDP attacks).

> By the way, TCP ACK only gives you so much. I remember studying the code of some of the old worms. It included some simple code like: spin many threads, then in each thread loop on an HTTP GET of s…

Completing a TCP 3 way handshake gives pretty good proof of return route-ability.  I agree it isn't absolute proof; it isn't cryptographically secure to be absolute proof.  But the 3 way handshake, and ongoing ACKs indicating continued interest in receiving the packets are more than we get with a UDP reflection attack with DNS, NTP, or the application de jour.

-d

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 28 Sep 2015 16:46:28 -0700

On 28-Sep-2015 04:28 pm, Ted Hardie <[email-masked]> wrote: 
> On Mon, Sep 28, 2015 at 4:10 PM, 🔓Dan Wing <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> A distinguisher between 'attack traffic' and 'non attack traffic' is necessary.  For the WebRTC data channel there are consent packets (draft-ietf-rtcweb-stun-consent-freshness) and for TCP there are ACKs.
> 
> WebRTC consent freshness checks are a verification to an originating peer of its corresponding peer's willingness to receive packets.  The threat model is malicious JavaScript which might other​wise be able to send an attack stream to the peer, and the verifier is the browser or web framework in which that JavaScript lives.  It's true that as a request/response it demonstrates that a handshake has taken place to a network observer in many conditions, but it is not necessarily going to be so for all time.  In some multipath conditions, for example, the browser may be satisfied with a statement of ongoing consent over all N paths even if the consent freshness packets are received over only one.

Uh, so you're saying Consent won't work with network designs that are not yet deployed on the Internet.  Sure, okay.  Seems we can engineer solutions there, or are you saying it's impossible to engineer solutions?

>  
>  If we can't get new protocols into the the OS kernel and thus trust the kernels to prevent attacks, something similarly low level needs to exist for other protocols to enabling filtering of attack traffic versus good traffic.
> 
> 
> ​I think a great deal depends on where you intend to do this filtering for us to discuss what solutions make sense.  If you are talking about within the networking stack of the host, for example, the set of solutions is very different from a filter in a local firewall or an AS edge filter.

I would love to install a filter on the host that says, "don't generate attack traffic."

-d

> [email-masked] <mailto:[email-masked]>
> https://www.iab.org/mailman/listinfo/marnew <https://www.iab.org/mailman/listinfo/marnew>
> 
>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 28 Sep 2015 16:53:19 -0700

On Mon, Sep 28, 2015 at 4:46 PM, 🔓Dan Wing <[email-masked]> wrote:

> Uh, so you're saying Consent won't work with network designs that are not
> yet deployed on the Internet.  Sure, okay.  Seems we can engineer solutions
> there, or are you saying it's impossible to engineer solutions?
>
> ​No, I'm saying "Don't build your security solutions on the side effects
of things that may change for other reasons"​.  Consent works fine to
answer the threat model it is built for, and it will work fine to answer
that threat even if you change the network deployment.  What may not work
is a network-based solution to a different base problem that is looking for
that consent traffic to distinguish flows.  The consent flow can move
without the data flow moving.

> I would love to install a filter on the host that says, "don't generate
​Consent freshness works because of what amounts to a dynamic filter in the
browser​ that says "don't generate attack traffic".  So feel free to pat
yourself on the back--you've done what you love.

Ted

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 28 Sep 2015 16:57:56 -0700

On 28-Sep-2015 04:53 pm, Ted Hardie <[email-masked]> wrote: 
> On Mon, Sep 28, 2015 at 4:46 PM, 🔓Dan Wing <[email-masked] <mailto:[email-masked]>> wrote:
> ​No, I'm saying "Don't build your security solutions on the side effects of things that may change for other reasons"​.  Consent works fine to answer the threat model it is built for, and it will work fine to answer that threat even if you change the network deployment.  What may not work is a network-based solution to a different base problem that is looking for that consent traffic to distinguish flows.  The consent flow can move without the data flow moving.

I understand what you're saying.

I'm saying don't build solutions that prevent the network from defending itself.

> ​Consent freshness works because of what amounts to a dynamic filter in the browser​ that says "don't generate attack traffic".  So feel free to pat yourself on the back--you've done what you love.

I haven't, because the limitation is only in a browser; the limitation isn't enforced with non-browser applications installed on the host.

-d

---

From: Christian Huitema <[email-masked]>
Date: Tue, 29 Sep 2015 00:01:55 +0000

On Monday, September 28, 2015 4:44 PM, Dan Wing wrote:
> >...
> > I was with you until you mentioned "OS Kernel." Yes, having some form of
> return verification helps distinguishing regular traffic from attack traffic. But
> kernel or not does not make much difference. The source of attack traffic are
> typically bot nets and compromised servers. In such systems, the kernel is
> very likely under the control of the attacker. Kernel or application space
> makes very little difference.
> 
> You're saying the server (victim) of the attack is under control of the
> attacker?  That isn't my experience.  My experience is the client is under
> (some) control of the attacker, and that the attacker is using the OS's TCP
> stack in almost all cases (for TCP attacks) and is generating their own UDP
> packets (for UDP attacks).

No. I am saying that the attackers will often use compromised servers as the source of their attacks. Compromised servers make great weapons, because they have access to lots of bandwidth.

> > By the way, TCP ACK only gives you so much. I remember studying the code
> of some of the old worms. It included some simple code like: spin many
> threads, then in each thread loop on an HTTP GET of some target resource.
> There was no attempt to hide the origin, or to use anything but the kernel's
> implementation of TCP...
> 
> Completing a TCP 3 way handshake gives pretty good proof of return route-
> ability.  I agree it isn't absolute proof; it isn't cryptographically secure to be
> absolute proof.  But the 3 way handshake, and ongoing ACKs indicating
> continued interest in receiving the packets are more than we get with a UDP
> reflection attack with DNS, NTP, or the application de jour.

Tools that use UDP reflection are of course nice for the attackers, because they launder the actual source of the attack. Sometimes, they may also add a nice amplification effect. But may point was that attackers do not necessarily try to hide the origin address. Botnets are cheap. Besides, it is entirely possible to mount a reflection attack using TCP SYN. Or ICMP. 

Of course, network operators could also deploy RFC 3704. It has been a BCP for 11 years...

-- Christian Huitema

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 28 Sep 2015 17:17:10 -0700

> Tools that use UDP reflection are of course nice for the attackers, because they launder the actual source of the attack. Sometimes, they may also add a nice amplification effect. But may point was…

The question that created this thread was about why UDP is difficult as the base for new protocols.  Dealing with TCP and ICMP attacks is pretty well-known.  UDP is the wild west, which is why it's so scary.  We need to reduce the scary factor to be on par with TCP, if we want UDP filters to be weakened (I chose 'weakened' on purpose).

> Of course, network operators could also deploy RFC 3704. It has been a BCP for 11 years...

Anyone operating a CGN is, as a side effect, preventing IP address spoofing (RFC3704).  Most -- if not all -- mobile network are operating a CGN.  So lack of filtering isn't the problem for those networks.

-d

---

From: Ted Hardie <[email-masked]>
Date: Mon, 28 Sep 2015 17:17:35 -0700

> I'm saying don't build solutions that prevent the network from defending
​I think the next truism in this chain is "Don't build defences that ​make
the network unusable for what user want", but we're at level of discourse
now that makes "Love is a two-way street" seem profound.

As for this bit "the limitation isn't enforced with non-browser
applications installed on the host.", I believe it would be enforced for
anything that users the built-in web frameworks in most mobile OSes, but I
grant you that anything that downloaded its own JS interpreter is off the
reservation.  Have you seen any in the wild?

Ted

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 28 Sep 2015 17:32:03 -0700

To clarify: The consensus I meant was not an IETF wg consensus, but
informal consensus among pretty much anyone who's doing any transport work
these days. I believe this was in fact one of the outcomes of the IAB's
SEMI workshop as well earlier this year.

Numbers I have heard about use of TURN for WebRTC sessions hover in the
10%-15% range, which still leaves 85%-90% on the table.

My intent was not to turn off the conversation; I was trying to direct it
towards something more productive. I am really not sure how talking about
UDP being a cesspool is particularly productive, given that that's where
innovation *is* happening.

On Mon, Sep 28, 2015 at 4:27 PM, Ca By <[email-masked]> wrote:

>> It's not a matter of belief -- SCTP is being deployed over UDP for
>> WebRTC, and so's QUIC, and these are the most significant
>>
>>
> There is no WG, charter, or viable draft or consensus on quic -- so I
> don't think it is appropriate to say what was done for webrtc in a rushed
> p2p use case could be applied to quic
>
>
>
>>
> I am afraid you are not in position to call consensus. And, it is
> generally a poor approach to close off discussion in such a way.
>

---

From: Ca By <[email-masked]>
Date: Mon, 28 Sep 2015 17:37:41 -0700

> innovation *is* happening.
I hear love is a 2 way street

CB

>
> On Mon, Sep 28, 2015 at 4:27 PM, Ca By <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>>
>>
>> On Monday, September 28, 2015, Jana Iyengar <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>
>>> Cameron,
>>>
>>> evolution of deployed end-to-end protocols today. I think this is
>>> largely consensus at this point, and I don't think debating this point is

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 Sep 2015 01:53:28 +0100

Hiya,

> 10%-15% range, which still leaves 85%-90% on the table.

Can you be more specific? 10-15% of what is doing what?

Ta,
S.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 29 Sep 2015 15:34:49 +0200

(Catching up on the Marnew threads; really sorry I couldn't make it to Atlanta for the workshop... let me jump in here)

> On 29 Sep 2015, at 01:10, 🔓Dan Wing <[email-masked]> wrote:
> 
> 
> A distinguisher between 'attack traffic' and 'non attack traffic' is necessary.

We are helped here by the fact that there are bit-strings that are valid in commonly-compromised UDP protocols, and there are bit strings that are invalid. If (1) we presume that the set of commonly-compromised UDP protocols stays constant -- i.e. you can use old, broken stuff to mount amplifying reflection attacks but new protocols will be built with care to avoid amplification -- and (2) we carefully design UDP-based encapsulations and transport protocols such that are guaranteed to contain a string of bits in the first n bits which will not appear on one of the commonly-compromised protocols, then simple bit-string comparison can be used to distinguish SPUD/QUIC'/whatever from "possibly garbage UDP".

This does nothing against compromised machines sending UDP garbage with the SPUD/QUIC'/whatever magic bits, but nothing keeps them from SYN flooding, either. Except perhaps BCP38, which I note has already been mentioned.

>  For the WebRTC data channel there are consent packets (draft-ietf-rtcweb-stun-consent-freshness) and for TCP there are ACKs.

And we presume other transports over UDP will have similar mechanisms; see section 3.7 of https://tools.ietf.org/html/draft-trammell-stackevo-explicit-coop-00 for some initial reflections on this.

Cheers,

Brian

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 29 Sep 2015 15:27:21 -0700

> Can you be more specific? 10-15% of what is doing what?

Apologies, I should have been more specific. My understanding is that about
10-15% of WebRTC sessions between browsers use TURN since P2P UDP doesn't
work. I'm happy to go digging and try to come back with a more precise
reference and more precise numbers if needed. I do have citable data for
QUIC usage between client and server, and our data shows that about 92% of
users are able to speak QUIC well to Google servers
<https://docs.google.com/presentation/d/15e1bLKYeN56GL1oTJSF9OZiUsI-rcxisLo9dEyDkWQs/edit#slide=id.gc34025b9a_0_0>
.

The larger point however is that UDP reachability exists for a significant
part of the Internet. Of course, managing UDP traffic in the network is
still something that operators need to figure out how to do, and as I have
said earlier, I am happy to discuss and see where I can help.

---

From: Brian Trammell <[email-masked]>
Date: Wed, 30 Sep 2015 13:11:20 +0200

> On 30 Sep 2015, at 00:27, Jana Iyengar <[email-masked]> wrote:
> 
> Apologies, I should have been more specific. My understanding is that about 10-15% of WebRTC sessions between browsers use TURN since P2P UDP doesn't work. I'm happy to go digging and try to come back with a more precise reference and more precise numbers if needed. I do have citable data for QUIC usage between client and server, and our data shows that about 92% of users are able to speak QUIC well to Google servers.
> 
> The larger point however is that UDP reachability exists for a significant part of the Internet.

We're working on a study to generate more data on this question. We plan to post a summary of our findings with links to raw data to the HOPS list once we've submitted. We can share here as well if that's interesting, although the measurements cover only terrestrially-connected non-enterprise networks. Super-quick summary: we have found no evidence of UDP reachability issues other than those attributable to the access network or the local (NAT/firewall) configuration. Of the ~64k paths we've analyzed so far, we come to a comparable conclusion: 94% have UDP connectivity to the Internet.

Cheers,

Brian

> Of course, managing UDP traffic in the network is still something that operators need to figure out how to do, and as I have said earlier, I am happy to discuss and see where I can help.
>

---

From: Ca By <[email-masked]>
Date: Wed, 30 Sep 2015 05:57:21 -0700

On Wednesday, September 30, 2015, Brian Trammell <[email-masked]> wrote:

>
> > On 30 Sep 2015, at 00:27, Jana Iyengar <[email-masked] <javascript:;>>
> wrote:
> >
> > Apologies, I should have been more specific. My understanding is that
> about 10-15% of WebRTC sessions between browsers use TURN since P2P UDP
> doesn't work. I'm happy to go digging and try to come back with a more
> precise reference and more precise numbers if needed. I do have citable
> data for QUIC usage between client and server, and our data shows that
> about 92% of users are able to speak QUIC well to Google servers.
> >
> We're working on a study to generate more data on this question. We plan
> to post a summary of our findings with links to raw data to the HOPS list
> once we've submitted. We can share here as well if that's interesting,
> although the measurements cover only terrestrially-connected non-enterprise
> networks. Super-quick summary: we have found no evidence of UDP
> reachability issues other than those attributable to the access network or
> the local (NAT/firewall) configuration. Of the ~64k paths we've analyzed so
> far, we come to a comparable conclusion: 94% have UDP connectivity to the
> Internet.
>
> Cheers,
>
> Brian
>
>

Sounds like a good effort, but unlikely to capture the scenario i am
concerned about in this picture

https://twitter.com/theipv6guy/status/623535325915168768

> > Of course, managing UDP traffic in the network is still something that
> operators need to figure out how to do, and as I have said earlier, I am
> happy to discuss and see where I can help.
> >

---

From: Brian Trammell <[email-masked]>
Date: Wed, 30 Sep 2015 15:22:45 +0200

> On 30 Sep 2015, at 14:57, Ca By <[email-masked]> wrote:
> 
> 
> 
> Sounds like a good effort, but unlikely to capture the scenario i am concerned about in this picture
> 

While we could certainly arrange to design a study to try and melt bits of the network with TCP and UDP and see which falls over first, at some point, the design of the infrastructure for a particular measurement study you want to run becomes functionally indistinguishable from a botnet (you'd be surprised how often this happens, especially in performance measurement), and you have to start asking yourself ethical questions about balancing the utility of your findings from the study with the external costs it imposes.

I'm *still* not overly concerned about this particular hack, although it is a nice hack. Countermeasures that are based on behavioral traffic profiling must always adapt to changes in the traffic, just as countermeasures based on signature matching must update those signatures. So has it ever been and so ever shall it be. The diagram you link to admits this itself -- the slope on the "organic UDP" line is, after all, positive. If QUIC and/or new transports over SPUD prove truly useful, then the traffic profile will change, perhaps quicker than it would otherwise. But imagine a world in which BitTorrent moved over to uTP when P2P was still on the upswing and you have the same situation.

Each access operator using UDP thresholding then has a decision to make: is this one tool I have in my toolbox more important than access to new services over UDP? After all, *all* of these services will have to build in a fallback to TCP anyway, so at worst you'll be causing less than ideal performance for your users, and there are so many sources of less than ideal performance that very few of them will ever notice, and fewer still will change providers over it. The churn caused by the decision may well cost less than finding other ways to eat garbage UDP.

As I said, what we *can* do is design these new services and their encapsulations with distinguishing them from garbage UDP quickly in mind. I suspect this is easier than allocating and deploying a new protocol number, though admittedly I haven't run that study yet. Perhaps we'll have more to say on this point in early '16.

Cheers,

Brian