Subject: [BEHAVE] Minutes of TURN conf call on 8 April 2008

From: Philip Matthews <[email-masked]>
Date: Tue, 8 Apr 2008 16:06:00 -0400

Below are the preliminary minutes of the TURN conference call of 8  
April 2008. If any of the attendees think I did not properly capture  
some aspect, then please send e-mail to the mailing list.

Furthermore, if anyone who was not on the call disagrees with a  
conclusion, then please send e-mail. By IETF procedures, all
decisions must be ratified on the mailing list.

- Philip

Minutes of TURN conference call of 8 April 2008
===============================================

Attendees:
Cullen Jennings
Hadriel Kaplan
Feng Liu
Rohan Mahy
Philip Matthews
Mariano O'Kon
Benny Prijono
Eric Rescorla
Jonathan Rosenberg
Magnus Westerlund
Dan Wing

1. TWIST
Hadriel gave a presentation of his TWIST proposal, followed by a  
discussion. The conclusion was that, while TWIST may be interesting,  
it doesn't fit the requirements of TURN. In particular, TWIST has high  
encapsulation overhead (although in the meeting Hadriel suggested a  
modification to reduce the overhead) and TWIST cannot be implemented  
as an unprivileged userland process. These reasons, and  the fact that  
the completion of TURN is holding up ICE, lead everyone on the call to  
agree that we would continue with the existing TURN direction and not  
bring in ideas from TWIST.
Decision: TWIST is a separate proposal, and is not a TURN replacement.

2. TCP and TLS between the Client and the Server
It was agreed that both these transports should be kept in TURN.
For TCP, it was agreed that the motivating text will be changed to  
describe why in some environments TCP is preferred over UDP (e.g.,  
clear indication of end of flow, data exchanged only with peer of 3- 
way handshake).
For TLS, the motivating text should talk about the fact that TLS  
provides a way for the client to verify that it is talking to the  
correct server, as well as a way to prevent third parties from reading  
the TURN messages.
Action: Philip to work with Jonathan and Cullen to craft some proposed  
text that described why these transports are in TURN.

3. Setting the DF bit in "Partly-Compliant" Allocations
There was a long discussion about how Path MTU Discovery might be done  
even if the server cannot read the setting of the DF bit on incoming  
packets. A number of possible solutions were discussed, and there  
seemed to be a general conclusion that the problem was harder than it  
seemed at first glance. However, it was agreed to go with Cullen's  
proposal that TURN provide a way for the client to indicate, on a per- 
packet basis, that the DF bit should be set when sending from the  
server to the peer. It was felt that this was easy to specify and  
implement, and provided at least part of the total solution. Philip  
noted that it was probably possible to do this with an existing unused  
bit for the Send indication.
Action: Philip to send a concrete proposal to the mailing list.

4. Anycast and ALTERNATE-SERVER
There was another long discussion about anycast and ALTERNATE-SERVER.  
It was agreed that TURN would not specify all the details about how  
anycast discovery of a server would work, but just specify some  
necessary pieces. A full anycast discovery procedure could then be  
advanced as a separate document (though note that BEHAVE does not have  
a milestone for such a document).
One necessary piece is the specification of the ALTERNATE-SERVER  
semantics, and the proposal that Philip sent to the mailing
list on 7 April 2008 was accepted without comment. A second piece  
might be a change in the requirement that any response using ALTERNATE- 
SERVER be authenticated -- it was pointed out that TURN authentication  
currently authenticates the client, not the server. However, the  
participants were unable to agree on a way to fix this, and more  
discussion is required.

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

---

From: "Benny Prijono" <[email-masked]>
Date: Wed, 9 Apr 2008 00:17:25 +0100

>  Action: Philip to send a concrete proposal to the mailing list.

Sorry I missed the discussion when people said this would be difficult
to implement as extension. I mean why something like these couldn't be
made to work?:
 - clients that require server to do DF extension would include a
mandatory REQUIRE-DF attribute in Allocate request.
 - server that wants to indicate DF extension support would include a
non-mandatory SUPPORT-DF in its Allocate response.

The benefit of this approach (apart from that it's a separate draft)
are server implementors doesn't have to implement this if they don't
care, and client will know for sure if server implements it.

cheers
 -benny

---

From: Philip Matthews <[email-masked]>
Date: Wed, 9 Apr 2008 09:24:32 -0400

Whoops! I forgot to include Derek MacDonald in the list of attendees.
- Philip

---

From: Philip Matthews <[email-masked]>
Date: Wed, 9 Apr 2008 09:33:54 -0400

> care, and client will know for sure if server implements it.

We could do this. There is already a REQUESTED-PROPS attribute which I  
would suggest using rather than a new REQUIRE-DF attribute.

However, I think the sense of the call was that a flag requesting the  
DF bit be sent on sending would be easy to implement, much easier than  
adding a "REQUIRE-DF" mechanism. The sense of the call is almost every  
OS provides an API to set the DF bit.

- Philip

---

From: "Benny Prijono" <[email-masked]>
Date: Wed, 9 Apr 2008 14:51:51 +0100

> would suggest using rather than a new REQUIRE-DF attribute.

Yes if we put this in the main spec.

>  However, I think the sense of the call was that a flag requesting the DF
> bit be sent on sending would be easy to implement, much easier than adding a
> "REQUIRE-DF" mechanism. The sense of the call is almost every OS provides an
> API to set the DF bit.

Okay. I just thought that if this would burden the development of the
main spec (you seem to have quite a lot of stuffs to do!) then we have
the option to put this as extension.

Thanks
 Benny

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 10 Apr 2008 21:06:50 -0600

On Apr 8, 2008, at 2:06 PM, Philip Matthews wrote:
> list on 7 April 2008 was accepted without comment.

Uhmm - I don't think that proposal specified enough to agree or  
disagree with. I would not view it as accepted.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 11 Apr 2008 08:30:32 -0700

At Tue, 8 Apr 2008 16:06:00 -0400,
> list on 7 April 2008 was accepted without comment.

I don't recall this, nor does it make sense without the authentication
issue being complete.

> A second piece  

-Ekr

---

From: Philip Matthews <[email-masked]>
Date: Mon, 14 Apr 2008 08:50:26 -0400

Ok, then comment away on the proposal.
- Philip