Protecting the Router Control Plane
draft-ietf-opsec-protect-control-plane-06

[Ballot discuss] This is a good document, but I had trouble with one aspect. The document talks about filtering and rate limiting ICMP traffic and ...

[Ballot discuss]
This is a good document, but I had trouble with one aspect. The document
talks about filtering and rate limiting ICMP traffic and entirely dropping
all fragmented packets. The document seemed to be unclear whether such
drastic measures are to be applied to the traffic destined to the router
itself or all traffic flowing through this. Dropping all fragmented
traffic through the router would be a very unfortunate design, and would
have severe impacts to the service that it provides to Internet users.

Please clarify that you meant to filter only traffic destined to the
device itself, i.e., with a destination address being one of the
router's addresses.

[Ballot comment] Ari Keränen had this comment: 4. Security Considerations The filter above leaves the router susceptible to discovery from any host in the Internet ...

[Ballot comment]
Ari Keränen had this comment:

4.  Security Considerations

    The filter above leaves the router susceptible to discovery from any
    host in the Internet.  If network operators find this risk
    objectionable, they can reduce the exposure by restricting the sub-
    networks from which ICMP Echo requests or traceroute packets are
    accepted.

In practice this does not help much, since, e.g., TCP scanning would be
still possible.

[Ballot discuss] Appendix A., paragraph 0: > Appendix A. Configuration Examples DISCUSS: I believe that the sequence of configuration commands in appendix A.1 and A ...

[Ballot discuss]
Appendix A., paragraph 0:
> Appendix A.  Configuration Examples

  DISCUSS: I believe that the sequence of configuration commands in
  appendix A.1 and A.2 constitute "code" (components intended to be
  directly processed by a computer). This means that some boilerplate
  text needs to be inserted, see
  http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf

[Ballot comment] Section 1 While software instructions run on both planes, the router control plane software is usually not optimized for high speed packet handling ...

[Ballot comment]
Section 1

  While software instructions run on both planes, the
  router control plane software is usually not optimized for high speed
  packet handling.

Did you actually mean "router control plane *hardware* is usually not
optimized"? It seems to me that the software *will* be optimized since
who would not want their control plane to scale well?

[Ballot comment] "Modern router architecture design maintains a strict separation of forwarding and router control plane hardware and software." Firstly I agree with the sentiment ...

[Ballot comment]
"Modern router architecture design maintains a strict separation of forwarding and router control plane hardware and software."

Firstly I agree with the sentiment of this statement, however whilst this is true in all high end core routers, and in many mid range routers, it is not universally true. The crossover point between distributed designs and classic designs depends on the current ability of CPUs and is thus always in a state of flux

It is also worth noting that the need to provide isolation and stability for the cp with work conservation and fast discard of rouge cp packets has been known and incorporated into designs for at least the past 30 years.

======

  o  Drop all IP packets that are fragments

There is some text on this later, but the reader would find it useful to have this explained up front. At least a forward reference would be useful.

[Ballot comment] It might be useful to add DHCP to the example because of the DHCP relay function, rate limiting inbound DHCP traffic from clients ...

[Ballot comment]
It might be useful to add DHCP to the example because of the DHCP
relay function, rate limiting inbound DHCP traffic from clients and
restricting traffic from servers to a list of known DHCP servers.

[Ballot discuss] As noted in the Glen Zorn's SECDIR review (http://www.ietf.org/mail-archive/web/secdir/current/msg02282.html) the RADIUS port #s ...

[Ballot discuss]
As noted in the Glen Zorn's SECDIR review (http://www.ietf.org/mail-archive/web/secdir/current/msg02282.html) the RADIUS port #s listed don't match up with the IANA port # registry.  The authors have agreed to make the appropriate changes to the text and the appendices.  After the agreed changes are incorporated and posted in a new version or RFC editor note, I'll clear my discuss.

[Ballot comment] Thanks. Revision -05 addresses the Routing Area Directorate review. I will return and perform my own review, but for now I have cleared ...

[Ballot comment]
Thanks.
Revision -05 addresses the Routing Area Directorate review.
I will return and perform my own review, but for now I have cleared my Discuss.

[Ballot discuss] This is an interim Discuss. I shall return and possibly add further comments after I have reviewed the document. The Routing Directorate review ...

[Ballot discuss]
This is an interim Discuss. I shall return and possibly add further comments after I have reviewed the document.

The Routing Directorate review by Acee Lindem came out on 12/2 while the I-D was in IETF Last Call and should, therefore, be considered as last call comments and should be addressed.

For the record, Acee's review is included below. There is only one point of substance, but a large number of minor edits.

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