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

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 2 Apr 2018 08:03:41 +0000

> -----Original Message-----
> From: Noriyuki Torii [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2018 12:13 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-15.txt
> 
> 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.

Thanks, fixed in my local copy.

Cheers,
-Tiru

> 
> Regards,
> Noriyuki Torii
> 
> 
> 2018-03-27 23:29 GMT+09:00 Konda, Tirumaleswar Reddy
> <[email-masked]>:
> > Thanks Noriyuki Torii, addressed the comments in the new revision.
> >
> > Cheers,
> > -Tiru
> >
> >> -----Original Message-----
> >> 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,
> >>
> >> 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
> >>
> >> ----------------
> >>
> >> 2018-03-18 17:50 GMT+09:00 Konda, Tirumaleswar Reddy
> >> <[email-masked]>:
> >> > 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
> >> >>
> >> >>
> >> >> 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/
> >> >>
> >> >> _______________________________________________
> >> >> tram mailing list
> >> >> [email-masked]
> >> >> https://www.ietf.org/mailman/listinfo/tram
> >> >
> >> > _______________________________________________
> >> > 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: Brandon Williams <[email-masked]>
Date: Mon, 2 Apr 2018 12:46:38 -0400

Karl,

There is no WG decision to hinder this, simply a disagreement about 
approach.

Some of us (the editors in particular) have been working on the turnbis 
draft for quite some time. It went into WGLC several months ago and it 
is already well behind the originally agreed schedule in the charter.

Considering the fact that this is not something that was ever called out 
previously, we are only questioning why it has suddenly become critical 
to expand the scope of turnbis and thus delay publishing even further.

If there were already a draft that explains the rationale, use cases, 
and protocol changes, it would be easier to assess the impact and 
consider inclusion. This was the path followed by a few other new 
capabilities that were eventually rolled directly into turnbis.

If the WG came to the conclusion that we should not delay turnbis any 
further but instead should advance the capability as a new RFC 
candidate, we would already be in a good position to that if we had a 
draft in hand. If the WG decided to include this in turnbis, we would 
already have text available.

IOW, I am only resisting the idea of expanding the scope of turnbis 
without WG consensus to do so; I am not resisting your proposal itself. 
The suggestion that you take the time to write down your idea in I-D 
format seems like a good way for you to drive the required WG discussion.

--Brandon

On 03/22/2018 05:17 PM, Karl Stahl wrote:
> 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
> 
> 2018-03-21 17:05 GMT+00:00 Brandon Williams <[email-masked] 
> <mailto:[email-masked]>>:
> 
> 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
> 
> **********************
> 
> 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
> 

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 2 Apr 2018 20:47:35 +0200

Hi!

Well, since Network-provided servers was added to the security section of RFC 8155, I kind of think it’s now in scope for
everything TURN and from that standpoint I do understand Karl’s objections.

On the other hand, I don’t really like how it was added to that RFC and like the idea of a separate document that
clears this mess up and explains clearly how network-provided TURN-servers is supposed to work, the requirements
and additions to the TURN protocol. 

The problem with that is that implementors may think it’s just an add-on and not implement it in the TURN client
implementations, which would be harmful in the long run. 

Question: Will adding operations or modifying existing ones in a new document make it a mandatory
part of the TURN protocol, an update to the TURN RFC (turnbis as an RFC that is)?

/O

> On 2 Apr 2018, at 18:46, Brandon Williams <[email-masked]> wrote:
> 
> Karl,
> 
> There is no WG decision to hinder this, simply a disagreement about approach.
> 
> Some of us (the editors in particular) have been working on the turnbis draft for quite some time. It went into WGLC several months ago and it is already well behind the originally agreed schedule in the charter.
> 
> Considering the fact that this is not something that was ever called out previously, we are only questioning why it has suddenly become critical to expand the scope of turnbis and thus delay publishing even further.
> 
> If there were already a draft that explains the rationale, use cases, and protocol changes, it would be easier to assess the impact and consider inclusion. This was the path followed by a few other new capabilities that were eventually rolled directly into turnbis.
> 
> If the WG came to the conclusion that we should not delay turnbis any further but instead should advance the capability as a new RFC candidate, we would already be in a good position to that if we had a draft in hand. If the WG decided to include this in turnbis, we would already have text available.
> 
> IOW, I am only resisting the idea of expanding the scope of turnbis without WG consensus to do so; I am not resisting your proposal itself. The suggestion that you take the time to write down your idea in I-D format seems like a good way for you to drive the required WG discussion.
> 
> --Brandon
> 
>> No and this draft cannot be approved without the generalization I have pointed out.
>> 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.
>> *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
>> 2018-03-21 17:05 GMT+00:00 Brandon Williams <[email-masked] <mailto:[email-masked]>>:
>> The proposal on the table is for Karl+Olle to write their idea into a new draft.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 03 Apr 2018 05:03:02 +0000

I spent time with Pal and others coming up with the initial dual allocation
concept (SSODA) and there are clear reasons for this approach (as discussed
in the intro of the original SSODA doc).

It's not clear to me why multiple addresses of the same family are ever
needed though, and even if we supported this, how the client would be
expected to select between them. It seems like a large expansion of scope
beyond the goals of SSODA.

On Mon, Apr 2, 2018 at 11:47 AM Olle E. Johansson <[email-masked]> wrote:

> Hi!
>
> Well, since Network-provided servers was added to the security section of
> RFC 8155, I kind of think it’s now in scope for
> On the other hand, I don’t really like how it was added to that RFC and
> like the idea of a separate document that
> draft for quite some time. It went into WGLC several months ago and it is
> already well behind the originally agreed schedule in the charter.
> >
> previously, we are only questioning why it has suddenly become critical to
> expand the scope of turnbis and thus delay publishing even further.
> >
> and protocol changes, it would be easier to assess the impact and consider
> inclusion. This was the path followed by a few other new capabilities that
> were eventually rolled directly into turnbis.
> >
> further but instead should advance the capability as a new RFC candidate,
> we would already be in a good position to that if we had a draft in hand.
> If the WG decided to include this in turnbis, we would already have text
> available.
> >
> without WG consensus to do so; I am not resisting your proposal itself. The
> suggestion that you take the time to write down your idea in I-D format
> seems like a good way for you to drive the required WG discussion.
> >
> > --Brandon
> >
> >> 2018-03-21 17:05 GMT+00:00 Brandon Williams <
> [email-masked] <mailto:[email-masked]>>:

---

From: Noriyuki Torii <[email-masked]>
Date: Thu, 5 Apr 2018 12:28:36 +0900

Hi,

>From my understandings, current TURNbis specification is intended, as its
scope of, just a single IP addressed server nevertheless its IPv4/v6
co-allocation capability. Such a capablity is introduced for v4 <-> v6
communication, and not as a generalization for a multiple IP addressed
server.

IMHO, if a server with multiple IP addresses of the same family will be
deployed into service, idential form of allocation request currently
defined also should be sent to such a server. And the server must process
the request appropriately according to its network configuration.

In general, clients don't know, and shouldn't need to know, how many IP
addresses are given to the server communicating with, or how is the
topology of the network into where the server is deployed, etc.
So the client side request form selection is not usually possible.

Because of above, I'm afraid to say but I couldn't agree with the Karl's
proposal of the modification of request form with additional attributes,
although I can understand there exists the demand of specification for
multiple IP addressed server.

I think the generalization of TURN for multiple IP addressed server is
something need more discussion and separate publication.

Regards,
Noriyuki Torii

2018-03-21 4:55 GMT+09:00 Karl Stahl <[email-masked]>:
> My comment about need for multiple allocations is NOT addressed.
>
>> 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
>
>> This draft is a work item of the TURN Revised and Modernized WG of the
>> IETF.
>>
> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 5 Apr 2018 17:52:43 +0200

Noriyoki, Answering in-line below with cuts from drafts/RFCs how the network provided turn server came to be (which is why we need the generalization to multiple allocation) and jumping back on the other thread to explain the application (that real-time media is not only over public Internet – actually, current VoIP is typically on separate (quality) networks)

And Olle, last below (what came first) “Network-provided servers was added to the security section of RFC 8155…”– It was the other way around! What became RFC 8155 was intended to be TURN server discovery mechanism for enterprises and ISPs. That is Network Provided TURN servers in the local or access network – Not Brandon’s TURN servers that are elsewhere (but discovered).

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Noriyuki Torii
Skickat: den 5 april 2018 05:29
Till: [email-masked]
Ämne: Re: [tram] Multiple allocations SV: I-D Action: draft-ietf-tram-turnbis-15.txt

Hi,

server.

[KS] --- That is the way it has happened (in contrast to intended/understood considering why TRAM was formed, charter https://datatracker.ietf.org/wg/tram/about and the overall need for a TURNbis)

[KS] --- That is totally changed with the network provided TURN server 

In ICE style, to get all candidates:

* With application provided TURN servers, the Client is given all TURN servers (into different networks) to Allocate multiple times.

* With network provided TURN servers, the Client needs to get all candidates in one go (One Allocation to that single network provided TURN server, that it has found somehow).

THE NETWORK PROVIDED TURNSERVER COMES FROM: RFC7478

https://tools.ietf.org/html/rfc7478 

Web Real-Time Communication Use Cases and Requirements

2.3.2.  Simple Video Communication Service: NAT/Firewall That Blocks UDP

2.3.2.1.  Description

   This use case is almost identical to the

   Simple Video Communication Service use case (Section 2.3.1).  The

   difference is that one of the users is behind a NAT/firewall that

   blocks UDP traffic.

2.3.2.2.  Additional Requirements

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

   REQ-ID          DESCRIPTION

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

   F18             The browser must be able to send streams and

                   data to a peer in the presence of NATs and

                   firewalls that block UDP traffic.

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

2.3.3.  Simple Video Communication Service: Firewall That Only Allows

        Traffic via an HTTP Proxy

2.3.3.1.  Description

   This use case is almost identical to the

   Simple Video Communication Service use case (Section 2.3.1).  The

   difference is that one of the users is behind a firewall that only

   allows traffic via an HTTP Proxy.

2.3.3.2.  Additional Requirements

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

   REQ-ID          DESCRIPTION

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

   F21             The browser must be able to send streams and

                   data to a peer in the presence of firewalls that only

                   allow traffic via an HTTP Proxy, when firewall policy

                   allows WebRTC traffic.

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

2.3.4.  Simple Video Communication Service: Global Service Provider

2.3.4.1.  Description

   This use case is almost identical to the

   Simple Video Communication Service use case (Section 2.3.1).  What is

   added is that the service provider is operating over large

   geographical areas (or even globally).

   Assuming that the Interactive Connectivity Establishment (ICE)

   mechanism [RFC5245] will be used, this means that the service

   provider would like to be able to provide several Session Traversal

   Utilities for NAT (STUN) and Traversal Using Relay NAT (TURN) servers

   (via the app) to the browser; selection of which one(s) to use is

   part of the ICE processing.  Other reasons for wanting to provide

   several STUN and TURN servers include support for IPv4 and IPv6, load

   balancing, and redundancy.

   Note that ICE support being mandatory does not preclude a WebRTC

   endpoint from supporting more traversal mechanisms than ICE using

   STUN and TURN.

2.3.4.2.  Additional Requirements

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

   REQ-ID          DESCRIPTION

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

   F19             The browser must be able to use several STUN

                   and TURN servers.

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

   A22

2.3.5.  Simple Video Communication Service: Enterprise Aspects

2.3.5.1.  Description

   This use case is similar to the Simple Video Communication Service

   use case (Section 2.3.1).

   What is added is aspects when using the service in enterprises.  ICE

   is assumed in the further description of this use case.

   An enterprise that uses a WebRTC-based web application for

   communication desires to audit all WebRTC-based application sessions

   used from inside the company towards any external peer.  To be able

   to do this, they deploy a TURN server that straddles the boundary

   between the internal and the external network.

   The firewall will block all attempts to use STUN with an external

   destination unless they go to the enterprise auditing TURN server.

   In cases where employees are using WebRTC applications provided by an

   external service provider, they still want the traffic to stay inside

   their internal network and in addition not load the straddling TURN

   server; thus, they deploy a STUN server allowing the WebRTC client to

   determine its server reflexive address on the internal side.  Thus,

   enabling cases where peers are both on the internal side to connect

   without the traffic leaving the internal network.  It must be

   possible to configure the browsers used in the enterprise with

   network specific STUN and TURN servers.  This should be possible to

   achieve by autoconfiguration methods.  The WebRTC functionality will

   need to utilize both network specific STUN and TURN resources and

   STUN and TURN servers provisioned by the web application.

<end cut from RFC 7478>

[KS continuing] That TURN server that straddles the boundary

   between the internal and the external network

+ is the network provided TURN server in the local or access network [terminology used in https://www.rfc-editor.org/rfc/pdfrfc/rfc8155.txt.pdf] 

+ and in the TRAM CHARTER is the (among milestones:)

Nov 2015  Send new TURN server discovery mechanism for enterprises and ISPs to IESG for publication as Proposed Standard draft-ietf-tram-turn-server-discovery  

+ and in https://www.ietf.org/archive/id/draft-ietf-rtcweb-return-02.txt 

TURN Proxy or Border TURN server

Brandon’s Network Provided TURN servers are OUTSIDE the local or access network and it is very unfortunate that https://www.rfc-editor.org/rfc/rfc8155.txt took that as the main approach “This document describes three discovery mechanisms, so as to maximize the opportunity for discovery, based on the network in which the TURN    client finds itself.” (We definitely don’t want to find Brandon’s turn servers when trying to discover the very private TURN server on the LAN – unfortunately making RFC 8155 more or less useless for its intended purpose: Autodiscovery of the network provided TURN server in the local and access network.)  

(And Olle: Your statement in other email “Well, since Network-provided servers was added to the security ection of RFC 8155, I kind of think it’s now in scope for everything TURN and from that standpoint I do understand Karl’s objections.” – It was the other way around! What became RFC 8155 was intended to be TURN server discovery mechanism for enterprises and ISPs.)

Enough of history now. And back to the other thread and the need for having real-time media on multiple WAN networks (heavily used for VoiP for over 10 years).

The Network Provided TURN Server in the local or access network, is really about finally resolving the NAT/Firewall traversal problem of real-time communication. After all these (15?) years, we cannot have a TURNbis RFC that in itself hinders its usage (only to use with real-time media on the public Internet – which rarely is the case).

[Noriyuki’s text again]

Regards,

Noriyuki Torii

>> From: Karl Stahl [ <mailto:[email-masked]> mailto:[email-masked]]

>> To: 'Marc Petit-Huguenin' < <mailto:[email-masked]> [email-masked]>; Konda, Tirumaleswar Reddy

>> < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]

>> > >  <https://tools.ietf.org/html/rfc6156#section-3> https://tools.ietf.org/html/rfc6156#section-3

> Från: tram [ <mailto:[email-masked]> mailto:[email-masked]] För Konda, Tirumaleswar Reddy

> Till:  <mailto:[email-masked]> [email-masked]

>> From: tram [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of internet-

>>  <mailto:[email-masked]> [email-masked]

>> To:  <mailto:[email-masked]> [email-masked]

>> Cc:  <mailto:[email-masked]> [email-masked]

>>  <https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/> https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/

>>  <https://tools.ietf.org/html/draft-ietf-tram-turnbis-15> https://tools.ietf.org/html/draft-ietf-tram-turnbis-15

>>  <https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-15> https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-15

>>  <https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-15> https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-15

>>  <ftp://ftp.ietf.org/internet-drafts/> ftp://ftp.ietf.org/internet-drafts/

>>  <mailto:[email-masked]> [email-masked]

>>  <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram

>  <mailto:[email-masked]> [email-masked]

>  <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram

>  <mailto:[email-masked]> [email-masked]

>  <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram

tram mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 5 Apr 2018 17:54:11 +0200

Justin> It's not clear to me why multiple addresses of the same family are ever needed

SIMPLY: Real-time media is not only over the public Internet

In fact, most of today’s telephony VoIP goes over other networks that the Internet.

Most SIP trunking into enterprise PBXs comes on higher quality pipes for that telephony VoIP, and the large enterprises that  block UDP access from their LANs (and which the https://tools.ietf.org/html/rfc7478 Web Real-Time Communication Use Cases and Requirements as well as your and Benjamin’s  https://www.ietf.org/archive/id/draft-ietf-rtcweb-return-02.txt 

have the aim of supporting) most often ALSO have a higher quality WANs between their branch offices. There is big business putting VoIP over those networks (today it is SIP based using SBCs, future will use WebRTC and Network Provided Turn-servers.

And a third need is in even seen in home access routers: Those telephony RJ11 FXS-ports you see on them, are typically connected to SPs VoIP higher quality than Internet networks (maybe an IMS network). There is a lot of policy based routing going in, especially with real-time media.

For doing that with ICE/TURN and network provided TURN server on the LAN, the “TURN Proxy” as you call it, simply needs the multiple Allocation. It is a simple and elegant solution (You would NOT like the alternative of addressing several TURN servers (auto discovered) on the LAN from the Client). 

Justin> and even if we supported this, how the client would be expected to select between them

Do you see problems with the approach of offering all and selecting the first that works, just like Happy Eyeballs?

I don’t have SSODA background and not so much HTTPS proxy background as you – More from real-time communication with SIP VoIP and arranging  NAT/Firewall traversal using SBC (don’t like that misused name on our products that are really SIP aware firewalls in line with the MIDCOM work from the time before ICE/TURN/STUN) which may be why we see different needs. 

I’m not saying anything of that SSODA is wrong or work wasted – on the contrary – I want it generalized because we need it! 

Olle, I also think there one day will (have to be) a separate document that … clearly how network-provided TURN-servers is supposed to work (there is more that should/could be done in there also), but now we need have the base standards to support instead of hinder it, which was one thing TRAM was supposed to achieve..

Olle> security section of RFC 8155 … On the other hand, I don’t really like how it was added to that RFC

It was the other way around…

The TRAM intent of what became https://www.rfc-editor.org/rfc/pdfrfc/rfc8155.txt.pdf  was (from mile stone) “TURN server discovery mechanism for enterprises and ISPs to IESG” that is Network Provided TURN server in local or access network.

The intent was NOT Brandon’s Network Provided TURN servers that are OUTSIDE the local or access network and it is very unfortunate that https://www.rfc-editor.org/rfc/rfc8155.txt took the approach “This document describes three discovery mechanisms, so as to maximize the opportunity for discovery, based on the network in which the TURN client finds itself.” (We definitely don’t want to find Brandon’s turn servers when trying to discover the very private TURN server on the LAN – unfortunately making RFC 8155 more or less useless for its intended purpose (under my protest).

/Karl

Från: Justin Uberti [mailto:[email-masked]] 
Skickat: den 3 april 2018 07:03
Till: Olle E. Johansson
Kopia: Brandon Williams; Simon Perreault; [email-masked]; [email-masked]; Karl Stahl
Ämne: Re: [tram] Multiple allocations SV: I-D Action: draft-ietf-tram-turnbis-15.txt

I spent time with Pal and others coming up with the initial dual allocation concept (SSODA) and there are clear reasons for this approach (as discussed in the intro of the original SSODA doc).

It's not clear to me why multiple addresses of the same family are ever needed though, and even if we supported this, how the client would be expected to select between them. It seems like a large expansion of scope beyond the goals of SSODA.

Hi!

/O