Early Review of draft-ietf-v6ops-ra-guard-implementation-
review-ietf-v6ops-ra-guard-implementation-secdir-early-moriarty-2012-07-13-00

Request Review of draft-ietf-v6ops-ra-guard-implementation
Requested rev. no specific revision (document currently at 07)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2012-11-09
Requested 2012-06-28
Authors Fernando Gont
Draft last updated 2012-07-13
Completed reviews Genart Last Call review of -?? by Francis Dupont
Genart Last Call review of -?? by Francis Dupont
Genart Telechat review of -07 by Francis Dupont
Secdir Early review of -?? by Kathleen Moriarty
Assignment Reviewer Kathleen Moriarty
State Completed
Review review-ietf-v6ops-ra-guard-implementation-secdir-early-moriarty-2012-07-13
Review result Ready
Review completed: 2012-07-13

Review
review-ietf-v6ops-ra-guard-implementation-secdir-early-moriarty-2012-07-13



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.




 




draft-ietf-v6ops-ra-guard-implementation-04 updates RFC6105 as a BCP. 




   The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly




   employed to mitigate attack vectors based on forged ICMPv6 Router




   Advertisement messages.  Many existing IPv6 deployments rely on RA-




   Guard as the first line of defense against the aforementioned attack




   vectors.  However, some implementations of RA-Guard have been found




   to be prone to circumvention by employing IPv6 Extension Headers.




   This document describes the evasion techniques that affect the




   aforementioned implementations, and formally updates RFC 6105, such




   that the aforementioned RA-Guard evasion vectors are eliminated.




 




Review Summary:




The draft is mostly ready (the draft introduces new requirements to protect against specific attack vectors and addresses them well), but I would recommend some stronger language in the Security Considerations
section in the following areas:




 




In the start of the security considerations section, it says that ‘advice’ is given to correct the problems.  Reading through the draft this updates and this draft, would saying ‘new requirements’ or ‘additional
requirements’ be better?  The updates proposed in this draft use RFC2119 language with MUST statements to correct a few issues (RA guards were not handling fragmentation or paying attention to IPv6 extension headers).




 




Also, to be compliant with this BCP, shouldn’t the security considerations section just require compliance with RFC5722?  The indented paragraph in the security considerations section could be updated to state
this requirement to make it a clear requirement from this draft.




 




Thank you,




Kathleen