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