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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

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

> -----Original Message-----
> From: Karl Stahl [mailto:[e-mail]]
> Sent: Sunday, March 4, 2018 10:36 PM
> To: 'Marc Petit-Huguenin' <[e-mail]>; Konda, Tirumaleswar Reddy
> <[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
> > > <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
>