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

From: [email-masked]
Date: Sun, 18 Mar 2018 01:43:22 -0700

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 WG 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-15.txt
	Pages           : 84
	Date            : 2018-03-18

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.

   This document obsoletes RFC 5766 and RFC 6156.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tram-turnbis-15
https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-15

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/

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sun, 18 Mar 2018 08:50:41 +0000

This revision addresses comments from Mark, Karl and Noriyuki Torii.

-Tiru

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: Sunday, March 18, 2018 8:43 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [tram] I-D Action: draft-ietf-tram-turnbis-15.txt
> 
> 
>         Title           : Traversal Using Relays around NAT (TURN): Relay Extensions
> to Session Traversal Utilities for NAT (STUN)
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Noriyuki Torii <[email-masked]>
Date: Mon, 19 Mar 2018 09:59:28 +0900

Hi Tiru,

I checked updated I-D and found some more points in section 12 below.

>      0x4000 through 0x4FFF: These values are the allowed channel
>      numbers (16,384 possible values).
                ~~~~~~
This value also need to be amended to 4,096.

>      0x8000 through 0xFFFF: These values are reserved for future use.

This line can be removed now because the previous sentence imply it, too.

And also, I think it may be preferable if the following paragraph is updated
so as to alignment to RFC 7983.

>   Because of this division, ChannelData messages can be distinguished
>   from STUN-formatted messages (e.g., Allocate request, Send
>   indication, etc.) by examining the first two bits of the message:
>
>      0b00: STUN-formatted message (since the first two bits of a STUN-
>      formatted message are always zero).
>
>      0b01: ChannelData message (since the channel number is the first
>      field in the ChannelData message and channel numbers fall in the
>      range 0x4000 - 0x7FFF).
>
>      0b10: Reserved
>
>      0b11: Reserved
>
>   The reserved values may be used in the future to extend the range of
>   channel numbers.  Thus, an implementation MUST NOT assume that a TURN
>   message always starts with a 0 bit.

I guess it could be

    According to RFC 7983, ChannelData messages can be distinguished
    from other multiplexed protocols by examining the first byte of the
    message:

          [0..3]  STUN
        [16..19]  ZRTP
        [20..63]  DTLS
        [64..79]  TURN Channel
      [128..191]  RTP/RTCP
          others  reserved, MUST be dropped and an alert MAY be logged

    Reserved values may be used in the future by other protocols.
    Thus, an implementation MUST comply the discrimination above.

Finally, in section 18, the example Refresh request in the diagram of the
page 67 doesn't have the PASSWORD-ALGORITHMS attribute nevertheless
it has the PASSWORD-ALGORITHM attributes, also need to be fixed.

Regards,
Noriyuki Torii

----------------

---

From: "Karl Stahl" <[email-masked]>
Date: Tue, 20 Mar 2018 20:55:15 +0100

> This revision addresses comments from Mark, Karl and Noriyuki Torii.
My comment about need for multiple allocations is NOT addressed.

Let me explain more clearly why multiple allocations is needed:

ICE is about finding all/many paths for the media, e.g. with the help of
TURN servers.
Those paths are not over ONE IPv4 network, over ONE IPv6 network or EXACTLY
ONE OF EACH. 
If fact, it is more common that you have several IPv4 networks paths.

Now that we have network provided TURN servers, you only ask for Allocation
once (contrary to application provided TURN servers, where you can be
directed to Allocate several times.) and thus we need all relay addresses in
one allocation request.

Wasn't that the reason dual allocation was requested? The need for multiple
allocation is stronger!

Please address this, e.g. like below (seems you are almost there).

/Karl

******************* Previous *******************

Allowing a turn allocation to return multiple relayed transport addresses,
beyond ONE IPv4 and ONE IPv6 (which may sit on the same or on different
interfaces/network segments), seems like very small step now when the dual
allocation was put in place in this draft. We certainly need it (some
reasons below) if TURN is going to be used where needed and we cannot wait
for any additional draft.

Seems like it is sufficient to extent this table (found in draft 14) with 3
new values (as shown): 

16.  STUN Attributes

   This STUN extension defines the following attributes:

     0x000C: CHANNEL-NUMBER
     0x000D: LIFETIME
     0x0010: Reserved (was BANDWIDTH)
     0x0012: XOR-PEER-ADDRESS
     0x0013: DATA
     0x0016: XOR-RELAYED-ADDRESS
     0x0017: REQUESTED-ADDRESS-FAMILY
     0x0018: EVEN-PORT
     0x0019: REQUESTED-TRANSPORT
     0x001A: DONT-FRAGMENT
     0x0021: Reserved (was TIMER-VAL)
     0x0022: RESERVATION-TOKEN
     TBD-CA: ADDITIONAL-ADDRESS-FAMILY
ADDITIONAL-ADDRESS-ALL
ADDITIONAL-ADDRESS-ALLV4
ADDITIONAL-ADDRESS-ALLV6
     TBD-CA: ADDRESS-ERROR-CODE
     TBD-CA: ICMP

Actually, browsing through the draft for ADDITIONAL-ADDRESS-FAMILY, very
little text seems to be added for generalization to  ADDITIONAL-ADDRESS-xxx.
Almost everything applies to ADDITIONAL-ADDRESS-xxx and can be reused.

ADDITIONAL-ADDRESS-ALL should be the default for any modern TURN client. 

Check! - We need this now.

Thanks,
Karl

> From: Karl Stahl [mailto:[email-masked]]
> Sent: Sunday, March 4, 2018 10:36 PM
> To: 'Marc Petit-Huguenin' <[email-masked]>; Konda, Tirumaleswar Reddy
> <[email-masked]>; [email-masked]
> Subject: SV: [tram] Review of dual allocation in TURNbis-11
> 
> Hi,
> 
> When we now have "dual allocation" into this draft (I see on page 26: "If
the
> client wishes to obtain one IPv6 and one IPv4 relayed transport address
then
> it includes an ADDITIONAL-ADDRESS-FAMILY transport address then it") can
> we not generalize that further and allow MORE THAN ONE relayed transport
> address (of any family) in response to an allocation?
> 
> I mean that a TURN server could have several relay interfaces at different
IP-
> addresses into different networks - not just the Internet, but also a VoIP
> (higher quality) network e.g. by some triple play service provider, an IMS
> network or some branch office network.
> 
> I think this is specifically important for network provided/auto
discovered
> turn servers (application provided turn servers could instead just list
several
> turn servers).
> 
> I saw someone snipped this about "SINGLE relayed transport address per
> allocation request"
> > > https://tools.ietf.org/html/rfc6156#section-3
> > > <snip>
> > >
> > >    TURN servers allocate a single relayed transport address per
> > >    allocation request.  Therefore, Allocate requests cannot carry more
> > >    than one REQUESTED-ADDRESS-FAMILY attribute.  Consequently, a
> client
> > >    that wishes to allocate more than one relayed transport address at
a
> > >    TURN server (e.g., an IPv4 and an IPv6 address) needs to perform
> > >    several allocation requests (one allocation request per relayed
> > >    transport address).
> > > </snip>
> 
> but if that is remedied now, it seems like a small step to generalize so
we can
> get multiple relayed transport addresses from one allocate request?
> 
> /Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Konda, Tirumaleswar Reddy
Skickat: den 18 mars 2018 09:51
Till: [email-masked]
Ämne: Re: [tram] I-D Action: draft-ietf-tram-turnbis-15.txt

-Tiru

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 20 Mar 2018 21:34:53 +0100

> On 20 Mar 2018, at 20:55, Karl Stahl <[email-masked]> wrote:
> 

I agree with Karl here, for network-provided turn servers (which is not defined
in the terminology section here on in 8155) I think there are use cases for 
multiple addresses in multiple families. 

I also understand that this will make the draft more complex. Consider
the case where a turn server have two IPv4 networks and one IPv6
and have run out of possible allocations on one IPv4 network - should
it send what’s available or send an error message and fail completely?

Regardless, this is a good time to fix this.

/O

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 21 Mar 2018 15:23:01 +0000

> From: Olle E. Johansson [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2018 8:35 PM
> To: Karl Stahl <[email-masked]>
> Cc: Olle E Johansson <[email-masked]>; Konda, Tirumaleswar Reddy
> Subject: Re: Multiple allocations SV: [tram] I-D Action: draft-ietf-tram-turnbis-
> 15.txt
> 
> 
> > ICE is about finding all/many paths for the media, e.g. with the help
> > of TURN servers.
> > Those paths are not over ONE IPv4 network, over ONE IPv6 network or
> > EXACTLY ONE OF EACH.
> > Now that we have network provided TURN servers, you only ask for
> > Allocation once (contrary to application provided TURN servers, where
> > you can be directed to Allocate several times.) and thus we need all
> > relay addresses in one allocation request.
> 
> I agree with Karl here, for network-provided turn servers (which is not defined in
> the terminology section here on in 8155) I think there are use cases for multiple
> addresses in multiple families.

The WG has only agreed on dual allocation, this is a new requirement for a specific deployment scenario. 
You may want to submit a new draft (just like we did for RFC8155). 

-Tiru

> 
> I also understand that this will make the draft more complex. Consider the case
> where a turn server have two IPv4 networks and one IPv6 and have run out of
> possible allocations on one IPv4 network - should it send what’s available or
> send an error message and fail completely?
> 
> > Wasn't that the reason dual allocation was requested? The need for
> > multiple allocation is stronger!
> >
> > Allowing a turn allocation to return multiple relayed transport
> > addresses, beyond ONE IPv4 and ONE IPv6 (which may sit on the same or
> > on different interfaces/network segments), seems like very small step
> > now when the dual allocation was put in place in this draft. We
> > certainly need it (some reasons below) if TURN is going to be used
> > where needed and we cannot wait for any additional draft.
> >
> > Seems like it is sufficient to extent this table (found in draft 14)
> > with 3 new values (as shown):
> >
> > 16.  STUN Attributes
> >
> > Actually, browsing through the draft for ADDITIONAL-ADDRESS-FAMILY,
> > very little text seems to be added for generalization to  ADDITIONAL-
> ADDRESS-xxx.
> >> To: 'Marc Petit-Huguenin' <[email-masked]>; Konda, Tirumaleswar
> >> Reddy <[email-masked]>; [email-masked]
> >> it includes an ADDITIONAL-ADDRESS-FAMILY transport address then it")
> >> can we not generalize that further and allow MORE THAN ONE relayed
> >> transport address (of any family) in response to an allocation?
> >>
> >> addresses into different networks - not just the Internet, but also a
> >> VoIP (higher quality) network e.g. by some triple play service
> >> provider, an IMS network or some branch office network.
> >>
> >> I saw someone snipped this about "SINGLE relayed transport address
> >> per allocation request"

---

From: Brandon Williams <[email-masked]>
Date: Wed, 21 Mar 2018 13:05:57 -0400

+1

When Tiru indicated that he had covered Karl's comments, I believe that 
he meant the other comments that were not asking to increase the scope 
of the document.

I think there will be enough work in this area to define the rationale 
and protocol changes that it would be an equivalent level of effort to 
change turnbis at this point vs just working it with a new draft. For 
that reason, I prefer covering the gap with a new draft.

If this does go in to turnbis, we'll need WG consensus to expand scope.

Chairs, Any suggestions on approach?

---

From: Simon Perreault <[email-masked]>
Date: Wed, 21 Mar 2018 13:13:16 -0400

> Chairs, Any suggestions on approach?

The proposal on the table is for Karl+Olle to write their idea into a new
draft.

Karl+Olle, can you guys live with that?

Simon

---

From: "Martin Gartner" <[email-masked]>
Date: Wed, 21 Mar 2018 07:01:04 +0100

In my thinking, a TURN server is just a remote extension of the available 
interfaces which a client can use to try network connections by using ICE.
All client interfaces are used when trying to find the best network path 
with ICE, so it seems just logical to do the same for the TURN server, to 
use all of its interfaces when trying to find the best network path. And to 
make this possible, there must be a way to inform the client about more than 
one available relay address, if the network provided TURN server has access 
to more than one network path.
So it seems what Karl proposes is definitely needed.
Martin

-----Ursprungligt meddelande----- 
From: Karl Stahl
Sent: Tuesday, March 20, 2018 8:55 PM
To: 'Konda, Tirumaleswar Reddy' ; [email-masked]
Subject: Multiple allocations SV: [tram] I-D Action: 
draft-ietf-tram-turnbis-15.txt

/Karl

16.  STUN Attributes

     0x000C: CHANNEL-NUMBER
     0x000D: LIFETIME

Thanks,
Karl

the
then
IP-
discovered
several
a
we can

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Konda, Tirumaleswar Reddy
Skickat: den 18 mars 2018 09:51
Till: [email-masked]
Ämne: Re: [tram] I-D Action: draft-ietf-tram-turnbis-15.txt

-Tiru

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 22 Mar 2018 22:17:09 +0100

No and this draft cannot be approved without the generalization I have pointed out.

I really don’t understand why we are having this resistance.

Already the second paragraph of the Abstract states:

And further in 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.

I cannot imagine that there is some WG decision to hinder ICE usage for network provided TURN servers EXCEPT FOR EXACTLY BRANDON’S NETWORK. 

For now I refrain from writing/debating more – which would override the effort of what is required to generalize as asked. 

Please be happy that most of the dual allocation work done, can be reused to fulfill the generalization.

Tiru and Brandon are encouraged to read the TRAM charter … 

/Karl

Från: Simon Perreault [mailto:[email-masked]] 
Skickat: den 21 mars 2018 18:13
Till: Brandon Williams
Kopia: Konda, Tirumaleswar Reddy; Olle E. Johansson; Karl Stahl; [email-masked]
Ämne: Re: [tram] Multiple allocations SV: I-D Action: draft-ietf-tram-turnbis-15.txt

The proposal on the table is for Karl+Olle to write their idea into a new draft.

Simon

**********************

TURN servers.

ONE OF EACH.

one allocation request.

allocation is stronger!

/Karl

new values (as shown):

16.  STUN Attributes

     0x000C: CHANNEL-NUMBER

     0x000D: LIFETIME

     0x0012: XOR-PEER-ADDRESS

     0x0013: DATA

     0x0018: EVEN-PORT

     0x001A: DONT-FRAGMENT

ADDITIONAL-ADDRESS-ALL

ADDITIONAL-ADDRESS-ALLV4

ADDITIONAL-ADDRESS-ALLV6

     TBD-CA: ICMP

Thanks,

Karl

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 27 Mar 2018 14:29:54 +0000

Thanks Noriyuki Torii, addressed the comments in the new revision.

Cheers,
-Tiru

> From: Noriyuki Torii [mailto:[email-masked]]
> Sent: Monday, March 19, 2018 6:29 AM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-15.txt
> 
> Hi Tiru,
> 
> And also, I think it may be preferable if the following paragraph is updated so as
> to alignment to RFC 7983.
> 
> Finally, in section 18, the example Refresh request in the diagram of the page 67
> doesn't have the PASSWORD-ALGORITHMS attribute nevertheless it has the
> PASSWORD-ALGORITHM attributes, also need to be fixed.
> 
> Regards,
> Noriyuki Torii
> 
> ----------------
> 
> >> 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.
> >>

---

From: Noriyuki Torii <[email-masked]>
Date: Wed, 28 Mar 2018 15:43:18 +0900

Hi Tiru,

Thank you for the update.
I hesitate to say but I noticed I've missed one more point.

That is the first paragraph of section 12.6

>   The receiver of the ChannelData message uses the first two bits to
>   distinguish it from STUN-formatted messages, as described above.  If
>   the message uses a value in the reserved range (0x8000 through
>   0xFFFF), then the message is silently discarded.

Apparently, above paragraph also need update to align with RFC7983 and
also last update of section 12.

Regards,
Noriyuki Torii