Skip to main content

Last Call Review of draft-ietf-isis-ieee-aq-
review-ietf-isis-ieee-aq-secdir-lc-barnes-2011-01-25-00

Request Review of draft-ietf-isis-ieee-aq
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-01-18
Requested 2011-01-04
Authors Paul Unbehagen , Nigel Bragg , David Allan , Don Fedyk , Peter J. Ashwood-Smith
I-D last updated 2011-01-25
Completed reviews Secdir Last Call review of -?? by Richard Barnes
Assignment Reviewer Richard Barnes
State Completed
Request Last Call review on draft-ietf-isis-ieee-aq by Security Area Directorate Assigned
Completed 2011-01-25
review-ietf-isis-ieee-aq-secdir-lc-barnes-2011-01-25-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 defines a set of additional sub-TLVs for IS-IS that enable IS-IS
nodes to communicate information related to the IEEE 802.1aq Shortest Path
Bridging system. The Security Considerations section of the document claims
that these extensions do not create any additional security risks.

This may be the case, but I found it difficult to evaluate this claim given a
basic knowledge of IS-IS and none of 802.1aq.  My high-level impression is that
the negotiations conducted through the mechanism defined in this document have
the ability to affect layer-2 routing in new ways, with the implication that
malicious actors in the protocol have new ways to influence traffic patterns or
deny service to users.

It would be helpful if the Security Considerations could explain why such
manipulations are not possible using these extensions (which would seem to
defeat the purpose of the extensions), or if they are, what assumptions need to
be true in order for the protocol to operate properly.  Do all internal network
elements need to behave as specified?  Only the SPB instances?

--Richard