Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

From: Oleg Moskalenko <[email-masked]>
Date: Sun, 1 Feb 2015 00:07:37 -0800

I found another thing. In the section 7.1, the turnbis document is saying
that:

"The client MUST NOT include any REQUESTED-ADDRESS-FAMILY attribute in
its Refresh Request."

But in the next section, 7.2, there is a paragraph that discusses the
server behaviour when it receives the REQUESTED-ADDRESS-FAMILY attribute in
the REFRESH request. I guess that paragraph slipped into turnbis from SSODA
draft and if has to be removed.

Thanks
Oleg

On Sat, Jan 31, 2015 at 11:07 PM, Oleg Moskalenko <[email-masked]>
wrote:

> Tiru, I do not see any problem with EVEN-PORT when its value is 0. The
> problem only arises when EVEN-PORT is equals 0x80 (reserved allocation
> required). So I'd suggest for forbid only the situation when the highest
> bit of EVEN-PORT is 1.
>
> Thanks
> Oleg
>
> On Sat, Jan 31, 2015 at 6:36 PM, Tirumaleswar Reddy (tireddy) <
> [email-masked]> wrote:
>
>>    *From:* Oleg Moskalenko [mailto:[email-masked]]
>> *Sent:* Sunday, February 01, 2015 4:40 AM
>> *To:* Tirumaleswar Reddy (tireddy)
>> *Cc:* [email-masked]
>> *Subject:* Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt
>>
>>
>>
>> Hi Tiru
>>
>> as the turnbis written, in its current form, it allows EVEN-PORT
>> attribute in the ALLOCATE request together with the
>> ADDITIONAL-ADDRESS-FAMILY attribute. If this is really what you want, then
>> the RESERVATION-TOKEN handling must be changed in the ALLOCATE response -
>> because there will be two RESERVATION-TOKEN attributes included into the
>> response (when EVEN-PORT=1).
>>
>> Or the EVEN-PORT must be prohibited in the same request with
>> ADDITIONAL-ADDRESS-FAMILY.
>>
>> As of now, there is inherent inconsistency.
>>
>> [TR] Agreed, will update the draft that AAF must not be used with even
>> port.
>>
>> -Tiru
>>
>> Thanks
>> Oleg
>>
>>
>>
>>
>>
>> On Thu, Jan 29, 2015 at 9:39 PM, Tirumaleswar Reddy (tireddy) <
>> [email-masked]> wrote:
>>
>> Major changes in this revision are support for SSODA and merged RFC6156.
>> Please review and provide your valuable comments.
>> Diff from previous version :
>> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tram-turnbis-01.txt
>>
>> -Tiru
>>
>>
>> > -----Original Message-----
>> > From: tram [mailto:[email-masked]] On Behalf Of internet-
>> > [email-masked]
>> > Sent: Friday, January 30, 2015 10:48 AM
>> > To: [email-masked]
>> > Cc: [email-masked]
>> > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt
>> >
>> >
>> > A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> >  This draft is a work item of the TURN Revised and Modernized Working
>> > Group of the IETF.
>> >
>> >         Title           : Traversal Using Relays around NAT (TURN):
>> Relay Extensions
>> > to Session Traversal Utilities for NAT (STUN)
>> >         Authors         : Tirumaleswar Reddy
>> >                           Alan Johnston
>> >                           Philip Matthews
>> >                           Jonathan Rosenberg
>> >       Filename        : draft-ietf-tram-turnbis-01.txt
>> >       Pages           : 77
>> >       Date            : 2015-01-29
>> >
>> > Abstract:
>> >    If a host is located behind a NAT, then in certain situations it can
>> >    be impossible for that host to communicate directly with other hosts
>> >    (peers).  In these situations, it is necessary for the host to use
>> >    the services of an intermediate node that acts as a communication
>> >    relay.  This specification defines a protocol, called TURN (Traversal
>> >    Using Relays around NAT), that allows the host to control the
>> >    operation of the relay and to exchange packets with its peers using
>> >    the relay.  TURN differs from some other relay control protocols in
>> >    that it allows a client to communicate with multiple peers using a
>> >    single relay address.
>> >
>> >    The TURN protocol was designed to be used as part of the ICE
>> >    (Interactive Connectivity Establishment) approach to NAT traversal,
>> >    though it also can be used without ICE.
>> >
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/
>> >
>> > There's also a htmlized version available at:
>> > http://tools.ietf.org/html/draft-ietf-tram-turnbis-01
>> >
>> > A diff from the previous version is available at:
>> > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-01
>> >
>> >
>> > Please note that it may take a couple of minutes from the time of
>> submission
>> > until the htmlized version and diff are available at tools.ietf.org.
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/
>> >
>> > _______________________________________________
>> > tram mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/tram
>>
>> _______________________________________________
>> tram mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tram
>>
>>
>>
>
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 1 Feb 2015 15:27:27 +0000

From: Oleg Moskalenko [mailto:[email-masked]]
Sent: Sunday, February 01, 2015 1:38 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

I found another thing. In the section 7.1, the turnbis document is saying that:

"The client MUST NOT include any REQUESTED-ADDRESS-FAMILY attribute in its Refresh Request."
But in the next section, 7.2, there is a paragraph that discusses the server behaviour when it receives the REQUESTED-ADDRESS-FAMILY attribute in the REFRESH request. I guess that paragraph slipped into turnbis from SSODA draft and if has to be removed.
[TR] The paragraph was picked from RFC 6156; Section 5.1 says client MUST not include any RAF attribute in its Refresh request and section 5.2 discusses the server behavior when it receives RAF
5.2<http://tools.ietf.org/html/rfc6156#section-5.2>.  Receiving a Refresh Request
   If a server receives a Refresh Request with a REQUESTED-ADDRESS-
   FAMILY attribute, and the attribute's value doesn't match the address
   family of the allocation, the server MUST reply with a 443 (Peer
   Address Family Mismatch) Refresh error response.

-Tiru

-Tiru
Thanks
Oleg

On Sat, Jan 31, 2015 at 11:07 PM, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:
Tiru, I do not see any problem with EVEN-PORT when its value is 0. The problem only arises when EVEN-PORT is equals 0x80 (reserved allocation required). So I'd suggest for forbid only the situation when the highest bit of EVEN-PORT is 1.
Thanks
Oleg

On Sat, Jan 31, 2015 at 6:36 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
From: Oleg Moskalenko [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, February 01, 2015 4:40 AM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

Hi Tiru
as the turnbis written, in its current form, it allows EVEN-PORT attribute in the ALLOCATE request together with the ADDITIONAL-ADDRESS-FAMILY attribute. If this is really what you want, then the RESERVATION-TOKEN handling must be changed in the ALLOCATE response - because there will be two RESERVATION-TOKEN attributes included into the response (when EVEN-PORT=1).
Or the EVEN-PORT must be prohibited in the same request with ADDITIONAL-ADDRESS-FAMILY.
As of now, there is inherent inconsistency.
[TR] Agreed, will update the draft that AAF must not be used with even port.
-Tiru
Thanks
Oleg

On Thu, Jan 29, 2015 at 9:39 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Major changes in this revision are support for SSODA and merged RFC6156. Please review and provide your valuable comments.
Diff from previous version : http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tram-turnbis-01.txt

-Tiru

> From: tram [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of internet-
> [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>         Title           : Traversal Using Relays around NAT (TURN): Relay Extensions
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 1 Feb 2015 15:43:50 +0000

From: Oleg Moskalenko [mailto:[email-masked]]
Sent: Sunday, February 01, 2015 12:37 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

[TR] Updated draft.
-Tiru
Thanks
Oleg

Hi Tiru

-Tiru

---

From: Oleg Moskalenko <[email-masked]>
Date: Sun, 1 Feb 2015 11:07:27 -0800

On Sun, Feb 1, 2015 at 7:27 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> *Sent:* Sunday, February 01, 2015 1:38 PM
> [TR] The paragraph was picked from RFC 6156; Section 5.1 says client MUST
> not include any RAF attribute in its Refresh request and section 5.2
> discusses the server behavior when it receives RAF
>
> *5.2* <http://tools.ietf.org/html/rfc6156#section-5.2>*.  Receiving a
> Refresh Request*
>

Tiru, I got that. But could you please explain why it is written that way ?
As it is now, I see two points:

1) The legacy RFC 6156-compliant clients are not turnbis-compliant -
because they include RAF into REFRESH;
2) The legacy RFC 6156-compliant clients are compatible with the new
turnbis-servers - because the turnbis-servers know how to handle RAF in
REFRESH.

Was that what you were trying to achieve ?

Thanks
Oleg

> as the turnbis written, in its current form, it allows EVEN-PORT attribute
> in the ALLOCATE request together with the ADDITIONAL-ADDRESS-FAMILY
> attribute. If this is really what you want, then the RESERVATION-TOKEN
> handling must be changed in the ALLOCATE response - because there will be
> two RESERVATION-TOKEN attributes included into the response (when
> EVEN-PORT=1).
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 2 Feb 2015 02:50:28 +0000

Inline [TR2]

From: Oleg Moskalenko [mailto:[email-masked]]
Sent: Monday, February 02, 2015 12:37 AM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

On Sun, Feb 1, 2015 at 7:27 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

Tiru, I got that. But could you please explain why it is written that way ?
[TR2] I don’t know why it is written like that ?
Simon/Gonzalo -  Can you please clarify the reasoning for Section 5.2
As it is now, I see two points:
1) The legacy RFC 6156-compliant clients are not turnbis-compliant - because they include RAF into REFRESH;
2) The legacy RFC 6156-compliant clients are compatible with the new turnbis-servers - because the turnbis-servers know how to handle RAF in REFRESH.
Was that what you were trying to achieve ?

[TR2 Point 2 (We cannot proceed with point 1 because it will break backward compatibility)

-Tiru

Thanks
Oleg

Hi Tiru

-Tiru

---

From: Oleg Moskalenko <[email-masked]>
Date: Sun, 1 Feb 2015 20:19:41 -0800

> [TR2 Point 2 (We cannot proceed with point 1 because it will break

I understand that. But I do not understand why the section 7.1 says that
the clients MUST not include RAF into REFRESH; but the section 7.2
describes what server has to do if it does receive RAF in the REFRESH
request. What was the reasoning for that ? The same wording can be found in
RFC 6156.

So, the section 7.1 contradicts the section 7.2. I still cannot understand
why the current wording is chosen.

Thanks
Oleg

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 2 Feb 2015 05:14:38 +0000

Inline [TR3]

From: Oleg Moskalenko [mailto:[email-masked]]
Sent: Monday, February 02, 2015 9:50 AM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

I understand that. But I do not understand why the section 7.1 says that the clients MUST not include RAF into REFRESH; but the section 7.2 describes what server has to do if it does receive RAF in the REFRESH request. What was the reasoning for that ? The same wording can be found in RFC 6156.
So, the section 7.1 contradicts the section 7.2. I still cannot understand why the current wording is chosen.
[TR3] Yes, I agree that the contradictory text in section 7.2 should be removed. But let’s hear from the authors of RFC 6156, they might had some valid reason for this behavior.
-Tiru
Thanks
Oleg

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 2 Feb 2015 08:28:20 -0800

The process of proof-reading the draft involved actual implementation:

https://code.google.com/p/coturn/wiki/Downloads

For experimental implementation, I used new attribute types 0x8032 and
0x8033 (for ADDITIONAL-ADDRESS-FAMILY and ADDRESS-ERROR-CODE). That will be
changed when IANA assigns actual numbers

Oleg

On Sun, Feb 1, 2015 at 9:14 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> *Sent:* Monday, February 02, 2015 9:50 AM
> [TR3] Yes, I agree that the contradictory text in section 7.2 should be
> removed. But let’s hear from the authors of RFC 6156, they might had some
> valid reason for this behavior.
>
> -Tiru
>
> Thanks
> Oleg
>
>
>
>
>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 2 Feb 2015 19:26:59 -0500

> Simon/Gonzalo -  Can you please clarify the reasoning for Section 5.2
Yeah it looks strange, but all of it is correct. That is, RAF is not
present in Refresh requests. I don't remember why we specified server
behaviour for invalid Refresh requests. Feel free to remove that in turnbis.

Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 3 Feb 2015 03:06:44 +0000

From: Simon Perreault [mailto:[email-masked]]
Sent: Tuesday, February 03, 2015 5:57 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Oleg Moskalenko; [email-masked]
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

On Sun, Feb 1, 2015 at 9:50 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
I found another thing. In the section 7.1, the turnbis document is saying that:

Tiru, I got that. But could you please explain why it is written that way ?
[TR2] I don’t know why it is written like that ?
Simon/Gonzalo -  Can you please clarify the reasoning for Section 5.2
Yeah it looks strange, but all of it is correct. That is, RAF is not present in Refresh requests. I don't remember why we specified server behaviour for invalid Refresh requests. Feel free to remove that in turnbis.

[TR] Done.

-Tiru

Simon

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 3 Feb 2015 16:18:34 +0800

Hi, Reddy,

I have some comments to the current version of turn-bis:
1. About Transport protocol
"Section 2.1 Transports" describe the reason that use different transport
protocol between TURN Client/TURN Server and TURN Server/Peer. But from the
viewpoint of application, it is very strange that one client use TCP to
transport data and the other end use UDP to transport. The common way is the
two peers will select the same protocol to transport data. So, I think it is
better to use the same protocol between the two legs(TURN Client/TURN Server
and TURN Server/Peer). Then the table in section 2.1 should be changed.

2. About EDM NAT transversal between TURN server and peer
"Section 2.4 Send Mechanism" describes as below:
" When using the Send mechanism, the client sends a Send indication to
   the TURN server containing (a) an XOR-PEER-ADDRESS attribute
   specifying the (server-reflexive) transport address of the peer and
   (b) a DATA attribute holding the application data.  When the TURN
   server receives the Send indication, it extracts the application data
   from the DATA attribute and sends it in a UDP datagram to the peer,
   using the allocated relay address as the source address.  Note that
   there is no need to specify the relayed transport address, since it
   is implied by the 5-tuple used for the Send indication.
 "
If there is one EDM NAT between TURN server and the peer, then the UDP
datagram can't pass through it, because the peer did not send packet to the
client's relay address before. Here we should add some descriptions about
how to meet such environments.

3. Relay between multiple TURN Server
As we described in the mail list previously and as proposed by Brandon, I
think we should include the scenarios that encompass two TURN Servers
between the client and peer. This scenario need not be very detail, but
should clarify some key points that different from the one TURN server
scenario. Such as which transport method will be used between the
client/TURN Server 1; TURN Server 1/TURN Server 2; TURN Server2/peer; how to
install the permission on different TURN servers and how the client know the
TURN Server 2's address that the peer selects etc. 

Aijun Wang
Best Regards.

> From: tram [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, January 30, 2015 1:18 PM
directories.
>  This draft is a work item of the TURN Revised and Modernized Working
Group
> of the IETF.
> 
>         Title           : Traversal Using Relays around NAT (TURN): Relay
> Extensions to Session Traversal Utilities for NAT (STUN)
submission

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 3 Feb 2015 00:50:50 -0800

> and TURN Server/Peer). Then the table in section 2.1 should be changed.

I do not see any justification for this claim. This is how TURN always has
been working, and it's been working just fine. We do not want to tie the
protocols of different clients. Each client is free to use whatever
protocol it wants and finds appropriate in the client's particular network
conditions.

> how to meet such environments.

The peer and the TURN server are supposed to be reachable both ways. If
that is not the case, then the 'peer' has to be a TURN client.

> TURN Server 2's address that the peer selects etc.

I do not see any sense in that clarification. The scheme is trivial. The
use case of single TURN server is trivially scaled to whatever number of
TURN servers you have. That's only about layers of the TURN protocol.

Regards,
Oleg

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 4 Feb 2015 10:41:20 +0800

From: Oleg Moskalenko [mailto:[email-masked]] 
Sent: Tuesday, February 03, 2015 4:51 PM
To: Aijun Wang
Cc: Tirumaleswar Reddy (tireddy); Brandon Williams; [email-masked]
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

On Tue, Feb 3, 2015 at 12:18 AM, Aijun Wang <[email-masked]> wrote:

Hi, Reddy,

I do not see any justification for this claim. This is how TURN always has been working, and it's been working just fine. We do not want to tie the protocols of different clients. Each client is free to use whatever protocol it wants and finds appropriate in the client's particular network conditions.

[Aijun Wang]: TURN acts just like one middleware component and should be called by the application layer. Application will select TCP  if they want the transport layer to assure the data transfer reliability (for example in file sharing scenario) and will select UDP if they want to eliminate the transfer delay(for example in video transfer scenario). Can you give one example that the application wants part of TCP and part of UDP to transfer data?

 

The peer and the TURN server are supposed to be reachable both ways. If that is not the case, then the 'peer' has to be a TURN client.

[Aijun Wang]: where is the assumption in current draft? In Figure 1 of current draft, the peer is located behind one NAT device. So your suppose(“… be reachable both ways…”) is not always true. Even in [RFC6062], there exists the following description(section 3, Overview of Operation ): 
 
“If a client wishes to establish a TCP connection to a peer from that

   relayed transport address, it issues a Connect request to the TURN

   server over the control connection.  That request contains an XOR-

   PEER-ADDRESS attribute identifying the peer IP address and port

   (i.e., its "transport address") to which a connection is to be made.

   The TURN server attempts to open the TCP connection, and assuming it

   succeeds, then responds to the Connect request with a success

   response.  The server also creates a connection identifier associated

   with this connection and passes that connection identifier back to

   the client in the success response.  Note that a maximum of one

   connection to a given peer transport address can be established per

   allocation.

      Note: Establishing a relayed connection from the client to a peer

      is done in two steps.  First, the allocation is created, and

      second, the connection is established.  Combining the two is not

      desirable for NAT traversal.  It is expected that, between the

      first and second steps, the client will communicate off-band with

      the peer (e.g., using ICE [RFC5245]) and tell it the relayed

      transport address that the TURN server allocated and from which it

      is about to initiate a connection.  The peer can then "get ready":

      open holes in its firewall, try to poke holes in a NAT, attempt a

      TCP simultaneous open, etc.

”

So,  this is also one evidence that your assumption is not always true. For UDP transport, current TURN solution must also consider the involve of other methods to let the data from TURN server pass the NAT to the peer. Is this true?

I do not see any sense in that clarification. The scheme is trivial. The use case of single TURN server is trivially scaled to whatever number of TURN servers you have. That's only about layers of the TURN protocol.

[Aijun Wang]: Current TURN solution can’t assure the communication peers select the same TURN Server, so this will be very common phenomena when you deploy the TURN servers in distributed manner. And it is not as simple as your image of easy scaling. We have discussed this in the mail list before and it is not easy to illustrate. Can you simplify the solution that based on the below graph:

A------NAT-1(EDM)-----------TURN Server 1-----------------------TURN Server-2----------------------NAT-2(EDM)---------------------------B

                                            |

                                            |

                                            |----------------------------------------------------------------------------------------NAT-3(EDM)----------------------------C

Regards,
Oleg

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 3 Feb 2015 19:11:26 -0800

Aijun, actually all answers to your questions are in RFC 5766. Sorry but I
have a feeling that you did noy read it. TURN is not what you think it is.
There is no point going into fine details while the whole picture is not
clear to you.

Regards,
Oleg
On Feb 3, 2015 6:41 PM, "Aijun Wang" <[email-masked]> wrote:

> *Sent:* Tuesday, February 03, 2015 4:51 PM
> *To:* Aijun Wang
> *Cc:* Tirumaleswar Reddy (tireddy); Brandon Williams; [email-masked]
> [Aijun Wang]: TURN acts just like one middleware component and should be
> called by the application layer. Application will select TCP  if they want
> the transport layer to assure the data transfer reliability (for example in
> file sharing scenario) and will select UDP if they want to eliminate the
> transfer delay(for example in video transfer scenario). Can you give one
> example that the application wants part of TCP and part of UDP to transfer
> data?
>
>
>    The TURN server attempts to open the TCP connection, and *assuming it*
>
> *   succeeds*, then responds to the Connect request with a success
>
>       desirable for NAT traversal.  It is expected that, *between the*
>
> *      first and second steps,* the client will communicate off-band with
>
> So,  this is also one evidence that your assumption is not always true.
> For UDP transport, current TURN solution must also consider the involve of
> other methods to let the data from TURN server pass the NAT to the peer. Is
> this true?
>
>
> [Aijun Wang]: Current TURN solution can’t assure the communication peers
> select the same TURN Server, so this will be very common phenomena when you
> deploy the TURN servers in distributed manner. And it is not as simple as
> your image of easy scaling. We have discussed this in the mail list before
> and it is not easy to illustrate. Can you simplify the solution that based
> on the below graph:
>
>
>
> A------NAT-1(EDM)-----------TURN Server 1-----------------------TURN
> Server-2----------------------NAT-2(EDM)---------------------------B
>
>                                             |
>
>                                             |
>
>

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 4 Feb 2015 11:38:13 +0800

Hi, Oleg,

“draft-ietf-tram-turnbis-01.txt” is the update version of RFC 5766,  and there is no clear description for these scenarios in both documents. 

Can you first answer the questions that I mentioned in these e-mails, based on the contents of the related RFCs? 

Best Regards. 

From: tram [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
Sent: Wednesday, February 04, 2015 11:11 AM
To: Aijun Wang
Cc: [email-masked]; Tirumaleswar Reddy (tireddy); Brandon Williams
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

Aijun, actually all answers to your questions are in RFC 5766. Sorry but I have a feeling that you did noy read it. TURN is not what you think it is. There is no point going into fine details while the whole picture is not clear to you.

Regards,
Oleg

 

Hi, Reddy,

 

 

 

   allocation.

”

                                            |

                                            |

 

Regards,
Oleg

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 4 Feb 2015 10:18:38 +0000

> On 04 Feb 2015, at 03:41, Aijun Wang <[email-masked]> wrote:
> 
>  

Local firewall traversal!

Very convenient to have TCP/TLS between you and your TURN server to get through stubborn firewalls. Likewise it is very convenient to still be able to talk to the remote host on UDP. The remote host can be a RFLX address of an ICE agent, a legacy SIP endpoint with a reachable IP and so on. 

> [Aijun Wang]: where is the assumption in current draft? In Figure 1 of current draft, the peer is located behind one NAT device. So your suppose(“… be reachable both ways…”) is not always true. Eve…

I think it is pretty clear from the Introduction:

"When a direct communication path cannot be found, it is necessary to
 use the services of an intermediate host that acts as a relay for the
 packets.  This relay typically sits in the public Internet and relays
 packets between two hosts that both sit behind NATs.”

Or is it the above text that causes confusion? I think it could be a bit more explicit in that it is not necsessary for both client to allocate their RELAY address on the same TURN server. But that is fairly good explained later.

In the operation section it also states:
"In a typical configuration, a TURN client is connected to a private
   network [RFC1918] and through one or more NATs to the public
   Internet.  On the public Internet is a TURN server.  Elsewhere in the
   Internet are one or more peers with which the TURN client wishes to
   communicate.  These peers may or may not be behind one or more NATs.
   The client uses the server as a relay to send packets to these peers
   and to receive packets from these peers.
“

I do not see how the above text can be misunderstood. 

> So,  this is also one evidence that your assumption is not always true. For UDP transport, current TURN solution must also consider the involve of other methods to let the data from TURN server pas…

I think you should follow the advice from the Introduction:
"TURN was designed as one piece in the larger ICE approach to NAT
 traversal.  Implementors of TURN are urged to investigate ICE and
 seriously consider using it for their application.  However, it is
 possible to use TURN without ICE.”

It is possible to deploy TURN servers in a way that would not work. This is because the specs was written in a non limiting way to allow for what ever deployment scenarios that might be useful to different implementors. But I think it is also described how to deploy it in a way that actually works.

>                                             |————————————————————————————————————————————NAT-3(EDM)----------------------------C

Relaying between several TURN servers should not be a part of the TURN RFC. How to install permissions and so on is described in the ICE RFC.

To summarise. Each agent has a responsibility to get through their own NAT. If it is a restrictive one it should use TURN to get through it. What the remote side is doing to get through his or her NAT is not your problem.

.-.
Pål-Erik

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 5 Feb 2015 14:51:04 +0800

> "Section 2.1 Transports" describe the reason that use different 
> transport protocol between TURN Client/TURN Server and TURN
> Very convenient to have TCP/TLS between you and your TURN server to get
> through stubborn firewalls. Likewise it is very convenient to still be able to talk
> to the remote host on UDP. The remote host can be a RFLX address of an ICE
> agent, a legacy SIP endpoint with a reachable IP and so on.
> 

TURN and ICE are mainly dealing with the communication between two hosts. Before their communication, normally they will agree with which transport protocol will be used. For the scenarios that you mentioned here(it is also mentioned in the original draft),  the two peers should both select TCP as the transport protocol. If one leg(between client and TURN server) select the TCP and the other leg(between TURN server and the peer) select the UDP, then the application that builds on TURN will lose the advantage of the data reliability(can be assured by TCP) and data efficiency(can be reached by UDP) at the same time. Do you think this is a good design? 
My main point here is that although it is possible to use the different transport protocols for these two legs, there is no benefits to do so. 

> >>
> >> 2. About EDM NAT transversal between TURN server and peer "Section
> 

All these sections describes clearly only the applicable scope of TURN but not related to my concern. My concern is that how you assure the UDP packet from the TURN Server to pass through the EDM type NAT that located before the peer? 

> "TURN was designed as one piece in the larger ICE approach to NAT  traversal.
> Implementors of TURN are urged to investigate ICE and  seriously consider
> using it for their application.  However, it is  possible to use TURN without
> ICE.”
> 
> 
> It is possible to deploy TURN servers in a way that would not work. This is
> because the specs was written in a non limiting way to allow for what ever
> deployment scenarios that might be useful to different implementors. But I
> think it is also described how to deploy it in a way that actually works.

If this spec can't even fulfill the general communication scenarios, then its usage will be limited. From our test experiences, more and more EDM NAT are now deployed, but current spec focuses only one special scenarios.

> 
> >>
> >> 3. Relay between multiple TURN Server As we described in the mail
> 
> Relaying between several TURN servers should not be a part of the TURN RFC.
> How to install permissions and so on is described in the ICE RFC.

Then we developed another draft to meet the multiple TURN Servers scenarios? "Create Permission" section is included in this draft, ICE(RFC 5245) only deals with the connectivity check.

> 
> To summarise. Each agent has a responsibility to get through their own NAT. If
> it is a restrictive one it should use TURN to get through it. What the remote
> side is doing to get through his or her NAT is not your problem.
> 
So current TURN spec can't be used independently, there must exist other mechanisms to assure it work correctly. As that described in [RFC6062], that 

"....... It is expected that, between the
>       TCP simultaneous open, etc."

Can we design one new solution of TURN to cover all these incomplete solutions? It can cover almost all the problems(even the current hot topic ----"ip address privacy" ) that current TURN specs wants to solve, but in one simpler manner.

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 5 Feb 2015 09:44:13 +0000

Ok, I will try to explain. Would be nice if some others  on the list can verify what I say is correct.

On 05 Feb 2015, at 07:51, Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:

TURN and ICE are mainly dealing with the communication between two hosts.
Sort of. Any box that terminates media. It can be switched MCU or something not clearly defined as a client. The ICE term is agent.

Before their communication, normally they will agree with which transport protocol will be used.
No. The whole idea with ICE is to say to the remote agent all the different protocols and addresses you can receive media on. IPv4, IPv6, UDP, TCP, TLS, HOST, RFLX, RELAY and multihomed hosts makes this a nice list of possible combinations.

For the scenarios that you mentioned here(it is also mentioned in the original draft),  the two peers should both select TCP as the transport protocol. If one leg(between client and TURN server) select the TCP and the other leg(between TURN server and the peer) select the UDP, then the application that builds on TURN will lose the advantage of the data reliability(can be assured by TCP) and data efficiency(can be reached by UDP) at the same time. Do you think this is a good design?
My main point here is that although it is possible to use the different transport protocols for these two legs, there is no benefits to do so.

You are mixing up things.

If you have a protocol that requires TCP you will only use ICE TCP candidates. How to do this with TURN is described in https://tools.ietf.org/html/rfc6062. For ICE this is described in https://tools.ietf.org/html/rfc6544.

For protocols like RTP that with some modifications can be run over UDP and TCP the local agent can offer all the candidates test what works and then pick the best suited. For RTP UDP is the best choice. Using TCP only between agent and TURN server has a nice side effect of keeping the TCP path short and you do not need an additional framing protocol as TURN provides that. (As long as the public facing side is UDP towards the remote peer).

I think this is an excellent design. It gives agents the flexibility to choose and can provide interop with old systems.

And that is not the responsibility of the TURN server. The TURN server is there to help your agent get through your own firewall. What the remote side does to get through the firewall is not something you can fix. (Other than run ICE and hope that the remote side also do that)

RTCweb seems to work fine. Can you please explain how two agents running ICE and TURN fail to communicate?

Any data on how many calls fails?

Then we developed another draft to meet the multiple TURN Servers scenarios? “Create Permission" section is included in this draft, ICE(RFC 5245) only deals with the connectivity check.

I do not think there is a multiple TURN scenario. But please post a draft explaining the problem. But as friendly advice I would encourage you to circulate it a bit off list and try to get a feel of it before you post and ask for a presentation slot.

Can we design one new solution of TURN to cover all these incomplete solutions? It can cover almost all the problems(even the current hot topic ——“
ip address privacy" ) that current TURN specs wants to solve, but in one simpler manner.

Not sure what you want to achieve. It is important that TURN is not an open pinhole through the NAT/FW, thus it is important to have the permissions set correctly. Its primary use is to get bidirectional communication up and going, not to be a general firewall penetration proxy thing.

.-.
Pål-Erik

.-.
Pål-Erik

Regards,
Oleg

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 9 Feb 2015 09:54:03 +0800

Hi, Pal:

Sorry to reply you late. Here I have one question to ask, would you like to explain it then:

http://tools.ietf.org/html/draft-ietf-tram-turnbis-02#section-8  “Permissions” describes as bellowing:

“For each allocation, the server keeps a list of zero or more

   permissions.  Each permission consists of an IP address and an

   associated time-to-expiry.  While a permission exists, all peers

   using the IP address in the permission are allowed to send data to

   the client.”

Why doesn’t the permission consider the Port value of XOR-PEER-ADDRESS? When the CGN(Carrier Grade NAT) are deployed by the service provider, many hosts may share one public addresses. Then in such environment, the client is prone to be attacked by hosts that under the same CGN coverage? The TURN server will also relay many traffic that is not the client’s  desirable data.

Also in such situation, even with the cooperation of TURN and ICE, there will likely be failure for the communication between two hosts, lets’ consider the following diagram:

A---------EDM NAT 1-------------TURN Server--------EDM NAT 2(CGN)------------------------B

1. Let’s suppose A、B Send ICE packet to each other and punch hole in the EDM NAT 1 and EDM NAT 2(this process should be added in current draft http://tools.ietf.org/html/draft-ietf-tram-turnbis-02#section-10.2)

2. A send “SendIndicatiion” to TURN Server, TURN Server send UDP packet to B, using A’s Relay Address(RA) as the source address.

3. B will send response UDP packet to TURN Server，use RA as the destination address. When one EDM NAT lies between the TURN server and host B, TURN Server will see this response UDP packet come from one new reflex address(we call XB’), not the reflex address(we call XB) when B send binding request to TURN Server’s well-known address.

4. So, if the IP address portion of XB’ is same as that of XB, this packet will be relayed by TURN Server; if not, this packet will dropped by TURN Server. This will lead to the communication failure between A and B.

How do you think about this scenarios?

From: Pal Martinsen (palmarti) [mailto:[email-masked]] 
Sent: Thursday, February 05, 2015 5:44 PM
To: Aijun Wang
Cc: Oleg Moskalenko; Brandon Williams; Tirumaleswar Reddy (tireddy); [email-masked]
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 9 Feb 2015 08:58:11 +0000

On 09 Feb 2015, at 02:54, Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Pal:

Sorry to reply you late.

No such think as a late reply in IETF.. :-)

Here I have one question to ask, would you like to explain it then:

Why doesn’t the permission consider the Port value of XOR-PEER-ADDRESS?

I think the idea is to mimic how a “good NAT” would work.

This behaviour is needed for ICE to work. Typical you wold set permissions on you TURN server to allow traffic from the remote RFLX and RELAY addresses. Since the remote agent probably learnt his RFLX address when allocating a RELAY address on his TURN server, the connectivity checks reaching your TURN server might come from a different port on the remote side NAT then what he signalled as a RFLX candidate in the SDP.

Section 17.2 explains this a bit more. But some more text in TURNbis explaining that setting permissions with would break ICE might come in handy. Tiru, any thoughts?

When the CGN(Carrier Grade NAT) are deployed by the service provider, many hosts may share one public addresses. Then in such environment, the client is prone to be attacked by hosts that under the same CGN coverage? The TURN server will also relay many traffic that is not the client’s  desirable data.

I am not very familiar with how a CGN NAT would differ from a “normal” NAT in ICE/TURN scenarios. The answers below might reflect that.

Isn’t this described in RFC5245? This is how ICE does it RFLX to RFLX checks? Is the point that if two CGN NATs are involved ICE would always fail in the RFLX to RFLX scenario, and have to fall back to using TURN? (Again, I do not know how CGN NATS operate)

2. A send “SendIndicatiion” to TURN Server, TURN Server send UDP packet to B, using A’s Relay Address(RA) as the source address.
3. B will send response UDP packet to TURN Server，use RA as the destination address. When one EDM NAT lies between the TURN server and host B, TURN Server will see this response UDP packet come from one new reflex address(we call XB’), not the reflex address(we call XB) when B send binding request to TURN Server’s well-known address.
You are forgetting that as part of ICE B will also send a connectivity check towards RA. This should open up the pinhole in EDM NAT 2.

ICE will fix this. Remember A and B have exchanged all candidates and crated a similar checklist that will run simultaneously form both sides. Some packets will be blocked at the remote NAT, but they still have opened up a pinhole on the local NAT. So with some synchronisation and retransmits al the necessary ports will be opened up. In ICE there is also the concept of peer RFLX addresses that the agents learn when they do the connectivity checks. Understanding how those work is probably important to understand how ICE solves your above scenario. Also keep in mind that the connectivity checks also are “tunnelled” via the TURN server and appears to be sent by the RELAY address.

Or is your intention to fix up TURN so it is independent of ICE. In that case it would be interesting to hear more about your use case and motivation for doing that.

.-.
Pål-Erik

From: Pal Martinsen (palmarti) [mailto:[email-masked]]
Sent: Thursday, February 05, 2015 5:44 PM
To: Aijun Wang
Cc: Oleg Moskalenko; Brandon Williams; Tirumaleswar Reddy (tireddy); [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

---

From: Simon Perreault <[email-masked]>
Date: Mon, 9 Feb 2015 06:33:57 -0700

To expand upon Pal's excellent answers (you should be thankful for his
patience!)...

On Sun, Feb 8, 2015 at 6:54 PM, Aijun Wang <[email-masked]>
wrote:
> When the CGN(Carrier Grade NAT) are deployed by the service provider, many
> hosts may share one public addresses. Then in such environment, the client
> is prone to be attacked by hosts that under the same CGN coverage?
>

Correct.

> The TURN server will also relay many traffic that is not the client’s
>  desirable data.
>

Yes if the client is "under attack". No in normal circumstances.

Also in such situation, even with the cooperation of TURN and ICE, there
> will likely be failure for the communication between two hosts, lets’
> consider the following diagram:
>
> 2. A send “SendIndicatiion” to TURN Server, TURN Server send UDP packet to
> B, using A’s Relay Address(RA) as the source address.
>
> 3. B will send response UDP packet to TURN Server，use RA as the
> destination address. When one EDM NAT lies between the TURN server and host
> B, TURN Server will see this response UDP packet come from one new reflex
> address(we call XB’), not the reflex address(we call XB) when B send
> binding request to TURN Server’s well-known address.
>
4. So, if the IP address portion of XB’ is same as that of XB, this packet
> will be relayed by TURN Server; if not, this packet will dropped by TURN
> Server. This will lead to the communication failure between A and B.
>
>
>

It is well known that using a single TURN server may not always work for
NATs that have arbitrary IP address pooling behaviour (see REQ-2 in RFC
4787). In that case it is necessary that two TURN servers be used. This was
a deliberate design decision favouring simplicity over completeness.

Simon

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 11 Feb 2015 08:47:46 +0800

From: Simon Perreault [mailto:[email-masked]] 
Sent: Monday, February 09, 2015 9:34 PM
To: Aijun Wang
Cc: Pal Martinsen (palmarti); Oleg Moskalenko; Tirumaleswar Reddy (tireddy); Brandon Williams; [email-masked]
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

It is well known that using a single TURN server may not always work for NATs that have arbitrary IP address pooling behaviour (see REQ-2 in RFC 4787). In that case it is necessary that two TURN servers be used. This was a deliberate design decision favouring simplicity over completeness.

Then it is needed in the current turn-bis draft to cover this scenarios(can we named TURN2TURN?) and give the guidance procedures to overcome this problem.

Simon

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 11 Feb 2015 09:35:17 +0800

From: tram [mailto:[email-masked]] On Behalf Of Pal Martinsen (palmarti)
Sent: Monday, February 09, 2015 4:58 PM
To: Aijun Wang
Cc: Oleg Moskalenko; Brandon Williams; Tirumaleswar Reddy (tireddy); [email-masked]
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

[Aijun] The remote peer will always use one different port to connect the other side. Then current permission mechanism is somehow loose and can easily be bypassed. And on the other hand, if the remote peer is given one new RLFX address(ip address part is also different), then current permission mechanism will block the real data that came from the desired peer.

 

I am not very familiar with how a CGN NAT would differ from a “normal” NAT in ICE/TURN scenarios. The answers below might reflect that. 
[Aijun]  The CGN NATs are normally deployed at the exit of MAN(Metro Area Network) or located inside the BRAS device, all the hosts under one CGN NAT will share one public IP address pool, then these hosts are very likely be assigned one same IP address, but use different TCP/UDP port.

1. Let’s suppose A、B Send ICE packet to each other and punch hole in the EDM NAT 1 and EDM NAT 2(this process should be added in current draft  <http://tools.ietf.org/html/draft-ietf-tram-turnbis-02#section-10.2> http://tools.ietf.org/html/draft-ietf-tram-turnbis-02#section-10.2)

[Aijun]: This step is actually the process of ICE. For completeness, I think the turn-bis draft should mentioned it here, or else some TURN packet  can’t pass through the NAT devices. CGN NAT can operate in different mode, for example in “FullCone” mode, or in “Symmetric” mode. In the latter mode, it behaves like one EDM NAT.

[Aijun]: it is true, I had assumed this step will be completed in step1. The problem of step 2 is that B get one new RFLX address, XB’

[Aijun]: So this is more complicated. Normally, every peer will get its RFLX address via send STUN packet to the STUN server, and each peer will exchange its RFLX addresses to the peer via SDP offer/response. The RFLX address that gotten from the connectivity check is not authenticated, and can’t be trust and used as the peer RFLX.   

[Aijun]. Yeah, we are trying proposal one lightweight TURN solution in coming IETF meeting. We have submitted the first version to this WG and make a presentation in the Honolulu meeting.  Maybe we did not describe the solution very clearly in the first version, so did not get very encouraging feedback. We are trying to revise it now. 

Wish will get more help from your commends later then.  

.-.

Pål-Erik

---

From: Simon Perreault <[email-masked]>
Date: Wed, 11 Feb 2015 08:29:23 -0500

On Tue, Feb 10, 2015 at 7:47 PM, Aijun Wang <[email-masked]>
wrote:

> Then it is needed in the current turn-bis draft to cover this
> scenarios(can we named TURN2TURN?) and give the guidance procedures to
> overcome this problem.
>

1. Please send text!

2. Note that the protocols are not actually "missing" anything to cover
this scenario. Although I agree it would be nice to give an informative
example showing how things fall into place.

Simon