Subject: [tram] Security use case around

From: Cullen Jennings <[email-masked]>
Date: Tue, 21 Jul 2015 15:05:01 +0200

Let work though the issue with anycast. Imagine the case where the anycast address happened to belong to Cisco. I realize we would not use that IP address but I will get to that later.  Now imagine some users happens to be at their friends houses using the friends wireless and that person does not have anything special configured. When the browser does the auto discovery, there will be no local routing of the IP address so Cisco’s turn server will get used. It’s a little confusing how what credential will be used with the server but it seems likely that the scheme we end up with will involve things like giving the turn server an OAuth token along with the Origin where it it from.

The TURN server learns all kinds of things. What IPs are calling each other, how long the calls last, and probably a fair amount of correlation if the same certificates are used for multiple calls which seems likely. I don’t really think too much is leaked by the non CBR encrypted voice issue but some people do and the server would see all that. Effectively this added Cisco as an on path attacker to all the media when previously Cisco was not on the path.

So obviously we would not use one of Cisco’s IP for this. But the more you think about it, the IP we would use is not much better for many of the attacks we care about it. It certainly realistic that a country or ISP could use BGP to ensure a fairly wide set of locations routed that anycast address to a proxy of their choice.  I have tested addresses out of the 192.0.0.0 block to see if equipment routes it and it’s clear a lot of stuff does. 

The arguments keeps getting made that when I connect to gogo wifi on a plane that the AP is a trusted element. That’s insane - of course I don’t trust it with my info - I’m just using it and want to reveal to it as little as possible. The argument get mades “but it owns you because it owns the DNS”. There are a variety of things one can do to mitigate that and more work is being done to close remaining holes. For example configuring a DNS server instead of the DHCP provided one, or using DTLS to a trusted DNS server, or DNSCrypt etc. The argument is made that one trusts the DHCP sever from the gogo AP by using it. Again, I don’t think people are trusting more than it gave them an IP to use. I would not want to make my security rely on the domain name returned by the gogo DHCP server. Now clearly gogo can currently MITM all the TLS but obviously we are doing our best to stop that from being possible. That’s because we don’t trust the AP. Yes, gogo does seem how much traffic I send over my VPN but they can be used without revelling much more than that. A TURN server sees a lot more metadata than some one that just sees the VPN traffic. Every advertising company would love to collect a list all the companies that a given person calls. 

Of course there are many AP’s that one might trust. For example if you a enterprise user is in the enterprise and did 802.1x and authenticated the AP, I’d view that as one that could be trustable. But that’s a bit different from gogo’s AP.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 21 Jul 2015 06:32:44 -0700

On Tue, Jul 21, 2015 at 6:05 AM, Cullen Jennings <[email-masked]> wrote:

>
> Let work though the issue with anycast. Imagine the case where the anycast
> address happened to belong to Cisco. I realize we would not use that IP
> address but I will get to that later.  Now imagine some users happens to be
> at their friends houses using the friends wireless and that person does not
> have anything special configured. When the browser does the auto discovery,
> there will be no local routing of the IP address so Cisco’s turn server
> will get used. It’s a little confusing how what credential will be used
> with the server but it seems likely that the scheme we end up with will
> involve things like giving the turn server an OAuth token along with the
> Origin where it it from.
>
> The TURN server learns all kinds of things. What IPs are calling each
> other, how long the calls last, and probably a fair amount of correlation
> if the same certificates are used for multiple calls which seems likely. I
> don’t really think too much is leaked by the non CBR encrypted voice issue
> but some people do and the server would see all that. Effectively this
> added Cisco as an on path attacker to all the media when previously Cisco
> was not on the path.
>

Can't the AP collect all this information as well?

---

From: Adam Roach <[email-masked]>
Date: Tue, 21 Jul 2015 15:56:08 +0200

On 7/21/15 15:32, Justin Uberti wrote:
>
>
> On Tue, Jul 21, 2015 at 6:05 AM, Cullen Jennings <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     Let work though the issue with anycast. Imagine the case where the
>     anycast address happened to belong to Cisco. I realize we would
>     not use that IP address but I will get to that later.  Now imagine
>     some users happens to be at their friends houses using the friends
>     wireless and that person does not have anything special
>     configured. When the browser does the auto discovery, there will
>     be no local routing of the IP address so Cisco’s turn server will
>     get used. It’s a little confusing how what credential will be used
>     with the server but it seems likely that the scheme we end up with
>     will involve things like giving the turn server an OAuth token
>     along with the Origin where it it from.
>
>     The TURN server learns all kinds of things. What IPs are calling
>     each other, how long the calls last, and probably a fair amount of
>     correlation if the same certificates are used for multiple calls
>     which seems likely. I don’t really think too much is leaked by the
>     non CBR encrypted voice issue but some people do and the server
>     would see all that. Effectively this added Cisco as an on path
>     attacker to all the media when previously Cisco was not on the path.
>
>

Right -- I made exactly this point at the microphone.

The exception is the "VPN as default route" case; but, for that 
situation, you're routing to whatever your VPN has set up for the 
anycast address, not for where the local network sends it, so it's no 
worse in that case either.

>> It certainly realistic that a country or ISP could use BGP to ensure 
>> a fairly wide set of locations routed that anycast address to a proxy 
>> of their choice.

Cullen -- your assertion here seems to be predicated on anycast 
addresses being easier to hijack than other IP addresses. This isn't 
self-evident [1]. Can you explain why you think this is true?

/a

____
[1] And, in fact, I think I can make an argument that they're actually 
harder to hijack in many cases.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 21 Jul 2015 22:44:43 +0200

> On Jul 21, 2015, at 3:56 PM, Adam Roach <[email-masked]> wrote:
> 

As I said at the mic, yes of course. But now anyone who is on the routing path of the anycast address can also collect it. Before they could not. What I said is allows a broader set of people that used to be off path attackers to become on path attackers.

---

From: Brandon Williams <[email-masked]>
Date: Wed, 22 Jul 2015 02:37:17 -0400

Let's return to Adam's other question ... What about anycast addresses 
makes this worse? There's nothing special about anycast addresses. Any 
address can be hijacked via BGP just as easily as any other. As long as 
you have buy-in from the various routers along the path to allow the 
hijack, which is required for anycast too, the packets will follow the 
path that you set up. Am I missing some special characteristic of an 
anycast address that makes it different from any other address and 
somehow more susceptible to hijack?

I also have a separate question which is why should I care about how 
easy it is for gogo to hijack the routing for whatever relay I might 
decide to use? If I use (D)TLS, I should be able to detect when they try 
to become the relay and I should be able to protect my metadata from 
untrusted third parties in the path between me and my trusted relay 
(including an untrusted border relay if I use return to get to the 
trusted relay).

--Brandon

On 07/21/2015 04:44 PM, Cullen Jennings wrote:
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Jul 2015 01:08:00 -0700

On 21 July 2015 at 06:05, Cullen Jennings <[email-masked]> wrote:
> the AP is a trusted element. That’s insane

+1

---

From: Adam Roach <[email-masked]>
Date: Wed, 22 Jul 2015 10:46:46 +0200

On 7/21/15 22:44, Cullen Jennings wrote:
> [A]nyone who is on the routing path of the anycast address can also collect it. Before they could not. What I said is allows a broader set of people that used to be off path attackers to become on path attackers.

For any of your objections to be a coherent argument against using 
anycast, they would have to be false if you replace "anycast" with 
"non-anycast."

This one fails that test.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 22 Jul 2015 10:53:43 +0200

>> the AP is a trusted element. That’s insane

Sure. Motherhood and apple pie. I'm not arguing from the perspective 
that the AP is supposed to be trusted.

My argument is that the AP has access to source and destination 
information as well as the payloads, by virtue of where it is in the 
network. You can't argue that giving it access to these three pieces of 
information is somehow a risk, because /it already has access to them/. 
If it's going to act maliciously, then anything you can do maliciously 
with this information is already possible.

The crux of Cullen's argument regarding APs is that they'll somehow 
allow access to this information if and only if we use anycast for 
discovery. That simply doesn't follow, since /they already have that 
access/.

/a

---

From: Brandon Williams <[email-masked]>
Date: Wed, 22 Jul 2015 04:56:46 -0400

I fully agree that the AP is not to be trusted unless you trust the AP's 
administrator and use some mechanism to verify that you have connected 
to the intended AP. No one should trust gogo wifi.

That said, I haven't heard anyone make this argument. Maybe it's been 
made in another context, but I don't think that argument has been made 
on the tram list nor do I think it was made in the meeting yesterday.

What I think was asked for is an explanation of why we should be more 
concerned about using an untrusted relay than we should be about using 
an untrusted AP. As soon as the untrusted AP gets into the flow, I can 
no longer trust that my packets will be delivered to the intended 
destination. The packets can follow any path that the AP chooses on the 
way to any destination that the AP chooses. There are no guarantees. And 
any node along the untrusted path has equal access to the metadata.

--Brandon

On 07/21/2015 09:05 AM, Cullen Jennings wrote:
> The arguments keeps getting made that when I connect to gogo wifi on a plane that the AP is a trusted element. That’s insane - of course I don’t trust it with my info - I’m just using it and want to reveal to it as little as possible. The argument get mades “but it owns you because it owns the DNS”. There are a variety of things one can do to mitigate that and more work is being done to close remaining holes. For example configuring a DNS server instead of the DHCP provided one,or using DTLS to a trusted DNS server, or DNSCrypt etc. The argument is made that one trusts the DHCP sever from the gogo AP by using it. Again, I don’t think people are trusting more than it gave them an IP to use. I would not want to make my security rely on the domain name returned by the gogo DHCP server. Now clearly gogo can currently MITM all the TLS but obviously we are doing our best to stop that from being possible. That’s because we don’t trust the AP. Yes, gogo does seem ho
 w much t

raffic I send over my VPN but they can be used without revelling much 
more than that. A TURN server sees a lot more metadata than some one 
that just sees the VPN traffic. Every advertising company would love to 
collect a list all the companies that a given person calls.

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 27 Jul 2015 11:27:31 +0200

I read this thread and wonder why the anycast method of draft-ietf-tram-turn-server-discovery-04.txt is discussed in a use case around a wrongly configured wrongly advertised "Cisco turn server".

1) 
Under 9. Security Considerations, 9.3 Anycast in the discovery draft, it correctly spells out that the anycast route to the server only should be available to inside (local, LAN side) of the default gateway (that a network provided turn server parallels to get a good path for real-time traffic)

So at "his friends WiFi AP", there should not even be a route to that Cisco turn server.

2) Further
> "It’s a little confusing how what credential will be used with the server"
It is indeed, and there seem to be a misunderstanding of why we need discovery of a network provided turn server
The very purpose of discovery is to find the turn server offered to users of the particular network segment that it serves.

Simply put, that Cisco turn server should not authenticate Allocate request from inside users. No credentials needed!
If configured to respond to Authenticate requests from outside users, that Cisco turn server should authenticate outside users, and could then serve as an application provided TURN server (NOT a network provided discovered turn server)

3) Further
> "The TURN server learns all kinds of things..."
So does the default gateway (in case it is not paralleled by a network provided turn server).
Both are provided by the same network admin, so what is the difference?

4) Further
> "gogo wifi on a plane that the AP is a trusted element"
> " > the AP is a trusted element. That’s insane
+1"
> "agree that the AP is not to be trusted"

This seems to be a matter of terminology: Do we call the one we send our data to the outside of our network segment (the default gateway) trusted or not. Let's use "same trust level" instead.

A network provided turn server has the same trust level as the default gateway it is paralleling, so no problem is introduced. 

This is actually highlighted by draft-jennings-behave-rtcweb-firewall-00, where the real-time traffic flow is suggested to be captured in an UDP flow, in the default gateway path in the firewall. Thus that firewall has the ability to "learns all kinds of things...", just like a turn server paralleling its default gateway would have. We give them our real-time traffic with the same level of trust. 

5) Very little of this has to do with the anycast method in itself.

Is the concern instead that, from network segments NOT having a properly configured and advertised network provided turn server, the very discovery process of sending an Allocate request to the anycast address, may reveal things to the outside or that a far away turn server (not paralleling any of the default gateways that has to be passed), will be used?

If so, the discovery draft under 9. Security Considerations, 9.3 Anycast 
Suggests "...set an IP TTL on their TURN requests that limits how far they can travel..."

Maybe this TTL setting can be guided by a trace route before, so that TURN requests intended for a network provided turn server never reaches the public internet.

Is there such improvement of the anycast discovery process to be made?

We need the discovery and the return drafts to be adopted as soon possible to get WebRTC going everywhere and with quality! 

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Brandon Williams
Skickat: den 22 juli 2015 10:57
Till: Cullen Jennings; [email-masked]; Adam Roach
Ämne: Re: [tram] Security use case around

I fully agree that the AP is not to be trusted unless you trust the AP's administrator and use some mechanism to verify that you have connected to the intended AP. No one should trust gogo wifi.

That said, I haven't heard anyone make this argument. Maybe it's been made in another context, but I don't think that argument has been made on the tram list nor do I think it was made in the meeting yesterday.

What I think was asked for is an explanation of why we should be more concerned about using an untrusted relay than we should be about using an untrusted AP. As soon as the untrusted AP gets into the flow, I can no longer trust that my packets will be delivered to the intended destination. The packets can follow any path that the AP chooses on the way to any destination that the AP chooses. There are no guarantees. And any node along the untrusted path has equal access to the metadata.

--Brandon

On 07/21/2015 09:05 AM, Cullen Jennings wrote:
> The arguments keeps getting made that when I connect to gogo wifi on a 
> plane that the AP is a trusted element. That’s insane - of course I 
> don’t trust it with my info - I’m just using it and want to reveal to 
> it as little as possible. The argument get mades “but it owns you 
> because it owns the DNS”. There are a variety of things one can do to 
> mitigate that and more work is being done to close remaining holes. 
> For example configuring a DNS server instead of the DHCP provided 
> one,or using DTLS to a trusted DNS server, or DNSCrypt etc. The 
> argument is made that one trusts the DHCP sever from the gogo AP by 
> using it. Again, I don’t think people are trusting more than it gave 
> them an IP to use. I would not want to make my security rely on the 
> domain name returned by the gogo DHCP server. Now clearly gogo can 
> currently MITM all the TLS but obviously we are doing our best to stop 
> that from being possible. That’s because we don’t trust the AP. Yes, 
> gogo does seem ho
 w much t

raffic I send over my VPN but they can be used without revelling much more than that. A TURN server sees a lot more metadata than some one that just sees the VPN traffic. Every advertising company would love to collect a list all the companies that a given person calls.