Re: [tram] Multiple allocations SV: I-D Action: draft-ietf-tram-turnbis-15.txt

["Karl Stahl" <[e-mail]>]

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:[e-mail]] För Noriyuki Torii
Skickat: den 5 april 2018 05:29
Till: [e-mail]
Ämne: Re: [tram] Multiple allocations SV: I-D Action: draft-ietf-tram-turnbis-15.txt

 

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.

 

[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)

 

 

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.

 

[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]

 

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 < <mailto:[e-mail]> [e-mail]>:

>> 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

> 

>> -----Original Message-----

>> From: Karl Stahl [ <mailto:[e-mail]> mailto:[e-mail]]

>> Sent: Sunday, March 4, 2018 10:36 PM

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

>> < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [e-mail]

>> 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> 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:[e-mail]> mailto:[e-mail]] För Konda, Tirumaleswar Reddy

> Skickat: den 18 mars 2018 09:51

> Till:  <mailto:[e-mail]> [e-mail]

> Ämne: Re: [tram] I-D Action: draft-ietf-tram-turnbis-15.txt

> 

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

> 

> -Tiru

> 

>> -----Original Message-----

>> From: tram [ <mailto:[e-mail]> mailto:[e-mail]] On Behalf Of internet-

>>  <mailto:[e-mail]> [e-mail]

>> Sent: Sunday, March 18, 2018 8:43 AM

>> To:  <mailto:[e-mail]> [e-mail]

>> Cc:  <mailto:[e-mail]> [e-mail]

>> 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/> 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://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

>> 

>> A diff from the previous version is available at:

>>  <https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-15> 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/> ftp://ftp.ietf.org/internet-drafts/

>> 

>> _______________________________________________

>> tram mailing list

>>  <mailto:[e-mail]> [e-mail]

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

> 

> _______________________________________________

> tram mailing list

>  <mailto:[e-mail]> [e-mail]

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

> 

> _______________________________________________

> tram mailing list

>  <mailto:[e-mail]> [e-mail]

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

 

_______________________________________________

tram mailing list

 <mailto:[e-mail]> [e-mail]

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