US00810737OB2
`
`(12) United States Patent
`Chandika et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 8,107,370 B2
`Jan. 31, 2012
`
`(54) NETWORKACCESS DEVICE WITH
`RECTED AND UNRESTRICTED INPUT
`
`(75) Inventors: Nagarani Chandika, Sunnyvale, CA
`(US); Hugh Holbrook, San Francisco,
`CA (US); Adam Sweeney, San Jose, CA
`s
`s
`s
`(US)
`(73) Assignee: Cisco Technology, Inc., San Jose, CA
`(US)
`
`(*) Notice:
`
`Subject to any disclaimer, the term of this
`atent is extended or adiused under 35
`ps C. 154(b) bV 1467 E.
`M
`YW-
`(b) by
`yS.
`(21) Appl. No.: 11/100,879
`(22) Filed:
`Apr. 6, 2005
`
`(65)
`
`Prior Publication Data
`US 2006/0227797 A1
`Oct. 12, 2006
`(51) Int. Cl.
`(2006.01)
`H04L 2/26
`(52) U.S. Cl. ..................... 370/230.1; 370/252; 370/255;
`37Of 463
`(58) Field of Classification Search ....... 370/299. 230.1,
`370/241-246, 252,254, 255, 256, 445, 446,
`370/463; 726/11–14; 340/5.2, 5.74; 709/238
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`5,124.984 A * 6/1992 Engel ............................ 370,230
`5,485.455 A *
`1/1996 Dobbins et al. ............... 370,255
`5.537,099 A * 7/1996 Liang ........................... 340,574
`
`5,822.303 A * 10/1998 Carter et al. .................. 370,246
`5,878,078 A * 3/1999 Griffin et al. ..
`375,222
`5,896.499 A * 4/1999 McKelvey ...................... T26, 11
`6,510,151 B1* 1/2003 Cioli et al. ..
`370,352
`6,680,917 B1 *
`1/2004 Seaman ......
`370.256
`7,299,296 B1 * 1 1/2007 Lo et al. .........
`TO9,238
`2002/01101.22 A1* 8, 2002 Ramfelt et al. ....
`370,389
`2004/0062267 A1* 4/2004 Minami et al. .
`... 370/463
`2006/0083177 A1* 4/2006 Iyer et al. ...................... 370,252
`OTHER PUBLICATIONS
`Cisco Systems, Inc., "Ciscoworks Access Control List Manager
`14'. Copyright (C) 2002, 14 pages.
`Cisco Systems, Inc., “Understanding and Configuring DHCP Snoop
`ing”. Chapter 17, Cisco IOS Software Configuration Guide-Release
`12.1 (12c)EW, obtained at http://www.cisco.com/en/US/docs/
`Switches/lan? catalyst4500/12.1/12ew configuration? guide/config.
`html, 1992-2009; 4 pages.
`* cited by examiner
`Primary Examiner — Andrew Lai
`(74) Attorney, Agent, or Firm — Fish & Richardson P.C.
`(57)
`ABSTRACT
`Access devices and methods according to the invention inter
`connect digital devices and a network. Setting a parameter
`associated with each input port of an access device specifies
`whether the device connected with that port is restricted or
`unrestricted. When a particular input port is restricted, packet
`detectors examine the packets received on that port. In some
`embodiments, an exception handler handles restricted pack
`ets from restricted devices in an advantageously flexible man
`ner. In other embodiments, a controller receives a configura
`tion command and sets the restriction parameters
`accordingly. The invention provides a simple, abstract, easy
`to use, and flexible tool for network management, configura
`tion, and reconfiguration.
`
`21 Claims, 5 Drawing Sheets
`
`Input Port
`a RESTRCTION PARAMETER
`
`Input Port
`a RESRCTION PARAMETER
`
`Input Port
`a RSTRCTION PARAMTR
`
`Packet Detectors
`
`act can "
`
`222
`
`
`
`
`
`Processor
`interface
`
`224
`
`210C
`
`Hardware
`Pattern
`Matcher
`
`
`
`
`
`Configuration
`Controller
`
`Exception
`ancer
`
`Packet Switch
`| Router
`
`
`
`25
`
`260a
`Output Port
`
`7?
`
`Output Port
`
`Output Port
`
`Y.
`200
`
`Microsoft Ex. 1008, p. 1
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`US. Patent
`
`Jan.31,2012
`
`Sheet 1 0f 5
`
`US 8,107,370 B2
`
`if
`
`mm000<
`
`00_>0n
`
`uch
`
`
`
`0.32502
`
`0o_>0n
`
`near
`
`
`
`Inca,as:00_>0n
`
`,
`
`0:02:02
`
`0o_‘>0n
`
`0.32302
`
`«:0E0mman
`
`022.502
`
`0o_>0n
`
`00_>0n
`
`mm000<mm0uo<
`
`
`
`
`
`o3‘—..07.\2:
`
`Microsoft Ex. 1008, p. 2
`Microsoft v. Daedalus Blue
`
`IPR2021-00832
`
`Microsoft Ex. 1008, p. 2
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`m
`
`8,
`
`2
`
`norm
`
`hommouo...I20%mgm,59.0.2...contour:m5033.
`
`
`
`“J“9.55.25...8N
`
`
`
`23030..Hosann—
`
`
`
`mm...m.s.<~.<n.20....uEhwmm.
`
`
`
`mmhms<m<m22.52.53..
`
`
`
`E5252“.20.5.58”..
`
`to.—.3...—
`
`ta.—:3...
`
`
`
`ton.23.:—
`
`
`
`
`
`
`
`
`
` dIINH.333..3.6.3...3:9:55m£3.25”—9.05.:OEQwoxm:o.u~.:m..:oo
`
`m08“DoomNmowm
`
`
`
`M8“N.OE8amJ,\mton.«35:0to.Sousa#5.."55:0
`
`
`
`
`
`Microsoft Ex. 1008, p. 3
`Microsoft v. Daedalus Blue
`
`IPR2021-00832
`
`Microsoft Ex. 1008, p. 3
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`
`
`
`
`
`

`

`
`
`
`
`
`
`U.S. Patent
`
`Jan. 31, 2012
`
`Sheet 3 of 5
`
`US 8,107,370 B2
`
`?IpueHD
`
`029
`
`009
`
`Microsoft Ex. 1008, p. 4
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`US. Patent
`
`Jan. 31, 2012
`
`Sheet 4 0f 5
`
`US 8,107,370 B2
`
`
`
`:o=m..:m=:ouozoooz
`
`unwEEoo
`
`
`
`
`
`.5—o:_u>539529—«mm
`
`cmv
`
`
`
`sumogamma.5035:“
`
`
`
`3*Locum—as.503mm
`
`to;3:33
`
`tomumEounm
`
`as
`
`o
`
`.5522
`
`:_tom
`
`ecu—5:00
`
`v.0."—
`
`8v
`
`Microsoft Ex. 1008, p. 5
`Microsoft v. Daedalus Blue
`
`IPR2021-00832
`
`Microsoft Ex. 1008, p. 5
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`
`
`
`
`
`
`

`

`US. Patent
`
`Jan. 31, 2012
`
`Sheet 5 of5
`
`US 8,107,370 B2
`
`fl
`
`xL
`
`O 3a 0 z
`
`connect
`Interface &
`
`
`58'
`
`9 0‘”
`n:
`
`
`
`”'3
`
`02
`mm
`
`:o E
`
`530
`
`In
`u
`9
`II-
`
`\O
`
`8
`
`Microsoft Ex. 1008, p. 6
`Microsoft v. Daedalus Blue
`
`IPR2021-00832
`
`a
`
`Mm
`
`0
`
`512
`
`>4
`2
`D.
`.9
`D
`
`h 6
`
`3
`>.
`
`0 I
`
`SIDE“:
`'BmDEI
`
`m
`:S
`M‘”<—>
`
`a
`8
`0
`0
`e
`fl.
`
`<——>
`
`Microsoft Ex. 1008, p. 6
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`US 8,107,370 B2
`
`1.
`NETWORKACCESS DEVICE WITH
`RESTRICTED AND UNRESTRICTED INPUT
`PORTS
`
`BACKGROUND OF THE INVENTION
`
`10
`
`15
`
`25
`
`30
`
`35
`
`Substantial changes have occurred in the data processing
`and computing industry over approximately the past decade.
`These changes have been driven, in part, by the increasing
`dominance of networking in general, and of the Internet in
`particular. In the past many computers were standalone, but
`today the capabilities and usefulness of many digital devices
`are Substantially enhanced by being interconnected with
`other digital devices. Packet networks often convey informa
`tion among computers, even those physically separated by
`vast distances.
`When all is working well, networking provides substantial
`benefits over computers and other digital devices operating
`alone. However, networks are themselves Vulnerable both to
`accidental malfunctions and to malicious attacks. Further,
`networks often expose to a wider audience the Vulnerabilities
`of the digital devices attached to the network. Still further,
`networks often convey the consequences of a malfunction or
`attack far beyond the digital device or devices that are the root
`of the problem. Thus, security and reliability of networks is of
`the utmost importance.
`One known approach to this problem is an access control
`list (ACL). An access control list stores in a memory a
`restricted pattern, compares this pattern to the packets trav
`eling across a particular point in a network, and drops any
`packets that are restricted, that is, that match the restricted
`pattern. Thus, any problems that would have been created by
`the restricted packet being received and acted upon are pre
`vented.
`Typically, restricted packets can be detected by examining
`the packet headers. The information required to detect a
`restricted packet typically includes some combination of data
`at the international standards organization (ISO) layer 2 (e.g.
`physical port), layer 3 (e.g. IP source address, IP destination
`address, or both), and layer 4 (e.g. protocol type, transport
`40
`layer port, or both). Thus, establishing an effective set of
`ACLS for a network is a complex and painstaking task that
`depends on the exact configuration of the network, on the
`communication protocols used (and not used) on the network,
`and on the expected use and behavior of the various digital
`devices on the network.
`Further, as the network evolves with additions, simplifica
`tions, or reconfigurations any or all of the patterns used in any
`or all of the ACLs may have to be modified to reflect the new
`configuration and expectations.
`
`45
`
`50
`
`SUMMARY OF EMBODIMENTS OF THE
`INVENTION
`
`Various embodiments of the invention provide systems and
`methods for interconnecting a restricted device and a net
`work. In a preferred embodiment, a device for accessing the
`network has various input ports, with each port having an
`associated parameter whose value is either restricted or unre
`stricted.
`One embodiment of the invention is an access device with
`input ports for receiving packets of network traffic. Each
`input port has a parameter indicating whether the connected
`digital device is restricted or unrestricted. The access device
`includes packet detectors that examine packets received when
`a particular packet detector is enabled for that input port and
`that determine whether the packets examined are restricted. A
`
`55
`
`60
`
`65
`
`2
`controller within the access device enables the packet detec
`tors for restricted input ports and disables the packet detectors
`for unrestricted input ports.
`In some embodiments, an exception handler within the
`access device handles restricted packets from restricted
`devices in an advantageously flexible manner. In other
`embodiments, the access device further includes a controller
`that receives a configuration command and that sets the value
`of the input port parameters in response to the command.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`Objects, features, and advantages of various embodiments
`of the invention will become apparent from the descriptions
`and discussions herein, when read in conjunction with the
`drawings. Technologies related to the invention, example
`embodiments of the invention, and example uses of the inven
`tion are illustrated in the following figures:
`FIG. 1 shows the components and their interconnections
`within a network according to an embodiment of the inven
`tion.
`FIG. 2 shows the components and data flow within an
`access device according to another embodiment of the inven
`tion.
`FIG. 3 shows the activities that occur when a packet is
`received by an access device according to yet another
`embodiment of the invention.
`FIG. 4 shows the activities that occur when a configuration
`command is received by an access device according to an
`embodiment of the invention.
`FIG. 5 shows the components and their interconnections
`within a digital device, including an access device according
`to another embodiment of the invention.
`
`DETAILED DESCRIPTION OF EMBODIMENTS
`OF THE INVENTION
`
`The descriptions, discussions and figures herein illustrate
`technologies related to the invention and show examples of
`the invention and of using the invention. Known methods,
`procedures, systems, circuits, or elements may be illustrated
`and described without giving details so as to avoid obscuring
`the principles of the invention. On the other hand, details of
`specific embodiments of the invention are described, even
`though Such details may not apply to other embodiments of
`the invention.
`Some descriptions and discussions herein use abstract or
`general terms including but not limited to receive, present,
`prompt, generate, yes, or no. Those skilled in the art use Such
`terms as a convenient nomenclature for components, data, or
`operations within a computer, digital device, or electrome
`chanical system. Such components, data, and operations are
`embodied in physical properties of actual objects including
`but not limited to electronic Voltage, magnetic field, and opti
`cal reflectivity. Similarly, perceptive or mental terms includ
`ing but not limited to compare, determine, calculate, and
`control may also be used to refer to Such components, data, or
`operations, or to Such physical manipulations.
`FIG. 1 is a block diagram of a network 100, which illus
`trates an embodiment of the invention. In network 100, access
`devices 110 interconnect a number of restricted devices and a
`number of unrestricted devices. Restricted devices, also
`known as host devices, include personal computers (PCs)
`150, a set top box (STB) 160, and a personal digital assistant
`(PDA) 170.
`Unrestricted devices, also known as trusted or secured
`devices, include network devices 120, a server 130, and a
`
`Microsoft Ex. 1008, p. 7
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`3
`network management device 140. Network devices 120
`include, but are not limited to, Switches, routers, bridges and
`the like. Server 130 may include, but is not limited to, a data
`server, a domain name system (DNS) server, or a dynamic
`host control protocol (DHCP) server.
`Network communication links 180 interconnect the vari
`ous components within network 100. For example, network
`communication link 180a interconnects network manage
`ment device 140 and network device 120a, and link 180b
`interconnects network devices 120c and access device 110c.
`Links 180 may include any mixture of, but are not limited to:
`Ethernet links; local area network (LAN) links; virtual local
`area network (VLAN) links; wide area network (WAN) links:
`private intranet links, or links over the public Internet.
`Access devices 110 have two types of interfaces. Interfaces
`113 include an unrestricted input port. Interfaces 113 inter
`connect the access devices with the unrestricted devices
`within network 100, for example, interfaces 113a and 113b
`interconnect access devices 110a and 110b, respectively, with
`network device 120b, which may be, for example, a router in
`a physically secure location that is controlled by the network
`administrator.
`Interfaces 116 include a restricted input port. Interfaces
`116 interconnect access devices 110 with the restricted por
`tions of network 100, for example, interfaces 116a and 116b
`interconnect set top box 160 with respectively access device
`110a and 110b. Set top box 160 may, for example, be in a
`location that is not secured and thus Vulnerable to having its
`network connections used maliciously.
`FIG. 2 is a data flow diagram of a portion 200 of an access
`device that illustrates an embodiment of the invention. Access
`device portion 200 includes input ports 210, packet detectors
`200, a configuration controller 230, an exception handler 240,
`a packet switch/router 250, and output ports 260. Each arrow
`in FIG. 2 indicates that network packets flow between the
`components of access device 200 in the direction indicated.
`Configuration controller 230 is described with respect to FIG.
`4 below.
`Associated with each input port 210 is a restriction param
`eter that has the value restricted or the value unrestricted,
`depending on whether the device connected with that particu
`lar input port is a host device or a network device, respec
`tively. Various embodiments of the invention define in various
`ways what types of devices should be restricted and what
`types of devices should be unrestricted. In some embodi
`ments, network devices are connected to unrestricted ports
`and host devices are connected to restricted ports.
`Each input port 210 receives packets of network data traffic
`that are transmitted from the digital device connected with
`that particular input port. The packets then flow to packet
`detectors 220. From packet detectors 220, the packets flow
`either to packet switch/router 250 for normal handling, or to
`exception handler 240 when restricted packets are received
`on a restricted input port.
`Various embodiments of the invention include packet
`detectors that detect various types of restricted packets. For
`example, host devices do not forward packets onto other
`devices. Thus, it is improper when a host device attempts to
`participate in Switching or routing protocols. Such attempts
`are likely due to a malicious attempt to intercept network
`traffic or to disrupt network capabilities.
`Such switching protocols include, but are not limited to, the
`well known spanning tree protocol. Thus, a packet detector
`that detects bridge protocol data unit (BPDU) packets, as used
`in a spanning tree protocol, is included in Some embodiments
`of the invention. Similarly there is no legitimate need for a
`host to participate in a routing protocol, including but not
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 8,107,370 B2
`
`4
`limited to the routing information protocol (RIP) and the
`interior gateway routing protocol (IGRP). BPDU packets,
`spanning tree protocols, the RIP protocol, and the IGRP pro
`tocol are known in the art.
`Many multicast protocols include both request packets that
`host devices may issue and command packets that they may
`not issue. A host may legitimately make a request to, for
`example, join a particular multicast stream. A router, but not
`a host, may issue a command to get information on all cur
`rently available multicast streams. Such multicast protocols
`include, but are not limited to, the well known Internet group
`management (IGMP) protocol, and the well known multicast
`listener discovery (MLD) protocol.
`Similarly, host devices may legitimately issue request
`packets within the well known dynamic host configuration
`protocol (DHCP) or the well known domain name system
`(DNS) protocol. However, hosts may not legitimately issue
`response packets in these protocols.
`The above descriptions of restricted packets are not
`exhaustive; that is, embodiments of the invention may con
`sider other packet types in these or other protocols to be
`restricted. Any set of packets may be considered restricted as
`long as it is possible to define a pattern that the set of packets
`follows. Such a pattern is called a restricted pattern.
`In some embodiments of the invention, role based access
`control (RBAC) techniques may be used to aid the process of
`generating suitable descriptions of restricted patterns. RBAC
`may also help with updating the restricted patterns as the
`components of the network and their interconnections
`change, as the protocols supported by the network change, or
`as better defenses against attacks and accidents are identified.
`RBAC techniques are well known.
`Various embodiments of the invention include packet
`detectors that have various designs and architectures. As
`shown in FIG. 2, packet detectors 220 include a content
`addressable memory (CAM) 222, a processor interface 224,
`and a hardware pattern matcher 226. When packets received
`are to be examined, fields within each packet, or more typi
`cally fields within the header of each packet, are extracted.
`One or more of packet detectors 220 examine one or more of
`the extracted fields.
`The contents of one or more of the extracted fields are
`looked up within CAM 222. If the extracted fields are found
`via the lookup operation, then the packet matches a restricted
`pattern and thus the packet is restricted. If a restricted packet
`is received on a restricted port then the packet is not processed
`normally, rather the packet flows on to exception handler 240.
`If an unrestricted packet is received or if any packet is
`received on an unrestricted port then the packet flows onto
`packet switch/router 250 for normal processing.
`In some embodiments of the invention, CAM 222 is con
`figured to hold access parameters based on access controllists
`(ACLs). Access control lists stored in CAMs allow dynamic
`configuration of the set of restricted patterns that are to be
`detected; that is, changing the content of the CAM changes
`what patterns are restricted. A ternary CAM, that is, one
`where some bit positions of the pattern to match can be stored
`as “don’t cares can be used advantageously for storing
`restricted patterns for packets. ACLs, CAMs, and ternary
`CAMs are known in the art.
`Packet detectors 220 also include a processor interface
`224. Processor interface 224 determines which packets are to
`be handled by a processor (as shown in FIG.5) working under
`the control of a firmware or software program. Some embodi
`ments of the invention use a program to handle, for example,
`routing protocol packets. Such a program includes traps that
`are executed, instead of normal processing, when a restricted
`
`Microsoft Ex. 1008, p. 8
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`5
`type of routing packet is received on a restricted input port.
`These program traps pass the packet that triggered the trap on
`to exception handler 240, or the traps simply handle the
`restricted packet within the program. Unrestricted packets, as
`well as all packets from unrestricted input ports, are handled
`normally under program control.
`Packet detectors 220 also include a hardware pattern
`matcher 226. Hardware pattern matcher 226 is a special pur
`pose pattern matcher that detects restricted packets that match
`the restricted pattern designed into or programmed into
`matcher 226. In a manner similar to that of ACL CAM 230,
`restricted packets received on a restricted input port flow on to
`exception handler 240. Unrestricted packets or any packet
`from an unrestricted port flow onto packet switch/router 250
`for normal processing.
`Exception handler 240 takes the appropriate action when a
`restricted packet is received on a restricted input port. These
`actions include, but are not limited to, one or more of the
`following: dropping the packet, generating a log message;
`generating a message according to a network management
`protocol Such as the simple network management protocol
`(SNMP); generating an e-mail message; generating a security
`alarm, disabling the input port on which the restricted packet
`is received; or limiting a rate of packets on the input port on
`which the restricted packet is received. Typically, each Sus
`pect packet is dropped and one other action from the above list
`is taken.
`Nevertheless, there are situations in which network integ
`rity can be maintained by allowing Suspect packets to go
`through, but only at a limited rate. For example, some routing
`protocol command packets may resultina Substantial amount
`of network traffic, a Substantial amount of router processing,
`or both. When Such packets are issued by an attacker at a high
`rate, legitimate network traffic and processing may be denied
`sufficient bandwidth to function properly. Such a denial of
`service attack is rendered ineffective if the access device only
`allows such packets to go through at a sufficiently low rate,
`and drops only such packets when received in excess of that
`rate.
`Packet switch/router 250 determines the output port or
`ports 260 to which the packet is sent. Switching and routing
`are known in the art.
`Each output port 260 transmits packets over the network
`communication link associated with that particular output
`port. Typically, but not necessarily, each communication link
`Supports bi-directional communication between the access
`device and a digital device, so that one input port and one
`output port are associated with each communication link and
`thus with each digital device.
`The distinction between the restricted input ports of inter
`faces 116 connected to host devices and the unrestricted input
`ports of interfaces 113 connected to secure devices advanta
`geously enhances the security and reliability of network 100.
`Security and reliability is further enhanced by associating the
`restriction parameter with each physical input port of the
`access device, i.e. by having the restriction mechanisms
`enabled and disabled at layer 2 of the ISO hierarchy.
`Further, the simplicity and abstract or high level nature of
`the input port parameter (i.e. each port is either restricted or
`unrestricted) allows the security of network 100 to be config
`ured easily, and easily reconfigured as the network configu
`ration is altered. Still further, as new protocols are introduced,
`the packet detectors used can be reconfigured, modified,
`enhanced, or augmented without the need to alter the network
`configuration as specified in the restriction parameters. Simi
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 8,107,370 B2
`
`10
`
`15
`
`6
`larly, as better defenses against attacks and malfunctions are
`identified, only the packet detectors need to be updated, not
`the restriction parameters.
`FIG.3 is a flow chart of a process 300, which describes the
`operation of an access device according to an embodiment of
`the invention. Process 300 is ongoing and has no predefined
`end point.
`In activity 310, an input port 210 receives a packet of
`network traffic. Next in activity 320, the packet received is
`passed to packet detectors 220. Each packet detector 220
`examines the packet to determine if it is restricted, that is, if it
`matches a restricted pattern. Input ports 210 and packet detec
`tors 220 are described with respect to FIG. 2.
`Next, activity 330 determines whether or not a restricted
`packet has been received on a restricted port. If so, activity
`350 occurs next. Otherwise, activity 340 occurs next, in
`which the packet is processed normally. Activity 350 handles
`the restricted packet as an exception. Activity 350 is described
`with respect to exception handler 240 of FIG. 2.
`Some embodiments of the invention use an alternative to
`process 300, in which activities 320 and 330 occur only for
`those packets received on a restricted input port. Packets
`received on an unrestricted port pass directly from activity
`310 to activity 340. This embodiment may be more efficient
`than process 300 when implemented via a program, or less
`efficient than process 300 when implemented in hardware.
`After either activity 340 or 350, activity 310 occurs repeat
`edly each time another packet is received on an input port 210
`of the access device.
`FIG. 4 is a flow chart of a process 400 according to an
`embodiment of the invention. In process 400, a configuration
`command is received and processed. Process 400 occurs in a
`configuration controller 230 within an access device, as
`described with respect to FIG. 2.
`Process 400 starts with activity 410, in which a configura
`tion command is received. Such a command may be received
`in various ways, including but not limited to: by receiving a
`simple network management protocol (SNMP) packet; or by
`a user Such as a network administrator entering a configura
`tion command into a command line interface (CLI) window
`linked to the access device. The SNMP packet or the CLI
`command may, but need not, originate from network man
`agement device 140, as described with regard to FIG. 1.
`The configuration command received specifies, at a mini
`mum, a particular value of the restriction parameter (i.e.,
`either restricted or unrestricted) for a particular input port of
`the access device. In various embodiments of the invention, a
`single command may specify multiple input ports and the
`value, or the set of respective values, to which each ports
`parameter is to be set.
`The configuration commands Supported by various
`embodiments of the invention provide simple, abstract, easy
`to use, and flexible mechanisms for network configuration. In
`particular, they substantially help the network administrator
`with the challenging task of ensuring the security and reli
`ability of the network. Practical networks are often in a state
`of flux, as new network devices and hosts are added, current
`devices are moved or removed, and network links are added,
`replaced, or restructured. Such network reconfigurations are
`also advantageously facilitated by the invention’s ease of use.
`After activity 410, activity 420 occurs, in which the param
`eter value specified in the command is stored for one of the
`input ports specified in the configuration command received.
`Next, activity 430 occurs. If the value specified in the com
`mand for the current input port is restricted, then each pattern
`matcher within the access device is enabled for packets arriv
`
`Microsoft Ex. 1008, p. 9
`Microsoft v. Daedalus Blue
`IPR2021-00832
`
`

`

`US 8,107,370 B2
`
`5
`
`10
`
`15
`
`25
`
`35
`
`7
`ing on that port. If the value specified is unrestricted, then
`each pattern matcher within the access device is disabled for
`packets arriving on that port.
`In some embodiments of the invention, a configuration
`command may specify which action or actions are to be taken
`when a restricted packet is received on a restricted input port.
`In Such embodiments, activity 430 includes configuring and
`initializing these actions.
`After activity 430, activity 440 occurs in which control
`returns to activity 420 if there is another input port specified
`in the configuration command received. Process 400 ends
`when activity 440 determines that all of the input ports speci
`fied in the configuration command received have been con
`figured as specified.
`FIG. 5 is a block diagram of a digital device 500. Various
`embodiments of the invention may use device 500 in various
`ways. Device 500, or a variant thereon, may be used as an
`access device, a network device, a host, a network manage
`ment device, a server, or the like.
`Digital device 500 includes one or more buses 510 config
`ured to communicate information, Such as addresses, opera
`tion codes, or data. The device also comprises one or more
`processors 502 configured to process information and data
`according to instructions and other data. The processor may
`be, but is not limited to: a central processing unit; a micro
`processor, an embedded processor, or a special purpose pro
`CSSO.
`Digital device 500 may optionally include RAM 504, that
`is, one or more Volatile memory units, devices or circuits
`configured to store information, data or instructions. RAM
`30
`504 may be but is not limited to random access memory
`(RAM), static RAM, or dynamic RAM. RAM504 is coupled
`to buS 510.
`Digital device 500 may optionally include ROM 506, that
`is, one or more non-volatile memory units or other devices or
`circuits configured to store static information and instruc
`tions. ROM506 may include, but is not limited to one or more
`of read only memory (ROM); programmable ROM: flash
`memory; electrically programmable ROM (EPROM); or
`erasable electrically programmable ROM (EEPROM). ROM
`40
`506 is coupled with bus 510.
`Digital device 500 may optionally include network inter
`face and interconnect 508, that is, one or more devices or
`circuits configured to interface with one or more other elec
`tronic devices via one or more networks 530. Network inter
`face and interconnect 508 is coupled to bus 510. Network
`interface and interconnect 508 may optionally perform one or
`more of Switching, routing, bridging, or relay functions
`among networks 530. Networks 530 may include, but are not
`limited to one or more of Internet protocol (IP) networks:
`asynchronous transfer mode (ATM) networks; frame relay
`networks; time division multiplexing (TDM) networks; or the
`public switched telephone network (PSTN).
`Digital device 500 may optionally include keyboard 514,
`that is, one or more alphanumeric input devices configured to
`communicate information and command selections from a
`user. Keyboard 514 may, for example, have alphabetic,
`numeric, function and control keys, buttons, selectors or
`touch-sensitive screens. The keyboard is coupled to bus 510.
`Alternatively or additionally, the functions of keyboard 514
`may be directed or activated via input from mouse 516 using
`special menus, click sequences, or commands.
`Digital device 500 may optionally include mouse 516, that
`is, one or more cursor control, indicating, selecting, pointing,
`or control devices configured to communicate analog, quan
`titative or selection user input information and command
`selections to processor 502. Mouse 516 may include, but is
`
`50
`
`45
`
`55
`
`60
`
`65
`
`8
`not limited to one or more of a mouse; a track ball; a touch
`pad; an optical tracking device; a joystick; a game controller;
`a touch screen; or a glove. The mouse is coupled to bus 510.
`Alternatively or additionally, the functions of mouse 516 may
`be directed or activated via input from keyboard 514 using
`special keys, key sequences or commands.
`Digital device 500 may optionally include disk 518, that is,
`one or more devices or circuits configured to store informa
`tion, data or instructions. Disk 518 may include, but is not
`limited to one or more of a mass storage device; a magnetic
`disk; an optical disk; a compact disk (CD); a writeable CD; a
`digital versatile disk (DVD); a hard disk; a floppy disk; a flash
`memory; or a memory stick. Disk 518 is coupled to bus 510.
`Digital device 500 may optionally include display 512, that
`is, one or more devices or circuits configured to display pic
`tures, video, text, or graphics. Display 512 may include, but is
`not limited to one or more of: a cathode ray tube (CRT); a flat
`panel display; a liquid crystal display (LCD); a field emission
`display (FED); or a heads up display suitable for use in a
`vehicle