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

["Carlos Pignataro (cpignata)" <[e-mail]>]

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:[e-mail]] 
Sent: Monday, December 06, 2010 6:01 AM
To: Carlos Pignataro (cpignata)
Cc: Adrian Farrel; [e-mail];
[e-mail]; [e-mail];
[e-mail]; 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, 

The corrections all sound good to me. See inline. 

On Dec 4, 2010, at 10:31 PM, Carlos Pignataro wrote:

> [Correcting the draft-ietf-... email address]
> 
> Acee,
> 
> Many thanks for a most thorough and useful review. Please see inline.
> 
> On 12/2/2010 12:03 PM, Acee Lindem wrote:
>> 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.
> 
> 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.
> 
>> 
>> 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.
>> 
> 
> 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.

This is exactly how I would have corrected the document.  


> 
> 
>>  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. 
>> 
> 
> We discussed this but decided against adding such network diagram.
> 
>> 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? 
> 
> 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.

Yes - this is clearer. 


> 
>> 
>> Section 3.3 - Should there be informative references to ICMP, ICMPv6,
>>  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).

Ok. 


> 
>> Editorial Nits:
>> 
> 
> Many thanks for the thorough review ! Follow-ups inline, plus implicit
> Ack for changes silently made as suggested.
> 
>> General - There seem to be a lot of commas missing from the text.
>>   However, I'll leave these to the RFC Editor. 
>> 
> 
> Ack, sounds good.
> 
>> 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".    
> 
> Used "from".
> 
>> 
>> Page 4, penultimate paragraph - Change "are on by default or
>>   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 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". 
> 
> Sure, (changed in the working copy as both ways sound OK to me ,) but
> 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. 

> 
>> 
>> 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.

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". 

> 
>> 
>> 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? 
> 
> Sure, <http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt>
> now up-to-date does not mark RSVP as well-known.
> 
>> 
>> Page 8, third paragraph - Replace "isolating a more" with "filtering
>>   a more" and "or isolating valid" with "or classifying valid". 
>> 
> 
> Used "filtering a more".
> 
>> 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
>> 
> 
> Changed all of these except the first two suggestions.
> 
>> 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". 
> 
> 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 

> 
>> 
>> Page 10, second paragraph - Change "PMTUD" to Path Maximum 
>>  Transmission Unit Discovery (PMTUD)". 
>> 
>> Thanks,
>> Acee
> 
> Thanks much !
> 
> -- Carlos.
> 
>> 
>> 
>