Last Call Review of draft-ietf-babel-dtls-06
review-ietf-babel-dtls-06-rtgdir-lc-rogge-2019-07-05-00

Request Review of draft-ietf-babel-dtls
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2019-07-05
Requested 2019-06-20
Requested by Martin Vigoureux
Draft last updated 2019-07-05
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 (diff)
Assignment Reviewer Henning Rogge
State Completed
Review review-ietf-babel-dtls-06-rtgdir-lc-rogge-2019-07-05
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/fuvl_TQmvfqxbtq5Qv12qB_ok4M
Reviewed rev. 06 (document currently at 09)
Review result Has Issues
Review completed: 2019-07-05

Review
review-ietf-babel-dtls-06-rtgdir-lc-rogge-2019-07-05

//resend to RTG DIR list
Hi,

I was asked by the Routing Directorate to do a last call review of
draft-ietf-babel-dtls-06.

I like that the draft is quite short, which is a good thing for a
security draft. I have found a few question you can consider to
address in the final document.

Chapter 2.3:
I wonder if using DTLS protected unicast Hellos should be mandatory...
using unprotected multicast to determine bidirectional reachability
looks like a good way to do a cheap denial of service attack.

Chapter 2.5:
What happens when a node starts a new DTLS connection and there is
already one in the neighbor table? This could both be an attempt to
attack Babel, a reboot of a node or just a matter of misconfiguration
of two nodes.

Chapter 3:
Different pairs of nodes could select different ciphers, resulting in
different MTUs. I assume this is no problem for Babel (could be
mentioned in the chapter).

Some of the design decisions of regarding the three questions could be
mentioned in chapter 5 (Security Implications).

Henning Rogge