Security encapsulation of ethernet frames

Information

  • Patent Grant
  • 8379638
  • Patent Number
    8,379,638
  • Date Filed
    Monday, September 25, 2006
    18 years ago
  • Date Issued
    Tuesday, February 19, 2013
    11 years ago
Abstract
A technique for encapsulating data packets at a Data Link Layer to provide security functions. The technique first encrypts a 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.
Description
BACKGROUND OF THE INVENTION

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.


SUMMARY OF THE INVENTION

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.





BRIEF DESCRIPTION OF THE DRAWINGS

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.



FIG. 1 is a high level diagram of a computer network that may provide security encapsulation of Ethernet frames in accordance with one embodiment of the invention;



FIG. 2 is a diagram of a standard Ethernet frame format in accordance with one embodiment of the invention;



FIG. 3 is a diagram illustrating a security encapsulated Ethernet frame after techniques according to the present invention are applied; and



FIG. 4 is a more detailed view of an encapsulation header and initialization vector portion of the encapsulated Ethernet frame in accordance with the example embodiment of the invention.





DETAILED DESCRIPTION OF THE INVENTION

A description of preferred embodiments of the invention follows.



FIG. 1 is a high level diagram of a network 100 that consists of sub-network 101a and sub-network 101b interconnected by a wide area network 130. An exemplary sub-network 101a consists of a number of customer premises equipment that may receive and provide communications in the wide area network 130. The customer premises equipment 105a 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. 105a-1, 105a-2, . . . , 105a-n).


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 FIG. 2. An Ethernet frame 200, as is well known in the art, consists of a header 201 including a destination address 205 of 6 bytes, a source address 210 of 6 bytes, and an 802.1Q tag type 215 of 2 bytes. The Ethernet frame 200 may also include a priority field 220 that may be used to assign a priority level, canonical format indicator (CFI) 225 to indicate the presence of a routing information field (RIF), and Virtual Local Area Network (VLAN) Identifiers (VIDs) 230 and 235. Priority field 220, CFI 225, and VIDs 230 and 235 occupy a total of 2 bytes. An Ethernet payload field 240, which may be from 48-1500 bytes long, is followed by a trailer field (cyclic redundancy check CRC 245) of 4 bytes.



FIG. 3 shows a detailed diagram of an output encapsulated frame 300 after being processed by encryptor 120a. Encryptor 120a receives an input Ethernet frame 200 having an original header 210 and payload 240 as shown in FIG. 2. Encryptor 120a encrypts the payload 240 to provide an Ethernet encrypted payload 350. Encryptor 120a then inserts the encrypted payload 350 in the output encapsulated frame 300, in the same place as the original payload 240. Thus output encapsulated frame 300 has the same destination address 305, source address 310, 802.1Q tag type 315, priority 320, CFI 325, VID fields 330 and 335 as the original Ethernet frame 200.


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 FIG. 3 (i.e., encrypted Ethernet payload 350 and padding 355) illustrates the portion of the packet that is encrypted. With the required padding the encrypted payload is typically longer than the original payload.



FIG. 4 shows the encapsulation header 340 and initialization vector 345 portion of encapsulated frame 300 in more detail. Encapsulation header 340 and initialization vector 345 together comprising a 24 byte field that is preferably inserted before the encrypted payload 340 of encapsulated packet 300. Encapsulation header 340 may include at least a 17-bit reserved field 405, 1-bit peer field 410, and 14-bit fragmentation field 435.


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.

Claims
  • 1. A method for providing security functions to data packets at the data link layer of the Open Systems Interconnection Reference Model, the method comprising: receiving, at the data link layer, a data packet having an Ethernet frame having an original header and original payload;encrypting, at the data link layer, the original payload to provide an encrypted payload that is longer than the original payload;fragmenting, at the data link layer, the encrypted payload into first and second output Ethernet frames if the size of the encrypted payload would result in the first output Ethernet frame exceeding a Path Maximum Transmission Unit limit for the data link layer;determining an encapsulation header for each of the first and second output Ethernet frames, the encapsulation header including a non-encrypted fragmentation field containing information to enable, at the data link layer, reconstruction of the encrypted payload from the first and second output Ethernet frames;constructing, at the data link layer, the first and second output Ethernet frames from the original header, the encapsulation header, and the encrypted payload, to provide security functions to the data packet at the data link layer.
  • 2. The method of claim 1 additionally comprising: determining an integrity check value for the encrypted payload.
  • 3. The method of claim 1 additionally comprising: appending the integrity check value to the encrypted payload.
  • 4. The method of claim 1 wherein the Ethernet frame further comprises: a Virtual Network Identifier (VID); andthe first and second output Ethernet frames further comprise the VID.
  • 5. The method of claim 1 wherein the encapsulation header includes a security association comprising a Security Parameters Index (SPI) value.
  • 6. An apparatus operating at the data link layer of the Open Systems Interconnection Reference Model, the apparatus comprising: a receiver for receiving, at the data link layer, a data packet having an Ethernet frame having an original header and original payload;a packet processor communicatively coupled to the receiver, the packet processor configured to:encrypt, at the data link layer, the original payload to provide an encrypted payload that is longer than the original payload;fragment, at the data link layer, the encrypted payload into first and second output Ethernet frames if the size of the encrypted payload would result in the first output Ethernet frame exceeding a Path Maximum Transmission Unit limit for the data link layer;determine an encapsulation header for each of the first and second output Ethernet frames, the encapsulation header including a non-encrypted fragmentation field containing information to enable, at the data link layer, reconstruction of the encrypted payload from the first and second output Ethernet frames; andconstruct, at the data link layer, the first and second output Ethernet frames from the original header, the encapsulation header, and the encrypted payload, to provide security functions to the data packet at the data link layer.
  • 7. The apparatus of claim 6 wherein the packet processor further determines an integrity check value for the encrypted payload.
  • 8. The apparatus of claim 7 wherein the packet processor additionally appends the integrity check value to the encrypted payload.
  • 9. The apparatus of claim 6 wherein the Ethernet frame further comprises a Virtual Network Identifier (VID), and the first and second output Ethernet frames further comprise the VID.
  • 10. The apparatus of claim 6 wherein the encapsulation header includes a security association comprising a Security Parameters Index (SPI) value.
US Referenced Citations (64)
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
Non-Patent Literature Citations (1)
Entry
Frankel, S. “Demystifying the IPsec Puzzle,” Artech House, Ch. 5, pp. 87-127, Ch. 9, pp. 179-205 (2001).
Related Publications (1)
Number Date Country
20080075073 A1 Mar 2008 US