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

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?

Section 3., paragraph 0:
> 3.  Method

  You should be MUCH more clear that Section 3.1 gives a particular
  EXAMPLE of how one might set up a filter to protect the control plane,
  and that any actual deployments SHOULD NOT blindly follow that example
  without considering the network setup at hand.


Section 4., paragraph 1:
>    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.

  Several techniques for tracerouting exists, and "traceroute" packets
  are therefore not so easy to identify. What can be done is preventing
  "TTL expired" ICMP responses from being sent, but that can have
  drawbacks.

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.

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

Nice document.  Clear presentation, much appreciated.

+1 on Sean's discuss...