USOO7561515B2
`
`(12) United States Patent
`(10) Patent No.:
`US 7,561,515 B2
`
`Ross
`(45) Date of Patent:
`Jul. 14, 2009
`
`(54) ROLE-BASED NETWORK TRAFFIC-FLOW
`RATE CONTROL
`
`2005/0157647 A1*
`2006/0023709 A1 *
`2006/0218302 A1 *
`
`7/2005 Sterne et al.
`................ 370/235
`2/2006 Hall et al. ............. 370/389
`
`.................. 709/245
`9/2006 Chia et al.
`
`(75)
`
`Inventor: Alan D. Ross, Shingle Springs, CA (US)
`
`OTHER PUBLICATIONS
`
`(73) Assignee:
`
`Intel Corporation, Santa Clara, CA
`(US)
`
`( * ) Notice:
`
`Subject to any disclaimer, the term Ofthis
`patent is extended or adjusted under 35
`U S C 154(1)) by 876 days
`
`(21) Appl.No.: 10/951,393
`
`(22)
`
`(65)
`
`Filed:
`
`Sep. 27, 2004
`_
`_
`_
`Prior Publication Data
`US 2006/0072451 A1
`Apr. 6, 2006
`
`(2006 01)
`IGn0t-IIEISI/08
`(51)
`(52) US. Cl.
`....................... 370/232; 370/230; 370/235;
`370/229
`(58) Field of Classification Search ................. 370/230,
`.
`.
`370/232’ 23.5; 709/229
`See application file for complete search history.
`References Cited
`U.S. PATENT DOCUMENTS
`
`(56)
`
`Matthew M. Williamson, et a1., “Virus Throttling”, Virus Bulletin,
`Mar. 2003, pp. 8-11, Virus Bulletin Ltd., Oxfordshire, England.
`Matthew M. Williamson, et a1., “Virus Throttling for Instant Messag-
`ing”, Virus Bulletin Conference, Sep. 2004, Chicago, Illinois, pp. 1-9,
`HeWIeH'PaCkard Company.
`_
`_
`_
`Jam1e Twycross et al., “Implementing and Testing aVirus Throttle”,
`Proceedings 12th USENIX Security Symposium, Aug. 4-8, 2003,
`Washington, DC, 11 pages, Hewlett-Packard Company.
`Matthew M. Williamson, et al., “Design, Implementation and Test of
`an Email Virus Throttle”, Jun. 2003, pp. 1-9, Hewlett Packard Com-
`Pany'
`Matthew M. Williamson, et al., “Throttling Viruses: Restricting
`Propagation to Defeat Malicious Mobile Code”, Jun. 2002, pp. 1-6,
`HeWICH'PaCkard Company
`Matthew M. Williamson, et al., “Throttling Viruses: Restricting
`Propagation to Defeat Malicious Mobile Code”, ACSAC Conference,
`Dec. 2002, Las Vegas, Nevada, pp. 1-8, Hewlett Packard Company.
`* Cited by examiner
`.
`.
`.
`Sglsgggffiygrifigffifigf Haflu
`(74) Attorney, Agent, or FirmiBlakely, Sokoloff, Taylor &
`Zafman LLP
`
`(57)
`
`ABSTRACT
`
`5 950 195 A *
`1
`t
`11
`9/1999 St k
`5,968,176 A
`10/1999 N::se‘txi:t:l 3' """""""
`7,343,485 B1*
`3/2008 Huang eta1.. ................ 713/153
`
`2003/019i853 A1* 10/2003 Ono .................... 709/232
`2004/0028059 A1*
`2/2004 Josyula et al.
`.............. 370/396
`2004/0039924 A1
`2/2004 Baldwin et al.
`
`707/4
`
`Trafiic flow rate control ina network device. Trafiic flow may
`be permitted/restricted based on the role of a dev1ce.1n a
`network The traffic flow may be hunted on the ham 0f
`PaCketS Per time PefiOds the limits to be applied on a Per'
`Protocols Per-Ports and/0r Per-Packet basiS~
`
`2005/0027837 A1 *
`
`2/2005 Roese et a1.
`
`................ 709/223
`
`17 Clailns3 4 Drawing Sheets
`
`RATE CONTROL AGENT
`
`APP(S)
`
`320
`
`CONTROL
`
`MEMORY
`
`fl
`
`&
`
`COMPLIANCE ENGINE
`
`POLICY UPDATE
`FEATURE
`
`INTERFACE
`
`$5.0
`
`m FEATURE
`
`POLICY
`DETERMINATION
`341
`FEATURE
`
`3 2
`
`
`PACKET
`MONITORING
`
`fl FEATURE
`
`POLICY
`ENFORCEMENT
`
`Palo Alto Networks v. Sable Networks
`
`IPR2020-01712
`
`EX 1 0 12
`
`EX1012
`Palo Alto Networks v. Sable Networks
`IPR2020-01712
`
`

`

`US. Patent
`
`Jul. 14, 2009
`
`Sheet 1 014
`
`US 7,561,515 B2
`
`HOST SYSTEM
`
`
`NETWORK DEVICE
`
`HOST
`
`
`FLOW
`
`
`
`FunFORM
`NETWORK
`POUCY
`
`
`
`SERVER
`INTERFACE
`
`
`RATE
`CONTROL
`
`AGENT121
`
`FIG. 1
`
`HOST SYSTEM
`
`HOST PLATFORM
`
`NETWORK
`
`DEVICE
`
`240
`
`&
`
`RAT E
`
`CONTROL
`AGENT
`
`NETWORK
`INTERFACE
`
`TRAFFIC POLICY
`SERVER
`
`FIG. 2
`
`

`

`US. Patent
`
`Jul. 14, 2009
`
`Sheet 2 014
`
`US 7,561,515 B2
`
`RATE CONTROL AGENT
`
`CONTROL
`
`MEMORY
`
`M
`
`&
`
`INTERFACE
`
`§5_0
`
`FEATURE
`
`COMPLIANCE ENGINE
`
`POLICY
`DETERMINATION
`3 1
`FEATURE
`
`POLICY UPDATE
`FEATURE
`
`3 2
`
`PACKET
`MONITORING
`
`POLICY
`ENFORCEMENT
`
`343
`
`FEATURE
`
`344
`
`FIG. 3
`
`

`

`US. Patent
`
`Jul. 14, 2009
`
`Sheet 3 014
`
`US 7,561,515 B2
`
`NETWORK ACCESS
`
`INITIALIZATION
`
`402
`
`TRAFFIC
`
`REQUEST
`
`04
`
`YES
`
`
`TRAFFIC FLOW
`DEVICE IDENTIFICATION
`
`
`POLICY SERVER?
`
`
`PROCESS
`41
`
`
`fl
`
`
`
`DETERMINE USER ROLE IN
`
`416
`
`NETWORK
`
` IMPLEMENT DEFAULT TRAFFIC
`
`FLOW POLICY
`412
`
`TRAFFIC FLOW POLICY
`
`
`ASSIGNMENT
`18
`
`
`
`
`
`ALLOW NORMAL TRAFFIC
`
`PROCESSES
`
`422
`
`£2_0
`
`NO
`
`YES
`
`REQUEST
`PERMISSIBLE?
`
`REQUEST DENIED
`
`424
`
`FIG. 4
`
`

`

`US. Patent
`
`Jul. 14, 2009
`
`Sheet 4 014
`
`US 7,561,515 B2
`
`NETWORK POLICY 521
`FOR PUBLIC FACING
`INTERFACE
`
`
`PERMIT
`
`
`
`
`
`mm-
`
`
`
`”—un
`
`NETWORK POLICY 551
`FOR LAN CLIENT2
`
`520
`
`
`CLIENT1 ON
`540
`LAN
`
`
`
`
`
`
`
`CLIENT2 ON
`550
`LAN
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`PUBLIC FACING
`_51_0 WEB SERVER
`
`530
`
`NETWORK POLICY 541
`FOR LAN CLIENT1
`
`PERMIT
`
`PERMIT
`
`C
`
`
`mm RATE
`_——-l:l
`><><
`
`“m-
`
`
`——-—-
`><><
`
`UDP —--—
`
`
` 443
`
`NETWORK POLICY 531
`FOR PRIVATE FACING
`INTERFACE
`
`
`
`

`

`US 7,561,515 B2
`
`1
`ROLE-BASED NETWORK TRAFFIC-FLOW
`RATE CONTROL
`
`FIELD
`
`Embodiments ofthe invention relate to network traffic flow
`
`control, and particularly to packet-based control at a network-
`connected device.
`
`BACKGROUND
`
`Spread of malware and other computer attacks has
`increased focus on network security. Malware may include
`Viruses, worms, or other malicious code meant to disrupt
`network service, impair computer performance, open holes
`for intrusion, etc. Computer attacks may include flooding a
`server with traffic/requests and/or other actions to overload a
`server or network and cause a denial of service (DoS) attack.
`Traditional approaches
`to mitigating malware have
`focused on preventing infection of networked machines.
`Antivirus software is typically concerned with recognizing
`viruses by examining software for particular known signa-
`tures. Recognized viruses can be quarantined and/or
`destroyed. Traditional malware protection suffers many limi-
`tations in that new viruses are able to spread unchecked until
`the virus can be analyzed for a signature, and antivirus defi-
`nitions can be updated on each individual machine. This may
`require considerable time and effort. Those who do not take
`advantage ofthe almost constant updates are more vulnerable
`to attack by viruses that are not in the outdated definitions.
`Many new viruses are also adaptable, and alter themselves as
`they spread, causing difficulty for antivirus software.
`Another approach is virus throttling,
`introduced by
`researchers of HP Laboratories Bristol. See, e.g., Jamie Twy-
`cross, Matthew M. Williamson, “Implementing and Testing a
`Virus Throttle,” Trusted Systems Laboratory, HP Laborato-
`ries Bristol, HPL-2003-103, May 21, 2003. The virus throttle
`approach recognizes that viruses typically spread by engag-
`ing in “abnormal” computer behavior, or behavior that is
`outside the expected norm ofcomputer conduct. For example,
`an infected computer may attempt to establish many connec-
`tions per second to increase the possibility of spreading. The
`virus throttle limits the number of new connections per sec-
`ond that can be made.
`One limitation of the virus throttle described above is that
`
`the approach is specifically connection-based. Only new, out-
`bound connections are restricted. The virus throttle as
`
`described does not protect connections that are already open,
`nor does it address inbound trafiic. Thus, the described virus
`throttle is limited both in scope and flexibility.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The description of embodiments of the invention includes
`various illustrations by way of example, and not by way of
`limitation in the figures and accompanying drawings.
`FIG. 1 is a block diagram of a system with a network
`interface having a rate control agent in accordance with an
`embodiment of the invention.
`
`FIG. 2 is a block diagram of a system with a rate control
`agent in accordance with an embodiment of the invention.
`FIG. 3 is a block diagram of a rate control agent in accor-
`dance with an embodiment of the invention.
`
`FIG. 4 is a flow diagram of a system implementing a traffic
`flow policy in accordance with an embodiment of the inven-
`tion.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`
`FIG. 5 is a representation of permitted trafiic allowances
`for various network devices in accordance with an embodi-
`ment of the invention.
`
`DETAILED DESCRIPTION
`
`In one embodiment the flow of traffic may be rate-limited
`at a network device. Restricting the packet flow of ingress
`traffic may operate to reduce the risk of DoS attacks. Restrict-
`ing the packet flow of egress traffic from a device may operate
`to reduce the risk of infection, or the spread of malware from
`one machine to another. With rate limits at each machine, the
`spread within a subnet is reduced with respect to traditional
`wide open network connections.
`Various references herein to an “embodiment” are to be
`
`understood as describing a particular feature, structure, or
`characteristic included in at least one embodiment of the
`
`invention. Thus, the appearance of phrases such as “in one
`embodiment,” or “in alternate an embodiment” may describe
`various embodiments ofthe invention, and may not necessar-
`ily all refer to the same embodiment.
`FIG. 1 is a block diagram of a system with a network
`interface having a rate control agent in accordance with an
`embodiment of the invention. Host system 100 interfaces
`with network device 130 through network interface 120. Host
`system 100 represents a variety of electronic systems,
`devices, or apparatuses. For example, host system 100 may
`include a personal computer (desktop, laptop, palmtop), a
`server, a handheld computing device, personal digital assis-
`tant (PDA), wireless computing device, cellular phone, game
`console, set-top box, etc. Host system 100 may be a termi-
`nating device of a network, or a user device of the network.
`Note that even in a case where system 100 is a server, it may
`be considered a “user” of the network.
`
`Host system 100 includes host platform 110, which repre-
`sents hardware and/or software to perform operation of sys-
`tem 100. Host platform 110 may include various hardware
`modules, subsystems, and/or circuits, as well as various soft-
`ware modules, applications, subroutines, etc. Host platform
`110 includes an operating system or equivalent, and may
`include a motherboard/main circuit board, or equivalent. Host
`platform 110 provides the environment on which to execute
`user applications and system functions.
`In one embodiment host system 100 includes network
`interface 120 to interact (e. g., transmit/receive/exchange traf-
`fic) over the network with devices external to system 100.
`Traffic transmitted, received, and/or exchanged may be con-
`sidered to go through, or pass through a networked device.
`Network interface 120 may include a network interface card,
`a network interface circuit built onto a computing platform, a
`wireless or wireline communication transceiver, etc. Network
`interface 120 may support multiple mechanisms that provide
`interface to the network, including multiple ports, various
`protocols (e.g., Internet protocol (IP), Internet control mes-
`sage protocol (ICMP), transmission control protocol (TCP),
`user datagram protocol (UDP), simple network management
`protocol (SNMP), Telnet, file transfer protocol (FTP), hyper-
`text transfer protocol (HTTP), etc.), and may include various
`open connections. In one embodiment each port, connection,
`protocol, etc. may be considered a network interface from
`system 100 to another system on the network.
`In one embodiment system 100 communicates with net-
`work device 130 through network interface 120. Network
`device 130 represents a hardware and/or software entity at a
`network node, e.g., a switch, a gateway, a router, a network
`access point, or other item of a network infrastructure. Net-
`work device 130 may be considered an edge device that
`
`

`

`US 7,561,515 B2
`
`3
`provides a path to the network. In one embodiment network
`device 130 performs authentication services to verify the
`identity of system 100 prior to granting authorization to sys-
`tem 100 to access the network, or determining what type of
`service may be allocated to host system 100. Alternatively,
`authentication services could be performed separately from
`network device 130, or network device 130 could be in com-
`munication over the network with an authentication server.
`In one embodiment network device 130 includes flow
`
`policy server 131, which represents a hardware and/or soft-
`ware module/node to provide a traffic flow policy. A traffic
`flow policy may include a description/listing of traffic flow
`rates permissible, and/or traffic flow limits imposed on host
`system 100. In one embodiment the traffic flow policy is part
`of a network policy describing the service available, the per-
`mitted use by, and/or the conditions under which host system
`100 communicates over the network. The type of use permit-
`ted for system 100 may depend upon the role system 100 has
`in the network. For example, authentication credentials may
`reveal that system 100 is a server, and is responsible for traffic
`to and from a local area network (LAN). The permitted use of
`a server may be different than, for example, a corporate user,
`a personal user, etc.
`Flow policy server 131 may indicate conditions for each
`interface of host system 100. For example, particular ports,
`protocols, and/or connections may be differentiated in the
`service allocated for each. A network policy/flow policy may
`indicate a permissible frequency, or packet flow for individual
`interfaces. Thus, one port may be limited to a certain number
`of packets per second, and another port may be limited to a
`different number of packets per second. Certain protocols
`may be restricted to a certain number of packets per second.
`Likewise, connections to particular network destinations may
`be limited to a certain frequency of packets. The policy may
`indicate the packet flow restrictions based on, for example,
`the extent to which the connection/port is trusted, an expected
`behavior of the port/protocol, in response to a perceived or a
`previous security violation on the interface, etc. By limiting
`the traffic flow, the spread of malware can be significantly
`slowed, and DoS attacks can rendered less effective or inef-
`fective.
`
`The policy or policies may be stored in database 140,
`which is accessible to flow policy server 131, either remotely,
`or locally. In one embodiment database 140 stores more than
`the network policies, such as authentication information. In
`one embodiment database 140 is a policy decision maker.
`Note that the policies may be established that apply restric-
`tions equally across all interfaces, or differentiate between the
`interfaces. A policy may indicate a rate limit for a protocol,
`and rate limits for certain ports. In the case of overlapping
`policies, the lower flow limit may be used.
`In one embodiment network interface 120 includes rate
`
`control agent 121. Rate control agent 121 may be a module on
`network interface 120. For example, rate control agent 121
`may be software/firmware running on hardware (e. g., a pro-
`cessor) on network interface 120. Alternatively, rate control
`agent 121 may include an embedded processor having pro-
`gramming information and/or data stored in a local memory
`sub system. The memory sub system may include non-volatile
`memory, random access memory (RAM), Flash, a memory
`controller, etc. On network interface 120, rate control agent
`121 may be independent of, and transparent to, a host oper-
`ating system (OS). Because software and hardware visible to
`the OS may be subject to being compromised, if an intruder
`compromised the OS, rate control agent 121 transparent to the
`OS may be less likely to be compromised by attack. Thus,
`having flow agent as a hardware element and/or as a software/
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`firmware element in a hardware element of network interface
`
`120 may provide added security to host system 100.
`Rate control agent 121 represents the agent/module to
`implement/enforce the policy received from flow policy
`server 131. Rate control agent 121 may operate by restricting
`the traffic flow of various ports, protocols, connections, etc.,
`ofnetwork interface 120. Rate control agent 121 may monitor
`a number of packets on ingress and/or egress for an interface,
`and determine whether the number of packets has reached or
`exceeded a threshold number specified in the flow policy, or a
`maximum number allotted in the flow policy. In the context of
`the traffic flow policy, the expression maximum may or may
`not be understood to be an absolute maximum. For example,
`a certain number of packets may be specified as a maximum,
`and when the number has been reached, certain actions may
`be performed to restrict the packets in excess of the number.
`For example, the packets may be dropped, or they may be
`buffered and delayed. The delay would operate to allow the
`packets to be sent, but at a rate slower than that at which they
`are received or prepared for transmission. If packets are buff-
`ered and delayed, a buffer overrun may cause additional pack-
`ets to be dropped.
`Note that the packet restricting is performed by rate control
`agent 121 at host system 100. Whereas quality of service
`(QoS) is performed at an enforcing network node, the traffic
`flow limiting is performed at an individual network user.
`Thus, QoS does not operate to prevent a user from overload-
`ing the network, because QoS deals on a macro level with
`traffic from multiple sources. In contrast, the traffic flow
`limiting described herein operates at the user device, and may
`prevent an individual machine from engaging in negative
`network behavior. Note also that rate control agent 121 may
`restrict connections that are already open, as well as imple-
`menting restrictions on new connections. Additionally, as
`discussed more below, the flow restrictions can be made to be
`dynamic, and/or the policy may be periodically checked to
`provide updated limits, making the flow limiting described
`herein dynamic and adaptable to changes in the network
`environment.
`
`FIG. 2 is a block diagram of a system with a rate control
`agent in accordance with an embodiment of the invention.
`Host system 200, host platform 210, and network interface
`220 are similar to the corresponding elements of FIG. 1
`above, and will not be discussed in detail here. In one embodi-
`ment host system 200 communicates through network inter-
`face 220 with network device 240. Network device 240 rep-
`resents a gateway, router, firewall, access point, etc., and may
`be a network edge device, interconnecting host system 100 to
`a network.
`
`In one embodiment host system 200 communicates
`through network interface 220 with traffic policy server 250.
`Traffic policy server 250 may be a separate entity from net-
`work device 240 and may communicate with host system 200
`through network device 240. Alternatively,
`traffic policy
`server 250 may have a connection with host system 200
`through network interface 220,
`independent of network
`device 240. Traffic policy server 250 may include database
`251 oftraffic policies and/or network policies. In one embodi-
`ment traffic policy server 251 monitors network traffic flow of
`one or more interfaces ofhost system 200 and may determine
`to update policies.
`In one embodiment host platform 210 includes rate control
`agent 121, which represents a monitoring and/or enforcing
`mechanism for network/traffic policies. Rate control agent
`121 may be a software/firmware module in a processor ofhost
`platform 210. In one embodiment, rate control agent 121 is
`implemented as an embedded system/subsystem in a proces-
`
`

`

`US 7,561,515 B2
`
`5
`sor on host platform 210. In another embodiment, rate control
`agent 121 may be, in whole or in part, a software module
`operating between the host OS and the interface drivers for
`network interface 220.
`
`FIG. 3 is a block diagram of a rate control agent in accor-
`dance with an embodiment of the invention. Rate control
`
`agent 300 represents a circuit, a combination of logic, firm-
`ware and/or group/series of instructions for execution on a
`computation/logic device, a subsystem, or a Virtual sub-
`system that is configured, enabled, or otherwise able to per-
`form operations related to integration of authentication and
`policy enforcement services. Control logic 310 directs the
`flow of operation of agent 300. In one embodiment, control
`logic 310 is a series of software/firmware instructions to
`perform logic operations. In another embodiment, control
`logic 310 can be implemented by hardware control logic, or a
`combination of hardware-based control logic and software
`instructions.
`
`Interface 350 provides a communication interface between
`agent 300 and an external electronic system (not shown)
`and/or network. For example, agent 300 as part of a host
`computing system may have interface 350 to provide a com-
`munication interface between agent 300 and the host com-
`puting system via a system bus, for example, on a host plat-
`form, or on a network card/circuit. In one embodiment
`interface 350 includes a communication path to a network.
`For example, interface 350 may include an interface to an
`Ethernet, Internet, wireless communication channel, etc. The
`communication path may be private to agent 300, shared with
`other agents, or an access path allocated by a system/sub-
`system of which agent 300 is a part. If the communication
`path is shared, it could be arbitrated, as is understood in the
`art.
`
`Agent 300 may include applications 320. Applications 320
`represent one or more programs and/or other series ofinstruc-
`tion sequences that are executed on control logic 310. In one
`embodiment agent 300 may execute part of all of a user
`application or a system application. Applications 320 may
`provide instructions to control logic 310 to cause agent 300 to
`perform operations. Instructions may also be provided to
`control logic 310 by memory 330. For example, control logic
`310 may access, or read a portion of memory 330 to obtain
`instructions to perform a series of operations and/or data for
`use with operations. Thus, control logic 310 can receive one
`or more instructions from internal application software run-
`ning locally on rate control agent 300, such as applications
`320, from memory 330, and/or from external applications,
`storage media, etc., through interface 350.
`In one
`Agent 300 includes compliance engine 340.
`embodiment compliance engine 340 may be considered an
`enforcement module. In one embodiment agent 300 may
`perform operations including accessing/reading a policy,
`determining a policy to apply to a network interface, moni-
`toring traffic flow, obtaining and/or gathering traffic statistics,
`delaying packets, dropping packets, indicating a change to a
`policy maker, etc. Compliance engine 340 is shown with
`various features, which represent functions or features that
`compliance engine 340 may provide. Each function or feature
`is provided through performing one or more operations.
`Compliance engine 340 may include one or more of: policy
`determination feature 341, policy update feature 342, statis-
`tics monitoring feature 343, and policy enforcement feature
`544. In one embodiment one or more of these features may
`exist independently of and/or be external to agent 300. Thus,
`compliance engine 350 may be more complex or less com-
`plex, containing some, all, or additional features to those
`represented in FIG. 3.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`Policy determination feature 341 enables agent 300 to
`ascertain a policy that will be enforced on a network interface
`with which the policy is associated. In one embodiment
`policy decision feature 341 obtains a policy from a remote
`location, such as from a node/entity on the network, for
`example, from a policy server. The policy may be obtained at
`one point andused at a later point, and/or used upon obtaining
`the policy. A policy server may be queried/polled to deter-
`mine if a policy update exists. Policy determination feature
`341 may enable agent 300 to periodically update the policy, or
`obtain a new policy upon an indication of a policy update by
`a policy server. The policy may indicate restrictions on packet
`flow frequency for a port, a group of ports, one or more
`protocols, connections to particular addresses, or connections
`to devices that have any address other than specified
`addresses/subnets, etc.
`In one embodiment the policy may indicate a lock-down
`mode, or equivalent. Such a mode of operation may occur, for
`example, if the policy decision point is aware of a particular
`malware or hacker threat. In a lock-down mode, all traffic
`may be halted. Alternatively, particular trafiic to/from a
`known trusted source may be permitted and all other traffic
`restricted. In one embodiment a policy may indicate, for
`example port, protocol, and or connection combinations to
`prevent the kazaa trafiic, peer-to-peer (P2P) trafiic, etc. Traf-
`fic associated with a known remote server may be allowed
`unrestricted access. The policy may be different based on the
`role of the device to which the policy applies. In one embodi-
`ment a degraded level of service may be allowed, where one
`or more interfaces may be allowed access, but under restricted
`traffic flow constraints (possibly resulting in noticeable delay
`to the user on those interfaces).
`Policy update feature 342 enables agent 300 to indicate a
`change in operation to a policy decision maker. In one
`embodiment this includes a routine/algorithm to determine
`based on gathered statistics whether a policy change would be
`advisable for a particular interface. For example, trafiic asso-
`ciated with a particular interface could be monitored, and a
`sudden large increase in traffic observed. Based on the pro-
`tocol, the connection, a history of use of the interface, etc.,
`policy update feature 342 may determine that the increase in
`traffic flow exceeds a trigger level and may request a policy
`update of a policy decision point. Alternatively, policy update
`feature 342 may alter a local copy of the policy and indicate
`the change to a policy server.
`Changes in traffic policy may be made at a policy server
`from which rate control agent 300 obtains the policy to
`enforce on the network interfaces. Policy changes may occur
`when an information technology administrator makes a
`change and pushes the new policy to the policy server. The
`policy server may then in turn push the change out to the
`connected devices. An automated threat detection and/or
`
`reaction system may determine a new threat exists and/or
`receive a threat warning, and enter a degraded mode of opera-
`tion, or target a policy change to a network interface that
`would likely be the target of the threat.
`Statistics monitoring feature 343 enables agent 300 to per-
`form operations relating to statistics, or information relating
`to the flow of traffic in one or more interfaces. For example,
`agent 300 may track, access, and/or interpret statistics. In one
`embodiment agent 300 includes the ability through compli-
`ance engine 340 to monitor statistics, by observing and
`recording activity at a network interface. One statistic that
`may be kept is that of packet frequency at the interface.
`Alternatively, or in addition, agent 300 may query or request
`another module that keeps statistics on an interface of inter-
`est. Agent 300 may also have access to data/statistics stored
`
`

`

`US 7,561,515 B2
`
`7
`by an entity that monitors the statistics. In one embodiment
`statistics monitoring feature 343 may operate to gather sta-
`tistics that will be used by compliance engine 340, or an
`external policy decision maker to update a network policy.
`Policy enforcement feature 344 enables agent 300 to
`implement the traffic policy. In one embodiment policy
`enforcement feature 344 is an enforcement module, in hard-
`ware, software, or a combination. Enforcement feature 344
`may determine if a rate limit or a traffic threshold/maximum
`has been reached by an interface. Enforcement feature 344
`may determine based on a network policy and local statistics
`(local statistics to the device having the network interface in
`question) how to deal with traffic for an interface.
`For example, if a threshold has been reached, future trafiic
`may be delayed until a future time. Thus, if a rate of 1000
`packets per second were allotted for transmit from a particular
`port, and the threshold of 1000 packets has been reached in
`the first 500 milliseconds, additional packets waiting to be
`transmitted may be delayed for 500 milliseconds prior to
`transmission. Alternatively, 1000 packets may be organized
`and transmitted at a spaced time, or bursts of packets may be
`transmitted at spaced intervals to accommodate the 1000
`packets per second threshold.
`In another example, packets in excess of the threshold may
`be dropped, and a message sent back to the originator that the
`packets were dropped. The message may include an indica-
`tion of the delay, which could be implemented through the
`originator. An application layer module, for example, may
`provide a pre-scheduling to delay packets in keeping with the
`network policy. Alternatively, a transport layer function could
`accomplish the same thing. Hardware/software at a network
`interface circuit or network interface card could monitor and/
`
`or delay and/or drop packets. The specific mechanisms of
`flow control are not critical, and many methods can be con-
`ceived by those of skill in the art.
`In one embodiment agent 300 is implemented with firm-
`ware, software, or a combination of firmware and software.
`Agent 300 may be implemented in hardware and/or a com-
`bination ofhardware and software and/or firmware. The soft-
`
`ware and/or firmware content may provide instructions to
`cause executing hardware to perform various operations,
`including some or all of the functions/features described
`above. Instructions to cause a machine/electronic device/
`
`hardware to perform the operations may be received via an
`article ofmanufacture. An article ofmanufacture may include
`a machine accessible medium having content to provide the
`instructions. A machine accessible medium includes any
`mechanism that provides (i.e., stores and/or transmits) infor-
`mation/content in a form accessible by a machine (e.g., com-
`puting device, electronic device, electronic system/sub-
`system, etc.). For example, a machine accessible medium
`includes recordable/non—recordable media (e.g., read only
`memory (ROM), random access memory (RAM), magnetic
`disk storage media, optical storage media, flash memory
`devices, etc.), as well as electrical, optical, acoustical or other
`form of propagated signals (e.g., carrier waves, infrared sig-
`nals, digital signals, etc.), etc.
`FIG. 4 is a flow diagram of a system implementing a traffic
`flow policy in accordance with an embodiment of the inven-
`tion. A networked device requests access to a network, and
`network access is initialized, 402. A static Internet protocol
`(IP) address may be assigned, a dynamic host configuration
`protocol (DHCP) assignment, a wireless access channel
`assignment, etc. The address/channel assignment can be used
`by the device to establish one or more network interfaces. A
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`traffic request may be made to configure the network access
`of the device, 404. Network access may be configured for
`ingress and egress traffic.
`In one embodiment a traffic policy server may be present.
`A device may look on the network for a traffic flow policy
`server, 410. If there is no traffic flow policy server, the device
`may implement a default traffic flow policy, 412. The default
`policy may be pre-configured in the device prior to network
`access initialization. Alternatively, during initialization a
`default policy may be given to the device, which the device
`would implement in the absence of a policy server. In one
`embodiment the traffic flow policy server may be an authen-
`tication entity, or part of an authentication entity. Altema-
`tively, the traffic flow policy server may sit separately on the
`network.
`
`If a traffic flow policy server is available, an identification
`process may be executed, 414. This may or may not be the
`same process as used to authenticate the networked device for
`network access. The identification process in this sense refers
`to the identifying of the device for purposes of assigning a
`traffic flow policy. One or more credentials may be trans-
`ferred between the device and the traffic flow policy server,
`e.g., device identity. Based at least in part on the identification
`ofthe device, the traffic flow policy server may determine the
`device role in the network, 416. Alternatively, the device may
`be configured to provide its role in the identification process.
`The role in the network is used to determine an appropriate
`policy for the device.
`For example, a server plays a much different role in a
`network than an end-user device serving a single user. Like-
`wise, a device that is a known entity on the network