1. Field of the Invention
This application relates to the field of networks, and more particularly to the field of data network traffic management.
2. Description of Related Art
Data networks may employ a number of routers to interconnect network terminals such as client devices, gateways to local area networks (“LAN's”), network resources, and the like. In data networks such as the Internet, routers are generally configured to exchange information with one another and to determine, on the basis of this messaging, routing tables for efficient routing between terminals.
One technique for developing routing tables is known as link state routing, in which each router transmits routing updates describing other routers and networks to which the router is connected. A commonly used standard for link state routing is the Open Shortest Path First (“OSPF”) standard.
As a significant disadvantage, networks such as those using OSPF and similar link state routing algorithms/standards are generally vulnerable to spurious network packets, which are packets that include incorrect source addresses. Spurious network packets may result from transmission errors or intentional tampering. An error in source address information may result in inappropriate acknowledgements, or superfluous retransmission of data, both of which place additional demands on network resources. If the tampering is intentional and malicious, more serious security breaches may result, since an interloper may falsify the identity of another by systematically forging source address information.
There remains a need for a system to protect networks from spurious network packets.
According to the principles of the invention, there is provided a system for detecting spurious network traffic. In a system according to the principles of the invention, a switch such as a router constructs a routing tree for each switch connected thereto. When a network packet is received, the switch inspects the source address of the packet, and determines whether the forwarding switch or network interface could be expected to deliver a network packet from the indicated address. If it appears from this analysis that the network packet should not have come from the forwarding switch, then certain measures may be taken to address the situation. For example, the network packet may be dropped, an alarm may be generated to the forwarding switch, or an alarm may be generated to an automated or human network supervisor.
A method for detecting spurious network traffic according to the principles of the invention includes receiving a packet, the packet including data for transmission over a network. The method further includes determining an expected port for the packet, the expected port being a port upon which the packet is expected to be received. The method further includes determining an actual port for the packet, the actual port being the port upon which the packet is actually received. And, the method may include providing spurious packet handling when the actual port does not correspond to the expected port.
A switch for use in an internetwork according to the principles of the invention includes a plurality of ports, each port connected in a communicating relationship with at least one of a connected switch and a network and a routing database, the routing database containing information relating to the internetwork. The switch may include a processor, the processor configured to compare a first port to a second port, the first port being a one of the plurality of ports through which a packet is received and the second port being a one of the plurality of ports through which the packet is expected to be received, the processor further configured to provide spurious packet handling when the first port is different from the second port.
An internetwork according to the principles of the invention includes a plurality of switches such as the switch described above, whereby spurious network traffic within the internetwork may be detected.
The foregoing and other objects and advantages of the invention will be appreciated more fully from the following further description thereof, with reference to the accompanying drawings, wherein:
To provide an overall understanding of the invention, certain illustrative embodiments will now be described, including a system for detecting spurious network traffic on the Internet. However, it will be understood by those of ordinary skill in the art that the methods and systems described herein can be suitably adapted to any network that uses a link state routing protocol such as OSPF, or more generally to any network in which routing information or network topology information is generally available to nodes within the network. The principles of the invention are particularly applicable to those environments where forged network traffic may pose security or network resource problems.
A network 20 may be any computer, collection of computers, or collection of computer networks that may be reached through a switch 10 connected thereto. One of the networks 20 may include one or more computers or other network devices that can operate as a source and/or destination of network packets, including, for example, a computer, a notebook or laptop computer, a workstation, an Internet appliance, a wireless access device, a kiosk, or any other device configured to send and/or receive Internet Protocol datagrams.
A network 20 may further include, for example, a gateway, a local area network (“LAN”), a wide-area network (“WAN”), or a virtual private network (“VPN”). A network 20 may be connected by, for example RS-232 connections, one or more Ethernet connections, or ATM networks. In an embodiment, each network 20 may be advertised by the connected switch 10, so that any traffic intended for computers or networks within the network 20 will be routed to the appropriate switch 10.
The switches 10 of
When the switch 100 receives a network packet on one of the ports 104, the processor 106 on the switch 100 examines the destination address, and determines a suitable output port 104 such that the network packet will be forwarded to the destination address. As used below, the term “network packet” is intended to refer to packets carrying data between terminals in the internetwork 5, as distinguished from “routing packets” carrying descriptive network information between switches 20, such as the packets of
When the switch 100 receives a routing packet, the switch may store the routing packet, and may forward the routing packet to other switches 10 within the internetwork 5. The switch 100 may also generate its own routing packets that are transmitted to other switches 10 in the internetwork 5. These routing packets may be used to calculate routing trees that describe how network packets should be transmitted through the internetwork 5.
In a link state routing system, each of the switches 10 in the internetwork 5 may collect information contained in link state update packets 220 and in routing update packets 200, and generate a routing tree that may be used to make routing decisions. The routing tree may be used to determine which switch 10 should receive a network packet in order for the network packet to reach an address within a particular network 20. The routing tree may also be used to choose an optimal path for reaching a switch 10 within the internetwork 5. According to the principles of the invention, a switch 10 may calculate routing trees for every switch 10 within the internetwork 5, and store each of these routing trees in the routing database 110.
In one part of the process, routing trees are calculated and stored. In step 302, link state information is received. The link state information may be, for example, the routing update packet 200 of
If the sequence number is valid, then the process may proceed to step 306 where the received link state information is stored in the routing database 301. The received link state information then becomes the current link state information for the switch 10 in the internetwork 5 that generated the link state information.
In step 308, a routing tree is calculated using the link state information received in step 302. The routing tree may be calculated using any algorithm suitable for routing tree generation. For example, Dijkstra's algorithm may be run locally to construct the shortest possible path to all possible destinations from the switch 100. According to the principles of the invention, the switch 100 further generates routing trees from every other switch 10 within the internetwork 5. Other methods for constructing shortest paths are known and may be usefully practiced with the invention. As will be further appreciated by those skilled in the art, other protocols using different link state information may be adapted to use with the invention. For example, the Intermediate System-Intermediate System protocol may be used, and may be supplemented with hierarchical routing.
In step 308, the routing trees may optionally be used to calculate a reverse look-up table. In this table, each possible source network address within the internetwork 5 would be associated with a specific port of the switch 100, so that subsequent processing, as in step 316–318 below, may be performed using a table look up.
In step 310, any routing trees generated in step 308 are stored in the routing database 301, and the process may return to step 302 where new link state information may be received. Once link state information has been received from each switch 10 within the internetwork 5, a routing tree corresponding to each switch 10 may be calculated, and the routing database 301 may contain a complete view of the internetwork 5 including the networks 20 connected thereto. These routing trees may then be applied to network packets received at the switch 100 according to the principles of the invention. It will be appreciated that variations are possible. For example, in order to conserve resources, the switch 100 may only calculate routing trees for those switches 10 directly connected to the switch 100.
In step 312, a network packet is received at the switch 100. The network packet may be any packet or datagram carrying data for transportation on the internetwork 5, and the network packet is received on a particular port of the switch 100, referred to here as the “actual port”, the actual port being connected to a corresponding port of another switch 10 within the internetwork 5, or to one of the networks 20 connected to the switch 100. The network packet may include a source network address and a destination network address. In step 314, the network packet is examined to determine the source network address.
In step 316, an expected switch source, or expected port, is determined using the routing trees stored in the routing database 301. More particularly, a routing tree for the switch 10 connected to the network 20 identified by the source network address is retrieved. Referring to
It will be appreciated that different approaches may be used to determine an expected switch source, and that in complex networks, there may be more than one expected switch source. Accordingly, the switch 100 may be configured to provide a set of expected switch sources for a given source network address. Optionally, the routing tables may be used to assign a probability or weight to each possible port within the set of expected switch sources.
In step 318, the expected switch source, or the expected port, is compared to the actual switch source, or the actual port, for the network packet. If the actual switch source is the same as the expected switch source, or one of the set of possible or likely switch sources, then the packet is forwarded according to the destination network address of the network packet, using the routing tree for the switch 100, as stored in the routing database 301. The process may then return to step 312 where a new network packet is received. If the actual switch source is not the same as the expected switch source, or is not one of the set of possible or likely switch sources, then the process may proceed to step 320 for spurious packet handling.
In step 320, the network packet is treated as a spurious network packet, and various handling options may be provided. The spurious network packet may be discarded. A record of the spurious network packet may optionally be stored in a spurious traffic log. An alert may optionally be generated to a monitoring center to inform the monitoring center of the spurious packet. The monitoring center may be a human operated station, or may be an automated station configured to automatically respond to spurious network traffic by, for example collecting alerts and attempting to locate a source of spurious network packets.
While the invention has been disclosed in connection with the preferred embodiments shown and described in detail, various modifications and improvements thereon will become readily apparent to those skilled in the art. It should be understood that all matter contained in the above description or shown in the accompanying drawings shall be interpreted as illustrative, and not in a limiting sense.
Number | Name | Date | Kind |
---|---|---|---|
5140585 | Tomikawa | Aug 1992 | A |
5477547 | Sugiyama | Dec 1995 | A |
5539737 | Lo et al. | Jul 1996 | A |
5610905 | Murthy et al. | Mar 1997 | A |
5649108 | Spiegel et al. | Jul 1997 | A |
5737525 | Picazo et al. | Apr 1998 | A |
5946308 | Dobbins et al. | Aug 1999 | A |
6023563 | Shani | Feb 2000 | A |
6104696 | Kadambi et al. | Aug 2000 | A |
6237007 | Brown | May 2001 | B1 |
6308218 | Vasa | Oct 2001 | B1 |
6308220 | Mathur | Oct 2001 | B1 |
6321338 | Porras et al. | Nov 2001 | B1 |
6446131 | Khansari et al. | Sep 2002 | B1 |
6510154 | Mayes et al. | Jan 2003 | B1 |
6522656 | Gridley | Feb 2003 | B1 |
6535489 | Merchant et al. | Mar 2003 | B1 |
6621796 | Miklos | Sep 2003 | B1 |
6665733 | Witkowski et al. | Dec 2003 | B1 |
6711623 | Furukawa et al. | Mar 2004 | B1 |
6731596 | Chiang et al. | May 2004 | B1 |