Subject: [RTG-DIR] Routing Area Directorate Review of draft-ietf-opsec-protocol-plane-04.txt (Reply to this one - removed unwanted recipient)

From: Acee Lindem <[email-masked]>
Date: Thu, 2 Dec 2010 12:17:28 -0500

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review. The purpose
of the review is to provide assistance to the Routing ADs. For more 
information about the Routing Directorate, please see 
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document:  draft-ietf-opsec-protocol-plane-04.txt
Reviewer: Acee Lindem
Review Date: 2010-12-02
IETF LC End Date:  2010-12-03
Intended Status: Informational

Summary: This document accomplishes its intended purpose of providing
guidance on defining filters to protect the router control plane. The 
fact that the OPSEC WG adopted this as a WG document indicates that this
is a viewed as a worthwhile effort. I found one major issue that needs 
to be fixed before this document should move forward.

Major Issues: 

Page 5, unless there are virtual links, all OSPFv3 packets use 
 an IPv6 link local address as the source address. Hence, you need
 to allow OSPFv3 packets sourced from the IPv6 link-local range
 (FE80::/10). I'd simply remove the IPv6 global prefix since
 virtual links are not the norm.

 Of course, the examples in the appendices need to be updated as well. 
 I didn't see any other problems with IPv6 link-local addresses. 
 Other than ICMPv6 which has no source address filter, the 
 other protocols filtered run on top of UDP or TCP.

Minor Issues:

General: It would be nice if there were a network diagram showing
  the target router and where the referenced subnets sit in relation to 
  the target. However, I realize it is a bit late to ask for this. 

Page 10, Third Paragraph - What do you mean by "when 
 rate limiters become active which serve as indicator that either
 normal traffic has increased or out of policy traffic rates have
 been detected."? This isn't clear to me. How would you know the
 difference? 

Section 3.3 - Should there be informative references to ICMP, ICMPv6,
 and ND since details of their functionality are referenced?

Editorial Nits:

General - There seem to be a lot of commas missing from the text.
  However, I'll leave these to the RFC Editor. 

Page 3, last paragraph - Expand out first occurrence of the
  acronym "Denial of Service (DoS)". 

Page 4, first paragraph - Change "diverted out of" to 
  "diverted from" and "up to" to "to".    

Page 4, penultimate paragraph - Change "are on by default or
  always on" to "are enabled by default or always enabled". 

Page 4, last paragraph - Change "sample legitimate traffic" to
  "legitimate traffic example" consistent with the terminology
  used elsewhere. This is clearly more of an "example" than a 
  "sample". 

Page 5, 3.1 bullets - Change "DNS resolvers" to "DNS servers"
  consistent with what is configured in most router implementations. 

Page 6, Section 3.2, First Paragraph - Change "match only on" to
  "match only". Also change, "any traffic matching traffic for" 
  to simply "any traffic matching". 

Page 7, first paragraph - Change "may not be this obvious" to 
   "may not be as obvious as the example described herein". 

Page 7, first paragraph - Change "herein provided" to "provided
   herein". 

Page 7, last paragraph - Change "turn up of" to "deployment of". 

Page 7, last paragraph - Replace "neighbor discovery" with 
 "Neighbor Discovery (ND)" and "multicast listener discovery
 version 2 (MLDv2)" with "Multicast Listener Discovery version 2
 (MLDv2)". 

Page 8, General - Use consistent capitalization for "IP optioned
 traffic"/"IP Optioned traffic". 

Page 8, first paragraph - The phrase "(and statistic gathering)"
 seems as though it should not be in parentheses. 

Page 8, second paragraph - Change "may not be possible" to "may not
 be feasible". Also replace "referenced here" with "included herein". 
 Finally, should RSVP be spelled out consistent with other explicitly
 referenced protocols? 

Page 8, third paragraph - Replace "isolating a more" with "filtering
  a more" and "or isolating valid" with "or classifying valid". 

Page 8, last paragraph - Change "matched in a" to "matched to a". 
 Change "allows the default traffic" to simply "accepts default 
 traffic".  Change "rather than just dropping it" to "as opposed to
  dropping it". Change "functionality of the device" to simply "device 
 functionality". Change "was highlighted" to "was chosen". Change
 "implementor" to "operator" consistent to other references to the
 party applying the filters in the document. draft-ietf-opsec-protocol-plane-04.txt

Page 9, first paragraph - Change "is being" to "has been identified 
 and" 

Page 9, third paragraph - Change "forensic analysis afterwards" to
 "ongoing forensic analysis". 

Page 9, Fourth paragraph - Change "on the Internet" to "in the
 Internet". 

Page 9, last paragraph - The phrase "at the source where the
 traffic has been originated" is redundant. Change to simply 
 "at the source". 

Page 10, second paragraph - Change "PMTUD" to Path Maximum 
 Transmission Unit Discovery (PMTUD)". 

Thanks,
Acee