Networks of computers such as intranets, local and wide area networks, and the Internet exchange information in “packets.” A packet includes data such as files and programs and can also include a header that contains information that identifies the packet and indicates its origin and destination. The header can further include network protocol identifiers and the version number of the protocol that is to be used to route the information through the network. The header can also contain information identifying the port on the source computer from which the packet was sent and the port on the destination computer to which the packet is to be sent.
Computers connected to the Internet can be given either a static or dynamic Internet Protocol, or IP, address. Packets exchanged through the Internet accordingly often include an IP source address, an IP destination address, and an IP protocol identifier in addition to source and destination port information.
Computer networks, including the Internet, control the exchange of packets in order to prevent the unauthorized disclosure, modification, or execution of data and programs on a networked computer. In packet-switching networks, this is often accomplished through the use of an Access Control List, or ACL, that contains filter rules which indicate whether a packet should be accepted or dropped based on the identifiers included in the packet header.
ACLs are typically implemented, or enforced, by a network device known as firewall. Firewalls are often a combination of software and hardware that receives a packet and then compares the source, destination, protocol and/or other identifiers in the packet header to determine which filter rule “correspond,” or applies, to the packet. The firewall then applies the corresponding rules to the packet in the order they are set forth in a firewall rule table. A filter rule is applied by determining whether the identifiers set forth in the packet header match or fall within the range of values set forth in the filter rule for each identifier. If all of the packet header identifiers match the parameters set forth in a filter rule, an action, typically an ACCEPT/DROP action, is carried out on the packet. If the packet identifiers do not match the values specified in the corresponding filter rule, the next corresponding filter rule is applied to the packet, and the above-described process is repeated. If a packet header does not satisfy any of the corresponding rules, or if no rules are found to correspond to the packet header, a default action, usually a DROP action, is carried out on the packet. The default rule is often the last rule in the firewall rule table.
In recent years, security protocols such as Internet Security Protocol (IPsec) have been implemented. Some secure protocols encrypt both the packet and one or more fields in the packet header (such as the inner port, IP address and protocol information). The encryption of the packet header information complicates enforcement of filter rules because a standard ACL is able only to query and evaluate clear, or unencrypted, packet headers.
Further difficulties can be posed by the introduction of an open network (“ON”) architecture wherein the router includes a control element (CE) that creates and manages the filter rules and a separate forwarding element (FE) that forwards the packets toward to their destination. Such architectures are “open” in the sense that they can be component-based and the components interact according to open interface protocols. In certain ON systems an effective decryption technique must be implemented across a multiplicity of forwarding elements with a single control element.
Like reference symbols in the various drawings indicate like elements.
A system for filtering encrypted packets can be realized by, for example, uploading an ACL and a Security Information Transport Protocol (SITP) mapping table to a Filter Rule Constructor (FRC) that integrates IPsec security information with packet filter rules and generates a graph of filter chains, or filter rule tables. The graph of filter chains can include a clear filter chain, the first rule of which diverts encrypted packets to an outer chain. The outer chain can be configured to route the encrypted packets to a corresponding inner filter chain, which contains the information necessary to decrypt the packet headers and filter the packets based on the identifiers in the encrypted packet header. The FRC that constructs the graph of filter chains may be disposed in a control element of an ON router. The graph of filter chains can be simultaneously downloaded to and enforced by a plurality of forwarding elements in an ON system. This particular implementation provides an IPsec-based VPN-friendly ON architecture.
In operation, the FRC 110 receives an Access Control Listing (ACL) table 104 and a SITP mapping table 106 and thereafter generates a graph of filter chains 114. The control element downloads the filter chain graph 114 to the forwarding element 108. The forwarding element 108 applies the filter rules embodied in the filter chains 114 to all packets received and route the packets pursuant to the identifiers in the packet headers.
In operation, the FRC 110 merges the ACL table 104, which is adapted primarily for clear packet headers, and the SITP mapping table 106, which describes how packets have certain specified identifiers should be decrypted. The resulting graph of filter chains 114 is shown in
It should be noted that in certain tunneling mode implementations, a packet's inner source IP address (ISIP), the inner destination IP address (IDIP), the inner protocol (IProto), the source port (SPort), and the destination port (DPort) are encrypted, while the remainder of the header parameters are clear, or unencrypted. In such embodiments, the outer chain forwards packets based on the clear header information, and the inner chain decrypts the remaining packet headers and then applies the appropriate filter rules.
An exemplary set of steps for deletion of a SITP mapping are illustrated in
Statistics can be harvested from the IPsec aware firewall according to the protocol illustrated in
The foregoing techniques can be customized to the needs of particular network, implemented in a wide variety of network architectures, and used to effectively filter packets encrypted by any number of security protocols. The matching of corresponding parameters or identifiers can be exact matching, range matching or wildcard matching, as noted above. The FRC reside or be executed on multiple elements or platforms. The foregoing filtering methods can be implemented in virtually any type of router, and the applicability of the techniques are by no means limited to ON routers. Similarly, there is no need to have the control element and forwarding element to reside on different platforms, or for that matter to be separate in any respect. The methods can likewise be implemented in networks other than VPNs, including but not limited to WANs, LANs, intranets, and the like. Moreover, there is no need that the firewall be a portal to an external network such as the Internet. Rather, the methods can be advantageously implemented in any network element that receives and transmits encrypted packets or packet headers.
Packets encrypted by other security protocols can be readily filtered in accordance with the teachings set forth above. In such systems, the packet identifiers, parameters, decryption algorithms, and decryption keys (if applicable) can be modified to correspond to the desired encryption protocol.
Various trust models can also be implemented. In the trust model shown in
Likewise, alternate filter layer arrangements can be selected. For instance, one can readily implement a plurality of clear filter chains and a single filter chain for encrypted packet headers, as will be readily appreciated by those skilled in the art. The encrypted filter chains may be more or less complex and processor-time intensive, depending on the particular tuples and layering selected for a particular application.
Similarly, it will be apparent to those skilled in the art that the specific protocols described above, and their particular sequencing, are merely illustrative embodiments selected for a particular network architecture and security protocol. Unless specifically stated otherwise, the steps of each protocol can be performed in a difference sequence.
The protocols need not be executed by a program in a control element. The component FRC can be embedded into forwarding elements. Alternately, the control element and forwarding element can be merged and controlled by an FRC that does not reside on router hardware. Still another option is for the FRC to reside on the forwarding element platform.
The graph of filter chains need not be in “graph” form. Rather, any desired filter rule set can be provided to the enforcing element in a router architecture.
Similarly, the FRC element(s) need not prepare a filter rule set “offline” and thereafter download it to the forwarding element or other network element that applies the filter rules to routed packets. Rather, the router can execute protocols on a control element and a forwarding element in parallel, as described in
While the above description has been directed primarily to firewalls, those skilled in the art will understand that the above techniques can be applied to other security aware services such as traffic engineering, QoS, load balancing, etc.
The foregoing techniques can be implemented in an almost limitless number of additional manners dictated by particular network architecture(s), security protocols, and other design parameters. The foregoing proposed modifications will be understood as merely illustrative by those skilled in the art. It will be understood that various modifications may be made without departing from the spirit and scope of the invention. Accordingly, other embodiments are within the scope of the following claims.
Aspects of the invention provide for one or more of the following advantages. In selected embodiments, the invention provides a system and method for circuit that integrates security information with packet filter rules. In certain embodiments, a single graph of filter chains is generated for efficient enforcement by a forwarding or routing element. In some embodiments, the IPsec aware classification circuit greatly enriches the programmability of ON routers. In still other embodiments, the foregoing techniques can be used to provide IPsec friendly services, such as firewall and QoS services, to IPsec based networks such as VPNs.
Number | Name | Date | Kind |
---|---|---|---|
5530854 | Emery et al. | Jun 1996 | A |
5870744 | Sprague | Feb 1999 | A |
5884025 | Baehr et al. | Mar 1999 | A |
6006016 | Faigon et al. | Dec 1999 | A |
6006253 | Kumar et al. | Dec 1999 | A |
6041355 | Toga | Mar 2000 | A |
6076168 | Fiveash et al. | Jun 2000 | A |
6088803 | Tso et al. | Jul 2000 | A |
6108786 | Knowlson | Aug 2000 | A |
6141686 | Jackowski et al. | Oct 2000 | A |
6154775 | Coss et al. | Nov 2000 | A |
6157955 | Narad et al. | Dec 2000 | A |
6163531 | Kumar | Dec 2000 | A |
6185625 | Tso et al. | Feb 2001 | B1 |
6202084 | Kumar et al. | Mar 2001 | B1 |
6233686 | Zenchelsky et al. | May 2001 | B1 |
6236996 | Bapat et al. | May 2001 | B1 |
6237031 | Knauerhase et al. | May 2001 | B1 |
6240514 | Inoue et al. | May 2001 | B1 |
6246678 | Erb et al. | Jun 2001 | B1 |
6289459 | Fischer et al. | Sep 2001 | B1 |
6292798 | Dockter et al. | Sep 2001 | B1 |
6304904 | Sathyanarayan et al. | Oct 2001 | B1 |
6304973 | Williams | Oct 2001 | B1 |
6311215 | Bakshi et al. | Oct 2001 | B1 |
6347376 | Attwood et al. | Feb 2002 | B1 |
6496935 | Fink et al. | Dec 2002 | B1 |
6519636 | Engel et al. | Feb 2003 | B2 |
6539483 | Harrison et al. | Mar 2003 | B1 |
6651099 | Dietz et al. | Nov 2003 | B1 |
6697872 | Moberg et al. | Feb 2004 | B1 |
6701437 | Hoke et al. | Mar 2004 | B1 |
6708218 | Ellington, Jr. et al. | Mar 2004 | B1 |
6751729 | Giniger et al. | Jun 2004 | B1 |
6915437 | Swander et al. | Jul 2005 | B2 |
6935155 | Yasui et al. | Aug 2005 | B2 |
20020104020 | Strahm et al. | Aug 2002 | A1 |
20020163920 | Walker et al. | Nov 2002 | A1 |
20020169980 | Brownell | Nov 2002 | A1 |
20020178355 | D'Sa et al. | Nov 2002 | A1 |
20030110377 | Chapman | Jun 2003 | A1 |
20030123452 | Cox et al. | Jul 2003 | A1 |
20030212901 | Mishra et al. | Nov 2003 | A1 |
Number | Date | Country |
---|---|---|
2317 792 | Jan 1998 | GB |
Number | Date | Country | |
---|---|---|---|
20030188192 A1 | Oct 2003 | US |