Subject: [RTG-DIR] Routing Area Directorate Review of draft-ietf-opsec-protocol-plane-04.txt (resending with authors copied since draft-ietf... bounced)

From: Acee Lindem <[email-masked]>
Date: Thu, 2 Dec 2010 12:03:55 -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

---

From: Carlos Pignataro <[email-masked]>
Date: Sat, 04 Dec 2010 22:31:47 -0500

[Correcting the draft-ietf-... email address]

Acee,

Many thanks for a most thorough and useful review. Please see inline.

> to be fixed before this document should move forward.

Thanks for this summary, we believe we have fixed this major issue, as
well as minor issues and nits. We have all the changes in our working copy.

Comments below.

>   virtual links are not the norm.

Great catch, thank you. This is the change we are making here:

From:

   o  Permit OSPF traffic from routers within subnet 192.0.2.0/24 and
      OSPFv3 traffic from subnet 2001:DB8:1::/48

To:

   o  Permit OSPF traffic from routers within subnet 192.0.2.0/24 and
      OSPFv3 traffic from IPv6 Link-Local unicast addresses (FE80::/10)

[and corresponding example config updates]

We thought about adding a note mentioning Virtual Links but decided
against it.

>    the target. However, I realize it is a bit late to ask for this. 

We discussed this but decided against adding such network diagram.

>   been detected."? This isn't clear to me. How would you know the

Reworded to this, please let us know if this does not help:

    when these rate limiters
    become active (i.e., when traffic is policed). This in turn serves
    as an indicator that either the normal traffic rates have increased
    or out of policy traffic rates have been detected. More thorough
    analysis of the traffic flows and rate-limited traffic is needed to
    identify which of these two cases triggered the rate limiters.

>   and ND since details of their functionality are referenced?

We thought about this earlier and decided against it. We are agreeable
to adding these references and corresponding citations if the shepherd
or ADs think it adds to the doc. However, our thinking was that there
are very many protocols mentioned in this document and although reading
about them would enhance the operators understanding, it would not
change the main message from this document. The exception here is
ICMPv6, and Informative would be warranted, but instead we are covering
this with the Informative reference to RFC 4890 (that has of course RFC
4443 as Normative, but speaks as to the filtering aspects).

> Editorial Nits:

Many thanks for the thorough review ! Follow-ups inline, plus implicit
Ack for changes silently made as suggested.

>    However, I'll leave these to the RFC Editor. 

Ack, sounds good.

>    "diverted from" and "up to" to "to".    

Used "from".

>    always on" to "are enabled by default or always enabled". 

Used "active" instead of "enabled" as per Gen-ART suggestion that
flagged the same nit.

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

Sure, (changed in the working copy as both ways sound OK to me ,) but
why is "herein provided" incorrect here?

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

Perhaps "test a new circuit turn-up"? Or "provisioning of"? `Turn up of
a circuit` seems to be a fairly common phrase. Changed to "deployment"
but curious about the suggestion.

>   Finally, should RSVP be spelled out consistent with other explicitly

Sure, <http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt>
now up-to-date does not mark RSVP as well-known.

>    a more" and "or isolating valid" with "or classifying valid". 

Used "filtering a more".

>   party applying the filters in the document. draft-ietf-opsec-protocol-plane-04.txt

Changed all of these except the first two suggestions.

>   traffic has been originated" is redundant. Change to simply 

Redundancy on purpose to add emphasis.

>   Transmission Unit Discovery (PMTUD)". 

Thanks much !

-- Carlos.

---

From: Acee Lindem <[email-masked]>
Date: Mon, 6 Dec 2010 06:00:35 -0500

Hi Carlos, 

The corrections all sound good to me. See inline. 

> We thought about adding a note mentioning Virtual Links but decided

This is exactly how I would have corrected the document.  

>    identify which of these two cases triggered the rate limiters.

Yes - this is clearer. 

> 4443 as Normative, but speaks as to the filtering aspects).

Ok. 

> why is "herein provided" incorrect here?

Both are correct. However, "provided herein" is the more common alternative and, IMHO, sounds much more natural. The form, "herein provided", sounds like it came out of a legal document. You can confirm the usage using a Google "exact phrase" search. 

> but curious about the suggestion.

I believe "deployment of" just reads better than "turn up of". I wouldn't use "provisioning of" since links may be "provisioned" well in advance of actually being "deployed". 

> Redundancy on purpose to add emphasis.

Ok - consider the following sentence. 

Over the Christmas holidays, many christians will visit Jesus'  birthplace, where He was born. 

Thanks,
Acee

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 6 Dec 2010 07:57:38 -0600

Hi Acee,

Very many thanks again for the follow-up. I agree with (and appreciate)
all your comments.
We have all these changes in our working copy, that we will ship early
this week.

Thanks,

-- Carlos.

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: Monday, December 06, 2010 6:01 AM
To: Carlos Pignataro (cpignata)
Cc: Adrian Farrel; [email-masked];
[email-masked]; [email-masked];
[email-masked]; Rodney Dunn (rodunn); Dave Dugal
Subject: Re: [RTG-DIR] Routing Area Directorate Review of
draft-ietf-opsec-protocol-plane-04.txt (resending with authors copied
since draft-ietf... bounced)

Hi Carlos, 

Yes - this is clearer. 

Ok. 

> why is "herein provided" incorrect here?

Both are correct. However, "provided herein" is the more common
alternative and, IMHO, sounds much more natural. The form, "herein
provided", sounds like it came out of a legal document. You can confirm
the usage using a Google "exact phrase" search. 

> but curious about the suggestion.

I believe "deployment of" just reads better than "turn up of". I
wouldn't use "provisioning of" since links may be "provisioned" well in
advance of actually being "deployed". 

Over the Christmas holidays, many christians will visit Jesus'
birthplace, where He was born. 

Thanks,
Acee