This invention relates generally to communication networks and in particular to a technique for securing communication at the Data Link Layer (layer 2) of the Open System Interconnection (OSI) Reference Model. The Data Link Layer may provide for reliable transfer of information across the physical layer.
Data transferred over many communication networks are typically sent unsecured, without the benefit of encryption and/or strong authentication of the sender. Sending unsecured data on a communication network may make the data vulnerable to being intercepted, inspected, modified and/or redirected. To make data less prone to these vulnerabilities, many networks employ various security standards and protocols to secure network traffic transferred in their networks. This secured network traffic is typically transferred using data packets that are encoded according to a security standard and/or protocol. As used herein, a secure data packet is a data packet that has been secured using a security standard and/or protocol. Likewise, as used herein, an unsecured data packet is a data packet that has not been secured using a security standard and/or protocol.
One well-known widely-used standard for securing Internet Protocol (IP) traffic is the IP security (IPsec) standard. The IPsec standard comprises a collection of protocols that may be used to transfer secure data packets in a communication network. IPsec operates at layer-3 (L3) which is the network layer of the Open Systems Interconnection Reference Model (OSI-RM). A description of IPsec may be found in Request for Comments (RFC) 2401 through RFC 2412 and RFC 4301 through RFC 4309 all of which are available from the Internet Engineering Task Force (IETF). Two cryptographic protocols that are commonly used to encapsulate IPsec packets are the Authentication Header (AH) protocol and the Encapsulating Security Payload (ESP) protocol.
The AH protocol is primarily used to provide connectionless integrity and authentication of IP datagram traffic. The authentication enables the origin of the traffic to be verified and ensure that the traffic has not been altered in transit. Authentication and integrity of an IP packet is achieved using a keyed one-way hash function, such as Message Digest algorithm 5 (MD5) or Secure Hash Algorithm-1 (SHA-1), in combination with a secret that is shared between a sender of the packet and a receiver of the packet.
Like the AH protocol, the ESP protocol provides a means to authenticate and verify the integrity of IP traffic carried in a secured packet. In addition, the ESP protocol provides a means to encrypt the IP traffic to prevent unauthorized interception of the IP traffic. Like the AH protocol, the ESP uses an ICV to authenticate and check the integrity of a packet. Encryption is used to secure the IP traffic. Encryption is accomplished by applying an encryption algorithm to the IP traffic to encrypt it. Encryption algorithms commonly used with IPsec include Data Encryption Standard (DES), triple-DES and Advanced Encryption Standard (AES).
A payload of an Ethernet packet may be encrypted, however encryption of the payload itself does not support authentication or other security functions as per IPsec. For example, IEEE 802.1AE Media Access Control Security (MACsec) standard integrates security protection into wired Ethernet to secure local area networks (LANs) from attacks. However, IEEE 802.1AE provides only hop-by-hop security, and not complete end-to-end security.
What is needed is a way to provide security to provide functions such as data origin authentication, data integrity, and data confidentiality transferred over a Data Link Layer (layer 2) of the Open System Interconnection (OSI) Reference Model without requiring modification of higher layers.
The present invention provides a technique for encapsulating data packets at a Data Link Layer to provide security functions. Starting with an input frame, that may be standard Ethernet frame having an original header and a payload, the technique first encrypts the payload to provide an encrypted payload. The encrypted payload is inserted in an output encapsulated frame. Also added to the output encapsulated frame is an encapsulation header that includes security information, such as a security packet index (SPI) value used to identify a security association (SA).
Because the output encapsulated frame may now be longer than maximum allowed Ethernet Path Maximum Transmission Unit (PMTU), the encapsulation header also preferably includes a fragmentation field. The fragmentation field supports the ability to fragment the encrypted datagrams into smaller pieces, i.e., pieces that are small enough to meet a PMTU requirement.
Moreover, in order to support features such as virtual local area network (VLAN) per IEEE 802.1Q and/or Multi-Protocol Label Switching (MPLS) both VLAN tags and MPLS labels may be included in the header of the output encapsulated frame.
Optional features of the encapsulation header may include further fields such as a peer data flag to identify peer to peer encrypted traffic and other elements that, for example, may include an initialization vector used for the encryption/decryption processing.
The foregoing will be apparent from the following more particular description of example embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments of the present invention.
A description of preferred embodiments of the invention follows.
The customer premises equipment 105a may be interconnected by a local Ethernet network 115a. An encryptor appliance 120a is disposed in line between the Ethernet network 115a and internetworking devices such as a gateway 125a. The gateway 125a provides connectivity into network 130 so that customer premises equipment 105a may communicate with other customer premises equipment 105b connected to network 130 such as computer terminals 105b-1, 105b-2, . . . , 105b-n and servers 110b-1, . . . , 110b-n in sub-network 101b.
Sub-network 101b may be similar to sub-network 101a. Sub-network 101b may include gateway 125b and encryptor appliance 120b that couple to Ethernet network 115b to provide network connectivity to customer premises equipment 105b. Customer premises equipment 105b may include Ethernet enabled devices such as personal computers, workstations, file servers, printers, Internet Protocol (IP) telephones, IP video devices and the like (e.g. 105b-1, 105b-2 . . . 105b-n).
In-line encryptor appliances 120a and 120b examine packet traffic traveling, respectively, between Ethernet 115a and gateway 120a and Ethernet 115b and gateway 120b. The line encryptor appliances 120a and 120b may modify the format of Ethernet packets according to the present invention. In particular, the encryptor appliances 120a and 120b apply a security protocol to Ethernet frames that provide data origin authentication, data integrity and data confidentiality through the use of security encapsulation of the Ethernet payload. Information concerning the security protocol to be applied, such as encryption keys, security associations, policies and the like, are provided to appliances 120 from elsewhere in the network.
Packets incoming to encryptor 120a from sub-network 101a or exiting encryptor 120a destined for Ethernet sub-network 101a may have the Ethernet frame format of
However, also included in the output encapsulated frame 300 are an encapsulation header 340 and initialization vector 345, encrypted Ethernet payload 350, padding 355 and authentication trailer 360. In addition it should be understood that the CRC field 365 would be different for the encapsulated packet 300.
If the original Ethernet frame 200 supports features such as VLAN per IEEE 802.1Q and/or Multi-Protocol Label Switching (MPLS) both VLAN tags and MPLS labels may be copied into the encapsulated packets header in the same location and without modification. However, the Ethernet payload in the original packet 240 becomes the encrypted Ethernet payload 350 in the outgoing encrypted Ethernet frame 300.
The Ethernet payload 350 may be encrypted using encryption algorithm such as the AES-256 CBC encryption algorithm. With the AES-256 CBC encryption algorithm, a padding filed 355 of from 1 to 16 bytes is added to the payload to adhere to encryption algorithm's 128-bit block size requirement. The shaded area of
The fragmentation field 435 allows encrypted datagrams to be fragmented into pieces that are small enough to pass over a communication link having a smaller path maximum transmission unit (PMTU) than the originally encapsulated datagram. In particular, certain networks require strict observation of the limitation on frame size; however, encryption of the payload portion of the frame may cause it to exceed the maximum allotted PMTU size, (i.e., 1500 bytes in some networks). The fragmentation field 435 includes a 12-bit fragment ID field 425, 1-bit begin fragment flag 415, and 1-bit end fragment flag 420. Field 425 and flags 415 and 420 enable reconstruction of a fragmented encrypted frame, such as by marking a first frame with the begin fragment flag 415, and an end frame with the end flag 420.
Also included is a 32-bit security parameters index (SPI) value field 430. This permits identification of a security association used to encapsulate and encrypt the packet. For example, an SA according to the IPsec standard may be used to determine an SPI value field.
The 1-bit peer data flag 410 may be used to identify a peer to peer encryptor traffic. In particular, the peer-to-peer flag is set when encryptor 120a sends a message to encryptor 120b without involving the customer premises equipment 105a and 105b. Such a message, for example, may include exchanges of security association information in order to authenticate end-to-end communication, set up secure tunnels or other management functions.
Finally, hashing algorithms such as the SHA-1 algorithm is then performed on the entire encrypted packet 300 to result in the CRC value 32. The integrity check value produced by the hashing algorithm and the packet CRC value 32 are then appended to the Ethernet encrypted payload 350 to produce the encrypted encapsulated packet 300.
As can be understood now the present invention provides for the ability to apply security encapsulation to Ethernet frames providing an advantage over prior art approaches to network security.
While this invention has been particularly shown and described with references to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.
Number | Name | Date | Kind |
---|---|---|---|
4881263 | Herbison et al. | Nov 1989 | A |
5237611 | Rasmussen et al. | Aug 1993 | A |
5303303 | White | Apr 1994 | A |
5577209 | Boyle et al. | Nov 1996 | A |
5940591 | Boyle et al. | Aug 1999 | A |
6035405 | Gage et al. | Mar 2000 | A |
6061600 | Ying | May 2000 | A |
6111876 | Frantz et al. | Aug 2000 | A |
6122378 | Yoshiura et al. | Sep 2000 | A |
6148405 | Liao et al. | Nov 2000 | A |
6173399 | Gilbrech | Jan 2001 | B1 |
6275588 | Videcrantz et al. | Aug 2001 | B1 |
6275859 | Wesley et al. | Aug 2001 | B1 |
6330562 | Boden et al. | Dec 2001 | B1 |
6393500 | Thekkath | May 2002 | B1 |
6484257 | Ellis | Nov 2002 | B1 |
6556547 | Srikanth et al. | Apr 2003 | B1 |
6591150 | Shirota | Jul 2003 | B1 |
6658114 | Farn et al. | Dec 2003 | B1 |
6697857 | Dixon et al. | Feb 2004 | B1 |
6708218 | Ellington, Jr. et al. | Mar 2004 | B1 |
6711679 | Guski et al. | Mar 2004 | B1 |
6823462 | Cheng et al. | Nov 2004 | B1 |
6915431 | Vasudevan et al. | Jul 2005 | B1 |
6915437 | Swander et al. | Jul 2005 | B2 |
6920559 | Nessett et al. | Jul 2005 | B1 |
6981139 | Enokida | Dec 2005 | B2 |
6986061 | Kunzinger | Jan 2006 | B1 |
7103784 | Brown et al. | Sep 2006 | B1 |
7269639 | Lawrence | Sep 2007 | B1 |
7321599 | Yen et al. | Jan 2008 | B1 |
7366894 | Kalimuthu et al. | Apr 2008 | B1 |
7398386 | Kessler et al. | Jul 2008 | B2 |
7817634 | Coffman et al. | Oct 2010 | B2 |
7953389 | Coleman et al. | May 2011 | B2 |
7990985 | Chen | Aug 2011 | B2 |
20010050903 | Vanlint | Dec 2001 | A1 |
20020061030 | Iny | May 2002 | A1 |
20020154782 | Chow et al. | Oct 2002 | A1 |
20020162026 | Neuman et al. | Oct 2002 | A1 |
20030135753 | Batra | Jul 2003 | A1 |
20030172144 | Henry et al. | Sep 2003 | A1 |
20030172307 | Henry et al. | Sep 2003 | A1 |
20030191937 | Balissat et al. | Oct 2003 | A1 |
20040005061 | Buer et al. | Jan 2004 | A1 |
20040044891 | Hanzlik et al. | Mar 2004 | A1 |
20040062399 | Takase | Apr 2004 | A1 |
20040139313 | Buer et al. | Jul 2004 | A1 |
20040153643 | Correll et al. | Aug 2004 | A1 |
20040160903 | Gai et al. | Aug 2004 | A1 |
20040215804 | Tan | Oct 2004 | A1 |
20040268124 | Narayanan | Dec 2004 | A1 |
20050010765 | Swander et al. | Jan 2005 | A1 |
20050066159 | Poussa et al. | Mar 2005 | A1 |
20050125684 | Schmidt | Jun 2005 | A1 |
20050138369 | Lebovitz et al. | Jun 2005 | A1 |
20050149732 | Freeman et al. | Jul 2005 | A1 |
20050190758 | Gai et al. | Sep 2005 | A1 |
20060029102 | Abe et al. | Feb 2006 | A1 |
20060072748 | Buer | Apr 2006 | A1 |
20060072762 | Buer | Apr 2006 | A1 |
20060155981 | Mizutani et al. | Jul 2006 | A1 |
20080005558 | Hadley et al. | Jan 2008 | A1 |
20080229095 | Kalimuthu et al. | Sep 2008 | A1 |
Entry |
---|
Frankel, S. “Demystifying the IPsec Puzzle,” Artech House, Ch. 5, pp. 87-127, Ch. 9, pp. 179-205 (2001). |
Number | Date | Country | |
---|---|---|---|
20080075073 A1 | Mar 2008 | US |