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

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

> -----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
> >>
> >> I should first apologize the the delay in reviewing this draft.  I
> >> never managed to get a sponsorship that spans the whole lifetime of a
> >> draft (or a Working Group for that matter), and that why it is so
> >> difficult for me to work on IETF stuff in a sustained and consistent manner.
> >>
> >> Anyway, I was working on a review for turnbis-11 that was
> >> specifically focusing on the synchronization with stunbis, but I kept
> >> be distracted by issues related to the dual allocation feature.  So I
> >> decided instead to send a separate email for that, to make things less
> confusing.
> >>
> >> My main comment about the dual allocation approach is about the
> >> choice of adding a new attribute for that.  STUN supports sending
> >> multiple attributes of the same type, and has a default processing
> >> rule for them ("Any attribute type MAY appear more than once in a
> >> STUN message.  Unless specified otherwise, the order of appearance is
> >> significant:  only the first occurrence needs to be processed by a
> >> receiver, and any duplicates MAY be ignored by a
> >> receiver.")
> >>
> >> So a TURNbis client that wants to do a dual allocating adds two
> >> REQUESTED- ADDRESS-FAMILY (RAF), one for IPv4 and one for IPv6.  An
> >> RFC 5766 server will just use the first one and ignore the second.
> >> The TURNbis client receives only one XOR-RELAYED-ADDRESS (XRA), for
> the first RAF it sent.
> >>
> >> The client can choose the order, so it receives immediately a XRA
> >> from the family it is most interested in, and can try a second
> >> allocation for the other if the server is implementing RFC 5766
> >
> >
> > No, the above change contradicts the behavior defined in
> > 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>
> >
> > You may want to go through the long discussion in the WG to pick a new
> > attribute (ADDITIONAL-ADDRESS-FAMILY) for dual-stack allocation.
> 
> I still think it is unnecessarily complicated, but all right.
> 
> >
> >>
> >> I think that this makes for simpler rules to implement and simpler text.
> >>
> >> Now some more specific comments about the text:
> >>
> >> - Title and abstract
> >>
> >> The draft should obsolete both RFC 5766 and RFC 6156, and that fact
> >> should be repeated in the abstract.  The authors of RFC 6156 should
> >> be acknowledged either in the Acknowledgment or Contributors section.
> >
> > Done.
> >
> >>
> >> - Section 5.
> >>
> >> The first item in the bullet list should say "the relayed transport
> >> address or addresses;"
> >
> > Updated line to say "All TURN operations revolve around allocations, and all
> TURN messages are associated with either a single or dual allocation."
> >
> >>
> >> In the the fourth item, there is one time-to-expiry per relayed
> >> transport address.
> >>
> >> Same for the list of permissions in the fifth item.
> >>
> >> "Both the relayed transport address and the 5-tuple MUST be unique
> >> across all allocations, so either one can be used to uniquely identify the
> allocation."
> >>
> >> With the dual allocation, the 5-tuple no longer uniquely identify an
> allocation.
> >
> > Yes, fixed.
> >
> >>
> >> - 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 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.
> >>
> >> 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.
> >
> > Cheers,
> > -Tiru
> >
> 
> 
> --
> Marc Petit-Huguenin
> Email: [e-mail]
> Blog: https://marc.petit-huguenin.org
> Profile: https://www.linkedin.com/in/petithug