Skip to main content

Last Call Review of draft-ietf-roll-trickle-mcast-05
review-ietf-roll-trickle-mcast-05-secdir-lc-kivinen-2013-11-21-00

Request Review of draft-ietf-roll-trickle-mcast
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-10-24
Requested 2013-10-17
Authors Jonathan Hui , Richard Kelsey
I-D last updated 2013-11-21
Completed reviews Genart Last Call review of -05 by Christer Holmberg (diff)
Genart Last Call review of -07 by Christer Holmberg (diff)
Genart Telechat review of -11 by Christer Holmberg (diff)
Secdir Last Call review of -05 by Tero Kivinen (diff)
Opsdir Last Call review of -09 by Benoît Claise (diff)
Assignment Reviewer Tero Kivinen
State Completed
Request Last Call review on draft-ietf-roll-trickle-mcast by Security Area Directorate Assigned
Reviewed revision 05 (document currently at 12)
Result Has nits
Completed 2013-11-21
review-ietf-roll-trickle-mcast-05-secdir-lc-kivinen-2013-11-21-00
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document describes the Multicast protocol for Low and Lossy
Networks. This protocol uses trickle algorithm. I am not familiar
enough to trickle to really analyze what the protocol does. Security
considerations section mentions that the protocol uses sequence
numbers to keep track of messages, and attacker who can insert
messages can mess up with those sequence numbers, and attacker can
then flush messages from the buffered messages list, and can also
allow setting it high enough so recipients will not get any messages
as they have too small sequence number.

The protocol has no protection against this attack, but notes that
both of those are denial-of-service attacks and devices can protect
against them by using link-layer security mechanisms. It also claims
that those mechanisms are typically employed without specifying which
security methods it is pointing to. I do not know how often those
link-layer security methods are really used. Perhaps it would be
useful to list some of those security methods here.

I do not have any other comments for the protocol, and otherwise I
think the document is ready, but as I said I did not have time to
really analyze the protocol itself.
-- 
kivinen at iki.fi