Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Stewart Bryant
2012-08-22
06 (System) post-migration administrative database adjustment to the Yes position for Jari Arkko
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Adrian Farrel
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2010-12-23
06 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2010-12-23
06 (System) IANA Action state changed to No IC from In Progress
2010-12-23
06 (System) IANA Action state changed to In Progress
2010-12-23
06 Amy Vezza IESG state changed to Approved-announcement sent
2010-12-23
06 Amy Vezza IESG has approved the document
2010-12-23
06 Amy Vezza Closed "Approve" ballot
2010-12-23
06 Amy Vezza Approval announcement text regenerated
2010-12-23
06 Amy Vezza Ballot writeup text changed
2010-12-17
06 Ron Bonica State changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed.
2010-12-17
06 Ron Bonica Ballot writeup text changed
2010-12-17
06 (System) Removed from agenda for telechat - 2010-12-16
2010-12-16
06 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Glen Zorn.
2010-12-16
06 Amy Vezza State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup.
2010-12-16
06 Stewart Bryant
[Ballot comment]
Related to my (now cleared) discuss

OLD
For network deployments where the protocols
    used do not rely on IP options, the …
[Ballot comment]
Related to my (now cleared) discuss

OLD
For network deployments where the protocols
    used do not rely on IP options, the filter is simpler to design in
    that it can drop all packets with any IP option set. 

NEW
For network deployments where the protocols
    used do not use IP options, the filter is simpler to design in
    that it can drop all packets with any IP option set. 

===============


"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.
2010-12-16
06 Stewart Bryant [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss
2010-12-16
06 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss
2010-12-16
06 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko
2010-12-16
06 Ron Bonica Ballot writeup text changed
2010-12-16
06 Ron Bonica Ballot writeup text changed
2010-12-16
06 Jari Arkko
[Ballot comment]
Ari Keränen had this comment:

4.  Security Considerations

    The filter above leaves the router susceptible to discovery from any
    …
[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.
2010-12-16
06 Jari Arkko
[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.
2010-12-16
06 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2010-12-16
06 Jari Arkko
[Ballot comment]
Ari Keränen had this comment:

4.  Security Considerations

    The filter above leaves the router susceptible to discovery from any
    …
[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.
2010-12-16
06 Lars Eggert
[Ballot comment]
Section 3., paragraph 0:
> 3.  Method

  You should be MUCH more clear that Section 3.1 gives a particular
  EXAMPLE of …
[Ballot comment]
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.
2010-12-16
06 Lars Eggert
[Ballot discuss]
Appendix A., paragraph 0:
> Appendix A.  Configuration Examples

  DISCUSS: I believe that the sequence of configuration commands in
  appendix A.1 …
[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
2010-12-16
06 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded
2010-12-16
06 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2010-12-15
06 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2010-12-15
06 Adrian Farrel
[Ballot comment]
Section 1

  While software instructions run on both planes, the
  router control plane software is usually not optimized for high speed …
[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?
2010-12-15
06 Tim Polk [Ballot comment]
Nice document.  Clear presentation, much appreciated.

+1 on Sean's discuss...
2010-12-15
06 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded
2010-12-15
06 Russ Housley
[Ballot discuss]
Based on the discussion that followed the posting of the Gen-ART
  Review by Roni Even on 2010-12-03. I expected a revided I-D …
[Ballot discuss]
Based on the discussion that followed the posting of the Gen-ART
  Review by Roni Even on 2010-12-03. I expected a revided I-D to be
  posdted.  It has not appeared yet.
2010-12-15
06 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss
2010-12-15
06 Russ Housley
[Ballot discuss]
Based on the discussion that followed the posting of the Gen-ART
  Review by Roni Even on 2010-12-03. I expected a revided I-D …
[Ballot discuss]
Based on the discussion that followed the posting of the Gen-ART
  Review by Roni Even on 2010-12-03. I expected a revided I-D to be
  posdted.  It has not appeared yet.
2010-12-15
06 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded
2010-12-15
06 (System) New version available: draft-ietf-opsec-protect-control-plane-06.txt
2010-12-15
06 Stewart Bryant
[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.
2010-12-15
06 Stewart Bryant
[Ballot discuss]
For network deployments where the protocols used rely on IP options, the filter is simpler to design in that it can drop all …
[Ballot discuss]
For network deployments where the protocols used rely on IP options, the filter is simpler to design in that it can drop all packets with any IP option set. 

That looks the wrong way round.
2010-12-15
06 Stewart Bryant [Ballot Position Update] New position, Discuss, has been recorded
2010-12-15
06 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2010-12-15
06 Dan Romascanu [Ballot comment]
I support Sean's DISCUSS
2010-12-15
06 Dan Romascanu [Ballot Position Update] New position, Yes, has been recorded
2010-12-15
06 Ralph Droms
[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.
2010-12-15
06 Ralph Droms
[Ballot discuss]
I'm surprised DHCP isn't mentioned anywhere in the document.  Wouldn't the DHCP relay function be implemented in the router control plane?  I understand …
[Ballot discuss]
I'm surprised DHCP isn't mentioned anywhere in the document.  Wouldn't the DHCP relay function be implemented in the router control plane?  I understand that section 3.1 is just an example and
2010-12-15
06 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2010-12-14
06 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2010-12-14
06 Sean Turner
[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 …
[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.
2010-12-14
06 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded
2010-12-13
06 Adrian Farrel
[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.
2010-12-13
06 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss
2010-12-12
06 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-12-12
05 (System) New version available: draft-ietf-opsec-protect-control-plane-05.txt
2010-12-03
06 Adrian Farrel
[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
2010-12-03
06 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded
2010-12-03
06 Ron Bonica State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation.
2010-12-03
06 Ron Bonica State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2010-12-03
06 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2010-12-01
06 Ron Bonica Placed on agenda for telechat - 2010-12-16 by Ron Bonica
2010-12-01
06 Ron Bonica Note field has been cleared by Ron Bonica
2010-12-01
06 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica
2010-12-01
06 Ron Bonica Ballot has been issued by Ron Bonica
2010-12-01
06 Ron Bonica Created "Approve" ballot
2010-11-29
06 Amanda Baber We understand that this document does not require any IANA actions.
2010-11-22
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Glen Zorn
2010-11-22
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Glen Zorn
2010-11-19
06 Cindy Morgan Last call sent
2010-11-19
06 Cindy Morgan
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Protecting The Router Control Plane) to Informational RFC


The IESG has received a request from the Operational Security
Capabilities for IP Network Infrastructure WG (opsec) to consider the
following document:
- 'Protecting The Router Control Plane'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-12-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsec-protect-control-plane/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsec-protect-control-plane/
2010-11-19
06 Ron Bonica Last Call was requested by Ron Bonica
2010-11-19
06 Ron Bonica State Changes to Last Call Requested from AD Evaluation::AD Followup by Ron Bonica
2010-11-19
06 (System) Ballot writeup text was added
2010-11-19
06 (System) Last call text was added
2010-11-19
06 (System) Ballot approval text was added
2010-10-25
06 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-10-25
04 (System) New version available: draft-ietf-opsec-protect-control-plane-04.txt
2010-10-22
06 Ron Bonica State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Ron Bonica
2010-09-15
06 Ron Bonica State Changes to AD Evaluation from AD is watching by Ron Bonica
2010-09-15
06 Ron Bonica State Changes to AD is watching from Publication Requested by Ron Bonica
2010-09-15
06 Ron Bonica Draft Added by Ron Bonica in state Publication Requested
2010-08-23
03 (System) New version available: draft-ietf-opsec-protect-control-plane-03.txt
2010-08-06
02 (System) New version available: draft-ietf-opsec-protect-control-plane-02.txt
2010-07-09
01 (System) New version available: draft-ietf-opsec-protect-control-plane-01.txt
2010-07-04
00 (System) New version available: draft-ietf-opsec-protect-control-plane-00.txt