Skip to main content

Early Review of draft-ietf-tram-turn-mobility-03
review-ietf-tram-turn-mobility-03-rtgdir-early-przygienda-2016-08-24-00

Request Review of draft-ietf-tram-turn-mobility
Requested revision 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
I-D 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
Request Early review on draft-ietf-tram-turn-mobility by Routing Area Directorate Assigned
Reviewed revision 03 (document currently at 09)
Result Has issues
Completed 2016-08-24
review-ietf-tram-turn-mobility-03-rtgdir-early-przygienda-2016-08-24-00

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