Early Review of draft-ietf-tram-turn-mobility-03

Request Review of draft-ietf-tram-turn-mobility
Requested rev. no specific revision (document currently at 09)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-08-24
Requested 2016-08-03
Authors Tirumaleswar Reddy.K, Dan Wing, Prashanth Patil, Paal-Erik Martinsen
Draft last updated 2016-08-24
Completed reviews Genart Last Call review of -03 by Pete Resnick (diff)
Genart Telechat review of -08 by Pete Resnick (diff)
Secdir Last Call review of -02 by David Waltermire (diff)
Rtgdir Early review of -03 by Tony Przygienda (diff)
Assignment Reviewer Tony Przygienda 
State Completed
Review review-ietf-tram-turn-mobility-03-rtgdir-early-przygienda-2016-08-24
Reviewed rev. 03 (document currently at 09)
Review result Has Issues
Review completed: 2016-08-24



I have been selected as the Routing Directorate reviewer for draft-ietf-tram-turn-mobility-03. The Routing Directorate seeks to review all routing or
 routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see


Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call
 comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-tram-turn-mobility-03.txt

Reviewer: Tony Przygienda

Review Date: 18 Aug 16

Intended Status: Standards




Overall, clear draft, fairly straight-forward extension to STUN. Possible improvement and minor security holes.


I have some concerns about this document that I think should be commented on/addressed/resolved before publication.




To prevent an in-path attack with replying mobility tickets I would add a sentence to the draft saying that the newly generated mobility ticket on refresh
 response MUST be different from the previous one (that can be assured by including a nonce or something even if the refresh doesn’t change the allocation). An even stronger replay attack could include a client nonce in the mobility ticket on the allocate request
 that MUST be used to generate the ticket. The nonce would be repeated in the Refresh request with the ticket. In a sense it would be best if the mobility ticket could not be reused without a client and a server context stored.



If the ticket is reused/corrupt, I’m missing according procedures for an error in the Refresh Response, i.e. an error response code with “mobility ticket invalid” and description what happens
 (is the allocation dropped, old value retained?)




--- tony