Subject: [BEHAVE] Goals for the proposed conf call on TURN encapsulations

From: Philip Matthews <[email-masked]>
Date: Tue, 1 Apr 2008 16:07:26 -0400

I have gotten the feedback that some people are unclear on the goals  
for the proposed conf call on TURN encapsulations. So let me try to  
clarify what I hope to achieve.

I have two goals:

1) TURN-UDP currently allows TCP or TLS over TCP connections between  
the client and the server. That is, the user data flows over TCP to  
the server, and then over UDP to the peer. However, the justification  
for these two transports in the document is weak, and it has been  
recently suggested that this can be used to violate firewall policy.   
I would like to talk about this and agree on good reasons why these  
transports are needed, or agree to remove them.

2) In my opinion, the TWIST proposal is essentially an alternative  
encapsulation proposal for TURN.  In my personal opinion, the working  
group should not pursue both the existing TURN proposal and TWIST at  
the same time. So I would like to discuss TWIST vs TURN and see if we  
can select one of these as the encapsulation that we will pursue in  
the short term. (Note that the WG may disagree with me, and elect to  
pursue both of these at the same time, but I feel we need to  
consciously make this decision).

Another motivation to have this call is that discussion of these  
topics on the mailing list was rather thin last week. I am hoping that  
a conference call with provide better discussion.

- Philip

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

---

From: "Benny Prijono" <[email-masked]>
Date: Tue, 1 Apr 2008 23:45:07 +0100

>  transports are needed, or agree to remove them.

As implementer working on client side, my holy grail is to have a
client that will "just work", and the TCP/TLS connection helps me a
lot here as I don't have to implement more complex protocol like
ICE-TCP. Not being conscious with policy matters, I'm still puzzled on
why are we not allowing this. I mean, if I run my RTP over TCP over
TURN (with UDP peers), how is this any different than RTP over TCP, or
RTP over ICE-TCP, from the policy point of view?

So I think probably what we're looking is just the appropriate and
softer wording on the issue rather than dropping the (nice) feature
altogether. Something that doesn't say "helloo we are breaking
firewall policies here".

>  consciously make this decision).

In own my personal opinion, let TWIST be TWIST and TURN be TURN. Maybe
TURN is not good enough for everyone, maybe it may not be able to run
on certain hardware, I know it would not run on my wrist watch, but
that's good enough for me. And I think it's good enough for most
people who want a working solution for VoIP vs symmetric NATs. And we
need this solution ASAP.

As implementor, I've been waiting for STUN/TURN/ICE trio to be
published since quite long time. Almost exactly a year ago I finished
my implementation and I wrote in my blog [1] how I thought we were
finally getting somewhere with STUN/ICE and that TURN was still
nowhere from stable. With what you're proposing, heck look where we're
at now. :)

Maybe nobody will care, but I will say here anyway that for
implementors like me it's been painful to keep up with the changes in
these protocols. I just re-wrote my software from scratch for TURN-07,
re-did interop tests (for the N-th time), and you're saying we'll have
to do these all over again with TURN-08 (and maybe every subsequent
TURN releases)? I wonder if implementors will still have the energy to
carry on with these.

[1] http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source-ice-stun-and-turn/

>  a conference call with provide better discussion.

The way I see it, the lack of discussions indicate the lack of
interest to take on board the issues, and perhaps the lack of strong
arguments on to why we're changing the hard-fought TURN-07.

Just my 0.02p.

Cheers
 Benny

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 2 Apr 2008 00:08:25 -0400

Hi Benny,
Comments inline...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Benny Prijono
>
> ICE-TCP.

I am not sure what you mean by not having to do ICE-TCP - you mean not doing RFC4571 framing?  Or you mean not using ICE connectivity checks and SIP/SDP pieces?  In other words you mean you plan to just use the TURN relay addresses, period?

> Not being conscious with policy matters, I'm still puzzled on

I'm no expert on that either - I personally only keep up with the network provider side of life.  From what I'm told by folks in my company who do deal with enterprises, though, firewall policies are not a fixed well-defined rule-set, and vary for a bunch of reasons.

Regardless, there is a "difference" between running RTP/TURN/TCP and RTP/TCP.  For the former, it allows multiple RTP sessions (like audio+video) to run over a single TCP connection, or for example both RTP and RTCP over the single TURN-TCP connection, or MSRP file transfer and RTP over the same TURN-TCP connection, or Bitorrent and MP3 streams over the same connection, ad infinitum.  It is going down a slippery-slope of firewall avoidance, such that the natural conclusion is not just to use TURN, but to use it on port 80 or 443.  That *will* "just work" for you.  It is what some p2p apps resort to, to get their apps to work.  It is also something the ietf has avoided, afaik.  Obviously there is some middle-ground.  I'm just not sure what it is personally.

RTP/TCP (RFC4571) is a single TCP connection for a single m-line stream, including one for RTP and one for RTCP.  Furthermore, RFC4571 does not define a general application use-case - it is for RTP/RTCP and RTP/RTCP only, signaled in SDP.  TURN is not media specific, nor SIP specific, nor anything specific.  And given the interest lately to use TURN for any protocol, that raises the stakes.

There are though issues that have nothing to do with firewall policies.  Worse than UDP, TCP as a transport presents a number of issues with multiplexing different application streams in the same connection (e.g., HOL blocking, congestion avoidance backoff, flow shaping or RED in routers).

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 2 Apr 2008 00:16:24 -0400

Hi Benny,
I think Philip was looking for email responses like yours, to get a sense of what people are thinking, so thanks for that!
Other comment inline...

> people who want a working solution for VoIP vs symmetric NATs. And we

Yes, that was what I proposed as well in an earlier email.  I did not mean to submit TWIST as a replacement for TURN, or to cause chaos.  It's like a Venn-diagram I think, of overlapping use-cases but not complete overlap of either.  Let the market(s) decide what they will.

I do, though, think TURN itself should be cleaned up, or at least consensus reached, on multiplexing and other issues - and here I'm talking about TURN-TCP, not TURN-UDP.

-hadriel

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 2 Apr 2008 07:42:52 +0300

> lot here as I don't have to implement more complex protocol like

I know TCP could help in some cases: braindead UDP support in the NAT, 
braindead firewall configuration that blocks UDP but lets outgoing TCP. I 
wonder if TLS buys you anything unless the TURN server runs on port 443 - 
which would clearly be a firewall.

> RTP over ICE-TCP, from the policy point of view?

As far as I know, we currently DO allow this.

The two main objections are it being a way to violate the firewall policy, and 
it being difficult or impossible to implement in hardware.

I think the firewall objection is bogus - UDP-to-UDP TURN can be used to 
work-around some loose firewall policies just as well. I would argue that's a 
bug in the firewall policy, not in TURN, if it works that way.

A third objection, would be head-of-line blocking. However, I believe this is 
a non issue for TCP-to-UDP relaying. The relay can just drop incoming UDP 
packets from peers if the TCP session to the client is congested.

(...)

> nowhere from stable. With what you're proposing, heck look where we're

As implementor, I have been holding back on implementing TURN, because it's 
been obvious, for the past 30+ months years I've been following BEHAVE it's 
not ready to be implemented.

Note however, that the current TURN spec is just plain broken when it comes to 
TCP, especially, TCP-to-TCP, so it's going to have to change anyhow.

-- 
Rémi Denis-Courmont

---

From: "Benny Prijono" <[email-masked]>
Date: Wed, 2 Apr 2008 10:50:16 +0100

> I am not sure what you mean by not having to do ICE-TCP - you mean not doing RFC4571 framing?  Or you mean not using ICE connectivity checks and SIP/SDP pieces?  In other words you mean you plan to…

I'm using TURN with ICE, and all I need to do is to advertise the
relay address in the ICE candidate list. The fact that the connection
to the TURN server uses TCP is oblivious to the remote endpoint, and
the remote endpoint doesn't need to support TCP at all.

Alternatively, if I want my media to reach Internet with TCP, I will
have to implement ICE-TCP, and RFC 3571, and probably RFC 4145. Maybe
I'm wrong since I haven't even read any of these considering that I'm
not ready to do major modification in my software to support TCP based
media.

>  Regardless, there is a "difference" between running RTP/TURN/TCP and RTP/TCP.  For the former, it allows multiple RTP sessions (like audio+video) to run over a single TCP connection, or for example both RTP and RTCP over the single TURN-TCP connection, or MSRP file transfer and RTP over the same TURN-TCP connection, or Bitorrent and MP3 streams over the same connection, ad infinitum.  It is going

I don't think that's accurate, CMIIW. One TURN UDP allocation/relay
address is only used for one type of media, regardless of whether the
connection to the TURN server uses UDP or TCP. So that means
application needs to allocate different TURN address for each SDP m=
line, including one allocation for RTP and another for RTCP.

Sure people can mux all of these in a single UDP allocation, by just
advertising the same transport address for all of them. But the same
can be done with plain RTP/UDP too, so TURN doesn't make the situation
any worse IMO.

> down a slippery-slope of firewall avoidance, such that the natural conclusion is not just to use TURN, but to use it on port 80 or 443.  That *will* "just work" for you.  It is what some p2p apps resort to, to get their apps to work.  It is also something the ietf has avoided, afaik.  Obviously there is some middle-ground.  I'm just not sure what it is personally.

Well whether I run my TURN on port 80 or 443 will be up to me, and to
be fair to the TURN draft, there's nothing there that says that
either. Maybe if TCP connection is disallowed I will run my TURN on
port 53, and then what, are we going to disallow TURN UDP too? ;-)

>  RTP/TCP (RFC4571) is a single TCP connection for a single m-line stream, including one for RTP and one for RTCP.  Furthermore, RFC4571 does not define a general application use-case - it is for RT…

With TURN application will also have to use one TURN allocation for
each m-line, and including one for RTP and one for RTCP.

>  There are though issues that have nothing to do with firewall policies.  Worse than UDP, TCP as a transport presents a number of issues with multiplexing different application streams in the same…

I believe you're talking about TURN TCP allocation, that will be a
different issue (which is being discussed on separate thread I
believe).

Cheers
 Benny

---

From: "Benny Prijono" <[email-masked]>
Date: Wed, 2 Apr 2008 11:22:18 +0100

>  which would clearly be a firewall.

The good thing with using TURN with ICE is, we don't care which one
will work. Just put everything in the candidate list and let ICE
machinery do its job.

>  As far as I know, we currently DO allow this.

Yep, and I'm trying to vote for it to stay.

>  it being difficult or impossible to implement in hardware.

I can sympathize with the hardware problem. But just as Hadriel said
he doesn't care if TWIST is not implementable in client since he
doesn't write client, I also don't care if TURN is not implementable
in a certain chip since I don't write chips. :)

>  bug in the firewall policy, not in TURN, if it works that way.

Maybe, can't really comment on that since I've no clue on policies
matter. But so far I've yet to hear why it's so bad to perform UDP
allocation using TCP connection to TURN server (what's the shorthand
name for this btw?), while I can do TCP media using other (non-TURN)
means without anybody complaining that I'm breaking somekind of
firewall policy.

>  packets from peers if the TCP session to the client is congested.

Exactly.

>  not ready to be implemented.

Well I thought we're finally getting somewhere with TURN-07, and I
know at least one other implementor who thought the same.

>  TCP, especially, TCP-to-TCP, so it's going to have to change anyhow.

Yep. I've been lurking here all along to see the latest discussions.

Cheers
 Benny

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 2 Apr 2008 11:18:29 -0400

> in a certain chip since I don't write chips. :)

I *never* said I don't care if TWIST is implementable in a client.  I said I don't care *how* it works in a client - i.e., I don't personally care about the implementation details of shims vs. stacks vs. whatever.  I most certainly *do* care that clients be able to implement it, and obviously the more easily/simpler the better.

BUT, you and others are implying the client should be easy and it doesn't matter how hard the server relay is.  I think it should be the other way around completely.  I think the clients should do absolutely everything in their power to off-load any burden from relays, and if that takes re-writing the existing client code or installing special-privilege shims to do so then so be it.  The reason I think that is not because I'm lazy, but because I think the client desperately wants there to be a relay to begin with, and so it should make the bar for relays as low as possible.  My $0.02 anyway (which, given the value of the $, is a lot less than $0.02 used to be).

-hadriel

---

From: Philip Matthews <[email-masked]>
Date: Wed, 2 Apr 2008 11:26:06 -0400

First of all, thanks for having a mailing list discussion on all this.  
I am following the mailing list closely, and will make sure that any  
comments made on the list are carefully considered when deciding what  
to do with TURN.

Regarding finishing TURN. Indeed, TURN has been very unstable for a  
long time, so it has not been a very good candidate for stable trial  
implementations. However, the authors are working hard to try to  
finish TURN as fast as possible, since it is the last piece holding  
back ICE from publication as an RFC.  I am still hoping to have a WGLC  
on TURN before the Dublin meeting. However, even though changing  
encapsulations is a major change, there is no point going forward with  
a document that is just going to be ignored. So I want to make sure  
the question of encapsulations is properly considered.

More comments on Hadriel's message below

On Wed, 2-Apr-08, at 00:08 , Hadriel Kaplan wrote:
> I am not sure what you mean by not having to do ICE-TCP - you mean  
> not doing RFC4571 framing?  Or you mean not using ICE connectivity  
> checks and SIP/SDP pieces?  In other words you mean you plan to just  
> use the TURN relay addresses, period?
>
>
> I'm no expert on that either - I personally only keep up with the  
> network provider side of life.  From what I'm told by folks in my  
> company who do deal with enterprises, though, firewall policies are  
> not a fixed well-defined rule-set, and vary for a bunch of reasons.
>
> Regardless, there is a "difference" between running RTP/TURN/TCP and  
> RTP/TCP.  For the former, it allows multiple RTP sessions (like audio 
> +video) to run over a single TCP connection, or for example both RTP  
> and RTCP over the single TURN-TCP connection, or MSRP file transfer  
> and RTP over the same TURN-TCP connection, or Bitorrent and MP3  
> streams over the same connection, ad infinitum.  It is going down a  
> slippery-slope of firewall avoidance, such that the natural  
> conclusion is not just to use TURN, but to use it on port 80 or  
> 443.  That *will* "just work" for you.  It is what some p2p apps  
> resort to, to get their apps to work.  It is also something the ietf  
> has avoided, afaik.  Obviously there is some middle-ground.  I'm  
> just not sure what it is personally.

What precisely are you objecting to here?  Is it the multiplexing, or  
the use of TCP? For example, if the client used a UDP connection to  
the server, then are you still concerned.

Someone told me privately that one reason people are interested in  
using TCP between a client and the server is because firewall vendors  
don't like UDP because there is no explicit connection termination.  
With TCP, there is a handshake to connect and another handshake to  
disconnect, and this makes everything much more explicit.

In my own company (Avaya), there is a firewall that monitors outgoing  
traffic (as well as incoming traffic), and it blocks various types of  
outgoing traffic. Though I don't know for sure, I think that the  
firewall is set to block all outgoing traffic (either TCP or UDP)  
unless an explicit permission has been inserted for the destination  
port. So this means that TURN will not work unless the IT department  
allows it. Thus I don't think allowing TCP connections between the  
client and the server will violate corporate security policy here.

>
>
> RTP/TCP (RFC4571) is a single TCP connection for a single m-line  
> stream, including one for RTP and one for RTCP.  Furthermore,  
> RFC4571 does not define a general application use-case - it is for  
> RTP/RTCP and RTP/RTCP only, signaled in SDP.  TURN is not media  
> specific, nor SIP specific, nor anything specific.  And given the  
> interest lately to use TURN for any protocol, that raises the stakes.
>
> There are though issues that have nothing to do with firewall  
> policies.  Worse than UDP, TCP as a transport presents a number of  
> issues with multiplexing different application streams in the same  
> connection (e.g., HOL blocking, congestion avoidance backoff, flow  
> shaping or RED in routers).

I don't think any of these problems apply in the situations allowed  
for by draft-ietf-behave-turn-07. If you believe otherwise, can you  
point out why?

- Philip

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 2 Apr 2008 11:48:18 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Benny
> Prijono
>

No, you're not following what I mean.  You can of course run TURN on port 80, or SIP on port 80, or whatever, and no the IETF is not the protocol police.  However, what I'm talking about is about a question I asked a while ago.

The question I asked is "Why do we need TCP/TLS as a transport for the TURN connection when the peer connection is UDP?"

The answer from several people was (paraphrasing): "So we can get UDP-based applications to work across firewalls, and have something that works as well as Skype or other p2p apps."

*That* is a slippery-slope.  Because using TCP/TLS TURN will NOT be sufficient to accomplish that goal.  Sending on port 80/443 will be necessary.  Implementing FEP (RFC3093) is probably ultimately necessary.  If one of the goals/requirements for TURN (and I have never actually seen any written goals/requirements for TURN) is "make applications of any type work across firewalls of any type", then to accomplish that goal it would have to specify more than just "use TCP".  And that is where the IETF would/should have concerns.  They should not be specifying FEP as anything but an April 1st RFC, imho.

That's not to say people don't/can't do that - we're only talking about what the IETF should officially advocate - not what people can do.

I'm not saying this means TCP/TLS use of TURN-udp should be removed.  Maybe it is the appropriate point of "firewall avoidance" we should get to.  I dunno.

-hadriel

---

From: Philip Matthews <[email-masked]>
Date: Wed, 2 Apr 2008 12:11:17 -0400

On Wed, 2-Apr-08, at 11:48 , Hadriel Kaplan wrote:
>   If one of the goals/requirements for TURN (and I have never  
> actually seen any written goals/requirements for TURN) is "make  
> applications of any type work across firewalls of any type", then to  
> accomplish that goal it would have to specify more than just "use  
> TCP".

The goal of TURN is to allow an client to work behind a NAT of any  
type (and specifically, behind NATs which are not BEHAVE-compliant)  
that implements only very simple filtering properties.  It is _NOT_ a  
goal to try to work around firewall policies.

In other words, if you go out a buy a NAT that is not have the  
Endpoint-Independent mapping property, then TURN should allow you to  
work through that NAT.

- Philip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 02 Apr 2008 09:27:13 -0700

Philip Matthews wrote:
> implementations. 

How a protocol can be proposed as a standard track RFC without
implementations is a mystery for me.  I know that it is mandatory to
have independent implementations only when a standard is promoted to
Draft Standard, but as nobody seems to worry to promote standards
anymore, I think that the burden of the two implementations should be
moved to the Proposed Standard.

Anyway even if everybody seems to have given up on TURN implementations,
I did not.  On request I can provide an access to our TURN servers
(turn-05 and rfc3489bis-15 currently, working on upgrading to turn-07).
 I can also provide a WIP patch for Wireshark.  We are also working on
implementing STUN and TURN in Zap[1], but it will take 2 or 3 more
months to release the code.

[1] http://www.croczilla.com/zap

> However, the authors are working hard to try to  

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 2 Apr 2008 12:41:36 -0400

> RTP/TCP.  For the former, it allows multiple RTP sessions (like
> audio+video) to run over a single TCP connection, or for example both RTP
> and RTCP over the single TURN-TCP connection, or MSRP file transfer and
> RTP over the same TURN-TCP connection, or Bitorrent and MP3 streams over
> the same connection, ad infinitum.  It is going
>

Nope - afaik, when you advertise multiple RFC4571 connections, each TCP connection handles exactly one RTP m-line stream, or one RTCP stream.  The mechanism follows Dr. Spengler's advice of "Don't cross the streams." :)

With TURN, one TURN TCP connection, from client to TURN server, can handle numerous peer UDP connections. (For TURN-TCP, it could handle numerous peer TCP connections, but I'll ignore TURN-tcp)  In other words, the relay address you give out in SDP may well be unique per stream, but the data for them all can come in and go out on one TCP connection between you and the relay.

> >  There are though issues that have nothing to do with firewall policies.
> Worse than UDP, TCP as a transport presents a number of issues with
> multiplexing different application streams in the same connection (e.g.,
> HOL blocking, congestion avoidance backoff, flow shaping or RED in
> routers).
> >
>

Nope, I'm talking draft-ietf-behave-turn, using TCP or TLS for the client-relay connection and UDP from relay to peers.

-hadriel

---

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

>  With TURN, one TURN TCP connection, from client to TURN server, can handle numerous peer UDP connections. (For TURN-TCP, it could handle numerous peer TCP connections, but I'll ignore TURN-tcp)  I…

I don't think that's true. One TCP connection between client and TURN
server can only be used to serve *exactly one* TURN allocation. But it
looks like this is not explicitly mentioned in the draft, the closest
thing that I can find that implies this is from this text in page 8:

      While the terminology used in this document refers to 5-tuples,
      the TURN server can store whatever identifier it likes that yields
      identical results.  Specifically, many implementations use a file-
      descriptor in place of a 5-tuple to represent a TCP connection.

The last sentence that says a (TCP) file descriptor may be used in
place of 5-tuple implies that a TCP client connection can only be used
to serve one allocation, since the 5-tuple uniquely identifies an
Allocation in the server.

Cheers
 Benny

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 2 Apr 2008 13:26:47 -0400

> From: Philip Matthews [mailto:[email-masked]]
> Sent: Wednesday, April 02, 2008 11:26 AM
>
> back ICE from publication as an RFC.

Whoah.  Why is draft-ietf-behave-turn delaying ICE???  I mean I see it in the normative section, and I see it riddled throughout the ICE doc.  Hmm.  Too bad ICE wasn't written to describe just using a relayed address gotten through some relay means, a possible one being TURN, and leave it at that. :(

Ugh.  This is not good.

-hadriel

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 02 Apr 2008 11:29:40 -0700

Pål-Erik Martinsen wrote:
> inline
> 
> 
> Marc Petit-Huguenin wrote:
> 
>> Philip Matthews wrote:
>>   
> I have not given up!
> Just finished a TURN-07 client implementation.
> 
> I have not implemented the REQUESTED-PROPS attribute. Further down the
> road ICE will need explicit rtcp-port signalling in the SDP anyway.

Isn't what RFC 3605 do?

> 
> I would be very interested in the Wireshark patch. Getting tired of just
> seeing STUN2 packets with unknown attributes.

Sent in private email.

> 
> Please let me know when your servers are upgraded to 07. I would love to
> do a quick test.
>

---

From: Philip Matthews <[email-masked]>
Date: Wed, 2 Apr 2008 16:32:22 -0400

On Wed, 2-Apr-08, at 13:25 , Benny Prijono wrote:
>> Nope - afaik, when you advertise multiple RFC4571 connections, each  
>> TCP connection handles exactly one RTP m-line stream, or one RTCP  
>> stream.  The mechanism follows Dr. Spengler's advice of "Don't  
>> cross the streams." :)
>>
>> With TURN, one TURN TCP connection, from client to TURN server, can  
>> handle numerous peer UDP connections. (For TURN-TCP, it could  
>> handle numerous peer TCP connections, but I'll ignore TURN-tcp)  In  
>> other words, the relay address you give out in SDP may well be  
>> unique per stream, but the data for them all can come in and go out  
>> on one TCP connection between you and the relay.
>>
>>
>

An allocation is uniquely identified by the 5-tuple (source IP  
address, source port, dest IP address, dest port, protocol) of the  
connection between the client and the server. Thus a TCP connection  
between the client and the server can only be used for one allocation.

However, multiple peers can talk to the client over that allocation,  
where "peer" is a unique (IP address, port) combination.

Thus it would be possible for a client to put the same relayed  
transport address for multiple streams in the SDP, provided the client  
could figure out what to send to each of the remote (IP address, port)  
combinations.

- Philip

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 3 Apr 2008 07:22:10 +0300

Le Wednesday 02 April 2008 18:18:29 ext Hadriel Kaplan, vous avez écrit :
> I *never* said I don't care if TWIST is implementable in a client.  I said
> I don't care *how* it works in a client - i.e., I don't personally care
> about the implementation details of shims vs. stacks vs. whatever.  I most
> certainly *do* care that clients be able to implement it, and obviously the
> more easily/simpler the better.

I understand.

But I am concerned that TWIST would become to TURN, what IPsec has become to 
TLS. Both are "implementable" and provide the same feature (relaying resp. 
authentication+confidentiality). But one is difficult for software vendors to 
integrate due to not stacking up nicely with the existing APIs, while the 
other one is easy.

Guess which one is being used...

I think we need to make a tradeoff, or better yet, try to make the protocol 
simple and scalable on both sides. That's one of the reason I like the N:N 
idea for TCP relaying.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 3 Apr 2008 07:23:59 +0300

Le Wednesday 02 April 2008 20:26:47 ext Hadriel Kaplan, vous avez écrit :
> Whoah.  Why is draft-ietf-behave-turn delaying ICE???  I mean I see it in
> the normative section, and I see it riddled throughout the ICE doc.  Hmm. 
> Too bad ICE wasn't written to describe just using a relayed address gotten
> through some relay means, a possible one being TURN, and leave it at that.
> :(

I had been complaining about this a while ago.

The answer was that there needs to be at least one normative relay protocol 
for the "relay" candidates to make sense (not_ that I was convinced by this 
argument).

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 3 Apr 2008 00:58:57 -0400

> From: Rémi Denis-Courmont [mailto:[email-masked]]
>

Ummm... BOTH!?!  They have different market use cases, and both are WILDLY successful.  Are you claiming IPSEC is not???  (and we're talking here VPN technologies I assume, not HTTP/application protection technologies, for which IPSEC does not even apply usually)

As an aside, do you ever wonder why 3GPP is so fixated on IPSEC as its favorite encryption mechanism, even for SIP?  Hint: It's not because they don't know about TLS, or think it's easy for the client, afaik.

-hadriel

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 3 Apr 2008 08:10:29 +0300

Le Thursday 03 April 2008 07:58:57 ext Hadriel Kaplan, vous avez écrit :
> As an aside, do you ever wonder why 3GPP is so fixated on IPSEC as its
> favorite encryption mechanism, even for SIP?  Hint: It's not because they
> don't know about TLS, or think it's easy for the client, afaik.

Because they hold for a fact that TCP does not scale, so they have to use UDP, 
so no TLS.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 3 Apr 2008 01:13:21 -0400

> Because they hold for a fact that TCP does not scale, so they have to use

Yup.

-hadriel

---

From: Pål-Erik Martinsen <[email-masked]>
Date: Thu, 03 Apr 2008 12:06:54 +0200

[snip]

>> road ICE will need explicit rtcp-port signalling in the SDP anyway.
Yes, you are right.  So to be more precise; I did not consider
supporting a call from my endpoint through a TURN relay to an endpoint
on a public IP not supporting RFC3605 as something I need to support in
my first release. If it turn out otherwise I will add it.

.-.
Pål-Erik