Subject: [BEHAVE] Summary of TURN call this afternoon

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Dec 2007 22:08:44 -0500

TURN Open Issues call
December 20, 2007

Attendees:
Jonathan Rosenberg
Dan Wing
Philip Matthews
Eric Rescorla
Derek MacDonald
Kevin Johns
Rémi Denis-Courmont

Summary:

First, we reviewed the open issues which appeared to be closed based on 
list discussion. There were no disagreements on the fact that these were 
closed, and on their resolution. They were:

Ekr Mechanism: Agreement on using this

Issue #2: This is requiring TURN server to be stateful
Resolution: text in rfc3489bis to clarify rule on sending same response 
in 10sec interval

Issue #3: address+port vs. address restricted
Resolution: keep address restricted, though need to discuss issues in 
v6ops doc

Issue #5: Port Range
Resolution: SHOULD be in 49152-65535 range, discuss criteria for 
violating SHOULD

Issue #7: Framing Header Length value
Resolution: agreed that length value is there for UDP and matches UDP 
length, mismatch causes packet discard

Issue #8: Managing permission lifetime
Conclusion: do not address at this time

Next, we discussed the primary meta-issue - long lived allocations. The 
main issue came up that, since TURN certainly allows allocations to live 
for a long time, we were going to need to provide some way for a turn 
server to clean up old channel numbers that aren't in use, otherwise it 
will leak memory. The server needs to be able to reclaim the memory and 
table entries allocated to holding the channel information. Thus, 
regardless of whether one ever thinks there will be a need to reclaim 
channel numbers, we need a mechanism to time them out, and once you do 
that, you can just re-bind to it, and thus the mechanism will exist.

We spent some time discussing how to do this. If we have the server time 
out channels, we need a way to deal with cases where the client thinks 
the channel is up, and the server doesn't. Otherwise, the client will 
send data on some channel and the server doesn't know the channel and 
then discards the data silently. The client has no way to know this. A 
similar problem happens if the TURN server reboots mid-allocation, or 
the NAT reboots. In all cases unencapsulated data is discarded. We need 
a way to alert the client.

We discussed sending an indication back to the client when the server 
receives an unecnapsulated packet on an unknown channel. One issue is 
that indications aren't authenticated, so does this open up a DoS 
attack, whereby an attacker can send faked indication? This is similar 
to the problem we have with indications in the currently documented 
Confirmation mechanism. ANother choice is a reverse transaction from 
server to client. There was no agreement on a mechanism; folks needed to 
go off and come up with one rather than try to design on the fly on the 
call. Ekr took an action item to think about it.

Given that direction, we next moved to the open issue around framing, 
and whether turn packets are framed or not. THe primary drawback of this 
had been that it reduces the number of channels to 32767. However, given 
that we will now have a way to reuse timed-out ones, this limitation 
seems a non-issue. Thus folks on the call agreed that it was OK to go 
ahead and not use the framing header for TURN messages.

We discussed next the open issue around bandwidth. There was some 
agreement that this mechanism was really about admission control for 
constant rate streams. Thus, it was meaningless to include it in 
requests for elastic flows, or include it in responses for those flows. 
There was a concern that we'd need more than just 'bandwidth' as a 
value, we'd need packet sizes too so that a proper job of cac can be 
done. Note that, there was agreement we were talking STRICTLY about 
admission and rate limiting on the TURN server, not in the network. We 
discussed also the idea of using RSVP for this, but we didn't get far in 
that and it was non-obvious how this would work.

The conclusion is that more discussion is needed.

Next steps:

* the remaining issues (bandwidth and port adjacency) remain 
contentious. However, these affect relatively little text in the 
document. Thus will we continue with the originally proposed plan for a 
revised document on Jan 8, including what has been agreed so far.

* In the meantime we can continue to debate these issues. We'll schedule 
another call to make progress after the new year, and continue to do 
that until the issues are closed.

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: Philip Matthews <[email-masked]>
Date: Fri, 21 Dec 2007 07:53:26 -0500

On 20-Dec-07, at 22:08 , Jonathan Rosenberg wrote:
> Resolution: keep address restricted, though need to discuss issues  
> in v6ops doc

Which v6ops doc is this?

- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Dec 2007 10:28:09 -0500

http://www.ietf.org/internet-drafts/draft-ietf-v6ops-teredo-security-concerns-01.txt

---

From: Christian Huitema <[email-masked]>
Date: Fri, 21 Dec 2007 13:01:00 -0800

That doc is very much a work in progress. Most of its discussion applies to enterprise firewalls rather than unmanaged NAT. If you care, I put out an opinion piece on the Symantec analysis of Teredo at http://blogs.technet.com/ipv6/.