Patent Application
20100309908
Communications networks (networks) enable communication between computing devices for forwarding or exchanging data, permitting control of one device by another, or for other purposes. Such networks may be wired and/or wireless, and may be internal (such as a local area network (LAN)) and/or external (such as a wide area network (WAN) or the Internet). Networks can be used to communicate among multiple computing devices. Such communication generally occurs as a result of data that is forwarded among one or more network infrastructure devices (network devices).
Typically, communication within a network takes place via the forwarding of packets from one computing device to a network device, from a network device to another network device, or from a network device to a computing device. For example, by breaking data for information or control into a plurality of packets, forwarding these packets from one computing device or network device to another, and reassembling the packets at a destination computing device, the data can be safely and efficiently communicated.
Security and reliability are important issues for communications networks. One significant issue is the reliability of the network in processing packets and/or forwarding packets. Such reliability is usually dependent on the effectiveness of network devices in processing the packets. A popular troubleshooting tool for network devices is to provide and forward a “test” or “ping” packet into the network. By tracing the path the packet takes as it travels through the network, and the processing of the packet by various network devices, the reliability of the network can be assessed and/or improved.
However, current network troubleshooting tools are becoming less effective as network devices become more intelligent. With network packet forwarding decisions increasingly being made based on the entire packet contents, it is difficult or impossible to predict with confidence where a particular packet will go.
Network devices forward packets from one device to another device based on an ever-increasing variety of criteria. When troubleshooting a network problem or auditing network operation, it is important to know what path the traffic is taking, and how it is being processed along the way. A problem is that the network equipment, being data-sensitive, may not react to a “test” or “ping” packet in the same way as the real traffic being investigated.
For example, current tracing tools include 802.2 “test” packets (network layer 2) and ICMP “ping” packets (network layer 3), which send and receive information packets containing specific information. Network devices recognize these standard diagnostic packets and process them according to relevant standards. However, these packets are often fundamentally different from “real” network traffic, and therefore are not handled by the network devices in the same way as would occur with the real traffic. Modern network equipment often recognizes application-layer headers and other packet contents for prioritizing, routing, filtering, or other special handling. Special-purpose test packets cannot contain this application-specific data, and thus incorrect or misleading diagnoses may be reported by those tools (and other tools built upon them). Such incorrect diagnoses, for example, may be as inconsequential as a slowing in finding a real fault in a network, or as severe as a failure to identify a critical network security flaw. On the other hand, it may be dangerous to inject a packet, live, into a network because of the concern that the packet may cause harm to a particular device, or to various parts of the network. Thus, it is desirable to check or control a path for a packet, without a risk of doing harm to devices in the network.
Embodiments of the present invention make it possible to inject real traffic into a communications network for tracing and troubleshooting purposes, without adverse effects. Using exemplary methods according to the present invention, the real path a network packet will take can be followed with confidence. Particularly, embodiments of the present invention make it possible to inject a sample of real network traffic by forwarding the packet to a network device and follow it from source to destination, with the assurance that it will not actually get delivered to a non-participating device, or acted upon in a non-transparent or state-altering manner.
Generally, embodiments of the present invention provide, among other things, methods for communicating with a network device in a communications network. For example, such communicating may be used to test a particular network device or group of network devices, or to trace the path of a packet. A data packet is provided, preferably by a computing device. This data packet preferably is a “real” data packet, in that it includes at least a header, a payload, and a trailer. The data packet includes an error detection code, such as but not limited to a cyclic redundancy check (CRC) or an IP checksum, which is derived at least partly based on data in the data packet, such as but not limited to data in the payload or in the header. The error detection code is modified using a reversible function to provide a marked data packet, and the marked data packet is sent to the network device. A reversible function is a function applied to an error detection code that alters the error detection code in some manner that can be consistently undone by another function (a reverse function) to provide the original error detection code; that is, for all valid original error detection codes, the reversible function provides a one-to-one mapping from the original error detection codes to their respective modified error detection codes, and vice versa. This reversible function makes the marked packet identifiable.
The network device, receiving the marked data packet, performs a reverse function to the modified error detection code to undo the reversible function and provide the (original) error detection code. The error detection code is then checked for validity at least partially based on the data in the data packet. If the error detection code is determined to be valid, the packet can be processed.
In this way, a network device that is configured to perform the reverse function can determine that the data packet has been marked, and process the data packet, such as in a manner known in the art. If a receiving network device is not configured to perform the reverse function, its normal validity check of the received data packet, based on the modified error detection code and the payload, will fail. Thus, a network device that is not configured to perform the reverse function will ignore the received data packet, while a network device that is configured to perform the reverse function will preferably record receipt of a marked data packet or other pertinent tracing information and process the packet, and preferably will avoid using the packet to alter network state.
Preferred embodiments will now be discussed with respect to the drawings. The drawings include schematic figures that are not to scale, which will be fully understood by skilled artisans with reference to the accompanying description. Features may be exaggerated for purposes of illustration. From the preferred embodiments, artisans will recognize additional features and broader aspects of the invention.
As is understood by one of ordinary skill in the art, data may be exchanged among the computing devices 12 by use of one or more data packets. These packets are forwarded from one computing device 12 to one or more different computing devices via network devices 14 in the communications network 10. Example network devices include, but are not limited to, routers, switches (such as but not limited to Ethernet switches and fiber channel switches), hubs, bridges, gateways, personal computers, workstations, servers, Internet backbones, etc. It will be appreciated that in particular embodiments of the present invention, one or more of the computing devices 12 may also function as a network device or vice versa. It will also be appreciated that the same physical device (with suitable internal communication) or different physical devices (with suitable links) may provide plural network devices and/or computing devices. As a nonlimiting example, one of the computing devices may serve the function of a router within the communications network 10 and in effect be part of the communications network.
The payload 26 includes the data 24, expressed in
A trailer 37 preferably includes an error detection code (EDC) (also referred to as a frame check or check code), shown in
The error detection code is based on data in the packet. In a nonlimiting example, the error detection code is determined at least partly based on the payload 26, and may be entirely based on the payload, so that the error detection code may be used to verify that the packet 20 was received correctly by the network device 14. As a more particular example, the error detection code may be based on adding the bits making up the data 24 in the payload 26 and expressing the total in bits to provide the error detection code. If a packet is received with a valid error detection code, it may be accepted by the network device 14. On the other hand, if a received packet contains an invalid error detection code, it may be discarded. Various methods for providing an error detection code are possible, and the present invention is not to be limited to a particular error detection code or a particular method of providing or generating an error detection code. Further, the location of the error detection code in embodiments of the present invention is not limited to the end, or trailer, of the packet, nor is the data from which the error detection code generated limited to data in the trailer of the packet. As another nonlimiting example, the IPv4 header has an EDC, which is an IP header checksum, within the header itself, and this IP header checksum is based on data in the header.
The packet 20 is marked by modifying the error detection code using a reversible function (step 42). By using a reversible function, the (properly generated) error detection code, though modified, remains accessible to a properly configured receiving device, such as the network device 14. In this way, the original error detection code may still be used for the purpose of verifying the integrity of the received packet as is known by those of ordinary skill in the art.
The modified error detection code is used to replace the original error detection code in the packet (for example, in the trailer) to provide a marked packet (step 44).
A nonlimiting example modification uses a 1's complement. In other words, all of the 1's bits in the CRC are inverted to 0's, and all 0's bits are inverted to 1's. This provides a one-to-one mapping from the original, valid CRC to the modified CRC.
In another example method, the error detection code (e.g., CRC) is modified by flipping (inverting a “0” to a “1” and a “1” to a “0”) several specifically chosen bits among the bits in the error detection code. In a nonlimiting example, the specific bits chosen are bit number 4 from each of the 4 bytes in a 32-bit CRC. The modified error detection code 54 shown in
The reversible function should be a modification algorithm that provides a one-to-one mapping between the original error detection code and the modified error detection code, and vice versa. However, it will be appreciated that other modifications are possible beyond those described herein and may be equally valid, so long as a function is available to provide the original error detection code from the modified error detection code.
The processor 66 includes suitable logic for performing methods according to the present invention. As a nonlimiting example, the processor 66 may include logic for providing a packet 70 (e.g., for retrieving a packet from the memory 68, the storage 69, or from the communications port(s) 62, or for generating a packet, including an error detection code). An error detection code modifier 72 modifies the error detection code, such as the CRC, using a reversible function. Once the error detection code is modified, marked packet assembly logic 74 may be provided for replacing the error detection code with the modified error detection code. Note that the logic embodied in the processor 66 may be provided (e.g., installed) by an add-on or external device, via media, by incorporating the method into VLSI of particular hardware, software, or firmware, or in other ways.
If, on the other hand, the error detection code is not valid, which will occur if the packet is marked according to embodiments of the present invention (and thus the error detection code is actually a modified error detection code), the network device 14 performs a reverse function on the error detection code of the received packet to provide the original error detection code (step 86). As a nonlimiting example, the network device 14 may invert selected bits (e.g., bit number 4 from each of the 4 bytes) of the received EDC, reversing the one-to-one mapping method shown in
If the original error detection code is valid, it is then determined at least that 1) the packet was received correctly, and 2) the packet is a marked packet. Thus, in an example embodiment, the network device 14 flags the packet as being a marked packet (or trips a counter, or takes other appropriate action) (step 90), and may then process the packet (step 84) as with other (non-marked) packets. One of ordinary skill in the art will appreciate that various methods of processing a packet are available, and may be device-specific. If, however, the test in step 88 for the original EDC fails, this indicates that the packet was not received correctly, and thus the packet is ignored or dropped (step 92).
Because the marked data packet 50 preferably is a real data packet, including a header, payload, and footer, and includes (once restored) an error detection code suitable for packet validation, the packet may be processed similarly to normal network traffic after the processing shown in
Note that, as shown in
During transit of the test packet 50, data may be collected on the packet, such as by flagging (step 90) and any follow-up data collection. Such data may include, but is not limited to, timing, routing decisions, ports of entry and egress, and packet capture, such as triggering packet sampling tools. With such information, a network management or diagnostic tool can clearly describe the path the marked packet 50 takes, and how it has been processed. For example, in a network security audit application, sample threat packets can be injected into the network 10 and followed to be sure they are handled properly, without worry that they would cause damage. The audit process can be assured that real network traffic will be handled in the same way as the marked data packets 50, and therefore an auditor can know that there is not a hidden security issue. Use of information gathered from processing marked data packets is not to be limited to these examples, however, and it will be appreciated that many different types of analyses may be possible using such information.
In particular packet-based methods involving networks, a packet may be modified by one or more network devices 14 as the packet travels through the network 10, for any of a variety of reasons. This is especially true if information derived from processing the packet is incorporated into the data in the packet (e.g., in the payload) as the packet goes through the network 10. It will be appreciated that the packet processing logic 118 in the network device 100 may include logic to modify the marked data packet, and generate a new marked data packet. Thus, the logic 118 may include logic similar to that provided in the processor 68 of the computing device 60.
An example method to generate a new marked data packet is shown in
Methods and devices for communicating with a network device, including methods for marking a data packet for a communications network, and for processing a marked data packet, have been shown and described herein having various features and benefits. Because the marked packet contains a modified error detection code that, without performing a reverse function to recover the original error detection code, would be considered invalid by a network device, such a packet will be discarded by any network device that is not configured to perform methods of the present invention. This makes it safe to inject arbitrary data into the communications network 10 via packets. However, because the test packet preferably otherwise contains real data, and because the modified error detection code, once restored to the original error detection code, preserves its packet validation function, the packet can be processed as it would under real circumstances after the reverse function is performed. This gives a network troubleshooter, evaluator, or auditor a highly accurate view of a network's behavior.
Methods and devices of the present invention may be incorporated into other applications, such as but not limited to management troubleshooting and network configuration. One or more devices may be selectively configured to provide or not provide the reverse function necessary to process a marked test packet. This selective configuration may be used to test particular network embodiments. As a nonlimiting example, a test network may be provided using a set of network devices for processing modified error detection codes, providing a “ghost configuration” and the network may be tested using marked data packets. Only the properly configured network devices would process the marked data packets. Once it is determined that the network is properly configured, the injected packets may be set to normal by using the original error detection codes. As disclosed herein, any of the computing devices or network devices may be capable of marking a packet, and thus it is contemplated to send packets that are marked at the beginning of a packet's path, or at one or more locations during packet transit. A network switch could also be configured to provide a new, unmarked data packet by using the original error detection code in the packet in place of the modified error detection code. Thus, embodiments of the present invention may provide a variety of methods for communicating with network devices by determining if and when a particular packet is marked before it is sent.
Devices incorporating embodiments of the present invention can be configured with relatively little effort and expense. Further, such devices can be clearly identified as conforming to embodiments of the present invention. In performing methods according to the present invention, it will be easily ascertainable which devices are capable or incapable of processing test packets, as incapable devices typically will ignore the packets altogether. A sub-network of conforming devices may be provided for communicating data without interference from non-conforming devices.
Methods according to embodiments of the present invention may be provided by hardware, firmware, software, or any combination of the above, so long as the hardware, firmware, software, or combination is configured to perform, or to allow a computing device or network device to perform such methods. Embodiments of the present invention may be embodied in, among other things, computing device-readable instructions in the form of software, firmware, and/or hardware suitable configured to operate on a computing device. Example media embodying the present invention may include, but is not limited to, removable storage, built-in storage, a computer data signal, magnetic, optical, or magneto-optical media, etc. A computing device or network device providing embodiments of the present invention may be any suitably configured computing or network device, and is not to be limited to the configurations shown and described herein. Devices according to the present invention may also include add-on devices, such as add-on processing devices, containing suitable logic for allowing a computing device or network device to perform methods according to the present invention. Computing devices may include network devices configured to perform methods of the present invention, and vice versa. Generally, embodiments of the present invention are not to be limited to a particular configuration of a device or a platform, so long as such embodiments are capable of carrying out one or more methods according to the present invention.
In the foregoing Detailed Description, various features are grouped together in a limited number of embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that any claim requires more features than are expressly recited in the claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment of the invention.
While various embodiments of the present invention have been shown and described, it should be understood that other modifications, substitutions, and alternatives are apparent to one of ordinary skill in the art. Such modifications, substitutions, and alternatives can be made without departing from the spirit and scope of the invention, which should be determined from the appended claims.
Various features of the invention are set forth in the appended claims.
