Network Working Group Y. Zhang INTERNET DRAFT HRL Labs October 1999 Expires April 2000 Multi-Layer Protection Scheme for IPSEC Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a multi-layer protection scheme for IPSEC that applies separate encryption/authentication with different keys on different parts of an IP datagram. It allows certain intermediate routers to have limited and controllable access to part of IP datagram (usually headers) but not the user data. 1. Introduction Recent advances in internetwork technology introduce a rich set of new services and applications, like router-based congestion controls, or TCP performance enhancements, or transparent proxies, all of which require intermediate network nodes to access certain part of an IP datagram, usually the upper layer protocol information, to perform intelligent routing or customized processing. Many of these mechanisms have already found widely used, such as per-flow queueing, Zhang draft-zhang-ipsec-mlipsec-00.txt [Page 1] Internet Draft Multi-Layer IPSEC Oct 1999 multi-field diffserv, TCPPEP for wireless/satellite networks, and NAT for ISPs. Other promising mechanisms include layer-4/5/6/7 routing/switching, or even ``active networks.'' Various IETF working groups or BOFs are addressing such needs, like PEP, PILC, TF-ESP, etc. Unfortunate, all these are in direct conflict with the IETF standard mechanism for providing security services -- IPSEC. IPSEC [RFC 2401] protects the entire IP datagram in an ``end-to-end'' fashion; no intermediate node in the public Internet can access or modify any information above the IP layer in an IPSEC-protected packet, which in effect disable all the above new services and applications. This memo specifies a multi-layer security protection scheme for IPSEC, which uses a finer-grain access control to allow trusted intermediate routers read and write a selected portion of IP datagram, in a secure and controlled manner. The goal is to support the above new services and applications, and preserves the end-to-end security protection for user data. 1.1 Background of IPSEC operation IPSEC uses two protocols to provide traffic security -- AH (Authentication Header) [RFC 2402] and ESP (Encapsulating Security Payload) [RFC 2406]. AH provides integrity and authentication without confidentiality; ESP provides confidentiality, with optional integrity and authentication. Each protocol supports two modes of use: transport mode and tunnel mode. Transport mode provides protection primarily for upper layer protocols, while in tunnel mode the protection applies to the entire IP datagram. The granularity of security protection in IPSEC is at the datagram level. IPSEC treats everything in an IP datagram after the IP header as one integrity unit. Usually, an IP datagram has three consecutive parts -- the IP header (for routing purpose only), and the upper layer protocol headers (e.g., the TCP header), and the user data (e.g., TCP data). In transport mode, an IPSEC header (AH or ESP) is inserted in after the IP header and before the upper layer protocol header to protect the upper layer protocols and user data. In tunnel mode, the entire IP datagram is encapsulated in a new IPSEC packet (a new IP header followed by an AH or ESP header). Either case, the upper layer protocol headers and data in an IP datagram are protected as one indivisible unit. The access control of IPSEC is through the distribution of keys used in authentication and encryption. Whoever has the keys have read and/or write access to the entire IP datagram. Normally, the keys are shared only by the sender-side and receiver-side security gateways. All other nodes in the public Internet, whether they are legitimate routers or malicious eavesdroppers, see only the IP header and will not be able to decrypt the content, nor can they tamper it without Zhang draft-zhang-ipsec-mlipsec-00.txt [Page 2] Internet Draft Multi-Layer IPSEC Oct 1999 being detected. This end-to-end model works well if the internet routers do only one thing - forwarding packets based on IP header (mainly the destination address field), but not if intermediate routers perform extra customized processing or intelligent routing based on some content of the datagram, such as the upper-layer protocol headers. An example of such cases is multi-field diffserv, where intermediate routers uses the TCP header information to classify flows and to expedite packet forwarding. Security Association (SA) [RFC 2401] is a key concept in IPSEC. It is a one-way relationship between a sender and a receiver that affords security services. Each SA defines a set of parameters including the sequence number and anti-replay window for anti-replay service, the protocol mode (transport or tunnel), the lifetime of SA, the path MTU and other implementation details. For authentication services in AH or ESP, each SA also defines the choice of cryptographic algorithm, the crypto-keys, key lifetimes and related parameters. For encryption services in ESP, each SA further defines the choice of encryption algorithm, the encryption keys, the initial values, key lifetimes, etc. When an outbound IP datagram passes the security gateway, IPSEC first compares the values of the appropriate fields in the IP datagram (the selector fields) against a set of predefined policies, called SA selectors, in the Security Policy Database (SPD). It then determines the SA for this datagram if any, and does the required IPSEC processing (i.e., encryption). When an inbound IPSEC datagram passes the security gateway, IPSEC uses the SPI (Security Parameter Index) field to determine the SA for this datagram and performs IPSEC processing (i.e. decryption). 2. A New Multi-Layer Security Protection Model ML-IPSEC is an extension to IPSEC that adds a finer grain access control. It uses a multi-layer security protection model to replace the single end-to-end model. Under IPSEC, the scope of encryption and authentication apply to the entire IP datagram payload (sometimes IP header as well). In ML-IPSEC, an IP datagram is divided into more than one ``zones.'' Different security relationship are defined for different zones. Each zone has its own sets of security associations, its own set of private keys (secrets) that are not shared with other zones, and its own sets access control rules (defining which nodes have access to the zone). When ML-IPSEC protects a traffic stream from its source to its destination, the first IPSEC gateway (or source) will re-arrange the IP datagram into zones and applies cryptographic protections. When the ML-IPSEC protected datagram flow through an authorized intermediate gateway, certain part of the datagram may be decrypted and/or modified and re-encrypted, but the other part will not be Zhang draft-zhang-ipsec-mlipsec-00.txt [Page 3] Internet Draft Multi-Layer IPSEC Oct 1999 compromised. When the packet reaches the last IPSEC gateway (or destination), ML-IPSEC will be able to reconstruct the original datagram. ML-IPSEC defines a complex security relationship that involves both the sender and the receiver of an security service, but also selected intermediate nodes along the traffic stream. For example, in a TCPPEP (TCP Performance Enhancement Proxy) application, the IP datagram payload is divided into two zones: TCP header and TCP data. The TCP data part uses an end-to-end protection with keys shared only between source and destination (either end hosts or IPSEC gateways). The TCP header part uses a separate protection scheme with keys shared among source, the destination, and certain trusted intermediate node (that performs TCPPEP). This way, no one in the public Internet other than source, destination or the trusted intermediate node has access to TCP header or TCP data, and no one other than source and destination (not even the trusted intermediate node) has access to TCP data. sender ... any node ... TCPPEP node ... any node ... receiver +---------+ +---------+ +---------+ | IP hdr | | IP hdr | | IP hdr | +---------+ +---------+ +---------+ +---------+ +---------+ | IP hdr | |IPSEC hdr| |IPSEC hdr| |IPSEC hdr| |IPSEC hdr| |---------| |---------| |---------| |---------| |---------| | TCP hdr | |/////////| | TCP hdr | |/////////| | TCP hdr | |---------| |///Enc///| |---------| |///Enc///| |---------| | | |///ryp///| |/////////| |///ryp///| | | | TCP data| |///ted///| |//Enc'd//| |///ted///| | TCP data| | | |/////////| |/////////| |/////////| | | +---------+ +---------+ +---------+ +---------+ +---------+ Since ML-IPSEC allows network operators and service providers to grant limited access of IP datagram contents (such as TCP header) to intermediate nodes, such access must be granted in a secure and controllable way. The identity of the intermediate nodes must be authenticated (using an out-of-band mechanism such as public-key infrastructure) to prevent any man-in-the-middle attack. This memo does not specify the authentication procedure. It however recommends the same authentication mechanisms used for the original IPSEC. 3. Zones A zone is the portion of IP datagram under the same security protection scheme. The granulative of a zone is 1 octet. The entire IP datagram is covered by zones, except the IP header in IPSEC transport mode, but zones cannot overlap. Zhang draft-zhang-ipsec-mlipsec-00.txt [Page 4] Internet Draft Multi-Layer IPSEC Oct 1999 Using the multifield diffserv or TCPPEP as an example, the portion of IP datagram that contains TCP header (21st to 40th octet) is Zone 1, and the TCP data portion (41st and above octet) is Zone 2 (assuming transport mode and no TCP options). A zone needs not to be a continuous block in an IP datagram, but each continuous block is called a ``subzone.'' A ``zone map'' is a mapping relationship from octets of the IP datagram to the associated zones for each octet. The following figure illustrates an example zonemap. +-------------------------------------------------//---------+ | IP datagram | +-------------------------------------------------//---------+ Zone 1 consists of 3 subzones: +---+ +-------+ +---------+ | | | | | | +---+ +-------+ +---------+ Zone 2 consists of 1 subzone: +---+ | | +---+ Zone 3 consists of 2 subzones: +-----------+ +-----------//---------+ | | | | +-----------+ +-----------//---------+ The zone map: +-------------------------------------------------//---------+ |1 1|2 2|1 1 1 1|3 3 3 3 3 3|1 1 1 1 1|3 3 3 3 3 3 3 3 3 3 3| +-------------------------------------------------//---------+ The zone map is a constant in a security relationship. That is, the zone boundaries in each IP datagram must remain fixed in the life time of the security association, otherwise, it will be extremely difficult to do zone-by-zone decryption and authentication. Since IP datagrams are variable in length, the zone that covers the last part of the datagram, usually the user data, should also be variable in size. Zone 3 of the above is an example. It is also possible, theoretically, to define a phantom zone that does not correspond to any byte in an IP datagram. 4. Composite SA Zhang draft-zhang-ipsec-mlipsec-00.txt [Page 5] Internet Draft Multi-Layer IPSEC Oct 1999 RFC 2401 defines a simple security relationship from the sender to the receiver that afford the protection service. ML-IPSEC however requires a much more complex security relationship to include sender and receiver, as well as the selected intermediate nodes. Since the security service is zone-by-zone, conceptually we can use individual security relationship to cover each zone, then build a composite relationship to cover the entire IP datagram. Mapping this idea to the basic Security Association (SA) concept, ML-IPSEC needs a new type of SA called ``Composite SA'' (CSA). CSA is a collection of SAs (per RFC 2401) that collectively afford a multi-layer security protection for the traffic stream. A CSA has two elements. The first element is a zone map. The zone map specifies the coverage of each zone in an IP datagram. The zone map must be consistent in all nodes involved in the same ML-IPSEC relationship. The second element in a CSA is a zone list. A zone list is a list of SAs for all the zones. Each and every such SA is stored in the Security Association Database (SAD) [RFC 2401]. However, some of the fields are used different in ML-IPSEC than in RFC 2401. The following SAD fields, for example, are applicable only on the corresponding zone of the SA. Lifetime of this Security Association. AH Authentication algorithm, keys, etc. ESP Encryption algorithm, keys, IV mode, IV, etc. ESP Authentication algorithm, keys, etc. The other SAD fields have no meanings in the zone level. With the exception of a designated SA in the zonelist, the following SAD fields are not use in other zonal SAs, although they may be initialized during the SA creation process. Sequence Number Counter. Sequence Counter Overflow. Anti-Replay Window. IPsec protocol mode. Path MTU. The designated SA however operates on these fields as defined in RFC 2401. The designated SA is a special SA in the zonelist, usually the first SA in the list. It is responsible for maintaining parameters for the IP datagram layer and ``represents'' the CSA in IPSEC processing. The zone map and zone list can be stored with the designated SA as additional fields in the SAD, or, they can be store in a separate CSA Zhang draft-zhang-ipsec-mlipsec-00.txt [Page 6] Internet Draft Multi-Layer IPSEC Oct 1999 database. This is an implementation choice and it allows flexibility in adding ML-IPSEC features to an existing IPSEC implementation. On inbound processing, if the traffic stream is under ML-IPSEC protection, the destination IP address, the IPsec protocol type, and the SPI identifies an entry in the SAD, which points to the designated SA of the CSA for this traffic stream. Or, under alternative implementation, the triplet identifies an entry in the CSA database. By traversing CSA's zone list ML-IPSEC can further identifies the SA entries for all the zones. On outbound processing, the Security Policy Database (SPD) [RFC 2401] will have a pointer to the designated SA or an entry in the CSA database. Same as in RFC 2401, the selectors will direct the outbound traffic to the proper SPD entry. 4.1 Access Control in a CSA A CSA involves the sender, receiver, and all authorized intermediated nodes that collectively provide a multi-layer security protection for a traffic stream. Therefore, an instance of CSA must be created in each of these nodes before the ML-IPSEC service can commence. The zonemap must be distributed and remain the same for all nodes. Each CSA instance must have a designated SA, and the choice of designated SA must be consistent across all nodes. However, the zone list need not be the same for all nodes. In principle, each zonal SA independently determines the access list for that zone; not all nodes will have access to all zones. If some node does not have access to a zone, the corresponding zonal SA in the zone list will be null. For a particular zonal SA, an instance must be created in each authorized node and stored in its SAD as a step in CSA creation. By determining which zonal SA to be created in which node, CSA enforces a multi-layer access control for an IP traffic stream. No node is allowed to have null designated SA. That is, every nodes involved in an ML-IPSEC relationship must all have access to at least one zone, although, in principle, it is possible to include a phantom zone and define the designated SA on that zone. For convenient, we called the zone for which the designated SA is chosen the "designated zone". 4.2 An TCP Example Here is an example to illustrate the concept of CSA. It is a traffic flow from Sender (the ultimate source or the outbound IPSEC gateway) to Receiver (the ultimate destination or the inbound IPSEC gateway), Zhang draft-zhang-ipsec-mlipsec-00.txt [Page 7] Internet Draft Multi-Layer IPSEC Oct 1999 passing through Gateway (an intermediate router providing diffserv or TCPPEP service). Let's assume the desired security service is ESP transport mode. The corresponding CSA in Sender or Receiver will have the following elements: - zonemap: zone 1 = byte 1-20 zone 2 = byte 21-? : SAD : : : - zonelist: +-----------------------------------+ SA1 (designated) ----------->| sequence number counter | SA2 ---------\ | sequence counter overflow | | | anti-replay window | | | protocol mode = TRANSPORT | | | path mtu | | | lifetime | | | ... | | | encryption algo = DES-CBC | | | encryption key = key1 | | | authentication algo = HMAC-MD5-32 | | | authentication key = key2 | | | ... | | +-----------------------------------+ | : : | : : | +-----------------------------------+ \-------------->| ... | | ... | | lifetime | | ... | | encryption algo = 3DES-CBC | | encryption key = key3 | | authentication algo = HMAC-MD5-96 | | authentication key = key4 | | ... | +-----------------------------------+ : : : : Zhang draft-zhang-ipsec-mlipsec-00.txt [Page 8] Internet Draft Multi-Layer IPSEC Oct 1999 The corresponding CSA in Gateway will have the following elements: - zonemap: zone 1 = byte 1-20 zone 2 = byte 21-? : SAD : : : - zonelist: +-----------------------------------+ SA1 (designated) ----------->| sequence number counter | SA2 ---------\ | sequence counter overflow | | | anti-replay window | | | protocol mode = TRANSPORT | | | path mtu | | | lifetime | | | ... | | | encryption algo = DES-CBC | | | encryption key = key1 | | | authentication algo = HMAC-MD5-32 | | | authentication key = key2 | | | ... | | +-----------------------------------+ | : : | : : \-----> NULL (HMAC-MD5-32 is a hypothetical keyed hash algorithm that produces a smaller 4-octet signature.) 5. AH and ESP Headers The same security protocol formats, AH and ESP, are used in ML-IPSEC. Both AH and ESP have transport mode or tunnel mode, as indicated by the "protocol mode" field of the designated SA. Since the transport mode provides protection primary for 5.1 AH Headers In ML-IPSEC, the protocol header format for AH is almost identical to IPSEC AH (RFC 2402), except that the Authentication Data section in AH can be further subdivided into zones: Zhang draft-zhang-ipsec-mlipsec-00.txt [Page 9] Internet Draft Multi-Layer IPSEC Oct 1999 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data for Zone 1 (variable) | ~ ~ | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | Authentication Data for Zone 2 (variable) | ~ ~ | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | ..... | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The "Authentication Data" field is a variable-length field that contains several Integrity Check Values (ICVs) for this packet. The total length of this field is controlled by "Payload Len". The size of each ICV is determined by the authentication algorithm used in each zonal SA, but must be an integral multiple of 32 bits. The boundaries of these zonal authentication data can be derived from the CSA. 5.2 Integrity Check Value Calculation and Verification The AH ICV calculation is rather different in ML-IPSEC. For the designated zone, the ICV is computed over: - IP header fields that are immutable in transit. - the AH header (Next Header, Payload Len, Reserved, SPI, Sequence Number, and the Authentication Data (which is set to zero for this computation), and explicit padding bytes (if any)) - all octets in the designated zone. For other non-designated zones, the ICV is computed only over the octets of the zone. Using the above example on TCP, here are the datagram before applying AH: Zhang draft-zhang-ipsec-mlipsec-00.txt [Page 10] Internet Draft Multi-Layer IPSEC Oct 1999 ---------------------------- |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- and after applying ML-IPSEC AH transport mode: --------------------------------- |orig IP hdr | | | | |(any options)| AH | TCP | Data | --------------------------------- |<---- authenticated --->| except for mutable fields |<---->| authenticated and after applying ML-IPSEC AH tunnel mode: ------------------------------------------------ | new IP hdr* | | orig IP hdr* | | | |(any options)| AH | (any options) |TCP | Data | ------------------------------------------------ |<----- authenticated except for ------>| | mutable fields in the new IP hdr | |<---->| authenticated On inbound processing, a zone is authenticated only if the corresponding zonal SA is non-null. The ICVs are calculated the same way as described above, and the values are then matched against the ICVs stored in the Authentication Data. In an intermediate node, a packet will go through inbound processing and then outbound processing. If changes are made to the packet in an authorized zone, the ICV is recomputed and stored in a proper place in the Authentication Data field. ICV data of unchanged zones are left untouched. 5.3 ESP Headers ML-IPSEC is perhaps more useful in ESP, where the IP datagram can be encrypted using different keys in different SAs. The following ML- IPSEC ESP header format follows the principle in IPSEC ESP (RFC 2406): Zhang draft-zhang-ipsec-mlipsec-00.txt [Page 11] Internet Draft Multi-Layer IPSEC Oct 1999 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Data for Zone 1 (variable) | ~ ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding (0-255 bytes) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Pad Length | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Data for Zone 2 (variable) | ~ ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding (0-255 bytes) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | | Pad Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ..... | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data for Zone 1 (variable) | ~ ~ | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | Authentication Data for Zone 2 (variable) | ~ ~ | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | ..... | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unlike IPSEC ESP, the Payload Data field in ML-IPSEC ESP are broken into pieces, one for each zone. The Payload Data for each zone, together with Padding, Padding Length, and Next Header field (only in the designed zone), are collectively referred as the ciphertext block for the zone. The size of each ciphertext block can be determined by the CSA, as all zones except the last one are fixed in size. Similar to ML-IPSEC AH, the "Authentication Data" field is a variable-length field that contains several Integrity Check Values (ICVs) for this packet, if authentication has been selected. The Zhang draft-zhang-ipsec-mlipsec-00.txt [Page 12] Internet Draft Multi-Layer IPSEC Oct 1999 size of each ICV is determined by the authentication algorithm used in each zonal SA, but must be an integral multiple of 32 bits. The boundaries of these zonal authentication data can be derived from the CSA. Using the above example on TCP, here are the datagram before applying ESP: ---------------------------- |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- and after applying ML-IPSEC ESP transport mode: ------------------------------------------------------------- |orig IP hdr | ESP | | ESP | ESP | | ESP | ESP| |(any options)| Hdr | TCP |Trailer| Hdr | Data |Trailer|Auth| ------------------------------------------------------------- |<-encrypted->| |<- encrypted ->| |<- authenticated ->|<-- authenticated -->| and after applying ML-IPSEC ESP tunnel mode: --------------------------------------------------------------------------- | new IP hdr | ESP | new IP hdr | | ESP | ESP | | ESP | ESP| |(any options)| Hdr |(any options)| TCP |Trailer| Hdr | Data |Trailer|Auth| --------------------------------------------------------------------------- |<------- encrypted ------->| |<- encrypted ->| |<-------- authenticated -------->|<-- authenticated -->| 5.4 Zone-by-zone Encryption On outbound processing, the sender takes the following steps in packet encryption: Step 1, Zone-wise Encapsulation. For each zone, all octets of all subzones are concatenated (in the order they appear in a datagram) and then encapsulted into the ESP Payload Data field for the corresponding zone. Step 2, Padding. The sender adds any necessary padding to each zone's Payload Data field, to meet encryption algorithm's block size requirement if any, and to align it on a 4-byte boundary. Step 3, Encryption. The sender then encrypts the result plaintext (Payload Data, Padding, Pad Length, and Next Header) using the key, encryption algorithm, algorithm mode indicated by the zonal SA and cryptographic synchronization data (if any). Zhang draft-zhang-ipsec-mlipsec-00.txt [Page 13] Internet Draft Multi-Layer IPSEC Oct 1999 After packet encryption, if authentication is selected, the sender computes the ICV from the ciphertext of each zone. On inbound processing, ML-IPSEC ESP first performs ICV check on a zone-by-zone basis (if authentication is selected). Then, for a zone whose zonal SA is valid and non-null, the receiver decrypts the ESP Payload Data, Padding, Pad Length, and optional Next Header using the key, encryption algorithm, algorithm mode, and cryptographic synchronization data (if any), indicated by the zonal SA. After processing Padding, the receiver then reconstructs the original IP datagram from the original IP header (transport mode) or the tunnel IP header (tunnel mode), plus the IP payload stored in all the Payload fields. In the reverse procedure of encryption, the receiver take Payload Data of a zone and restore the bytes back according to the zonemap. If a zone has a null SA, the bytes corresponding to the zonemap will be left zero. In an intermediate node, a packet will go through inbound processing and then outbound processing. If changes are made to the packet in an authorized zone, the receiver will have to re-encrypt the zone and save the ciphertext back to the corresponding Payload Data field. Disclaimer The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. Author's Address Yongguang Zhang HRL Laboratories, LLC 3011 Malibu Canyon Road Malibu, CA 90265 Phone: (310) 317-5147 EMail: ygz@hrl.com Zhang draft-zhang-ipsec-mlipsec-00.txt [Page 14]