Protecting the Router Control Plane
Note: This ballot was opened for revision 04 and is now closed.
Jari Arkko (was Discuss) Yes
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.
( Ron Bonica ) Yes
( Dan Romascanu ) Yes
Comment (2010-12-15 for -)
I support Sean's DISCUSS
( Stewart Bryant ) (was Discuss) No Objection
"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.
( Gonzalo Camarillo ) No Objection
( Ralph Droms ) No Objection
Comment (2010-12-15 for -)
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.
( Lars Eggert ) (was Discuss) No Objection
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.
( Adrian Farrel ) (was Discuss) No Objection
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?
( Russ Housley ) (was Discuss) No Objection
( Tim Polk ) No Objection
Nice document. Clear presentation, much appreciated. +1 on Sean's discuss...