OPSEC                                                           D. Dugal
Internet-Draft                                          Juniper Networks
Intended status: Informational                              C. Pignataro
Expires: August 2, 2010                                          R. Dunn
                                                           Cisco Systems
                                                        January 29, 2010


                  Protecting The Router Control Plane
             draft-dugal-opsec-protect-control-plane-01.txt

Abstract

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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 2, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Dugal, et al.            Expires August 2, 2010                 [Page 1]


Internet-Draft            Protect Control Plane             January 2010


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  4
   3.  Method . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Legitimate Traffic . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Filter Design  . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Design Trade-offs  . . . . . . . . . . . . . . . . . . . .  5
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  Informative References . . . . . . . . . . . . . . . . . . . .  7
   Appendix A.  Cisco Configuration . . . . . . . . . . . . . . . . .  8
   Appendix B.  Juniper Configuration . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

























Dugal, et al.            Expires August 2, 2010                 [Page 2]


Internet-Draft            Protect Control Plane             January 2010


1.  Introduction

   Modern core router architecture design maintains a strict separation
   of forwarding and control plane hardware and software.  Forwarding
   plane is typically described as router architecture hardware and
   software components responsible for taking a packet coming in one
   interface, performing a lookup to identify the packet's IP next hop
   and determine the outgoing interface towards the destination, and
   forwarding the packet through the correct outgoing interface.
   Control plane supports routing and management functions, and is
   generally described as as router architecture hardware and software
   components for handling packets destined to the device itself as well
   as building and sending packets originated locally on the device.

   Visually it can be represented as the control plane hardware sitting
   on top of and interfacing with the forwarding plane hardware, with
   interfaces connecting to other network devices.  See Figure 1.

                             +---------------+
                             | Control Plane |
                             +------+ +------+
                                    | |
                               Router Control
                              Plane Protection
                                    | |
                             +------+ +------+
                             |   Forwarding  |
               Interface X ==[     Plane     ]== Interface Y
                             +---------------+

                 Figure 1: Router Control Plane Protection

   Typically, forwarding plane functionality is realized in high-
   performance Application Specific Integrated Circuits (ASICs) that are
   capable of handling very high packet rates.  By contrast, the control
   plane is generally realized in software on general purpose
   processors.  While software instructions run on both planes, the
   control plane software is usually not optimized for high speed packet
   handling.  Given their differences in packet handling capabilities,
   control plane hardware is more suceptible to be overwhelmed by a DoS
   attack than forwarding plane ASICs.  It is imperative that the
   control plane remain stable regardless of traffic load to and from
   the device because the control plane is what drives the programming
   of the forwarding plane.

   The control plane processes traffic destined to the router, and
   because of the wider range of functionality is more suceptible to
   security vulnerabilities and a more likely target for a DoS attack



Dugal, et al.            Expires August 2, 2010                 [Page 3]


Internet-Draft            Protect Control Plane             January 2010


   than the forwarding plane.

   It is advisable to protect the control plane by implementing
   mechanisms to filter completely or rate limit traffic not required at
   the control plane level (i.e., unwanted traffic).  Control Plane
   Protection is the concept of filtering traffic unwanted traffic which
   would be diverted out of the forwarding plane up to the control
   plane.  The closer to the forwarding plane and line-rate hardware the
   filters and rate-limiters are, the more effective the protection is
   and the more resistent the system is to DoS attacks.  This memo
   demonstrates how to deploy such a filter.


2.  Applicability Statement

   The method described in Section 3 is a sample illustration to
   demonstrate how to protect the router control plane from unwanted
   traffic.  Recognizing that deployment scenarios will vary, the exact
   implementation is not generally applicable in all situations.  The
   cateorization of legitimate control plane traffic is critically
   important in a successul implementation.

   The examples given in this memo are simplified and minimalistic,
   designed to illustrate the concept of protecting the router's control
   plane.  From them, operators can extrapolate specifics based on their
   unique configuration and environment.

   This method is applicable for IPv4 as well as IPv6 traffic.  The
   sample legitimate traffic in Section 3.1 uses IPv4 addresses, but can
   be expanded to IPv6 as well.


3.  Method

   In this memo, the authors demonstrate how a filter protecting the
   control plane can be deployed.  In Section 3.1, a sample router
   introduced and all traffic that its control plane must process is
   identified.  In Section 3.2, filter design concepts are discussed.
   Cisco (Cisco IOS software) and Juniper (JUNOS) implementations are
   provided in Appendices A and B, respectively.

3.1.  Legitimate Traffic

   In this example, the router control plane must process traffic from
   the following sources:






Dugal, et al.            Expires August 2, 2010                 [Page 4]


Internet-Draft            Protect Control Plane             January 2010


   o  ICMP traffic from any source, rate-limited to 2 Mbps

   o  OSPF traffic from routers within own network (network mask
      192.0.2.0/24)

   o  iBGP traffic from routers within own network (network mask
      192.0.2.0/24)

   o  eBGP traffic from known eBGP peers (network addresses
      198.51.100.25, 198.51.100.27, 198.51.100.29, 198.51.100.31)

   o  DNS traffic from local DNS resolvers (198.51.100.0/30)

   o  NTP traffic from local NTP (198.51.100.4/30)

   o  SSH traffic from network management stations (198.51.100.128/25)

   o  SNMP traffic from network management stations (198.51.100.128/25)

   The characteristics of legitimate traffic will vary from network to
   network.  The list provided above is for example only.

3.2.  Filter Design

   A filter is installed on the forwarding plane.  This filter counts
   and silently discards all traffic not matching the profile provided
   in Section 3.1.  Because the filter is enforced on the forwarding
   plane, it prevents unwanted traffic from consuming bandwidth on the
   interface that connects the forwarding plane to the control plane.
   The counters serve as an important forensic tool for the analysis of
   potential attacks, and as an invaluable debugging and troubleshooting
   aid.

   A rate limiter also is installed on the forwarding plane.  The rate
   limiter restricts ICMP traffic bound for the control plane to some
   reasonable volume.  In our example, we will rate limit to 2 Megabits
   per second (Mbps).

   Syntactically, these filters explicitly define "allowed" traffic
   (including IP addresses, protocols, and ports), define acceptable
   actions for these acceptable traffic profiles (e.g., rate-limit or
   simply permit the traffic), and then drop to the bit bucket all
   traffic destined to the control plane but not explicitly allowed.

3.3.  Design Trade-offs

   In designing the protection method, there are two independent parts
   to consider: the classification of traffic (i.e., which traffic is



Dugal, et al.            Expires August 2, 2010                 [Page 5]


Internet-Draft            Protect Control Plane             January 2010


   matched by the filters), and the policy actions taken on the
   classified traffic.

   There are different levels of granularity utilized for traffic
   classification.  For example, allowing all traffic from specific
   source IP addresses versus allowing only a specific set of protocols
   from those specific source IP addresses will each affect a different
   set of traffic.

   Similarly, the policy actions taken on the classified traffic have
   degrees of impact that may not become immediately obvious.  For
   example, discarding all ICMP traffic may have a negative impact on
   the operational use of ICMP tools such as ping or traceroute to debug
   network issues or to test turn up of a new circuit.

   It is important to note that both classification and policy action
   decisions are accompanied by respective trade-offs.  Two examples of
   these trade-off decisions are, operational complexity at the expense
   of policy (and statistics gathering) detail, and tighter protection
   at the expense of network supportability and troubleshooting ability.

   The goal of the method for protecting the router control plane is to
   minimize potential disruptions.  The granularity of the filter design
   inversely correlates to the scope of the potential disruption.  The
   finer the granularity of the filter design (e.g., isolating kinds of
   sub-traffic from the rest of the policed traffic, or isolating valid
   source addresses into a different class or classes) the smaller the
   scope of disruption.


4.  Security Considerations

   The filter above leaves the router susceptible to discovery from any
   host on the Internet.  If network operators find this risk
   objectionable, they can mitigate it by restricting the sub-networks
   from which ICMP Echo requests are accepted.

   The filter above also leaves the router exposed to port scans from
   hosts spoofing the source addresses found in Section 3.1.  Network
   operators can mitigate this risk by preventing source address
   spoofing with filters applied at the network edge.  Refer to Section
   5.3.8 of [RFC1812] for more information regarding source address
   validation.  Other methods also exist for limiting exposure to packet
   spoofing such as the Generalized TTL Security Mechanism (GTSM)
   [RFC5082] and Ingress Filtering [RFC3704].

   The ICMP rate limiter specified in this filter protects the router
   from floods of ICMP traffic.  However, during an ICMP flood, some



Dugal, et al.            Expires August 2, 2010                 [Page 6]


Internet-Draft            Protect Control Plane             January 2010


   legitimate ICMP traffic may be dropped.  Because of this, when
   operators discover a flood of ICMP traffic, they are highly motivated
   to cut it off at its source.

   Additional considerations pertaining to the usage and handling of
   traffic that utilizes the IP Router Alter Options can be found at
   [I-D.rahman-rtg-router-alert-considerations].

   The treatment of exception traffic in the forwarding plane, and the
   generation of specific messages by the control plane also requires
   protection from a DoS attack.  Specifically, the generation of ICMP
   Unreachable messages by the control plane needs to be rate-limited,
   either implicitly within the router's architecture or explicitly
   through configuration.  See Section 4.3.2.8 of [RFC1812].

   Additionally, the handling of TTL / Hop Limit expired traffic needs
   protection.  For example, rate limiting the TTL / Hop Limit expired
   traffic before sending the packets to the control plane component
   that will send the ICMP error, and distributing the sending of ICMP
   errors in a Line Card CPU are protection mechanisms that deter
   attacks before a rate limited in the main control plane component.


5.  IANA Considerations

   [RFC Editor: please remove this section prior to publication.]

   This document has no IANA actions.


6.  Acknowledgements

   The authors would like to thank Ron Bonica for providing review,
   suggestions, and valuable input.  Pekka Savola, Warren Kumari and Xu
   Chen provided very thorough and useful feedback that improved the
   document.


7.  Informative References

   [I-D.rahman-rtg-router-alert-considerations]
              Faucheur, F., "IP Router Alert Considerations and Usage",
              draft-rahman-rtg-router-alert-considerations-03 (work in
              progress), October 2009.

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
              RFC 1812, June 1995.




Dugal, et al.            Expires August 2, 2010                 [Page 7]


Internet-Draft            Protect Control Plane             January 2010


   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, March 2004.

   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
              Pignataro, "The Generalized TTL Security Mechanism
              (GTSM)", RFC 5082, October 2007.


Appendix A.  Cisco Configuration


   !Start: Protecting The Router Control Plane
   !
   !Policy-map Configuration
   !
   !Access-list Definitions
   ip access-list extended ICMP
    permit icmp any any
   ip access-list extended OSPF
    permit ospf 192.0.2.0 0.0.0.255 any
   ip access-list extended IBGP
    permit tcp 192.0.2.0 0.0.0.255 eq bgp any
    permit tcp 192.0.2.0 0.0.0.255 any eq bgp
   ip access-list extended EBGP
    permit tcp host 198.51.100.25 eq bgp any
    permit tcp host 198.51.100.25 any eq bgp
    permit tcp host 198.51.100.27 eq bgp any
    permit tcp host 198.51.100.27 any eq bgp
    permit tcp host 198.51.100.29 eq bgp any
    permit tcp host 198.51.100.29 any eq bgp
    permit tcp host 198.51.100.31 eq bgp any
    permit tcp host 198.51.100.31 any eq bgp
   ip access-list extended DNS
    permit udp 198.51.100.0 0.0.0.252 eq domain any
   ip access-list extended NTP
    permit udp 198.51.100.4 255.255.255.252 any eq ntp
   ip access-list extended SSH
    permit tcp 198.51.100.0 0.0.0.128 any eq 22
   ip access-list extended SNMP
    permit udp 198.51.100.128 0.0.0.125 eq snmp any
    permit udp 198.51.100.128 0.0.0.125 eq snmptrap any
   !
   !Class Definitions
   !
   class-map match-all ICMP
    match access-group name ICMP
   class-map match-all OSPF
    match access-group name OSPF



Dugal, et al.            Expires August 2, 2010                 [Page 8]


Internet-Draft            Protect Control Plane             January 2010


   class-map match-all IBGP
    match access-group name IBGP
   class-map match-all EBGP
    match access-group name EBGP
   class-map match-all DNS
    match access-group name DNS
   class-map match-all NTP
    match access-group name NTP
   class-map match-all SSH
    match access-group name SSH
   class-map match-all SNMP
    match access-group name SNMP
   !
   !Policy Definition
   !
   policy-map COPP
    class ICMP
     police 2000000
    class OSPF
    class IBGP
    class EBGP
    class DNS
    class NTP
    class SSH
    class SNMP
    class class-default
      police cir 8000
        conform-action drop
        exceed-action drop
        violate-action drop
   !
   !Control Plane Configuration
   !
   control-plane
    service-policy input COPP
   !
   !End: Protecting The Router Control Plane


Appendix B.  Juniper Configuration


   policy-options {
       prefix-list IBGP-NEIGHBORS {
           192.0.2.0/24;
       }
       prefix-list EBGP-NEIGHBORS {
           198.51.100.25/32;



Dugal, et al.            Expires August 2, 2010                 [Page 9]


Internet-Draft            Protect Control Plane             January 2010


           198.51.100.27/32;
           198.51.100.29/32;
           198.51.100.31/32;
       }
   }
   firewall {
       policer 2Mbps {
           if-exceeding {
               bandwidth-limit 2m;
               burst-size-limit 2k;
           }
           then discard;
       }
       family inet {
           filter protect-control-plane {
               term icmp {
                   from {
                       protocol icmp;
                   }
                   policer 2Mbps;
                   then accept;
               }
               term ospf {
                   from {
                       source-address {
                           192.0.2.0/24;
                       }
                       protocol ospf;
                   }
                   then accept;
               }
               term ibgp-connect {
                   from {
                       source-prefix-list {
                           IBGP-NEIGHBORS;
                       }
                       protocol tcp;
                       destination-port bgp;
                   }
                   then accept;
               }
              term ibgp-reply {
                   from {
                       source-prefix-list {
                           IBGP-NEIGHBORS;
                       }
                       protocol tcp;
                       port bgp;



Dugal, et al.            Expires August 2, 2010                [Page 10]


Internet-Draft            Protect Control Plane             January 2010


                   }
                   then accept;
               }
               term ebgp-connect {
                   from {
                       source-prefix-list {
                           EBGP-NEIGHBORS;
                       }
                       protocol tcp;
                       destination-port bgp;
                   }
                   then accept;
               }
               term ebgp-reply {
                   from {
                       source-prefix-list {
                           EBGP-NEIGHBORS;
                       }
                       protocol tcp;
                       port bgp;
                   }
                   then accept;
               }
               term dns {
                   from {
                       source-address {
                           198.51.100.0/30;
                       }
                       protocol udp;
                       port domain;
                   }
                   then accept;
               }
               term ntp {
                   from {
                       source-address {
                           198.51.100.4/30;
                       }
                       protocol udp;
                       destination-port ntp;
                   }
                   then accept;
               }
               term ssh {
                   from {
                       source-address {
                           198.51.100.128/25;
                       }



Dugal, et al.            Expires August 2, 2010                [Page 11]


Internet-Draft            Protect Control Plane             January 2010


                       protocol tcp;
                       destination-port ssh;
                   }
                   then accept;
               }
               term snmp {
                   from {
                       source-address {
                           198.51.100.128/25;
                       }
                       protocol udp;
                       port [snmp snmptrap];
                   }
                   then accept;
               }
               term default-term {
                   then {
                       count copp-discards;
                       log;
                       discard;
                   }
               }
           }
       }
   }
   interfaces {
       lo0 {
           unit 0 {
               family inet {
                   filter input protect-control-plane;
               }
            }
       }
   }


Authors' Addresses

   David Dugal
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   US

   Email: ddugal@juniper.net






Dugal, et al.            Expires August 2, 2010                [Page 12]


Internet-Draft            Protect Control Plane             January 2010


   Carlos Pignataro
   Cisco Systems
   7200-12 Kit Creek Road
   Research Triangle Park, NC  27709
   US

   Email: cpignata@cisco.com


   Rodney Dunn
   Cisco Systems
   7200-12 Kit Creek Road
   Research Triangle Park, NC  27709
   US

   Email: rodunn@cisco.com



































Dugal, et al.            Expires August 2, 2010                [Page 13]