Last Call Review of draft-ietf-bess-multicast-damping-04
review-ietf-bess-multicast-damping-04-secdir-lc-eastlake-2016-04-28-00
| Request | Review of | draft-ietf-bess-multicast-damping |
|---|---|---|
| Requested revision | No specific revision (document currently at 06) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2016-05-03 | |
| Requested | 2016-03-23 | |
| Authors | Thomas Morin , Stephane Litkowski , Keyur Patel , Zhaohui (Jeffrey) Zhang , Robert Kebler , Jeffrey Haas | |
| Draft last updated | 2016-04-28 | |
| Completed reviews |
Genart Last Call review of -04
by
Joel M. Halpern
(diff)
Secdir Last Call review of -04 by Donald E. Eastlake 3rd (diff) Opsdir Last Call review of -04 by Bert Wijnen (diff) |
|
| Assignment | Reviewer | Donald E. Eastlake 3rd |
| State | Completed | |
| Review |
review-ietf-bess-multicast-damping-04-secdir-lc-eastlake-2016-04-28
|
|
| Reviewed revision | 04 (document currently at 06) | |
| Result | Has Nits | |
| Completed | 2016-04-28 |
review-ietf-bess-multicast-damping-04-secdir-lc-eastlake-2016-04-28-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. Document
editors and WG chairs should treat these comments just like any other last call
comments.
This document describes procedures for damping multicast virtual private
network routing state changes to control the effect, particularly the control
plane load, of the churn due to the dynamic multicast group membership in
customer sites.
Security:
Overall, I think it is ready with nits but my confidence in that assessment is
not very high.
The feature specified in this document is aimed at limiting one type of denial
of service, or at least at interference to some users by others: denial or
interference due to excessive control plane traffic due to a high rate of
multicast group membership change. Still, it makes me a bit queasy that the
document has not one word, even by reference, about security for the setting or
changing of the parameters used at a node in the damping algorithm. I suppose
it is reasonable that it doesn't talk about how any of the control messages
involved are protected or authenticated since the document is just about
suppressing such messages...
The Security Considerations section has a reasonable discussion of how and to
what extent the mechanisms specified provide the services claimed.
Page 15, Section 9 (Security Considerations), 1st paragraph starting on this
page: There are a number of things wrong with the following sentence:
Note well that the two
mechanism may interact: state for which Prune has been requested may
still remain taken into account for some time if damping has been
triggered and hence result in otherwise acceptable new state from
being successfully created.
I would guess it should be "result in preventing otherwise" or should end with
"state not being successfully created". Here is a suggested replacement:
The two mechanisms may interact as follows: i
f damping has
been triggered,
state for which
Prune has been requested may remain
and still be taken into account
for some time
resulting in an
otherwise acceptable new state not
being created.
Editorial:
This document is very heavy with acronymic jargon with no expansion or
definition in this document. However, most of it is defined in other RFCs that
are referenced.
Although I am willing to accept that it is just a matter of style, this
document has lots of extra words that add nothing but verbosity. Things that
could be completely dropped with no loss, like starting a sentence with
"Additionally, it is worth nothing that ...". If it wasn't worth noting, it
presumably wouldn't be in the document.
Page 4, Section 3, 3rd paragraph: "...this technique will allow to meet the
goals..." -> "...this technique will meet the goals..."
Page 12, Section 7.2: "More specifically it is RECOMMENDED to complement the
existing ... (e.g. MRIB states): ..." -> "Complementing the existing ... (e.g.
MRIB states) is RECOMMENDED: ..."
Page 13, Section 7.3, 2nd paragraph: What does "dimentioning" mean? Also
"...state churn to go beyond what..." -> "...state churn going beyond what..."
Page 14, Section 9, 3rd paragraph: The word "shall" is used. While not
capitalized, this word sounds quite mandatory to me but it is not used in a
mandatory requirement context... I suggest "shall rely upon" -> "relies on".
Page 15, near the top: "should rely upon already" -> "should use already"
Finally, while I understand that others have a different opinion, I find it
objectionable that not a single first page author is willing to list a
telephone number of any sort in the Authors' Addresses section. To my mind,
this sort of corner cutting does not speak well for the document.
Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3 at gmail.com