Hello, 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 http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 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   Summary:   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.   Comments:   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.   Omission: 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?)   Thanks   --- tony