Subject: [BEHAVE] TURN Issue #3: Address v. Address and Port Restricted

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Dec 2007 14:38:36 -0500

This issue was not discussed at the WG meeting, but generated a bunch of 
discussion at the ad-hoc.

The issue is this. Currently, a TURN server basically acts like a NAT 
whose filtering behavior is address-dependent [RFC4787]. RFC 4787 has 
this to say on this property:

REQ-8:  If application transparency is most important, it is
       RECOMMENDED that a NAT have an "Endpoint-Independent Filtering"
       behavior.  If a more stringent filtering behavior is most
       important, it is RECOMMENDED that a NAT have an "Address-Dependent
       Filtering" behavior.

Note that this is a SHOULD and not a MUST. One of the reasons for that, 
is that there is a belief that some firewall or NAT vendors or operators 
would believe (true or not) that address and port restricted NAT 
behavior is 'more secure'. A huge governing principle of TURN is that, 
firewall admins would not be afraid of TURN and would not block it, 
because it doesn't lessen the security properties of a firewall in any 
way; it merely transforms an address or address-and-port depending 
mapping NAT and an address-and-port dependent filtering NAT, into one 
that is endpoint independent mapping and address dependent filtering, 
which does not lessen security. The problem is, we may all believe that 
to be true, but firewall admins may not, and thus block TURN anyway.

An alternative proposal, therefore, would be to make a TURN server 
address and port restricted filtering. If this is done, we would end up 
with several cases with ICE where two TURN servers get used. Also ICE 
would operate more slowly. In particular, if agents A and B are both 
behind an address-dependent mapping NAT, two TURN servers would be used. 
With the current design, its just one.

Some of the folks in the ad-hoc proposed that, this was not actually a 
bug. The reason is that the current mechanism misplaces incentives. An 
address-dependent filtering behavior in the TURN server allows my TURN 
server to fix the problem of SOMEONE ELSES NAT. Thus, the worry was that 
provider X would deploy ICE but skip a TURN server, since it would just 
assume that other providers it was connecting to would deploy TURN, and 
if they did, provider X would not need a TURN server. If provider Y came 
to the same conclusion, neither would deploy TURN. Making TURN 
address-and-port dependent filtering would basically force each provider 
to deploy TURN to fix its own NAT problems.

Others, myself included, did not agree with this analysis. I believe 
that providers will due what is needed to make their service work. Any 
provider that skips TURN since they are betting that other providers 
deploy it, will probably not be in business long. So I do not agree this 
is a problem.

Another issue that came up is, forgetting inter-provider calls, moving 
to address-and-port restricted behavior in TURN servers will make things 
worse in a single domain deployment (which is 100% of the cases today). 
If you have regional TURN servers in different data centers, and a 
customer associated with one TURN server calls a customer associated 
with another, you'd incur the cost of two TURN servers. The most 
expensive part of that is the traffic in and out of the data center. The 
secondary cost would be the server capacity. The folks with an existing 
deployment were in the ad-hoc and confirmed that a multi-data center 
deployment was a concern and they were worried about this issue.

We also recognized that user A could call user B, and both be on the 
*same* TURN server. The TURN server needs to hairpin. This is unrelated 
to this issue, but undocumented in the current TURN spec, and we need to 
document that a TURN server needs to be prepared for this.

So, amongst the folks present in the ad-hoc, we agreed that the existing 
address-dependent filtering behavior was better and we'd like to stick 
with that. However, we need to get input from folks in the security area 
to get some feedback on whether this would pose a concern in 
deployments. Magnus agreed to help us reach out to sec-dir to get some 
of that input.

If you agree (or not) with this conclusion, please speak up.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 10 Dec 2007 11:07:53 +0200

Le Friday 07 December 2007 21:38:36 ext Jonathan Rosenberg, vous avez écrit :
> behavior is 'more secure'.

My person belief is that this would not *really* provide any extra security. 
But I do know that some people do claim (and probably think) it does.

draft-ietf-v6ops-teredo-security-concerns-01 (§ 4.2, 4.3) kind of hint at 
this. I have also heard of NATs that were purposedly made to be evil 
symmetric NATs to hinder P2P applications - basically it is quite effective 
at preventing NAT-to-NAT communication.

I am not all saying we should go for port-restricted behavior. However, if we 
do keep the current behavior, I think we need to put some explanatory 
justification somewhere (SecCons?).

-- 
Rémi Denis-Courmont

---

From: Bob Andreasen <[email-masked]>
Date: Mon, 10 Dec 2007 10:53:42 -0500

> deploy it, will probably not be in business long. So I do not agree this

Our goal to make the service work -- regardless if the other party
deploys a TURN server ... or if legacy clients within our domain are
fielded without TURN support.

> deployment was a concern and they were worried about this issue.

This is clearly a problem for large deployments.  The odds of having
the client land on the same server is small -- especially if you have
regional deployments where clients are directed to the 'best' server.

> If you agree (or not) with this conclusion, please speak up.

AOL (Bob Andreasen and Elena Furman) support keeping the behavior
as-is.  Some comments below.