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 |