Subject: Re: [tram] Review of dual allocation in TURNbis-11

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 2 Mar 2018 13:16:35 -0800

As suggested by Brandon, I reviewed turnbis-14 for the modifications agreed on below, and found some discrepancies.  See inline.

On 02/09/2018 04:51 AM, Konda, Tirumaleswar Reddy wrote:
>> -----Original Message-----
>> From: Marc Petit-Huguenin [mailto:[email-masked]]
>> Sent: Sunday, October 22, 2017 9:38 PM
>> To: Konda, Tirumaleswar Reddy
>> <[email-masked]>; [email-masked]
>> Subject: Re: [tram] Review of dual allocation in TURNbis-11
>>
>> Inline.
>>
>> On 10/16/2017 07:14 PM, Konda, Tirumaleswar Reddy wrote:
>>> Thanks Marc for the detailed review, Please see inline
>>>
>>>> -----Original Message-----
>>>> From: tram [mailto:[email-masked]] On Behalf Of Marc Petit-
>>>> Huguenin
>>>> Sent: Saturday, October 14, 2017 12:59 AM
>>>> To: [email-masked]
>>>> Subject: [tram] Review of dual allocation in TURNbis-11
>>>>

[snip]

>>>
>>>>
>>>> - Section 6.2
>>>>
>>>> I would suggest to make ADDRESS-ERROR-CODE more generic by
>> renaming
>>>> it as WARNING-CODE and use the same format than for ERROR-CODE.
>> Then
>>>> allocate a new error code for that specific warning.  I would suggest
>>>> to request the 0x8009 codepoint for that attribute.
>>>
>>> I don't understand the need to change ADDRESS-ERROR-CODE !
>>
>> To make it more generic and reusable in future specifications.
> 
> ADDRESS-ERROR-CODE cannot use the same format as ERROR-CODE, ADDRESS-ERROR-CODE signals the IP address family for which the warning is generated + all the fields in the ERROR-CODE. 
> 
>>
>>>
>>>>
>>>> Also I think we needs two different warnings, one that states that
>>>> dual allocation is not available in a TURNbis server, but both
>>>> protocols are available, and another that says that dual allocation
>>>> failed because one of the two protocols is not available.  This is to
>>>> let the client know that it is useless to try another allocation for the
>> missing protocol.
>>>
>>> I don't get the reason for two different warnings.
>>
>> A server may support both IPv6 and IPv4 allocations and not support dual
>> allocation, in which case the client can do a second allocation for the IPv6
>> relayed address.
> 
> If the server does not support dual allocation but supports both IPv6 and IPv4 allocations, it will only allocate the IPv4 relayed address and not will not return ADDRESS-ERROR-CODE in the response, the client will know the server does not understand the ADDITIONAL-ADDRESS-FAMILY attribute (ADDITIONAL-ADDRESS-FAMILY is a comprehension-optional attribute). 
> 
>>
>> Alternatively the server may not support IPv6 at all, in which case the second
>> allocation will fail and was unnecessary.
> 
> ADDRESS-ERROR-CODE signals both unsupported IP address type (0x02 (IPv6 address family)) and the reason for failure (440 (unsupported address family)). 
> 
> Cheers,
> -Tiru
> 
>>
>> Using two different warnings permits to know if the second allocation will
>> succeed or not.
>>
>>>
>>>>
>>>> What is the policy when reserving the next port with the EVEN-PORT
>>>> attribute in a dual allocation, but one of them fails to find a pair
>>>> of subsequent ports available?
>>>
>>> It's discussed in section 6.1
>>>
>>> <snip>
>>>    Clients MUST NOT
>>>    include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request
>>>    that contains an EVEN-PORT attribute with the R bit set to 1.
>>> </snip>
>>>
>>>>
>>>> It is not said that the Allocate successful response must contain two
>>>> XRAs after a successful dual allocation.
>>>
>>> Good point, Updated draft.

I cannot find this update in turn-14.

>>>
>>>>
>>>> I would also suggest to add some text that says that when a TURNbis
>>>> server sends an Allocate success response, it must always send the
>>>> XRAs in the same order than the RAFs were sent.  So in case the
>>>> server sends back by mistake two XRAs, the first one matches the one
>> requested by the client.

Did not get answer to that and did not see it in turn-14.

>>>>
>>>> The bullet list at the end needs also to be fixed for dual allocation.
>>>
>>> Agreed, fixed.
>>>
>>>>
>>>> - Section 6.3
>>>>
>>>> Here's too, the text needs to be updated for the dual allocation case.
>>>
>>>
>>> Yup, updated.
>>>

Same, there is no update since -11 in section 7.3 (formerly 6.3)

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sun, 4 Mar 2018 13:30:23 +0000

Hi Marc,

Please see inline

> Sent: Saturday, March 3, 2018 2:47 AM
> As suggested by Brandon, I reviewed turnbis-14 for the modifications agreed
> on below, and found some discrepancies.  See inline.
> 
> >>>> allocate a new error code for that specific warning.  I would
> >>>> suggest to request the 0x8009 codepoint for that attribute.
> >>>
> > ADDRESS-ERROR-CODE cannot use the same format as ERROR-CODE,
> ADDRESS-ERROR-CODE signals the IP address family for which the warning is
> generated + all the fields in the ERROR-CODE.
> >
> >>
> >>>
> >>>>
> >>>> failed because one of the two protocols is not available.  This is
> >>>> to let the client know that it is useless to try another allocation
> >>>> for the
> >> missing protocol.
> >>>
> >> A server may support both IPv6 and IPv4 allocations and not support
> >> dual allocation, in which case the client can do a second allocation
> >> for the IPv6 relayed address.
> >
> > If the server does not support dual allocation but supports both IPv6 and
> IPv4 allocations, it will only allocate the IPv4 relayed address and not will not
> return ADDRESS-ERROR-CODE in the response, the client will know the
> server does not understand the ADDITIONAL-ADDRESS-FAMILY attribute
> (ADDITIONAL-ADDRESS-FAMILY is a comprehension-optional attribute).
> >
> >>
> >> Alternatively the server may not support IPv6 at all, in which case
> >> the second allocation will fail and was unnecessary.
> >
> > ADDRESS-ERROR-CODE signals both unsupported IP address type (0x02
> (IPv6 address family)) and the reason for failure (440 (unsupported address
> family)).
> >
> > Cheers,
> > -Tiru
> >
> >>
> >> Using two different warnings permits to know if the second allocation
> >> will succeed or not.
> >>
> >>>
> >>>>
> >>>> attribute in a dual allocation, but one of them fails to find a
> >>>> pair of subsequent ports available?
> >>>
> >>>> It is not said that the Allocate successful response must contain
> >>>> two XRAs after a successful dual allocation.
> >>>

This comment is partially addressed in -12 revision, step 9 (in Section 6.2 in -12 revision and Section 7.2 in -14 revision) is updated to discuss dual allocation. 
<snip>
If the server can fully meet
the request, then the server allocates one IPv4 and one IPv6
relay address, and returns an Allocate success response
containing the relayed transport addresses assigned to the dual
allocation.
</snip>

NEW:
If the server can fully meet
the request, then the server allocates one IPv4 and one IPv6
relay address, and returns an Allocate success response
containing the relayed transport addresses assigned to the dual
allocation in two XOR-RELAYED-ADDRESS attributes.

> Did not get answer to that and did not see it in turn-14.

I did not get this comment. If a request contains both REQUESTED-ADDRESS-FAMILY and ADDITIONAL-ADDRESS-FAMILY attributes, the request is rejected by the server. Further, only IPv6 address family is allowed in the 
ADDITIONAL-ADDRESS-FAMILY attribute.

> Same, there is no update since -11 in section 7.3 (formerly 6.3)

This comment is addressed in -12 revision itself, the updated text uses "relayed transport address or addresses" and " address family or families" to discuss the 
dual allocation case.

Cheers,
-Tiru

---

From: "Karl Stahl" <[email-masked]>
Date: Sun, 4 Mar 2018 18:05:50 +0100

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

PS: I also saw one small inconsistency when browsing through.

On page 26: 
"7.2.  Receiving an Allocate Request

   When the server receives an Allocate request, it performs the
   following checks:

   1.   The server MUST require that the request be authenticated..."

Without mentioning (making exception from the MUST) that authentication may not be required (which is already mentioned on page 17:
"2.9.  Happy Eyeballs for TURN
...

   o  For clear text UDP, send TURN Allocate requests to both IP address
      families as discussed in [RFC8305], without authentication
      information. If the TURN server requires authentication, it will
      send back a 401 unauthenticated response and the TURN client uses
      the first UDP connection on which a 401 error response is
      received.  If a 401 error response is received from both IP
      address families then the TURN client can silently abandon the UDP
      connection on the IP address family with lower precedence.  If the
      TURN server does not require authentication (as described in
      Section 9 of [RFC8155]), it is possible for both Allocate requests
      to succeed."

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Marc Petit-Huguenin
Skickat: den 2 mars 2018 22:17
Till: Konda, Tirumaleswar Reddy; [email-masked]
Ämne: Re: [tram] Review of dual allocation in TURNbis-11

[snip]

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 5 Mar 2018 10:47:24 +0000

Thanks Karl. I have fixed the inconsistency.

NEW:
   1.   The server SHOULD require that the request be authenticated.
        The authentication of the request is optional to allow TURN
        servers provided by the local or access network to accept
        Allocation requests from new and/or guest users in the network
        who do not necessarily possess long term credentials for STUN
        authentication and its security implications are discussed in
        [RFC8155].  If the request is authenticated, the authentication
        MUST be done using the long-term credential mechanism of
        [I-D.ietf-tram-stunbis] unless the client and server agree to
        use another mechanism through some procedure outside the scope
        of this document.

WG has discussed and agreed only on dual allocation and your proposal to return multiple relayed transport addresses of the same family is new work and the need for this enhancement needs to be discussed and agreed in the WG.
A new draft looks more suitable to discuss this enhancement.

-Tiru

> From: Karl Stahl [mailto:[email-masked]]
> Sent: Sunday, March 4, 2018 10:36 PM
> To: 'Marc Petit-Huguenin' <[email-masked]>; Konda, Tirumaleswar Reddy
> 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).
> 
> 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
> 
> Without mentioning (making exception from the MUST) that authentication
> may not be required (which is already mentioned on page 17:

---

From: "Karl Stahl" <[email-masked]>
Date: Fri, 9 Mar 2018 13:35:19 +0100

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

-----Ursprungligt meddelande-----
Från: Konda, Tirumaleswar Reddy [mailto:[email-masked]] 
Skickat: den 5 mars 2018 11:47
Till: Karl Stahl; 'Marc Petit-Huguenin'; [email-masked]
Ämne: RE: [tram] Review of dual allocation in TURNbis-11

...

-Tiru

> get multiple relayed transport addresses from one allocate request?

**** Left a few clips from "[tram] Review of dual allocation in TURNbis-11" thread

---

From: Brandon Williams <[email-masked]>
Date: Fri, 9 Mar 2018 16:14:49 -0500

I agree with Tiru that opening up turnbis for such a change at this 
stage is not the right approach. The WG has broad consensus already on 
the scope of turnbis, and multiple addresses of each family type is not 
part of that scope.

--Brandon

On 03/09/2018 07:35 AM, Karl Stahl wrote:
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: Brandon Williams <[email-masked]>
Date: Fri, 9 Mar 2018 16:16:42 -0500

This change looks good to me.

Karl, Do you agree that it addresses the inconsistency you previously 
mentioned?

--Brandon

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

---

From: Brandon Williams <[email-masked]>
Date: Fri, 9 Mar 2018 16:19:55 -0500

Hi Marc,

Tiru had one response and one question below. Any thoughts?

--Brandon

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 11 Mar 2018 05:45:53 -0700

Inline.

> allocation in two XOR-RELAYED-ADDRESS attributes.

OK.

> ADDITIONAL-ADDRESS-FAMILY attribute.

No, my request was to ask that in case of dual allocation the address that is selected following the ADDITIONAL-ADDRESS-FAMILY attribute is inserted after the address selected by the REQUESTED-ADDRESS-FAMILY attribute in the response.

So if the order in the request is:

REQUESTED-ADDRESS-FAMILY for ipv4
ADDITIONAL-ADDRESS-FAMILY for ipv6

then the response contains

XOR-RELAYED-ADDRESS for ipv4
XOR-RELAYED-ADDRESS for ipv6

This is a corner case (if the server misbehave, the client still works), so I am OK with this request ignored.

> This comment is addressed in -12 revision itself, the updated text uses "relayed transport address or addresses" and " address family or families" to discuss the 

OK.