datatracker.ietf.org
Sign in
Version 5.6.2.p5, 2014-08-04
Report a bug

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

Yes
(was Discuss)
No Objection
(was Discuss)
(was Discuss)
(was Discuss)
(was Discuss)
(was Discuss)

Note: This ballot was opened for revision 04 and is now closed.

Summary: Has enough positions to pass.

Adrian Farrel

Comment (2010-12-15 for -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?

Jari Arkko

Comment (2010-12-16 for -06)

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.

[Dan Romascanu]

Comment (2010-12-15 for -)

I support Sean's DISCUSS

[Lars Eggert]

Comment (2010-12-16 for -06)

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.

[Ralph Droms]

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.

[Stewart Bryant]

Comment (2010-12-15 for -06)

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

[Tim Polk]

Comment (2010-12-15 for -)

Nice document.  Clear presentation, much appreciated.

+1 on Sean's discuss...