US007224668B1
`
`(12) United States Patent
`US 7,224,668 B1
`(10) Patent No.:
`Smethurst et al.
`(45) Date of Patent:
`May 29, 2007
`
`(54) CONTROL PLANE SECURITY AND
`TRAFFIC FLOW MANAGEMENT
`
`(75)
`
`Inventors: Adrian C. Smethurst, Groton, MA
`(US); Michael F. Keohane,
`Shrewsbury, MA (US); R. Wayne
`Ogozaly, Hollis, NH (US)
`
`(73) Assignee: Cisco Technology, Inc., San Jose, CA
`(US)
`
`( * ) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 1000 days.
`
`(21)
`
`Appl. No.: 10/307,154
`
`(22)
`
`Filed:
`
`Nov. 27, 2002
`
`(51)
`
`(52)
`
`(58)
`
`(56)
`
`Int. Cl.
`G06F 11/00
`
`(2006.01)
`(2006.01)
`H04L 12/50
`(2006.01)
`H04L 12/28
`US. Cl.
`...................... 370/229; 370/352; 370/360;
`370/401; 370/402
`Field of Classification Search ................ 370/229,
`370/360, 387, 352, 357, 401, 402; 379/88.22,
`379/207.02, 221.08; 709/224, 238
`See application file for complete search history.
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`6,304,568 B1
`2001/0026612 A1
`2002/0097672 A1
`
`10/2001 Kim
`10/2001 Duspiva et a1.
`7/2002 Barbas et a1.
`
`OTHER PUBLICATIONS
`
`Park, K. and Lee, H., “On the Effectiveness of Route-Based Packet
`Filtering for Distributed DOS Attack Prevention in Power-Law
`Internets,” SIGCOMM’ 0121-12 (2001).
`
`[RPSEC] Draft Status, from a protocol developer’s angle.
`Re:
`[online], Jul. 26, 2002 [retrieved on Sep. 18, 2002]. Retreived from
`the Internet <URL:https://www1.ietf.org/mailman-archive/work-
`ing-groups/rpsec/current/msg00167.htm1>.
`Durham, D., et a1, “Elimination of Distributed Denial of Service
`Attacks using Programmable Network Processors,” Intel Research
`and Development: 1-4 (2002).
`Flexible Firewalls for Network Processors. [online] [retrieved on
`Sep. 18, 2002]. Retrieved from the Internet <URL:mhtm1:file://
`C:\tibnet\dad\c1ients\cisc0\utexas.mht>.
`
`Primary ExamineriAfsar Qureshi
`(74) Attorney, Agent, or FirmiHamilton, Brook, Smith &
`Reynolds, PC.
`
`(57)
`
`ABSTRACT
`
`An internetworking device that provides improved immu-
`nity to Denial of Service attacks, and in general, improved
`Quality of Service (QoS). An internetworking element or
`other route processor is composed of two main parts, includ-
`ing a data forwarding plane and a control plane; the control
`plane runs routing, signaling and control protocols that are
`responsible for determining the packet forwarding behavior
`by the data plane. Independent control plane processes may
`be provided; however, they are considered to be a single
`network entity that is a uniquely addressable port. Packets
`thus intended for the control plane always pass through a
`designated point. As a result, a set of port services unique to
`the control plane may be applied to the control plane port.
`These control plane port services thus can be utilized to
`control all packet traffic entering and exiting the control
`plane processes as a whole.
`
`72 Claims, 6 Drawing Sheets
`
`FORWARDING INTAKES LGQ
`.ACCESS CONTROL LISTS fl
`PER FLOW 005, etc. m
`
`11ROUTE
`
`PROCESSOR
`ALL
`PACKETS
`
`CONTROL
`
`PLANE
`
`
`
`GP
`PROCESSOR
`1§§
`
` CP
`
`PACKETS
`
`m
`
`125
`
`ALL
`PACKETS
`
`AGGREGATE OF
`SERVICES fl
`
`CENTRAL
`
`
`SWITCH
`ENGINE fl
`
`135
`—l
`I“
`PACKETS
`
`
`
`I.I.I
`
`DATA
`PLANE
`
`110
`
`ALL
`
`110
`
`LINECARD
`
`110
`
`120
`
`
`
`1
`
`ARISTA 1001
`
`1
`
`ARISTA 1001
`
`

`

`U.S. Patent
`
`a
`
`y
`
`m
`
`eh
`
`SU
`
`2,
`
`6,
`
`1B
`
`
`
`Q.06"moo26:NEamagm5:SE28$62.K888”;mzfiaa3%?w25m§>m8849:28
`
`
`
`
`
`MmeXQ/Eo:
`
`no
`
`mmewwmmmmmammusfimM,nomzommomz3
`
`Samzazm
`
`EEO/aIosswEva/a
`
`
`
`j<._<m._.2m0._..<.
`
`_.
`
`t<20e_
`6.
`
`fm?mfiflmiwzjm
`
`9282:o:9:82:o:92.82:c:
`
`8.6rOE
`
`7OIOCOCOCO
`
`M5as03028,OS
`
`2
`
`
`
`

`

`U.S. Patent
`
`May 29, 2007
`
`Sheet 2 of 6
`
`US 7,224,668 B1
`
`
`
`mzfm
`
`$on“5
`
`o:
`
`no
`
`355%;
`
`n5E<ommoo<
`
`awwoswmm
`
`3:23
`
`1855
`
`amzazm
`
`._..<
`
`mpmxo/E
`
`Jomhzoo o:
`
`no859155
`
`nfiSmEBEa805%
`
`Io:>>w
`
`mz_ozm
`
`no
`
`whmxo/E
`
`n5BSQEQQ
`
`aflosmmm
`
`QwHDmEHwE
`
`Iot>>m
`
`mz_ozw
`
`N.OE
`
`56m...
`
`a9282:
`
`3
`
`

`

`U.S. Patent
`
`Dday29,2007
`
`Sheet 3 of 6
`
`US 7,224,668 B1
`
`DmSmEHmE
`
`mh<0mmoo<
`
`mmoSmwwmo
`
`m.OE
`
`Aomkzoo
`
`mz<4a
`
`Amov
`
`no
`
`waSmmm
`
`4
`
`

`

`U.S. Patent
`
`May 29, 2007
`
`Sheet 4 of 6
`
`US 7,224,668 B1
`
`LINE CARD RECEIVES THE PACKET AND
`
`DELIVERS IT TO CENTRAL SWITCH ENGINE
`
`THE CENTRAL SWITCH ENGINE PERFORMS
`NORMAL INPUT PORT SERVICES AND OOS
`
`. CENTRAL'SWITCH ENGINE PERFORMS L2/L3
`
`SWITCHING OR ROUTING DECISION AND
`DETERMINES IF THE PACKET IS DESTINED TO THE CP
`
`FOR CP PACKETS, THE CENTRAL SWITCH ENGINE
`PERFORMS AGGREGATE CP SERVICES (TREATED
`AS OUTPUT SERVICES FOR THE .CP
`
`DESTINATION PORT)
`
`
`
`BASED ON THE RESULT OF AGGREGATE CP SERVICES,
`' DROP THE PACKET, MARK THE PACKET AND
`POTENTIALLY DELIVER THE PACKET TO
`THE CP FOR FINAL PROCESSING
`
`FIG. 4
`
`400
`
`402
`
`403
`
`405
`
`406
`
`5
`
`

`

`U.S. Patent
`
`May 29, 2007
`
`Sheet 5 of 6
`
`US 7,224,668 B1
`
`
`
`#222550
`
`202.4350_“.260
`
`
`
`
`
`_uw|uwc_muEuwcw—mummfloumeh
`
`
`
`
`
`mmm_o-uw:_wu“mmw_o\/\com
`
`
`
`
`
`:E:939:23.93“err—95$53noman.
`
`
`
`ooodmnoFEE3m...m8330.552:;
`
`>o__on-ocm_a-_obcouUwEmcamE5:2;<
`
`
`
`
`
`no.6uwmoxw:EwcmbShowcoooowoooow8:0;
`
`320-553320.\/Lmom
`
`
`
`9;mzohmlmmooomscams:
`
`
`
`
`
`>o__oalm:w_a-_obcoo$2.8.\(Nom
`
`m.OE
`
`
`
`2.33zuzoa.9555$5cumuu<
`
`
`
`ton953.35:00
`
`Emu—Q05m5:8
`
`
`
`zu:oauw:m_nl_obcoohozoaumoghwm
`
`
`
`w:m_a-_obcou\(mom
`
`
`
`
`
`err—mtumo:uwumabm.m.m.m>>0=<
`
`
`umEouawhumm.m.m.m“mo:Quazcwua:um__-mmmuumI/xmom
`
`
`
`
`
`ortmbawe:Uwumzb¢.v.v.v>>o=<
`
`
`
`
`amt—mucwhcmvéééumo:13>22...03.um:-mmwoom(Em
`
`
`2:3..—umeuL050:5:E:3mm
`
`
`553cmhzmhamno“:ELoQo:um.:-mmmoom/\.2m
`
`6
`
`

`

`U.S. Patent
`
`May 29, 2007
`
`Sheet 6 of 6
`
`US 7,224,668 B1
`
`DISTRIBUTED LINECARD RECEIVES THE PACKET
`
`AND DELIVERS IT TO THE DISTRIBUTED SWITCH ENGINE
`
`600
`
`THE DISTRIBUTED SWITCH ENGINE PERFORMS
`NORMAL INPUT PORT SERVICES AND 008
`
`DISTRIBUTED SWITCH ENGINE PERFORMS L2/L3
`SWITCHING OR ROUTING DECISION AND
`DETERMINES IF THE PACKET IS DESTINED
`TO THE CP
`
`FOR AGGREGATE PROCESSING
`
`FOR CP PACKETS, THE DISTRIBUTED SWITCH ENGINE
`PERFORMS DISTRIBUTED CP SERVICES (TREATED
`AS OUTPUT SERVICES FOR THE CP DESTINATION PORT)
`
`BASED ON THE RESULT OF DISTRIBUTED CP SERVICES:
`
`DROP THE PACKET, MARK THE PACKET, AND POTENTIALLY
`DELIVER THE PACKET TO THE CENTRAL SWITCH ENGINE
`
`I THE CENTRAL SWITCH ENGINE PERFORMS AGGREGATE
`CP SERVICRES AND POTENTIALLY DELIVERS THE
`PACKET TO THE CP
`
`
`
`
`
`
`
`
`FIG. 6
`
`602
`
`504
`
`606
`
`608
`
`610
`
`7
`
`

`

`US 7,224,668 B1
`
`1
`CONTROL PLANE SECURITY AND
`TRAFFIC FLOW MANAGEMENT
`
`BACKGROUND OF THE INVENTION
`
`Computer networks, and in particular the web servers,
`routers, switches, firewalls and end hosts which make up the
`Internet as well as private intranets have become critical to
`the operation of many organizations. Recently there have
`been a number of highly publicized attacks on network
`equipment belonging to commercial enterprises, govem-
`ment institutions and major intemet service providers. This
`can clearly affect the ability of these institutions to access
`information, or even to conduct business as usual. Given the
`widespread adoption of the Internet, in the not to distant
`future it is foreseeable that such an attack might actually
`disrupt the conduct of society in general.
`It has been estimated that even a three hour outage of the
`popular Yahoo servers could cause a loss of commerce and
`advertising revenue of about $500,000.
`Tests have determined that over twelve thousand attacks
`
`on five thousand distinct Internet hosts belonging to more
`than two thousand distinct organizations occurred during a
`three week period early in 2002.
`And, during one week in October 2002, a powerful
`coordinated electronic attack was directed to the central
`
`thirteen servers that manage global Internet traffic. While the
`attack only lasted for one hour,
`it caused seven of the
`thirteen servers to fail to respond.
`These attacks, often taking the form of so-called Denial of
`Service (DoS) attacks, impede the efficient functioning and
`provisioning of services by network infrastructure elements
`according to their intended purpose. The impact of such
`attacks is more pronounced than network congestion itself,
`due to the concentrated and targeted ability of such attacks
`to not only deplete specific resources but also clog traffic. In
`the extreme case, when such attacks are coordinated and
`distributed over many internetworking devices, they may
`result
`in multiple compromised Internet hosts that can
`disrupt the operation of the Internet itself.
`Susceptibility to DoS attacks is an intrinsic problem for
`any service provisioning system where the occurrence of a
`potentially valid event (such as the request
`to make a
`connection, e.g., a Transmission Central Protocol (TCP SYN
`packet)) must first be processed to ascertain its validity. This
`is true even though the processing resources needed to
`handle a single event may be negligible. While such attacks
`can take on many forms,
`they typically generate traffic
`streams at very high data rates. The devices attempt to
`service even the simplest of commands being thrown at it an
`extraordinary rate can therefore cause the device to fail.
`More particularly an internetworking device such as a
`router typically separates its functionality into control plane
`functions and data plane functions. The data plane is prin-
`cipally responsible for accepting transit packets at input
`ports and routing or switching them to output ports. On the
`other hand, the control plane is responsible for higher layer
`functions of the device, such as establishing routing tables
`and entering quality service policies. DoS attacks are thus
`commonly directed at control plane service functions that
`reside on route processors such as routers, switches, fire-
`walls and the like, since they are the most likely to cause
`widespread disruption when they fail. These control plane
`service functions may include the execution of certain
`protocols such as a Border Gateway Protocol (BGP), Simple
`Network Management Protocol (SNMP), route table man-
`agement, memory management and the like. Because the
`
`2
`
`execution of such processes is critical to the operation of the
`route processor, when such attacks are directed at such
`functions, they can be devastating.
`DoS attacks that target infrastructure devices they may
`cause a number of problems, including:
`loss of line protocol keep alive functions, which causes a
`network connection to drop, leading to route flaps and
`major network transitions;
`loss of routing protocol updates which can also lead route
`flaps and network transitions;
`causing the control plane to utilize more central process-
`ing resources than planned;
`causing route processors to lock up, or preventing them
`from completing higher priority tasks;
`reduced response time at user command line prompts,
`preventing a human administrator from taking correc-
`tive action to respond to an attack;
`such as
`consumption of route processor
`resources
`memory, buffers, data structures, causing negative side
`effects in being able to process other traffic;
`back-up of packet queues leading to indiscriminant drops;
`ultimately, crashing of the device.
`Attempts to solve such problems in the past have included
`such approaches as Reverse Pass Forwarding (RPF) verifi-
`cation and Selective Packet Discard (SPD). Selectively
`based distributed packet filtering techniques apply filters to
`packets arriving from specific known mischievous Internet
`Protocol (IP) addresses. More sophisticated techniques can
`detect forged source IP addresses by determining the routes
`from which such disruptive packets originate.
`A second technique is to apply an access list configured on
`an input interface to explicitly deny or limit specific prob-
`lematic packet types. Hardware based rate limits can then be
`implemented as a throttling mechanism for the specific
`packet types so identified. For example, packets of the type
`SYN can be specifically rate limited on a particular port or
`other hardware, at least preventing the rate at which such
`packets are sent to the control plane. A hardware based rate
`limit may be applied to RPF failures, Internet Control
`Message Protocol
`(ICMP) unreachables, Time To Live
`(TTL) failures, Maximum Transmission Unit (MTU) fail-
`ures, Internet Protocol Version 4 (IPv4) option bit packets,
`or similar packets.
`While these methods all provide some level of control
`plane protection, specific features and implementations vary
`from platform to platform. There also remain packet types
`and scenarios in which a stated feature sets do not provide
`adequate control plane protection.
`For example, based on current day capabilities, a system
`administrator could construct class maps and policy maps
`that are specific for control plane packets of known type.
`Once created, however,
`these policies would need to be
`included in the access policy for every interface in a net-
`work. Since there may typically be hundreds, if not thou-
`sands of ports in even a modest network, it is not typically
`feasible for network administrators to deploy and maintain
`such features everywhere.
`Also, when control plane policies are defined within input
`port features, a significant performance impact typically
`results for transit (that is non-control plane) traffic. Because
`additional control plane classes and policies that need to be
`executed for transit packets as well as control plane destined
`packets, overall
`transit
`traffic performance is markedly
`reduced. An interface which previously had no configura-
`tion, would be forced to execute control plane policies for
`every packet it receives. This performance impact, rather
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`
`

`

`US 7,224,668 B1
`
`3
`than help, could thus actually hinder proper operation of
`currently deployed infrastructure.
`For certain packet types that are destined for both the
`transit and control planes (i.e. special broadcasts,
`IPv4
`option bits, etc.) it is also not possible to set different yet
`compatible service policies for packets within such a single
`class. There is for example nothing inherent in such a packet
`to help understand whether it is destined to the control plane
`or should be forwarded as a transit packet.
`Thus,
`it is also not typically possible in all cases to
`configure specific classes to identify all control plane des-
`tined packet types, since these packet types cannot be readily
`identified, and current interface policies cannot be config-
`ured to control them efficiently.
`
`SUMMARY OF THE INVENTION
`
`The present invention is a technique for improved immu-
`nity to denial of service attacks, and in general, to provide
`improved Quality of Service (QoS) for network infrastruc-
`ture equipment.
`In one embodiment, an internetworking device or other
`route processor is composed of two main parts. These
`include a forwarding path that operates as a data forwarding
`plane responsible for per packet processing (e.g., forward-
`ing). Above the data plane is a network operating system that
`is responsible for operations in a control plane. In the case
`of a device such as a router or switch, the control plane runs
`routing, signaling and control protocols that are responsible
`for determining the packet forwarding behavior by the data
`plane. The control plane in a router, for example, executes
`routing or switching protocols, manipulates forwarding
`tables, per flow quality of service tables, access control lists,
`and the like.
`
`In embodiments of the invention, based upon information
`acquired through its control plane processes, packet for-
`warding behavior of the data plane elements is thus dictated.
`Data planes thus typically otherwise include a plurality of
`ports that define physical co1mection points to the network.
`Port services are then typically applied to operate on packets
`entering into or exiting from each individual physical port.
`In accordance with embodiments of the present invention,
`the control plane processes are implemented as indepen-
`dently executing processes. However,
`the control place
`processes are collectively arranged as a single addressable
`entity, to provide the ability to better manage control plane
`traffic.
`
`in embodiments of the invention, a
`More specifically,
`collection of control plane processes are considered to be a
`single entity that is a uniquely addressable device port.
`Packets, which are destined to specific control plane pro-
`cesses, are now destined through that specific control plane
`port, such that such packets intended for the control plane
`always pass through this designated port. As a result, a set
`of port services unique to the control plane may be applied
`to the aggregate control plane port. These control plane port
`services thus can be ensured to operate on packets entering
`and exiting each of the control plane processes.
`In one embodiment, packets destined to the control plane
`port can be identified in a number of ways, such as by using
`information implicit to specific packets (i.e., the recognition
`of a control plane process address), the result of a routing or
`switching decision, or by considering other control or con-
`figuration information. This allows a route processor to
`identify candidate packets destined to the control plane port
`enabling those packets to be processed by the aggregate
`control plane port services.
`
`4
`
`Embodiments of the invention provide the ability for a
`network administrator to prevent denial of service attacks
`and provide quality of service for control plane packets. A
`class of packets to be controlled are defined (such as Telnet
`SYN) and policies are attached to such class. For example,
`one policy may be to rate limit Telnet SYN packets to a
`specific rate that is a tolerable rate determined through a
`specific hardware configuration. The administrator can then
`apply this limit to the single control plane port, which would
`limit packets from all ports in the device. A limit command
`could be applied to the single control plane port rather than
`modifying the configuration on all ports.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The foregoing and other objects, features and advantages
`of the invention will be apparent from the following more
`particular description of preferred embodiments of the
`invention, as illustrated in the accompanying drawings in
`which like reference characters refer to the same parts
`throughout the different views. The drawings are not nec-
`essarily to scale, emphasis instead being placed upon illus-
`trating the principles of the invention.
`FIG. 1 is a block diagram overview of an internetworking
`device having an aggregate control plane services function.
`FIG. 2 is a block diagram of a distributed control plane
`services implementation.
`FIG. 3 is a diagram illustrating how distributed control
`plane services may affect specific ports, and an aggregate
`control plane services function may provide top level con-
`trol.
`
`FIG. 4 is a sequence of steps that may be performed in
`routing control plane packets from the data plane to the
`control plane in one environment.
`FIG. 5 is an example ofa set of rules that may be used to
`configure aggregate control plane services to rate limit
`Telnet traffic.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`FIG. 6 is a flow chart of the process in a distributed switch
`engine environment.
`
`40
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`45
`
`50
`
`55
`
`60
`
`65
`
`A description of preferred embodiments of the invention
`follows.
`
`FIG. 1 is a block diagram of a typical internetworking
`device 100 such as a router, bridge, switch, server or the like
`in which the invention may be implemented. Such an
`internetworking device 100 consists of a number of func-
`tional entities. These include line cards 110 that are respon-
`sible for physically attaching to network connections such as
`ports 120. Each of the line cards 110, typically provide a
`number of ports 120, such as through Network Interface
`Adaptors. Packets received from the ports 120 are fed to a
`route processor 125. In the case where the device 100 is a
`router or switch, the processor 125 includes a central switch
`engine 130. A control plane 150 associated with the device
`100 is defined as a collection of processes, typically running
`on the route processor 125. These control plane 150 pro-
`cesses collectively provide high level control
`for most
`router/switch Input/Output Services (IOS) functions. These
`control plane 150 processes could be implemented as soft-
`ware at any level of a system, or as hardware.
`As will be understood shortly, the invention herein con-
`cerns a control plane port 140, defined as a single access path
`between the switch engine 130 and the control plane 150.
`
`9
`
`

`

`US 7,224,668 B1
`
`5
`The control plane port 140 may or may not be a single
`physical port. For example,
`it may be a virtual address
`through which packets travel or are routed from the data
`plane 135 to the control plane 150.
`More specifically, the line cards 110 and central switch
`engine 130 operate to accept packets received on a given
`port 120 and route them through to another output port 120.
`These forwarding or data plane 135 components are thus
`responsible for forwarding network transit packets.
`The control plane 150 on the other hand, functions largely
`independently of the data plane 135. The control plane 150
`is responsible for processing routing, signaling and control
`protocols that dictate the packet forwarding behavior of the
`data plane 135. Such protocols typically manipulate for-
`warding tables 160, per flow Quality of Service (QoS) tables
`161, access control lists 162, and the like are utilized by the
`device 100 to make packet
`forwarding decisions. For
`example, the control plane 150 might manipulate the for-
`warding table 160 in the switch engine 130 or change the
`state of one of the port interfaces 120 in a line card 110 to
`effect a route change. The control plane 150 is typically not
`a single process or processor but rather a collection of
`processes.
`The primary goal of Denial of Service (DoS) protection,
`or otherwise maintaining a specific Quality of Service (QoS)
`at the control plane 150 is to maintain packet forwarding and
`protocol states while the device 100 is either under attack or
`experiencing normal
`to heavy traffic load. Under these
`conditions, device 100 should continue to process important
`packets destined to control plane 150 functions, including
`protocol control packets, Layer 2 (L2) or Layer 3 (L3) keep
`alive packets, and the like while at the same time maintain-
`ing critical Input/Output Service (IOS) functions.
`The central switch engine 130 typically performs high
`speed Input and Output Services (IOS) for port interfaces
`such as the line cards 110. An important aspect of the central
`switch engine 130 is that all packets destined to the control
`plane 150 must pass through the central switch engine 130
`prior to being routed to the functions 155 in the control plane
`150. In this instance the central switch engine 130 can be
`utilized to implement aggregate control plane protection, for
`all such processes 155 as will be described below.
`An alternate arrangement shown in FIG. 2, uses a dis-
`tributed switching engine architecture. This approach pro-
`vides high speed switching of packets among specialized
`distributed line cards 111 typically without utilizing any
`central switch engine 130 resources. In this architecture, a
`distributed switch engine 131 may perform input and output
`services for each respective line card 111. In this instance
`distributed control plane port services will be utilized to
`implement the specific aspects of the invention described
`herein.
`
`Regardless of whether the control plane port services are
`implemented as aggregate port services 145 or as distributed
`control plane services 146, they perform certain basic func-
`tions. Control plane port services most importantly deter-
`mine if a given packet is destined to a control plane process
`150. Such determination can be made through a route
`look-up mechanism or in other ways. For example, an L2
`destination address look-up mechanism may be used for L2
`port addresses. Alternatively for an L3 port, L3 destination
`address lookup functions such as Cisco Express Forwarding
`(CEF) may be used to identify packets destined to control
`plane processes 155. Both of the look-up mechanisms are
`able to identify packets destined for the control plane 150.
`With processes 155 in the control plane 150 being treated
`in this way, the control plane port 140 can be treated as a
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`traditional hardware port. As a result, a full range of tradi-
`tional port control features can be applied to help protect the
`control plane 150 from a DoS attack, or to provide other
`QoS. Such control features can, for example, be imple-
`mented as a set of programmed rules that determine whether
`or not packets arriving at the control plane port 140 qualify
`for delivery to the control plane and at what level of QoS.
`While this will be described in a detailed specific example
`below, assume as one example that a system administrator
`would like to limit packets of type TCP/SYN that are
`destined to the control plane 150 to a maximum rate of one
`megabit per second. With the control plane 150 being treated
`as an addressable single port 140, rules can be established to
`enforce this rate limit, after port input services are applied to
`the port 120, and after a switching decision is made in the
`data plane 130. The rules are applied if and only if a packet
`has been first determined to have a destination of the control
`
`plane 150. The specific control plane feature (i.e., rate limit
`with access list) can then be applied by the control plane
`services 145 or 146,
`thus preventing even correctly
`addressed packets from progressing up to any of the control
`plane processes 155 if the specific rate limit has been
`exceeded.
`
`In some instances, an administrator might employ a more
`complex set of rules. For example, such rules might also be
`put in place to allow only a system administrator to access
`the router through a trusted host address. This allows the
`administrator to connect to the router, even while it is under
`attack, since the rate limit and access list would permit the
`session connected from the trusted host while rate limiting
`other connectors.
`
`In a similar fashion, important packets such as routing
`protocol control packets can be placed in appropriate hier-
`archical queues based on priority as determined by the user.
`This potentially can improve routing convergence rates.
`Thus, the user is afforded significant control over the flow of
`traffic destined to the control plane 150 just as if the control
`plane 150 were a hardware interface. Since control plane
`150 destined packets will invoke only control plane services,
`transit
`traffic
`and system performance is minimally
`impacted. That is, transit packets will not invoke control
`plane port services, but will continue to invoke normal input
`and output port services.
`FIG. 3 illustrates how the aggregate control plane services
`145 and distributed control plane services 146 can be
`thought of as providing a hierarchical approach (rings of
`security) to access control. The central, aggregate control
`plane services 145 provide a level of service (or control) for
`all packets received from any port on the device 100. The
`distributed control plane services 146 provide a level of
`service (or control) only for those parts with which they are
`associated, which may be a single port 120 or multiple ports
`120. A different level of service may therefore result for
`ports 1 and 2, serviced by distributed services module 146-1,
`than for a port 5, which is serviced by a different distributed
`services module 146-2.
`
`In an implementation such as that shown in FIG. 1, the
`central switch engine 130 can provide an aggregate level of
`control planeservice 145, which is applied to all control
`plane packets received from all interfaces. Central switch
`engine 130 executes the input port services for the control
`plane port 140 making routing decisions for packets desig-
`nated for the control plane 150.
`One example is shown in the flow chart in FIG. 4. In a first
`state 400, a line card detects a packet and delivers it to the
`central switch engine 130. In a next step 402, the central
`
`10
`
`10
`
`

`

`US 7,224,668 B1
`
`7
`switch engine 130 performs normal input port services and
`Quality of Service (QoS) processing on the received packet.
`In a next state 403, the central switch engine 130 performs
`its normal Layer 2 and Layer 3 switching/routing decision.
`In the case of a normal transit packet, the packet would be
`routed to a destination port 120 on an associated line card
`110, using for example, the forwarding table information
`160. If, however, the packet is destined for a known control
`plane 150 address, or to an address not on a forwarding table
`160, the packet is tagged being destined to as a control plane
`port. The packet is then routed through the aggregate control
`plane port 140.
`In state 405 the control plane port 140 then performs the
`aggregate control plane port services on the packet.
`In a state 410, based on the results of the aggregate control
`plane services function 145, the control plane port function
`will either drop the packet, or mark the packet and poten-
`tially deliver it to the control plane 150 for processing.
`Class maps and policy maps may be used for both DoS
`protection and packet quality of service. For the single
`aggregate port 140 these classifications and policies can be
`applied to in a known fashion. Consider the control plane
`services pseudo-example described in FIG. 5. Configuration
`commands are shown on the left hand side with comments
`
`on the right hand side. These types of commands are typical
`rate limit commands familiar to network administrators.
`
`This example is for illustrative purposes only; it should be
`understood that a whole range of techniques could be used
`to implement such features.
`The particular example limits aggregate control plane
`services for Telnet type traffic. In a first construction 500, a
`class map is defined as “telnet-class”. These packets are for
`example identified by matching the telnet access group 140.
`Telnet access group 140 matches packets with “TCP field”
`equal to “telnet”. In the next definitional statement 502, a
`policy map is associated with the “control-plane-policy”.
`The next instructions 503 define the policy assigned to the
`“telnet-class” as allowing 80,000 bits per second of traffic,
`with excess traffic being dropped. This rate limit definition
`is then attached to the control plane port by the following
`statement 505, which assigns the service policy of “control-
`plane-policy” to the control plane port. Statement 505 rep-
`resents a control plane port which could be either aggregate
`145 or distributed 146. All other commands specified are
`common and familiar to system administrators.
`Additional attributes of the port services may be defined
`as access control lists. For example,
`in statement 506 a
`trusted address 3 .3 .3 .3 is considered and allowed to have any
`amount of Telnet traffic. Similarly, in statement 507 another
`address of 4.4.4.4 is defined as trusted. However all other
`
`Telnet traffic is rate limited by the final access list command
`510.
`
`The above configuration allows trusted host with source
`addresses 3.3.3.3 or 4.4.4.4 to forward telnet packets to the
`control plane without rate limit constraints, and all remain-
`ing Telnet packets will be policed to the specified rate.
`Specifically, only these packets that match the access
`control list (ACL) are policed. The last ACL statement 512
`includes a match for any packet equal to Telnet. The deny
`ACL statements allow those packet types to skip the policer
`and therefore would always be forwarded.
`In an alternate scenario, a distributed switch engine is
`used to provide a distributed level of service as per FIG. 2.
`The distributed switch engine is such that portions may
`execute on line cards 111, and other portions may execute in
`a central
`location to make the routing decision. But all
`control plane 150 traffic from all ports 120 still passes
`
`8
`through the distributed control plane services, and thus
`through the control plane port 140.
`FIG. 6 is a sequence of steps that may be performed to
`implement the invention in such a distributed control plane
`environment. In a first state 600 a distributed line card
`
`receives a packet delivering it to its associated distributed
`switch engine. In a next state 602 the distributed switch
`engine performs normal input port services and quality of
`service processing.
`In state 604 the distributed switch engine performs a
`Layer 2 and Layer 3 switching routing decision, determining
`if the packet is destined to the control plane 150. For control
`plane packets in state 606, the distributed switch engine then
`performs the distributed control plane services (such as the
`commands of FIG. 5). In state 608, depending upon the
`result of those distributed control plane services, the packet
`is either dropped or marked and potentially delivered to the
`central switch engine 130.
`In a state 610 a cent