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

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

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:[e-mail]] För Marc Petit-Huguenin
Skickat: den 2 mars 2018 22:17
Till: Konda, Tirumaleswar Reddy; [e-mail]
Ämne: Re: [tram] Review of dual allocation in TURNbis-11

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:[e-mail]]
>> Sent: Sunday, October 22, 2017 9:38 PM
>> To: Konda, Tirumaleswar Reddy
>> <[e-mail]>; [e-mail]
>> 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:[e-mail]] On Behalf Of Marc Petit-
>>>> Huguenin
>>>> Sent: Saturday, October 14, 2017 12:59 AM
>>>> To: [e-mail]
>>>> 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: [e-mail]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug