Subject: [tram] Alissa Cooper's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Tue, 30 Aug 2016 08:47:57 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-tram-turn-mobility-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

= Section 3 =

The diagram needs a caption and some explanation. Why does the first
Allocate request result in a 401 error? This is not discussed anywhere in
the document.

= Appendix A =

In the data structure there is a "state" field but the text below it
refers to an "encrypted_state" field.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 30 Aug 2016 21:36:05 -0500

> Allocate request result in a 401 error? This is not discussed anywhere 

Hi,

IIUC, the 401 is inherited from normal TURN behavior (using the STUN 
long-term credential stuff.) But I agree that some explanation of the 
steps would be helpful.

Ben.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 31 Aug 2016 02:41:28 +0000

Hi Alissa,

Thanks for the review. Please see inline

> -----Original Message-----
> From: Alissa Cooper [mailto:[email-masked]]
> Sent: Tuesday, August 30, 2016 9:18 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Simon Perreault
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> Subject: Alissa Cooper's No Objection on draft-ietf-tram-turn-mobility-05:
> (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Allocate request result in a 401 error? 

401 error is returned by the server because of STUN's long-term credential mechanism.

> This is not discussed anywhere in the
> document.

Added caption "Mobility using TURN " with the following explanation:

   In Figure 1, the client sends an Allocate request with an MOBILITY-
   TICKET attribute to the server without credentials.  Since the server
   requires that all requests be authenticated using STUN's long-term
   credential mechanism, the server rejects the request with a 401
   (Unauthorized) error code.  The client then tries again, this time
   including credentials (not shown).  This time, the server accepts the
   Allocate request and returns an Allocate success response and a
   ticket inside the MOBILITY-TICKET attribute.  Sometime later, the
   client IP address changes and decides to refresh the allocation and
   thus sends a Refresh request to the server with MOBILITY-TICKET
   attribute containing the ticket it had received from the server.  The
   refresh is accepted and the server replies with a Refresh success
   response and a new ticket inside the MOBILITY-TICKET attribute.

> 
> = Appendix A =
> 
> In the data structure there is a "state" field but the text below it refers to an
> "encrypted_state" field.

Fixed.

-Tiru