|Publication number||US8006304 B2|
|Application number||US 12/478,216|
|Publication date||Aug 23, 2011|
|Filing date||Jun 4, 2009|
|Priority date||May 21, 2003|
|Also published as||US7523485, US7562390, US7979903, US8245300, US8918875, US20090254973, US20090265785, US20090307773, US20120011584|
|Publication number||12478216, 478216, US 8006304 B2, US 8006304B2, US-B2-8006304, US8006304 B2, US8006304B2|
|Original Assignee||Foundry Networks, Llc|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (107), Non-Patent Citations (86), Referenced by (13), Classifications (10), Legal Events (9)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present application is a continuation application of U.S. application Ser. No. 10/631,091 filed Jul. 31, 2003, now U.S. Pat. No. 7,562,390, issued Jul. 14, 2009, which is incorporated herein by reference in its entirety for all purposes. U.S. application Ser. No. 10/631,091 claims benefit from U.S. Provisional Patent Application Ser. No. 60/472,170, filed May 21, 2003, which is incorporated herein by reference in its entirety for all purpose. U.S. application Ser. No. 10/631,091 also claims benefit from U.S. Provisional Patent Application Ser. No. 60/472,158, filed May 21, 2003, which is incorporated herein by reference in its entirety for all purposes.
The present invention relates to a method of providing for enhanced security on a computer network to reduce the risk created by the spoofing of address resolution protocol (ARP) replies.
The address resolution protocol (ARP) is a widely known process by which devices obtain necessary address information for transmitting data packets over computer networks.
A host device on the subnet can communicate with other hosts by transmitting data packets to the host that they desire to communicate with. These data packets will include a number of pieces of information that are used to ensure that the data packet is received by the destination host. Each host device on the subnet has a MAC address. The MAC address is unique for each host, and is usually determined by the network interface card for the host device, as is widely known. Further, as is also widely known each host will generally be assigned an IP address when the host is coupled to the subnet. The assigning of an IP to a host can be done in a number of different ways. One very common technique is to use the Dynamic Host Configuration Protocol (DHCP), which provides for transmitting a data packet to a host when the host is initially coupled to the subnet, and this data packet will provide the host with its IP address.
When a source host on a subnet generates a data packet to be transmitted to a destination host on the subnet, the generated data packet should include a number of elements including the MAC address and IP address for the source host, and the MAC address and the IP address for the destination host. It is sometimes the case that the source host will have the IP address for the destination host, but not the destination MAC address. In this situation the source host will generate an ARP request. The ARP request is transmitted from a host, to a switch, and the switch will broadcast the ARP request across the subnet.
Area 208 shows specific contents of the ARP reply. The source of ARP reply has source hardware address (MAC address) of 00:50:18:03:D5:30, and a source protocol address (IP address) 192.168.1.254. The destination MAC address and IP address are shown as being the addresses for the host which generated the ARP request.
Layer 2 network devices on the subnet operate to route data packets based on the MAC addresses contained in the data packets generated by the hosts on the subset. The IP addresses for the different hosts are utilized when the switches, or other layer 2, devices on the subnet recognizes that the MAC address is not coupled to the particular subnet. Once it has been determined that the MAC address of the destination host is not in the subnet, then the datapacket is switched through ports of the layer 2 network devices such that the datapacket is transmitted to the layer 3 router 126. The router 126 operates to route received data packets based on the IP address contained in the data packet, and the router 126 does not utilize the MAC address of the host which originally generated the data packet. For example, if a host device coupled to switch 102 of the first subnet were to transmit a data packet identifying a destination host which was coupled to the switch 116 of the second subnet, the data packet would be transmitted to the port of the router which was coupled to the first subnet, and based on the IP address of the destination host contained in the data packet the router would make the determination that the data packet should be transmitted to the second subnet 130 through a port of the router 126 which is coupled to the second subnet. As is known in the art a router can also operate to transmit datapackets, as IP datagrams over the Internet according to the TCP/IP protocol, and possibly other similar protocols.
ARP spoofing occurs in situations where an attacker poisons the ARP cache of the victim host, typically a personal computer (PC), by spoofing the MAC/IP pair of the ARP reply. For example, an attacker host could respond to an ARP request, which is broadcast on the subnet, as if the attacker host were the host which is assigned the IP address which is being queried in the ARP request. In response to the ARP request, the attacking host will generate a spoofed ARP reply in which the attacking host provides its MAC address and the IP address which was contained in the ARP request. This ARP response with the spoofed information, when received, will cause the host which generated the ARP request, to operate using the MAC address of the attacking host instead of the MAC address for the host which is actually assigned the IP address that was contained in the original ARP request.
A goal in an ARP spoofing attack is for the attacking host's forged, or spoofed, ARP reply (spoofed in the sense that the ARP reply shows an improper pairing of a MAC address and an IP address) to trick a target computer into caching the forged ARP entry, meaning that the target host will store the MAC address for the attacking host and use this MAC address in place of the MAC address for the actual desired destination host. When the ARP spoofing attack is successful the target will send data packets to the attacking host, and the target will have no idea that data packets have been redirected to the attacking host.
ARP spoofing can allow an intruder's computer to perform a man-in-the-middle (MIM) attack between hosts on a particular subnet and a gateway router port, and to perform session hijacking attacks. Using ARP spoofing, the attacker's host tricks the victim, or target, hosts into thinking that the attacking host is the gateway address through an ARP and MAC Address Spoof, as described above. The attacking host can then collect the data packet traffic and sniff the data packets (e.g. the attacking host can analyze and save information from the transmitted data packets). The attacking host can then route the traffic back to the gateway address.
Another way of sniffing on a switched network is through a concept called MAC flooding. The attacking host sends spoofed ARP replies to a switch on the subnet at a very high rate and overflows a MAC address table in the switch. This attack attempts to put the switch into broadcast/hub mode when their MAC tables are overflowed, which allows the data packet traffic to be sniffed. A variation of the MAC flood attack is to flood the network with spoofed ARP replies setting the MAC address table of a network gateway to the broadcast addresses, all external-bound data will be broadcast. This also enables sniffing on a switch.
ARP spoofing can also be used effectively as a Denial of Service (DoS) attack. By using ARP replies to flood the network with non-existent MAC addresses, host caches on the subnet are filled with garbage ARP entries that cause packets to be dropped. Session hijacking which allows an intruder, or attacking host, to take control of a connection between two computers can also be achieved using ARP and MAC spoofing similar to MIM attacks.
The risks poised by ARP spoofing attacks have been recognized, and currently there is a widely adopted software application called Arpwatch which is used to spot malicious ARP activity. Arpwatch is used by system administrators to detect changes in host IP addresses and ethernet addresses (MAC addresses). ARP watch listens for ARP requests which are broadcast and ARP reply packets which are sent on the ethernet (subnet) interfaces it is monitoring. For example, in the computer network 100 of
Below is a sample output from arpwatch (version 2.0.1a1):
8:0:69:6:b2:b7 220.127.116.11 856807441 buffett 8:0:69:6:8c:6c 18.104.22.168 856810206 peace 8:0:69:a:6a:a 22.214.171.124 856810392 heckler 8:0:69:8:7e:39 126.96.36.199 856810397 leo 8:0:20:8:61:a2 188.8.131.52 856810390 poppy 8:0:69:8:7e:13 184.108.40.206 856810239 win112 8:0:69:9:1d:9e 220.127.116.11 856810235 silk 8:0:69:a:3f:7a 18.104.22.168 856810192 nothing 8:0:20:18:1e:e0 22.214.171.124 856810464 vips 8:0:69:9:b1:5a 126.96.36.199 856810205 gecko
The first column lists the 6 hexadecimal digit ethernet address (MAC address) of a host. Column two contains the ip address. Column three holds a timestamp for the reporting made by the host for activity regarding the ip/ethernet addresses. Lastly, the hostname is reported in the fourth column. While system activity is logged to file arp.dat, any occurring changes are reported to root through e-mail messages.
One limitation with Arpwatch has been its ability to see all the ARP traffic on the subnet. It cannot be used for network wide monitoring due to ARP's inability to send ARP natively over Layer 3 networks. For example, as is known in the art, the ARP request and ARP replies on the subnet 128 would not be transmitted through the layer 3 router to the second subnet. Further, in certain circumstances, it is possible that depending on the configuration of the subnet, and the location of the hosts generating the ARP requests and ARP replies, the Arpwatch program running on 114 may not even see all ARP request and ARP replies on the first subnet. In order to overcome some of these limitations in Arpwatch, implementations of networks utilizing mirrored ports on uplinks, tagged VLANs, etc. have been developed to increase the amount of ARP request and ARP reply traffic, which can be observed by Arpwatch. However, each of these fixes has been found to have limitations and can be difficult to implement in some network configurations.
An embodiment herein provides a system and method where layer 2 devices, such as switches on a subnet, operate to copy and forward information from ARP replies on a subnet, to a central ARP collector. It should be noted that in referring to a layer 2 device, this does not exclude a device which also includes some layer 3 capabilities. As is known in the art a number of network devices provide for both layer 2 and layer 3 functionality. For example, a layer 2 device can operate to direct the transmission of data packets based on the Ethernet or MAC address information in a data packet, and provide some layer 3 capability such as routing data packets based on IP address information. In general layer 2 and layer 3 functions are widely known under the International Standards Organization's Open Systems Interconnection (OSI) model. Additional aspects of layer 2 and layer 3 operations are discussed in pending patent application titled MULTIPLE TIERED NETWORK SECURITY SYSTEM, METHOD AND APPARATUS, filed Jun. 10, 2003, U.S. patent application Ser. No. 10/458,628 (inventors Philip Kwan and Chi-Jui Ho) and which is assigned to the same assignee as the present patent application, and which is incorporated herein by reference.
One feature of an embodiment of a network device of the present invention, such as 300 shown in
As discussed in more detail below, an embodiment herein provides for formatting and transmitting copies of ARP Replies or ARP Broadcasts to an ARP collector, or to several ARP collectors. By forwarding copies of ARP replies, multiple network segments, and subnets can be observed using at a single point. This single point can be a computer programmed to store the ARP information as described below, and to analyze the information according to the procedures herein. By increasing the amount of ARP information and learning all Ethernet/IP Pairs at a central point, increased protection against ARP spoofing can be obtained.
An additional feature of an embodiment of a system and method herein, is that port information can be utilized in addition to the ARP information. As can be seen from the sample Arpwatch output (shown above), Arpwatch does not utilize port information. To obtain and utilize the port information, an embodiment of the network device herein provides for sending port information, such as information showing the port where the ARP reply packet was received, along with the transmitted copy of the ARP information. The date and time of the original ethernet/ip pair information should also be collected to show when the information was first learned.
Because every host, or IP device, must use ARP to communicate on an IP network, and all ARP Replies are handled by a processor in an embodiment of a network device herein as part of the normal processing of an ARP reply, an embodiment herein can provide a solution which provides for protection against ARP spoofing by providing a system or method which includes a number of possible functions.
For example, the ARP Protection feature herein allows for one, or several, ARP collectors to be defined at the global level. In determining a configuration for use of ARP collectors, and determining which ARP information to copy and transmit it may be beneficial to utilize a methodology similar to known sFlow systems. Additionally the assignee of the present patent application has developed enhanced sflow systems and methods as described in currently pending and commonly assigned patent application entitled NETWORK MONITORING USING STATISTICAL PACKET SAMPLING, with Ser. No. 10/107,749 filed Mar. 26, 2002, which is incorporated herein by reference in its entirety.
An embodiment of the present invention, allows for the ARP Protection feature to be selectively enabled on a port-by-port bases, such that a system administrator can select ports to monitor ARP traffic on. This will allow a system administrator to avoid heavy traffic uplink ports and select only the end-user ports that supporting areas with high-risk users (hackers).
In addition to normal processing of the ARP Reply packet, the ARP protection features described herein provide for capturing ARP reply information which is received at port on the network device. This captured ARP Reply information is encapsulated in a standard IP datagram, datapacket, and sent it to a central ARP collector. This capturing of ARP reply information is referred to herein as ARP Tunnel Protocol (ATP). The ATP can utilize encryption technologies such as MD5 and a shared secret key between the network device and an ARP collector. This will ensure that the ARP traffic being sent to the ARP collector is legitimate and unmodified. Hackers may indeed learn of the ATP operation and may attempt to spoof packets to the ARP collector to poison its database. Using MD5 and a secret key greatly decreases the likelihood of this type of activity being successful. Further, instead of using MD5 technology, a unique protocol could be utilized for formatting the information in the ATP data packets; this protocol would be unique and used specifically for the formatting of the ATP packets, and only data packets conforming to this unique protocol would be utilized by the ARP collector.
A computer network 700 of an embodiment of the present invention is shown in
The ARP collector can also provide a DNS lookup module 812 which operates to perform a DNS lookup on the ATP packet to add the fully qualified host name to its database record. Using ARP Spoofing detection module 814, the ARP collector can monitor the ARP reply information in the ATP packets. The ARP collector can provide an ARP spoof alarm generator 816 that is triggered when there is a rapid “flip flopping” of the ethernet/ip address pair, such as: Original ethernet/ip pair→spoofed ethernet/ip pair→original ethernet/ip pair. The ARP spoofing detection module 814 can be programmed to allow a system administrator to set the duration for the ARP Spoof cycle, or a default duration can be utilized. The time duration should be short enough such that it is very unlikely that the change of the Ethernet/IP address pair is legitimate. The ARP collector could be implemented in a standalone computer, or the software could be used to program a computer which is providing additional system functions.
When an ARP spoof condition is detected, the ARP Collector may perform a number of different actions, as determined by its programming. One possibility is that the ARP collector will do nothing. For example, the ARP collector may just be building and collecting data, or the ARP protection feature may not be activated on a particular port. The ARP collector could also generate an alert. This alert could take a number of different forms. The alert could include logging the suspected ARP spoofing activity in a log in the ARP collector and sending a notice to an external Syslog server. The alert could also include emailing a system administrator at a predefined email addresses. In addition to providing an alert, the system could operate to disable the port on which the suspected spoofed ARP reply was received for a predefined amount of time. This predefined amount of time could be set to a default amount time, for example 10 minutes, or a system administrator could set the amount of time to disable the port. In some cases, the port might be disabled for a much longer period of time or possibly permanently. In some embodiments, the MAC filtering on the network device could be utilized to filter a MAC address which is suspected of generating spoofed ARP replies. This filtering could be set for a predefined amount of time (e.g., 10 minutes), and in some cases the suspected device could be MAC filtered permanently. To facilitate automated implementation of these security features the ARP collector could communicate instructions directly to the network switching devices on the subnets 724 and 726 of the computer network 700 shown in
The ARP Collector will accept the ATP packets from all ARP Protection enabled network devices. Valid ATP packets will be decrypted and stored in a dedicated ARP Database. At the minimum, the following ARP Reply attributes should be stored:
The above reference to the Ethernet MAC refers to the device's MAC address, for the host which generated the ARP reply. The reference to Source IP, above, is a reference to the device's Source IP address, for the host which generated the ARP reply. The reference to the Source Port, is a reference to the port on which the ARP Reply packet was received. It should be noted that the source port information may not normally be included in an ARP reply, but the network device could identify this information and include it in the ATP data packet sent to the ARP collector. The Original Date column refers to the first time the ARP Collector learned the ethernet/ip pair, and specifically the first time the Ethernet address was identified. The Latest Date column is the last ethernet/ip pair received from the device, and this information is used to spot flip-flopping conditions. The hostname column shows the DNS/WINS name of the device sending the ARP Reply. Additional optional identification information may include a chassis identifier, such as the management IP address of the device, device name, or device serial number.
The ARP collector is programmed to provide a range of functions in connection with providing ARP anti-spoofing protection. This operation provides that when a host initially comes online to a computer network, and the ATP packets is transmitted to the ARP collector, the ethernet/ip pair for the host is recorded in the ARP collector database with the original date stamp and port information. As the ARP collector receives subsequent ARP Replies from the same host device, these subsequent ARP replies are compared to this original record. If there are no changes in the ethernet/ip pair information, the ARP collector records only the date and time in the Latest Date/Time field and discards the ARP Reply (nothing has changed).
When the collector detects a change in the ethernet/ip information for the device, one of two conditions has occurred: a legitimate IP Address change was made or the device has sent an ARP Reply Spoof. The ARP collector should search the database to see if there is another device holding the same IP Address. If there is another existing device with the IP address noted in the new ethernet/ip pair, the latest date/time stamp of the existing device should be checked to see when the last time the IP address was used. If it was very recent, this should be flagged as a warning and the ARP collector should watch for another change back to the original IP address. DHCP installations will usually hold the same IP address for the host for a certain amount of time and not hand it to another device. A “garbage collector” timer can be used to groom the database every n seconds to remove the old ARP Reply records that have not been active. This will help reduce false positives (e.g. situations where old data base entries indicate that IP address is assigned to particular device, where the IP address has in fact been more recently assigned to another device).
If this is a Spoofed ARP Reply, there should be another device in the ARP collector database with the same IP Address. This is most likely the host that the victim host was talking to originally. The latest date/time of the victim host should be fairly recent. This can be the first sign of a possible ARP Spoof attempt.
When the ARP Collector sees that an ethernet/ip pair has changed, it records this information along with the originally learned ethernet/ip pair for this source MAC address. The ARP collector also searches the database to see if there is another MAC address holding the same Source IP address. Where another MAC address is seen as holding the same source IP address, the latest date of the other device is compared to the newly learned ethernet/ip pair's originally learned date. If they are very close together, this adds evidence that a Spoofing attempt is likely taking place. If the date/time are far apart, this is most likely an IP address change.
Typically after an attacking host has engaged in an ARP Reply spoofing session, the Ethernet/IP pair for the attacking host, returns back to the original settings, and a third ethernet/ip pair will be noted for the same MAC address. The original date/time from the three packets are compared against the allowable time window. If it is shorter than the allowable time window, an ARP Spoof condition is assumed. When a flip-flop condition with the same MAC address but different IP Addresses it should also be flagged.
If this was a legitimate IP Address change, the ARP Collector will leave the records in the database and let the garbage collector routine groom the old records out after the garbage interval has been met. The garbage interval is a timer, shown in
As each record is recorded in the database, it is stamped with several date and time fields to allow the ARP Collector to make intelligent decisions on how to process multiple ethernet/ip pair conditions. The garbage collector timer 818 can include a settable time parameter that is added to each record as it is created or updated. The Garbage Timer allows the system to compare newly received ARP Replies with older existing records in the database.
As the newly received ARP Replies are compared to existing records, a decision is made based on the results of the Garbage Collector timer. If the newly received ARP Replies are within the Garbage Collector interval, then the logic moves down the path of a possible ARP Reply Spoof condition or a bad IP Change condition. This turns the “Flip-Flop” tag to a value of 1 to tag the beginning of the ARP Reply spoofing process.
If the newly received ARP Reply is outside the Garbage Collector interval, the existing record is stale and can be removed from the system. As a separate grooming function, a database scavenging routine can be added to remove all stale records from the database at preset intervals—such as low usage times.
If it is determined that the Ethernet/IP address is not new at 606, then a determination 610 is made as to whether the Ethernet/IP pair in the ARP reply has changed. If it is determined that the Ethernet/IP pair has not changed, then the previous entry for this Ethernet/IP pair is updated 612 to record this latest date and time information in the ARP collector database, and this latest time information can be utilized by the garbage collector timer. If the Ethernet/IP pair has changed then the new Ethernet/IP pair is recorded 614 in the ARP collector database, as well as date and time information for use by the garbage collector. Information in the ARP collector database is then analyzed 616 to determine if the Ethernet address has had more than three Ethernet/IP address pair changes within a flip-flop timer time period. If there have not been more than 3 changes within the time period, then the ARP collector database is searched 618 to determine if the IP address of the new Ethernet/IP pair is already in the database. If the IP address is not in the database, then a message can be sent 620 to a syslog to provide notification of the changed IP address.
If it is determined at 618 that the IP address of the new Ethernet/IP address pair was already in the ARP collector database, then the time information indicating the most recent entry for the IP address previously recorded in the database, is compared 622 with the time of receipt of the new Ethernet/IP address pair. If it is determined that the previous information of the IP address was stored more than a predetermined amount of time before receipt of the new Ethernet/IP address pair, then the old record is identified 624 as a possibly expired entry and can be considered for deletion. Conversely if the comparison, shows that the previous entry of the IP address was recorded or updated only a short time before receipt of the new Ethernet/IP pair, then the ARP collector can send 626 a warning of a possible ARP spoof of invalid IP address change.
If at 616 it is determined that there have been 3 or more changes in the Ethernet/IP address pair for a given host, then a determination 628 is made as to whether the recently received Ethernet/IP address pair changes the Ethernet/IP address pair back to the original pairing. If a determination is made that the address pair was not made back to the original Ethernet/IP address pair, then message indicating multiple IP address changes can be sent 630. In addition the procedures for responding to possible ARP spoofing conditions can include taking different ARP antispoofing procedures 634 including blocking ports on which possibly spoofed ARP replies are received, or MAC filtering certain hosts based on the MAC address. Additionally if it is determined that the recently received ARP reply flopped the Ethernet/IP address pair back to the original pairing then a notice of ARP spoofing activity can be sent 632, and ARP antispoofing procedures can be followed 634.
The processor 342 can also include an ARP security module which operates to receive ARP input from a system administrator computer 346 which can be coupled to a port 332 of the device 300. This input from the system administrator can operate to enable the operation of the ATP module 350 for ARP replies on selected ports of the network device 350. Additionally, the ARP security module 338 could operate to receive communications from the ARP collector 722, where such communications may instruct the network device to block certain ports, or to provide MAC addresses to filter, where certain MAC address are identified as attempting to transmit spoofed ARP replies through the device 300, based on ARP collector antispoofing procedures.
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example, and not limitation. It will be apparent to persons skilled in the relevant art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention. This is especially true in light of technology and terms within the relevant art(s) that may be later developed. Thus, the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4897874||Mar 31, 1988||Jan 30, 1990||American Telephone And Telegraph Company At&T Bell Laboratories||Metropolitan area network arrangement for serving virtual data networks|
|US5237614||Jun 7, 1991||Aug 17, 1993||Security Dynamics Technologies, Inc.||Integrated network security system|
|US5721780||May 31, 1995||Feb 24, 1998||Lucent Technologies, Inc.||User-transparent security method and apparatus for authenticating user terminal access to a network|
|US5757924||Sep 18, 1995||May 26, 1998||Digital Secured Networks Techolognies, Inc.||Network security device which performs MAC address translation without affecting the IP address|
|US5774551||Aug 7, 1995||Jun 30, 1998||Sun Microsystems, Inc.||Pluggable account management interface with unified login and logout and multiple user authentication services|
|US5825890||Jul 1, 1997||Oct 20, 1998||Netscape Communications Corporation||Secure socket layer application program apparatus and method|
|US5835720||May 17, 1996||Nov 10, 1998||Sun Microsystems, Inc.||IP discovery apparatus and method|
|US5892903||Sep 12, 1996||Apr 6, 1999||Internet Security Systems, Inc.||Method and apparatus for detecting and identifying security vulnerabilities in an open network computer communication system|
|US5894479||Dec 10, 1996||Apr 13, 1999||Intel Corporation||Providing address resolution information for self registration of clients on power-up or dial-in|
|US5946308||Oct 30, 1997||Aug 31, 1999||Cabletron Systems, Inc.||Method for establishing restricted broadcast groups in a switched network|
|US5958053||Aug 22, 1997||Sep 28, 1999||At&T Corp.||Communications protocol with improved security|
|US6009103||Dec 23, 1997||Dec 28, 1999||Mediaone Group, Inc.||Method and system for automatic allocation of resources in a network|
|US6021495||May 30, 1997||Feb 1, 2000||3Com Corporation||Method and apparatus for authentication process of a star or hub network connection ports by detecting interruption in link beat|
|US6167052||Apr 27, 1998||Dec 26, 2000||Vpnx.Com, Inc.||Establishing connectivity in networks|
|US6167445||Oct 26, 1998||Dec 26, 2000||Cisco Technology, Inc.||Method and apparatus for defining and implementing high-level quality of service policies in computer networks|
|US6212191||Jan 30, 1998||Apr 3, 2001||International Business Machines Corporation||Method and system for providing security to asynchronous transfer mode emulated local-area networks|
|US6219790||Jun 19, 1998||Apr 17, 2001||Lucent Technologies Inc.||Centralized authentication, authorization and accounting server with support for multiple transport protocols and multiple client types|
|US6256314||Aug 11, 1998||Jul 3, 2001||Avaya Technology Corp.||Apparatus and methods for routerless layer 3 forwarding in a network|
|US6338089||Mar 31, 1999||Jan 8, 2002||Bull Hn Information Systems Inc.||Method and system for providing session pools for high performance web browser and server communications|
|US6339830||Mar 15, 2000||Jan 15, 2002||Alcatel Internetworking, Inc.||Deterministic user authentication service for communication network|
|US6363489||Nov 29, 1999||Mar 26, 2002||Forescout Technologies Inc.||Method for automatic intrusion detection and deflection in a network|
|US6393484||Apr 12, 1999||May 21, 2002||International Business Machines Corp.||System and method for controlled access to shared-medium public and semi-public internet protocol (IP) networks|
|US6496502||Jun 29, 1998||Dec 17, 2002||Nortel Networks Limited||Distributed multi-link trunking method and apparatus|
|US6510236||Dec 11, 1998||Jan 21, 2003||International Business Machines Corporation||Authentication framework for managing authentication requests from multiple authentication devices|
|US6519646||Sep 1, 1998||Feb 11, 2003||Sun Microsystems, Inc.||Method and apparatus for encoding content characteristics|
|US6553028||Apr 30, 1999||Apr 22, 2003||Cisco Technology, Inc.||Method and apparatus for multicast switching using a centralized switching engine|
|US6615264||Apr 9, 1999||Sep 2, 2003||Sun Microsystems, Inc.||Method and apparatus for remotely administered authentication and access control|
|US6651168||Jan 29, 1999||Nov 18, 2003||International Business Machines, Corp.||Authentication framework for multiple authentication processes and mechanisms|
|US6728246||Feb 11, 2000||Apr 27, 2004||Advanced Micro Devices, Inc.||Arrangement for reducing layer 3 header data supplied to switching logic on a network switch|
|US6732270||Oct 23, 2000||May 4, 2004||Motorola, Inc.||Method to authenticate a network access server to an authentication server|
|US6751728||Jun 16, 1999||Jun 15, 2004||Microsoft Corporation||System and method of transmitting encrypted packets through a network access point|
|US6771649||Dec 6, 1999||Aug 3, 2004||At&T Corp.||Middle approach to asynchronous and backward-compatible detection and prevention of ARP cache poisoning|
|US6775290||May 24, 1999||Aug 10, 2004||Advanced Micro Devices, Inc.||Multiport network switch supporting multiple VLANs per port|
|US6789118||Feb 23, 2000||Sep 7, 2004||Alcatel||Multi-service network switch with policy based routing|
|US6807179||Apr 18, 2000||Oct 19, 2004||Advanced Micro Devices, Inc.||Trunking arrangement in a network switch|
|US6813347||Apr 10, 2001||Nov 2, 2004||Lucent Technologies Inc.||Selective call waiting|
|US6853988||Sep 20, 2000||Feb 8, 2005||Security First Corporation||Cryptographic server with provisions for interoperability between cryptographic systems|
|US6874090||Jun 21, 2001||Mar 29, 2005||Alcatel||Deterministic user authentication service for communication network|
|US6892309||Feb 8, 2002||May 10, 2005||Enterasys Networks, Inc.||Controlling usage of network resources by a user at the user's entry point to a communications network based on an identity of the user|
|US6907470||Jun 28, 2001||Jun 14, 2005||Hitachi, Ltd.||Communication apparatus for routing or discarding a packet sent from a user terminal|
|US6912592||Jan 5, 2001||Jun 28, 2005||Extreme Networks, Inc.||Method and system of aggregate multiple VLANs in a metropolitan area network|
|US6950628||Aug 2, 2002||Sep 27, 2005||Cisco Technology, Inc.||Method for grouping 802.11 stations into authorized service sets to differentiate network access and services|
|US6959336||Apr 7, 2001||Oct 25, 2005||Secure Data In Motion, Inc.||Method and system of federated authentication service for interacting between agent and client and communicating with other components of the system to choose an appropriate mechanism for the subject from among the plurality of authentication mechanisms wherein the subject is selected from humans, client applications and applets|
|US6980515||Feb 23, 2000||Dec 27, 2005||Alcatel||Multi-service network switch with quality of access|
|US6981054||Jul 18, 2000||Dec 27, 2005||Advanced Micro Devices, Inc.||Flow control arrangement in a network switch based on priority traffic|
|US7028098||Jul 20, 2001||Apr 11, 2006||Nokia, Inc.||Selective routing of data flows using a TCAM|
|US7062566||Oct 24, 2002||Jun 13, 2006||3Com Corporation||System and method for using virtual local area network tags with a virtual private network|
|US7079537||Apr 25, 2000||Jul 18, 2006||Advanced Micro Devices, Inc.||Layer 3 switching logic architecture in an integrated network switch|
|US7088689||Dec 21, 2001||Aug 8, 2006||Lg Electronics Inc.||VLAN data switching method using ARP packet|
|US7093280||Sep 27, 2001||Aug 15, 2006||Juniper Networks, Inc.||Internet security system|
|US7113479||May 31, 2002||Sep 26, 2006||Broadcom Corporation||Aggregated rate control method and system|
|US7134012||Aug 15, 2001||Nov 7, 2006||International Business Machines Corporation||Methods, systems and computer program products for detecting a spoofed source address in IP datagrams|
|US7188364||Jan 25, 2002||Mar 6, 2007||Cranite Systems, Inc.||Personal virtual bridged local area networks|
|US7194554||Oct 20, 2000||Mar 20, 2007||Nomadix, Inc.||Systems and methods for providing dynamic network authorization authentication and accounting|
|US7234163 *||Sep 16, 2002||Jun 19, 2007||Cisco Technology, Inc.||Method and apparatus for preventing spoofing of network addresses|
|US7249374||Jan 22, 2001||Jul 24, 2007||Cisco Technology, Inc.||Method and apparatus for selectively enforcing network security policies using group identifiers|
|US7360086||Dec 6, 1999||Apr 15, 2008||Hitachi, Ltd.||Communications control method and information relaying device for communications network system|
|US7360245||Jul 18, 2001||Apr 15, 2008||Novell, Inc.||Method and system for filtering spoofed packets in a network|
|US7483971||Mar 28, 2002||Jan 27, 2009||Intel Corporation||Method and apparatus for managing communicatively coupled components using a virtual local area network (VLAN) reserved for management instructions|
|US7516487||May 20, 2004||Apr 7, 2009||Foundry Networks, Inc.||System and method for source IP anti-spoofing security|
|US7523485||Jul 31, 2003||Apr 21, 2009||Foundry Networks, Inc.||System and method for source IP anti-spoofing security|
|US7529933||May 30, 2002||May 5, 2009||Microsoft Corporation||TLS tunneling|
|US7536464||Sep 25, 2003||May 19, 2009||Cisco Technology, Inc.||Methods and apparatus for performing layer 2 authentication and service selection in SSG based networks|
|US7562390 *||Jul 31, 2003||Jul 14, 2009||Foundry Networks, Inc.||System and method for ARP anti-spoofing security|
|US7567510||Feb 13, 2003||Jul 28, 2009||Cisco Technology, Inc.||Security groups|
|US7596693 *||Oct 31, 2006||Sep 29, 2009||Occam Networks||Controlling ARP packet traffic to enhance network security and scalability in TCP/IP networks|
|US7774833||Sep 23, 2003||Aug 10, 2010||Foundry Networks, Inc.||System and method for protecting CPU against remote access attacks|
|US20010012296||Jan 17, 2001||Aug 9, 2001||Burgess Jon J.||Multi-port network communication device with selective mac address filtering|
|US20020016858||Jun 28, 2001||Feb 7, 2002||Sunao Sawada||Communication apparatus for routing or discarding a packet sent from a user terminal|
|US20020055980||Aug 15, 2001||May 9, 2002||Steve Goddard||Controlled server loading|
|US20020065938||May 15, 2001||May 30, 2002||Jungck Peder J.||Edge adapter architecture apparatus and method|
|US20020133534||Jan 8, 2001||Sep 19, 2002||Jan Forslow||Extranet workgroup formation across multiple mobile virtual private networks|
|US20020146002||Jul 24, 2001||Oct 10, 2002||Takayuki Sato||Network administration apparatus, network administrating program, network administrating method and computer network system|
|US20020146107||Apr 10, 2001||Oct 10, 2002||Baals Kimberly A.||Selective call waiting|
|US20030028808||Jul 16, 2002||Feb 6, 2003||Nec Corporation||Network system, authentication method and computer program product for authentication|
|US20030037163||Mar 8, 2002||Feb 20, 2003||Atsushi Kitada||Method and system for enabling layer 2 transmission of IP data frame between user terminal and service provider|
|US20030043763||Jul 29, 1998||Mar 6, 2003||Paul D Grayson||Wireless networked message routing|
|US20030051041||Aug 6, 2002||Mar 13, 2003||Tatara Systems, Inc.||Method and apparatus for integrating billing and authentication functions in local area and wide area wireless data networks|
|US20030056001||Jul 20, 2001||Mar 20, 2003||Ashutosh Mate||Selective routing of data flows using a TCAM|
|US20030056063||Sep 17, 2001||Mar 20, 2003||Hochmuth Roland M.||System and method for providing secure access to network logical storage partitions|
|US20030065944||Sep 28, 2001||Apr 3, 2003||Mao Yu Ming||Method and apparatus for implementing a layer 3/layer 7 firewall in an L2 device|
|US20030067874||Apr 22, 2002||Apr 10, 2003||See Michael B.||Central policy based traffic management|
|US20030105881||Dec 3, 2001||Jun 5, 2003||Symons Julie Anna||Method for detecting and preventing intrusion in a virtually-wired switching fabric|
|US20030142680||Dec 30, 2002||Jul 31, 2003||Naoki Oguchi||Device, network, and system for forwarding frames between geographically dispersed user networks|
|US20030188003||Mar 28, 2002||Oct 2, 2003||Mikael Sylvest||Method and apparatus for the provision of unified systems and network management of aggregates of separate systems|
|US20030217151||Feb 28, 2003||Nov 20, 2003||Roese John J.||Location based data|
|US20030226017||May 30, 2002||Dec 4, 2003||Microsoft Corporation||TLS tunneling|
|US20030236898||May 22, 2003||Dec 25, 2003||Chunzhe Hu||Method based on border gateway protocol message for controlling messages security protection|
|US20040003285||Jun 28, 2002||Jan 1, 2004||Robert Whelan||System and method for detecting unauthorized wireless access points|
|US20040053601||Sep 9, 2003||Mar 18, 2004||Frank Ed H.||Method and system for providing multiple encryption in a multi-band multi-protocol hybrid wired/wireless network|
|US20040078485||Oct 18, 2002||Apr 22, 2004||Nokia Corporation||Method and apparatus for providing automatic ingress filtering|
|US20040160903||Feb 13, 2003||Aug 19, 2004||Andiamo Systems, Inc.||Security groups for VLANs|
|US20040210663||Apr 15, 2003||Oct 21, 2004||Paul Phillips||Object-aware transport-layer network processing engine|
|US20040213172||Apr 24, 2003||Oct 28, 2004||Myers Robert L.||Anti-spoofing system and method|
|US20040213260||Apr 28, 2003||Oct 28, 2004||Cisco Technology, Inc.||Methods and apparatus for securing proxy Mobile IP|
|US20040255154||Jun 11, 2003||Dec 16, 2004||Foundry Networks, Inc.||Multiple tiered network security system, method and apparatus|
|US20050025125||Aug 1, 2003||Feb 3, 2005||Foundry Networks, Inc.||System, method and apparatus for providing multiple access modes in a data communications network|
|US20050055570||Sep 4, 2003||Mar 10, 2005||Foundry Networks, Inc.||Multiple tiered network security system, method and apparatus using dynamic user policy assignment|
|US20050091313||Aug 28, 2002||Apr 28, 2005||Peng Zhou||System and implementation method of controlled multicast|
|US20050185626||Apr 15, 2005||Aug 25, 2005||Meier Robert C.||Method for grouping 802.11 stations into authorized service sets to differentiate network access and services|
|US20050254474||Jun 29, 2005||Nov 17, 2005||Iyer Pradeep J||System and method for monitoring and enforcing policy within a wireless network|
|US20060028996||Aug 9, 2004||Feb 9, 2006||Huegen Craig A||Arrangement for tracking IP address usage based on authenticated link identifier|
|US20060155853||Nov 6, 2002||Jul 13, 2006||Peter Nesz||Method and arrangement for preventing illegitimate use of ip addresses|
|US20070220596||Nov 3, 2006||Sep 20, 2007||Keeler James D||Authorization and authentication of user access to a distributed network communication system with roaming feature|
|US20090254973||Feb 25, 2009||Oct 8, 2009||Foundry Networks, Inc.||System and method for source ip anti-spoofing security|
|US20090260083||Feb 25, 2009||Oct 15, 2009||Foundry Networks, Inc.||System and method for source ip anti-spoofing security|
|US20090265785||Jun 4, 2009||Oct 22, 2009||Foundry Networks, Inc.||System and method for arp anti-spoofing security|
|1||"[IP-spoofing Demystified] (Trust-Relationship Exploitation)," at URL: http://www.networkcommand.com/docs/ipspoof.txt, Jun. 1996, 9 pages, printed on May 18, 2003.|
|2||"Authenticated VLANs: Secure Network Access at Layer 2," An Alcatel White Paper, Nov. 2002, pp. 1-14, Alcatel Internetworking, Inc.|
|3||"Automatic Spoof Detector (aka Spoofwatch)," Jan. 28, 2002, at URL: http://www.anml.iu.edu/PDF/Automatic-Spoof-Detector.pdf, printed on Jul. 23, 2003, 2 pages.|
|4||"Automatic Spoof Detector (aka Spoofwatch)," Jan. 28, 2002, at URL: http://www.anml.iu.edu/PDF/Automatic—Spoof—Detector.pdf, printed on Jul. 23, 2003, 2 pages.|
|5||"CERTŪ Incident Note IN-2000-04 (Denial of Service Attacks using Nameservers)," Jan. 2001, at URL: http://www.cert.org/incident-notes/IN-2000-04.html, printed on Jul. 23, 2003, 3 pages.|
|6||"CERTŪ Incident Note IN-2000-04 (Denial of Service Attacks using Nameservers)," Jan. 2001, at URL: http://www.cert.org/incident—notes/IN-2000-04.html, printed on Jul. 23, 2003, 3 pages.|
|7||"Cisco Catalyst 1900 Series Switches," at URL: http://www.cisco.com/en/US/products/hw/switches/ps574/products-configuration-guide-chapter09186a008007ef90.html#xtocid3, printed on Jul. 29, 2003, 13 pages (PDF & web pages).|
|8||"Cisco Catalyst 1900 Series Switches," at URL: http://www.cisco.com/en/US/products/hw/switches/ps574/products—configuration—guide—chapter09186a008007ef90.html#xtocid3, printed on Jul. 29, 2003, 13 pages (PDF & web pages).|
|9||"Cisco IOS Software Releases 12.2 T," at URL: http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products-feature-guide09186a00801543c8.html#1027177, printed on Jul. 29, 2003, 26 pages (PDF & web pages).|
|10||"Cisco IOS Software Releases 12.2 T," at URL: http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products—feature—guide09186a00801543c8.html#1027177, printed on Jul. 29, 2003, 26 pages (PDF & web pages).|
|11||"Cisco-Cable Source -Verify and IP Address Security," at URL: http://www.cisco.com/en/US/tech/tk86/tk803/technologies-tech-note09186a00800a7828.shtml (PDF & web pages), printed on Jul. 23, 2003, 25 pages.|
|12||"Cisco—Cable Source —Verify and IP Address Security," at URL: http://www.cisco.com/en/US/tech/tk86/tk803/technologies—tech—note09186a00800a7828.shtml (PDF & web pages), printed on Jul. 23, 2003, 25 pages.|
|13||"Configuring 802.1X Port-Based Authentication," Catalyst 3550 Multilayer Switch Software Configuration Guide, Cisco IOS Release 12.1 (13) EA1, Mar. 2003, pp. 1-18, Ch. 9, Cisco Systems, Inc.|
|14||"Configuring Network Security with ACLs," Catalyst 3550 Multilayer Switch Software Configuration Guide, Cisco IOS Release 12.1 (13) EA1, Mar. 2003, pp. 1-48, Ch. 27, Cisco Systems, Inc.|
|15||"Configuring Port-Based Traffic Control," Catalyst 3550 Multilayer Switch Software Configuration Guide, Cisco IOS Release 12.1 (13) EA1, Mar. 2003, pp. 1-14, Ch. 20, Cisco Systems, Inc.|
|16||"IEEE Standard for Local and Metropolitan Area Networks-Port-Based Network Access Control" IEEE Std 802.1X-2001, Jul. 13, 2001, pp. i-viii and 1-134, IEEE, The Institute of Electrical and Electronics Engineers, Inc.|
|17||"IEEE Standard for Local and Metropolitan Area Networks—Port-Based Network Access Control" IEEE Std 802.1X-2001, Jul. 13, 2001, pp. i-viii and 1-134, IEEE, The Institute of Electrical and Electronics Engineers, Inc.|
|18||"IP Addressing Services," at URL: http://www.cisco.com/en/US/tech/tk648/tk361/technologies-tech-note09186a0080094adb.shtml, 10 pages, printed on Jul. 29, 2003, (PDF & web pages).|
|19||"IP Addressing Services," at URL: http://www.cisco.com/en/US/tech/tk648/tk361/technologies—tech—note09186a0080094adb.shtml, 10 pages, printed on Jul. 29, 2003, (PDF & web pages).|
|20||"Keen Veracity Legions of the Underground," at URL: http://www.legions.org/kv/kv7.txt, pp. 1-41, Issue 7, printed on Jun. 24, 2003.|
|21||"Recommendations for IEEE 802.11 Access Points," at URL: http://www.microsoft.com/whdc/device/network/802x/AccessPts.mspx, Apr. 2, 2002, pp. 1-16, Microsoft, printed on Mar. 8, 2007.|
|22||"Tech Brief Extreme Ware 6.2," at URL: http://www.extremenetworks.com/libraries/prodpdfs/products/ex-ware-tech-brief.pdf, 8 pages, printed on Jul. 29, 2003, (Extreme Networks PDF).|
|23||"Tech Brief Extreme Ware 6.2," at URL: http://www.extremenetworks.com/libraries/prodpdfs/products/ex—ware—tech—brief.pdf, 8 pages, printed on Jul. 29, 2003, (Extreme Networks PDF).|
|24||"Unified Access Architecture for Wired and Wireless Networks," at URL: http://www.extremenetworks.com/libraries/prodpdfs/products/UnifiedWireless.asp, 10 pages, printed on Jul. 29, 2003.|
|25||Bass, S., "Spoofed IP Address Distributed Denial of Service Attacks: Defense-in-Depth," at URL: http://www.sans.org/rr/papers/60/469.phf, Aug. 13, 2001, 7 pages, version 2.0, printed on Jul. 23, 2003.|
|26||Cisco Systems, "Virtual LAN Security Best Practices," copyright 1992-2002, pp. 1-13, Cisco Systems, Inc.|
|27||Congdon, P. et al., "IEEE 802.1X Remote Authentication Dial in User Service (RADIUS) Usage Guidelines," The Internet Society, 2003, at URL: http://www.faqs.org/ftp/rfc/pdf/rfc3580.txt.pdf, 30 pages.|
|28||Final Office Action for U.S. Appl. No. 10/458,628, Mailed Feb. 26, 2009, 26 pages.|
|29||Final Office Action for U.S. Appl. No. 10/458,628, Mailed Jun. 1, 2007, 19 pages.|
|30||Final Office Action for U.S. Appl. No. 10/458,628, mailed on Mar. 24, 2010, 29 pages.|
|31||Final Office Action for U.S. Appl. No. 10/631,091, Mailed May 28, 2008, 13 pages.|
|32||Final Office Action for U.S. Appl. No. 10/631,366, Mailed Oct. 10, 2007, 17 pages.|
|33||Final Office Action for U.S. Appl. No. 10/631,898, mailed on Dec. 18, 2009, 17 pages.|
|34||Final Office Action for U.S. Appl. No. 10/654,417, Mailed Feb. 27, 2009, 17 pages.|
|35||Final Office Action for U.S. Appl. No. 10/654,417, Mailed Jun. 18, 2007, 15 pages.|
|36||Final Office Action for U.S. Appl. No. 10/654,417, mailed on Mar. 24, 2010, 28 pages.|
|37||Final Office Action for U.S. Appl. No. 10/850,505 Mailed Jun. 12, 2008, 12 pages.|
|38||Final Office Action for U.S. Appl. No. 12/392,398, mailed on Jan. 20, 2011, 11 pages.|
|39||Gill, "Catalyst Secure Template," Nov. 14, 2002, version 1.21, printed on Nov. 29, 2010, at URL: http://www.cymru.com/gillsr/documents/catalyst-secure-template.htm, pp. 1-19.|
|40||Glenn, M., "A Summary of DoS/DDoS Prevention, Monitoring and Mitigation Techniques in a Service Provider Enviroment." SANS Institute, Aug. 21, 2003, 34 pages.|
|41||Haviland, G. "Designing High Preformance Campus Intranets with Multilayer Switching." 1998, pp. 1-33, Cisco Systems, Inc.|
|42||Non Final Office Action for U.S. Appl. No. 10/631,091, Mailed Jan. 12, 2007, 9 pages.|
|43||Non Final Office Action for U.S. Appl. No. 10/631,091, Mailed Jul. 24, 2007, 8 pages.|
|44||Non Final Office Action for U.S. Appl. No. 10/631,091, Mailed Oct. 28, 2008, 15 pages.|
|45||Non Final Office Action for U.S. Appl. No. 10/631,366, Mailed Feb. 2, 2007, 14 pages.|
|46||Non Final Office Action for U.S. Appl. No. 10/631,366, Mailed Jul. 17, 2008, 12 pages.|
|47||Non Final Office Action for U.S. Appl. No. 10/668,455, Mailed Mar. 20, 2009, 25 pages.|
|48||Non Final Office Action for U.S. Appl. No. 10/850,505 Mailed Dec. 7, 2007, 14 pages.|
|49||Non-Final Office Action for U.S. Appl. No. 10/458,628, Mailed Aug. 15, 2008, 20 pages.|
|50||Non-Final Office Action for U.S. Appl. No. 10/458,628, Mailed Dec. 8, 2006, 14 pages.|
|51||Non-Final Office Action for U.S. Appl. No. 10/458,628, Mailed Nov. 30, 2007, 19 pages.|
|52||Non-Final Office Action for U.S. Appl. No. 10/458,628, mailed on Apr. 28, 2011, 23 pages.|
|53||Non-Final Office Action for U.S. Appl. No. 10/458,628, mailed on Oct. 8, 2009, 23 pages.|
|54||Non-Final Office Action for U.S. Appl. No. 10/631,898, Mailed Apr. 28, 2009, 17 pages.|
|55||Non-Final Office Action for U.S. Appl. No. 10/631,898, Mailed Feb. 20, 2008, 13 pages.|
|56||Non-Final Office Action for U.S. Appl. No. 10/631,898, Mailed Jul. 24, 2007, 11 pages.|
|57||Non-Final Office Action for U.S. Appl. No. 10/631,898, mailed on Feb. 18, 2010, 24 pages.|
|58||Non-Final Office Action for U.S. Appl. No. 10/631,898, Mailed Sep. 4, 2008, 14 pages.|
|59||Non-Final Office Action for U.S. Appl. No. 10/654,417, Mailed Dec. 15, 2006, 11 pages.|
|60||Non-Final Office Action for U.S. Appl. No. 10/654,417, Mailed Dec. 31, 2007, 19 pages.|
|61||Non-Final Office Action for U.S. Appl. No. 10/654,417, Mailed Jul. 29, 2008, 19 pages.|
|62||Non-Final Office Action for U.S. Appl. No. 10/654,417, mailed on Sep. 4, 2009, 20 pages.|
|63||Non-Final Office Action for U.S. Appl. No. 12/392,398, mailed on Sep. 1, 2010, 22 pages.|
|64||Non-Final Office Action for U.S. Appl. No. 12/478,229, mailed on Jan. 21, 2011, 15 pages.|
|65||Notice of Allowance for U.S. Appl. 10/631,366, Mailed Jan. 13, 2009, 10 pages.|
|66||Notice of Allowance for U.S. Appl. No. 10/631,091 Mailed Apr. 24, 2009, 9 pages.|
|67||Notice of Allowance for U.S. Appl. No. 10/654,417, mailed on Apr. 22, 2010, 14 pages.|
|68||Notice of Allowance for U.S. Appl. No. 10/668,455, mailed on Jun. 1, 2010, 8 pages.|
|69||Notice of Allowance for U.S. Appl. No. 10/850,505, Mailed Jan. 14, 2009, 10 pages.|
|70||Notice of Allowance for U.S. Appl. No. 10/850,505, Mailed Sep. 4, 2008, 6 pages.|
|71||Notice of Allowance for U.S. Appl. No. 12/392,398, mailed on Apr. 29, 2011, 12 pages.|
|72||Office Action for U.S. Appl. No. 10/925,155, mailed Mar. 20, 2008.|
|73||Office Action for U.S. Appl. No. 10/925,155, mailed on Apr. 14, 2009.|
|74||Office Action for U.S. Appl. No. 10/925,155, mailed on Jan. 11, 2010.|
|75||Office Action for U.S. Appl. No. 10/925,155, mailed on Oct. 27, 2008.|
|76||Pfleeger, "Security in Computing," 2nd edition, 1996, pp. 426-434, Prentice Hall PTR, NJ.|
|77||Requirement for Restriction/Election for U.S. Appl. No. 12/392,422, mailed on Apr. 14, 2011, 5 pages.|
|78||Schmid, S. et al., "An Access Control Architecture for Microcellular Wireless IPv6 Networks," LCN 2001: proceedings : 26th Annual IEEE Conference on Local Computer Networks : Nov. 14-16, 2001, pp. 454-463, Tampa, Florida, USA, 2001, IEEE Computer Society, Los Alamitos, US.|
|79||Sharma, K., "IP Spoofing," at URL: http://www.linuxgazette.com/issue63/sharma.html, 2001, 3 pages, printed on Jul. 23, 2003.|
|80||U.S. Appl. No. 10/631,091, filed Jul. 31, 2003, Kwan.|
|81||U.S. Appl. No. 10/668,455, filed Sep. 23, 2003, Szeto et al.|
|82||U.S. Appl. No. 10/925,155, filed Aug. 24, 2004, Kwan.|
|83||U.S. Appl. No. 12/392,398, filed Feb. 25, 2009, Kwan.|
|84||U.S. Appl. No. 12/392,422, filed Feb. 25, 2009, Szeto et al..|
|85||Welcher, "Switching MultiLayer Switching," Chesapeake Netcraftsmen, Copyright 1999, pp. 1-7, available at URL: http//www.netcraftsmen.net/welcher/papers/switchhmls.html.|
|86||Wright, "Using Policies for Effective Network Management," International Journal of Network Management, Copyright 1999, pp. 118-125, John Wiley & Sons, Ltd.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8239929||Apr 28, 2010||Aug 7, 2012||Foundry Networks, Llc||Multiple tiered network security system, method and apparatus using dynamic user policy assignment|
|US8245300||Jun 4, 2009||Aug 14, 2012||Foundry Networks Llc||System and method for ARP anti-spoofing security|
|US8249096||Aug 26, 2010||Aug 21, 2012||Foundry Networks, Llc||System, method and apparatus for providing multiple access modes in a data communications network|
|US8528071||Aug 24, 2004||Sep 3, 2013||Foundry Networks, Llc||System and method for flexible authentication in a data communications network|
|US8533823||Feb 25, 2009||Sep 10, 2013||Foundry Networks, Llc||System and method for source IP anti-spoofing security|
|US8681800||May 1, 2012||Mar 25, 2014||Foundry Networks, Llc||System, method and apparatus for providing multiple access modes in a data communications network|
|US8893256||Jun 30, 2010||Nov 18, 2014||Brocade Communications Systems, Inc.||System and method for protecting CPU against remote access attacks|
|US8918875||Jul 18, 2011||Dec 23, 2014||Foundry Networks, Llc||System and method for ARP anti-spoofing security|
|US20040255154 *||Jun 11, 2003||Dec 16, 2004||Foundry Networks, Inc.||Multiple tiered network security system, method and apparatus|
|US20080250498 *||Sep 21, 2005||Oct 9, 2008||France Telecom||Method, Device a Program for Detecting an Unauthorised Connection to Access Points|
|US20090260083 *||Feb 25, 2009||Oct 15, 2009||Foundry Networks, Inc.||System and method for source ip anti-spoofing security|
|US20090265785 *||Jun 4, 2009||Oct 22, 2009||Foundry Networks, Inc.||System and method for arp anti-spoofing security|
|US20100333191 *||Jun 30, 2010||Dec 30, 2010||Foundry Networks, Inc.||System and method for protecting cpu against remote access attacks|
|Cooperative Classification||H04L61/103, H04L63/0236, H04L63/1466, H04L63/1408, H04L63/101|
|European Classification||H04L63/14D4, H04L63/14A, H04L63/02B1|
|Jan 20, 2010||AS||Assignment|
Owner name: WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATE
Free format text: SECURITY AGREEMENT;ASSIGNORS:BROCADE COMMUNICATIONS SYSTEMS, INC.;FOUNDRY NETWORKS, LLC;INRANGE TECHNOLOGIES CORPORATION;AND OTHERS;REEL/FRAME:023814/0587
Effective date: 20100120
|Jul 21, 2010||AS||Assignment|
Owner name: FOUNDRY NETWORKS, LLC, CALIFORNIA
Free format text: CHANGE OF NAME;ASSIGNOR:FOUNDRY NETWORKS, INC.;REEL/FRAME:024733/0739
Effective date: 20090511
|Sep 20, 2011||AS||Assignment|
Owner name: BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT, CA
Free format text: SUPPLEMENTAL PATENT SECURITY AGREEMENT;ASSIGNORS:BROCADE COMMUNICATIONS SYSTEMS, INC.;FOUNDRY NETWORKS, LLC;MCDATA CORPORATION;REEL/FRAME:026938/0922
Effective date: 20110916
|Sep 26, 2011||AS||Assignment|
Owner name: WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATE
Free format text: SUPPLEMENTAL PATENT SECURITY AGREEMENT;ASSIGNORS:BROCADE COMMUNICATIONS SYSTEMS, INC.;FOUNDRY NETWORKS, LLC;INRANGE TECHNOLOGIES CORPORATION;AND OTHERS;REEL/FRAME:026971/0042
Effective date: 20110916
|Jan 21, 2015||AS||Assignment|
Owner name: BROCADE COMMUNICATIONS SYSTEMS, INC., CALIFORNIA
Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:034784/0609
Effective date: 20150114
Owner name: FOUNDRY NETWORKS, LLC, CALIFORNIA
Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:034784/0609
Effective date: 20150114
|Jan 22, 2015||AS||Assignment|
Owner name: BROCADE COMMUNICATIONS SYSTEMS, INC., CALIFORNIA
Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATERAL AGENT;REEL/FRAME:034804/0793
Effective date: 20150114
Owner name: FOUNDRY NETWORKS, LLC, CALIFORNIA
Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATERAL AGENT;REEL/FRAME:034804/0793
Effective date: 20150114
|Apr 3, 2015||REMI||Maintenance fee reminder mailed|
|Aug 4, 2015||SULP||Surcharge for late payment|
|Aug 4, 2015||FPAY||Fee payment|
Year of fee payment: 4