Last Call Review of draft-ietf-trill-oam-req-04
review-ietf-trill-oam-req-04-secdir-lc-gondrom-2013-01-03-00
Request | Review of | draft-ietf-trill-oam-req |
---|---|---|
Requested revision | No specific revision (document currently at 05) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2013-01-03 | |
Requested | 2012-12-13 | |
Authors | Tissa Senevirathne , David Mich Bond , Sam Aldrin , Yizhou Li , Rohit Watve | |
I-D last updated | 2013-01-03 | |
Completed reviews |
Genart Last Call review of -04
by Wassim Haddad
(diff)
Secdir Last Call review of -04 by Tobias Gondrom (diff) |
|
Assignment | Reviewer | Tobias Gondrom |
State | Completed | |
Request | Last Call review on draft-ietf-trill-oam-req by Security Area Directorate Assigned | |
Reviewed revision | 04 (document currently at 05) | |
Result | Has issues | |
Completed | 2013-01-03 |
review-ietf-trill-oam-req-04-secdir-lc-gondrom-2013-01-03-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 ust like any other last call comments. This ID is informational and specifies requirements for operations, administration and maintenance (OAM) in TRILL (Transparent Interconnection of Lots of Links). The document lists requirements from an operational perspective. And less from a security perspective. Section "4.8. Security and Operational considerations" is very brief. And although I like the basic attitude of the first sentence there "Methods MUST be provided to protect against exploitation of OAM framework for security and denial of service attacks." The section is not clear about which requirements might derive from the "protect against exploitation of OAM ...for security...". The draft could benefit from deriving from this security consideration statement a set of clear and specific requirements for OAM for TRILL and/or linking them to the operational requirements listed in the previous sections. Section 5 is just a pointer to section 4.8 and could be merged with section 4.8 and/or removed. It is reasonable to refer to the basic security considerations for TRILL in RFC6325, but it would be good to add/think about requirement implications from security requirements for OAM. Best regards, Tobias