Early Review of draft-ietf-babel-dtls-00
review-ietf-babel-dtls-00-rtgdir-early-przygienda-2018-09-26-00

Request Review of draft-ietf-babel-dtls
Requested rev. no specific revision (document currently at 07)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2018-09-24
Requested 2018-08-27
Requested by Donald Eastlake
Draft last updated 2018-09-26
Completed reviews Rtgdir Early review of -00 by Tony Przygienda (diff)
Secdir Early review of -03 by Sean Turner (diff)
Rtgdir Last Call review of -06 by Henning Rogge (diff)
Genart Last Call review of -05 by Dan Romascanu (diff)
Secdir Last Call review of -07 by Sean Turner
Comments
QA review.
Assignment Reviewer Tony Przygienda
State Completed
Review review-ietf-babel-dtls-00-rtgdir-early-przygienda-2018-09-26
Reviewed rev. 00 (document currently at 07)
Review result Has Issues
Review completed: 2018-09-26

Review
review-ietf-babel-dtls-00-rtgdir-early-przygienda-2018-09-26

I have been selected to do a routing directorate “early” review of this draft.
​https://datatracker.ietf.org/doc/draft-ietf-babel-dtls

Document: draft-ietf-babel-dtls
Reviewer: Tony Przygienda
Intended Status: STD
Summary:
Choose from this list...

  *   I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG. Concerns are not defects but basically request for some clarification in document and reconsideration on minor issues
Comments:

·         Draft makes inherent sense, of significance for future work in the routing area IMO for other protocols if the security requirements for routing keep on tightening

·         I think that the draft will benefit from an explicit justification why I solution based on SHA-1 cannot satisfy the security profile desired. Reading the draft I assumed that the main requirement was confidentiality which was incorrect. Discussions with the authors let to quite interesting insights that should be captured in the draft IMO.

·          The section explaining that all the babel frames must be unicast with DTLS could benefit from a small rewrite to read easier

·         I recommend the authors to rethink where they want to change base spec babel MTU by a hard offset. Even the DTLS can evolve in a Backwards compatible manner changing sizes. From experience with tunnels and routing protocols it may be better  to just keep the original spec and imply than an implementation supporting DTLS has to deal with the according size overhead

thanks

--- tony