Subject: [OPSEC] I-D Action:draft-ietf-opsec-protect-control-plane-00.txt

From: [email-masked]
Date: Sat, 3 Jul 2010 22:45:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF.

	Title           : Protecting The Router Control Plane
	Author(s)       : D. Dugal, et al.
	Filename        : draft-ietf-opsec-protect-control-plane-00.txt
	Pages           : 17
	Date            : 2010-06-29

This memo provides a method for protecting a router's control plane
from undesired or malicious traffic.  In this approach, all
legitimate router control plane traffic is identified.  Once
legitimate traffic has been identified, a filter is deployed in the
router's forwarding plane.  That filter prevents traffic not
specifically identified as legitimate from reaching the router's
control plane or rate limited to an acceptable level.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opsec-protect-control-plane-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 5 Jul 2010 16:15:23 +0530

Hi,

Couple of comments:

o Just like OSPF, you should probably also add some filters for link level LDP as you don't want LDP to start exchanging MPLS labels with all the peers it receives HELLOs from. 

o Can some filters be added for IS-IS?

o It might also be a good idea to add some text on what some implementations do to protect the control plane without any manual configs. This would for example be, rate limiting all traffic for which ARP is unresolved or rate limiting all traffic for which there is no route in the routing table, etc. 

o Related to the above point you should also add some configs about how providers can rate limit all the ICMP host/network unreachables that it sends out, etc.

Cheers, Manav

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Sunday, July 04, 2010 11.15 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [OPSEC] I-D 
> Action:draft-ietf-opsec-protect-control-plane-00.txt
> 
> This draft is a work item of the Operational Security 
> Capabilities for IP Network Infrastructure Working Group of the IETF.
> 
>

---

From: Rodney Dunn <[email-masked]>
Date: Tue, 06 Jul 2010 11:51:16 -0400

Manav,

Thanks for the review. Comments inline at rd>

> o Just like OSPF, you should probably also add some filters for link level LDP as you don't want LDP to start exchanging MPLS labels with all the peers it receives HELLOs from.

rd> We felt the OSPF example coupled with the Applicability Statement 
would be enough for the user to understand the concept enough to extend 
the configuration to cover MPLS.

> o Can some filters be added for IS-IS?

rd> Those would be captured in the default and "family any" IOS and 
JUNOS examples.

> o It might also be a good idea to add some text on what some implementations do to protect the control plane without any manual configs. This would for example be, rate limiting all traffic for whi…

Good idea. There are a lot of one off implementations in this area that 
are Vendor/platform specific so we should keep it generic. How about in 
the Introduction we add?

"There may be additional implementation specific protections that are 
on-by-default or always-on that apply to specific traffic punt causes 
that are outside the scope of this document."

> o Related to the above point you should also add some configs about how providers can rate limit all the ICMP host/network unreachables that it sends out, etc.

rd> We made reference to that in the Security Considerations section:

"Specifically, the generation of ICMP Unreachable messages by the router 
control plane needs to be rate-limited, either implicitly within the 
router's architecture or explicitly through configuration."

Rodney

> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

---

From: Rodney Dunn <[email-masked]>
Date: Fri, 09 Jul 2010 08:44:32 -0400

Manav,

We updated the applicability statement per your suggestion:

"Additionally, there may be other vendor or implementation specific
    protection mechanisms that are on-by-default or always-on.  Those
    approaches may apply in conjunction with or in addition to the method
    described in Section 3 and illustrated in Appendices A and B. Those
    implementations should be considered as part of an overall traffic
    management plan but are outside the scope of this document.
"

Rodney

On 7/6/10 11:51 AM, Rodney Dunn wrote:
>> o Just like OSPF, you should probably also add some filters for link
>> level LDP as you don't want LDP to start exchanging MPLS labels with
>> all the peers it receives HELLOs from.
>>
>
>> o It might also be a good idea to add some text on what some
>> implementations do to protect the control plane without any manual
>> configs. This would for example be, rate limiting all traffic for
>> which ARP is unresolved or rate limiting all traffic for which there
>> is no route in the routing table, etc.
>>
>
>> o Related to the above point you should also add some configs about
>> how providers can rate limit all the ICMP host/network unreachables
>> that it sends out, etc.
>>
>

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 9 Jul 2010 10:38:28 -0600

(coffee != sleep) & (!coffee == sleep)
[email-masked] gcia

> On Behalf Of Rodney Dunn
> Sent: Tuesday, July 06, 2010 9:51 AM
> To: Bhatia, Manav (Manav)
> Cc: [email-masked]'
> Subject: Re: [OPSEC] I-D
> > o Just like OSPF, you should probably also add some filters
> for link level LDP as you don't want LDP to start exchanging
> MPLS labels with all the peers it receives HELLOs from.
> >
>
> > o It might also be a good idea to add some text on what
> some implementations do to protect the control plane without
> any manual configs. This would for example be, rate limiting
> all traffic for which ARP is unresolved or rate limiting all
> traffic for which there is no route in the routing table, etc.
> >
>
> > o Related to the above point you should also add some
> configs about how providers can rate limit all the ICMP
> host/network unreachables that it sends out, etc.
> >
>

Implicity rate-limiting is a pain to troubleshoot unless very well documented.
Most router heads would rather put in their OWN tested and validated ratelimits and be able to review them.

Also I may have missed it but bps is NOT the right measurement for ratelimiting. PPS is much more important.
I realize most ratelimiting today is done with bps but it is pps that has the real impact on the RE/CPU.

> >> implementation to automatically retrieve the ASCII version of the

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

---

From: Glen Kent <[email-masked]>
Date: Fri, 9 Jul 2010 22:17:34 +0530

> I realize most ratelimiting today is done with bps but it is pps that has the real impact on the RE/CPU.

Wouldnt there be a strong correlation between bps and pps?

Glen

---

From: Rodney Dunn <[email-masked]>
Date: Fri, 09 Jul 2010 13:16:57 -0400

Thanks Donald...

<snip>

> Most router heads would rather put in their OWN tested and validated ratelimits and be able to review them.

I agree with that. I added that note "*..*"

"Specifically, the generation of ICMP Unreachable messages by the router 
control plane needs to be rate-limited, either implicitly within the 
router's architecture or explicitly through configuration. *It is 
recommended to deploy explicit rate limiters where possible to improve 
troubleshooting and monitoring capability.*"

> I realize most ratelimiting today is done with bps but it is pps that has the real impact on the RE/CPU.

Yep.

In the Filter_Design section I added the *..* text:

" In addition to the filters, rate-limiters for certain classes of 
traffic are also installed in the forwarding plane as defined in <xref 
target="Legitimate_Traffic"/>. These rate limiters help futher control 
the traffic that will reach the control plane for each filtered class as 
well as all traffic not matching an explicit class. The actual rates 
selected for various classes is network deployment specific and analysis 
of required rates for stability should be done periodically. *It's 
important to note that the most significant factor to consider regarding 
the traffic profile going to the router control plane is the packets per 
second (pps) rate. Therefore, consideration should be taken when 
defining the rate limiters for various packet size distributions the 
potential packet rates that would be allowed.*

Those both look ok?

---

From: Rodney Dunn <[email-masked]>
Date: Fri, 09 Jul 2010 13:25:40 -0400

> Wouldnt there be a strong correlation between bps and pps?

Yep. But I do agree that calling it out more clearly would hopefully 
encourage implementers to think about how they are correlated so I added 
a bit of text around it.

Rodney

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 9 Jul 2010 12:52:36 -0600

> From: Glen Kent [mailto:[email-masked]]
> Sent: Friday, July 09, 2010 10:48 AM
> To: Smith, Donald
> Cc: [email-masked]
> Subject: Re: [OPSEC] I-D
> > Most router heads would rather put in their OWN tested and
> validated ratelimits and be able to review them.
> >
> > Also I may have missed it but bps is NOT the right
> measurement for ratelimiting. PPS is much more important.
> > I realize most ratelimiting today is done with bps but it
> is pps that has the real impact on the RE/CPU.
>
There is a correlation but its not as strong as you might think.
Most attack traffic tends to be small (40-50 bytes) , voip and other streaming protocols tend towards small (60ish bytes), most downloads are large (MTU).

Since we are doing this to protect the control plane I am more concerned about the small fast packets.

You could also measure this in "cell length" that would probably be the best measurement but not ever router vendor even talks about the inner cross bar switch cell length:)

---

From: John Kristoff <[email-masked]>
Date: Tue, 20 Jul 2010 12:16:32 -0500

On Fri, 09 Jul 2010 13:16:57 -0400
Rodney Dunn <[email-masked]> wrote:

> "Specifically, the generation of ICMP Unreachable messages by the
> router control plane needs to be rate-limited, either implicitly

RFC 1812 has this:

4.3.2.8 Rate Limiting

   A router which sends ICMP Source Quench messages MUST be able to
   limit the rate at which the messages can be generated.  A router
   SHOULD also be able to limit the rate at which it sends other sorts
   of ICMP error messages (Destination Unreachable, Redirect, Time
   Exceeded, Parameter Problem).  The rate limit parameters SHOULD be
   settable as part of the configuration of the router.  How the limits
   are applied (e.g., per router or per interface) is left to the
   implementor's discretion.

I believe most routers rate limit ICMP messages already.

John

---

From: Rodney Dunn <[email-masked]>
Date: Thu, 22 Jul 2010 22:07:46 -0400

Thanks John.

We listed that as a reference:

The treatment of exception traffic in the forwarding plane, and the
    generation of specific messages by the router control plane also
    requires protection from a DoS attack.  Specifically, the generation
    of ICMP Unreachable messages by the router control plane needs to be
    rate-limited, either implicitly within the router's architecture or
    explicitly through configuration.  It's recommended to deploy
    explicit rate limiters where possible to improve troubleshooting and
    monitoring capability.  For additional information of ICMP rate
    limiting see Section 4.3.2.8 of [RFC1812].

Rodney

On 7/20/10 1:16 PM, John Kristoff wrote:
> Rodney Dunn<[email-masked]>  wrote:
>