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

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 13 Oct 2017 12:29:24 -0700

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.

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.

- Section 5.

The first item in the bullet list should say "the relayed transport address or addresses;"

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.

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

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.

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 is not said that the Allocate successful response must contain two XRAs after a successful dual allocation.

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.

- Section 6.3

Here's too, the text needs to be updated for the dual allocation case.

-- 
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: Tue, 17 Oct 2017 02:14:20 +0000

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

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

> The first item in the bullet list should say "the relayed transport address or

Updated line to say "All TURN operations revolve around allocations, and all TURN messages are associated with either a single or dual allocation."

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

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 !

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

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

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

Agreed, fixed. 

> Here's too, the text needs to be updated for the dual allocation case.

Yup, updated.

Cheers,
-Tiru

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 22 Oct 2017 09:08:15 -0700

Inline.

> attribute (ADDITIONAL-ADDRESS-FAMILY) for dual-stack allocation.

I still think it is unnecessarily complicated, but all right.

> I don't understand the need to change ADDRESS-ERROR-CODE !

To make it more generic and reusable in future specifications.

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

Alternatively the server may not support IPv6 at all, in which case the second allocation will fail and was unnecessary.

Using two different warnings permits to know if the second allocation will succeed or not.