Skip to main content

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 revision 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
Result Ready
Completed 2012-07-13
review-ietf-v6ops-ra-guard-implementation-secdir-early-moriarty-2012-07-13-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.



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