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 documenttalks about filtering and rate limiting ICMP traffic and ...

[Ballot discuss]This is a good document, but I had trouble with one aspect. The documenttalks about filtering and rate limiting ICMP traffic and entirely droppingall fragmented packets. The document seemed to be unclear whether suchdrastic measures are to be applied to the traffic destined to the routeritself or all traffic flowing through this. Dropping all fragmentedtraffic through the router would be a very unfortunate design, and wouldhave severe impacts to the service that it provides to Internet users.

Please clarify that you meant to filter only traffic destined to thedevice itself, i.e., with a destination address being one of therouter'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 ...

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

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

05

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

05

Stewart Bryant

[Ballot Position Update] New position, Discuss, has been recorded

2010-12-15

05

Robert Sparks

[Ballot Position Update] New position, No Objection, has been recorded

2010-12-15

05

Dan Romascanu

[Ballot comment]I support Sean's DISCUSS

2010-12-15

05

Dan Romascanu

[Ballot Position Update] New position, Yes, has been recorded

2010-12-15

05

Ralph Droms

[Ballot comment]It might be useful to add DHCP to the example because of the DHCPrelay function, rate limiting inbound DHCP traffic from clients ...

[Ballot comment]It might be useful to add DHCP to the example because of the DHCPrelay function, rate limiting inbound DHCP traffic from clients andrestricting traffic from servers to a list of known DHCP servers.

[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

05

Ralph Droms

[Ballot Position Update] New position, No Objection, has been recorded

2010-12-14

05

Peter Saint-Andre

[Ballot Position Update] New position, No Objection, has been recorded

[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

05

Sean Turner

[Ballot Position Update] New position, Discuss, has been recorded

2010-12-13

05

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

05

Adrian Farrel

[Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss

2010-12-12

05

(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

04

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-relateddrafts as they pass through IETF last call and IESG review. The purposeof 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, itwould be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them throughdiscussion or by updating the draft.

Summary: This document accomplishes its intended purpose of providingguidance on defining filters to protect the router control plane. The fact that the OPSEC WG adopted this as a WG document indicates that thisis 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 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, 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

The IESG has received a request from the Operational SecurityCapabilities for IP Network Infrastructure WG (opsec) to consider thefollowing document:- 'Protecting The Router Control Plane' <draft-ietf-opsec-protect-control-plane-04.txt> as an Informational RFC

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