TUBA Working Group K. Robert Glenn (NIST) INTERNET-DRAFT Integrated Network Layer Security Protocol For TUBA (draft-ietf-tuba-inlsp-00.txt) (Posted: May 16, 1994/Expires: November 16, 1994) Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), it's Areas, and it's 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the status of any Internet-Draft, please check the 1id- abstract.txt listing contained in the Internet-Drafts Shadow Direc- tories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. It is intended that this document will be submitted to the IESG for consideration as a standards document. Distribution of this document is unlimited. Abstract This Internet Draft specifies a protocol that may be used by End Sys- tems (ESs) and Intermediate Systems (ISs) in order to provide secu- rity services in support of TUBA. The TUBA deployment and transition plan relies on a dual-stack (i.e., CLNP and IPv4) approach to evolv- ing the Internet to IPng. Thus, to provide secure operation in an TUBA environment this Internet Draft defines a simple Integrated Net- work Layer Security Protocol (I-NLSP) that provides confidentiality and integrity services for both CLNP and IPv4. TUBA systems supporting I-NLSP will be capable of secure operations with: (1) other TUBA/I-NLSP systems using either CLNP or IP, and or (2) exist- ing IPv4 operating behind TUBA/I-NLSP capable secure ISs. Glenn [Page 1] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 Contents Section 1. Introduction.......................................... 3 Section 2. Functional Overview of I-NLSP......................... 4 Section 2.1. ES Mode............................................. 5 Section 2.2. IS Mode............................................. 5 Section 2.3. TCP/UDP Encapsulation/Decapsulation Mode............ 6 Section 2.4. DFP Encapsulation/Decapsulation Mode................ 6 Section 2.5. Security Association................................ 6 Section 3. Security Association Attributes....................... 7 Section 4. Secure Data Transfer PDU Format....................... 9 Section 4.1. SDT PDU Header...................................... 9 Section 4.2. Protected_Octet_String.............................. 10 Section 5. I-NLSP Functional Description......................... 12 Section 5.1. Encapsulation Function.............................. 12 Section 5.1.1. Obtain SA Attributes.............................. 13 Section 5.1.2. Generate SDT PDU Header........................... 14 Section 5.1.3. Apply Encapsulation Mechanisms.................... 14 Section 5.1.4. Forward SDT PDU................................... 15 Section 5.1.5. Complete Encapsulation Diagram.................... 15 Section 5.2. Decapsulation Function.............................. 16 Section 5.2.1. Verify SDT PDU Header and Obtain SA Attributes.... 16 Section 5.2.2. Apply Decapsulation Mechanisms.................... 17 Section 5.2.3. Sink or Forward................................... 17 Section 5.2.4. Decapsulation Diagram............................. 18 Section 6. IPv4 And I-NLSP....................................... 18 Section 6.1. TCP/UDP Encapsulation/Decapsulation Mode............ 18 Section 6.2. DFP Encapsulation/Decapsulation Mode................ 19 Section 7. CLNP And I-NLSP....................................... 20 Section 7.1. TCP/UDP Encapsulation/Decapsulation Mode............ 21 Section 7.2. DFP Encapsulation/Decapsulation Mode................ 22 Appendix A. Policy Mechanisms..................................... 24 Appendix B. Tables................................................ 24 Appendix C. In-Band Security Association Exchange................. 24 References........................................................ 25 Glenn [Page 2] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 1. Introduction The capability for "secure operation" is identified [IPng-Criteria] as a required integral component of any IPng proposal. It is also widely recognized that the evolution to any IPng may be slow and will require IPng to coexist and inter-operate with IPv4 systems for an extended period of time. As such, the security mechanisms of an IPng must address their coexistence and inter-operation with IPv4 systems also. This Internet Draft specifies a protocol that may be used by End Sys- tems (ESs) and Intermediate Systems (ISs) in order to provide secu- rity services in support of TUBA. The TUBA deployment and transition plan relies on a dual-stack (i.e., CLNP and IPv4) approach to evolv- ing the Internet to IPng. Thus, to provide secure operation in an TUBA environment this Internet Draft defines a simple Integrated Net- work Layer Security Protocol (I-NLSP) that provides confidentiality and integrity services for both CLNP and IPv4. TUBA systems support- ing I-NLSP will be capable of secure operations with: (1) other TUBA/I-NLSP systems using either CLNP or IP, and or (2) existing IPv4 operating behind TUBA/I-NLSP capable secure ISs. It should be noted that I-NLSP may be suitable for other, non-TUBA related, scenarios (e.g., implementation and general use in "IPv4 only" and "CLNP only" systems, extensions to support other connec- tionless network protocols). These other applications of I-NLSP are beyond the scope of this document. This Internet Draft specifies the following services: 1. Connectionless Confidentiality: Access to information is restricted to authorized individuals, entities, and processes. Confidentiality is provided by encrypting the information requiring protection. 2. Connectionless Integrity: Information cannot be altered without detection. Integrity is provided by calculating a secured checksum over the information requiring protection. Although the degree of protection afforded by some security services depends on the use of some specific cryptographic techniques, correct operation of this protocol is not dependent on the choice of a par- ticular integrity or confidentiality mechanisms; that is left as a local matter for the communicating systems. Only those ESs and ISs requiring secure communications will be required to alter their existing IP or CLNP implementations. ESs Glenn [Page 3] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 running IPv4 or CLNP without I-NLSP will be able to continue communi- cating with other ESs and ISs running IPv4 or CLNP with or without I-NLSP in a non-protected fashion. ISs with existing implementations of IPv4 or CLNP will not require any changes to be able to forward datagrams protected by I-NLSP. The remainder of this Internet Draft contains a functional descrip- tion of the I-NLSP protocol and it's components. Also included, are Appendices that contain descriptions of local security policy mechan- isms; descriptions and contents of globally known tables to be used by I-NLSP; and an example Key/Security Association Exchange protocol to be used with I-NLSP. 2. Functional Overview of I-NLSP I-NLSP supports the ability to transfer protected or unprotected con- nectionless datagrams between peer DFP ESs and ISs. Protection is defined as the application of one or more of the security services offered by I-NLSP. I-NLSP resides in the Network Layer and is a functional component of the Datagram Forwarding Protocol (DFP) as shown in Figure 1. The term DFP is used throughout this document to generically represent the services offered by either IP or CLNP. TCP/UDP ------------------------------ ^ | v +---------------+ Network | | Layer | DFP + | | I-NLSP | | functions | | | +---------------+ ^ | v ------------------------------ Subnetwork Figure 1: I-NLSP within the Network Layer I-NLSP performs two functions, Encapsulation and Decapsulation. Within the Network Layer, there are two distinct modes of operation Glenn [Page 4] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 for which these functions are performed, ES Mode and IS Mode. Within I-NLSP there are two modes of Encapsulation/Decapsulation, TCP/UDP Encapsulation/Decapsulation Mode and DFP Encapsulation/Decapsulation Mode. The following sections provide an overview of these four modes of operation. 2.1. ES Mode When the DFP receives data from TCP/UDP to be forwarded, local secu- rity policy is checked to determine if I-NLSP security services are required for the destination address. Local security policy dictates whether non-protected communication with the destination is permit- ted. If these services are required, I-NLSP functions are invoked. I-NLSP generates a Secure Data Transfer (SDT) PDU and encapsulates the data within the SDT PDU. The Encapsulation Function applies either integrity, confidentiality, or both depending on local secu- rity policy. The SDT PDU becomes the payload of a DFP datagram and is forwarded towards the peer I-NLSP Entity (I-NLSPE). When the DFP receives data from the subnet, local security policy and the DFP header are checked to determine if I-NLSP security services have been applied. Local security policy dictates whether non- protected communication with the source is permitted. If I-NLSP security services have been applied, I-NLSP functions are invoked. I-NLSP decapsulates the SDT PDU. The Decapsulation Function checks for integrity, confidentiality, or both depending on local security policy. The decapsulated data is then passed to TCP/UDP or treated as a new DFP packet depending on which mode of Encapsulation was used. 2.2. IS Mode When the DFP receives a DFP packet from the subnet to be forwarded, local security policy is checked to determine if I-NLSP security ser- vices are required for the destination address. Local security pol- icy dictates whether non-protected communication with the destination is permitted. If these services are required, I-NLSP functions are invoked. I-NLSP generates a SDT PDU and encapsulates the data within the SDT PDU. The Encapsulation Function applies either integrity, confidentiality, or both depending on local security policy. The SDT PDU becomes the payload of a DFP datagram and is forwarded towards the peer I-NLSPE. When the DFP receives data from the subnet, local security policy and Glenn [Page 5] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 the DFP header are checked to determine if I-NLSP security services have been applied. Local security policy dictates whether non- protected communication with the source is permitted. If I-NLSP security services have been applied, I-NLSP functions are invoked. I-NLSP decapsulates the SDT PDU. The Decapsulation Function checks for integrity, confidentiality, or both depending on local security policy. The decapsulated data is then forwarded toward its final destination. 2.3. TCP/UDP Encapsulation/Decapsulation Mode TCP/UDP Encapsulation/Decapsulation mode dictates that the SDT PDU contains TCP/UDP Data. The remainder of this section explains the cases in which this mode is used. When an ES I-NLSPE is communicating with another ES I-NLSPE, it is preferable for the I-NLSPE to only encapsulate the TCP/UDP data and avoid the overhead generated by the DFP Encapsulation/Decapsulation Mode. IS I-NLSPEs communicating with ES I-NLSPEs could also use this mode but there are problems associated with fragmentation before encapsulation. As a result of these problems it is recommended that ISs always use the DFP Encapsulation/Decapsulation Mode. 2.4. DFP Encapsulation/Decapsulation Mode DFP Encapsulation/Decapsulation mode dictates that the SDT PDU con- tains an entire DFP packet. The remainder of this section explains the cases in which this mode is used. When an I-NLSPE (ES or IS) is communicating with an IS I-NLSPE two destination addresses are required (one to get the DFP packet to the IS and another to get the packet to the destination ES). By encapsu- lating an entire DFP packet, both destination addresses are preserved. Encapsulating the entire DFP packet also preserves frag- mentation information kept in the DFP packet header, allowing the encapsulated data to be reassembled by the peer I-NLSPE. 2.5. Security Association A Security Association(SA) is defined as a relationship between com- municating lower layer entities for which there exists a common set of corresponding attributes. These SA attributes define the Glenn [Page 6] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 particular mechanisms and how they are to be used by I-NLSP to pro- vide security services between peer I-NLSPEs. In order to protect an instance of connectionless communication, an existing suitable SA is used. If no suitable SA exists, one needs to be established between the communicating parties. The Security Association may be esta- blished "out-of-band" or using an "in-band" SA Protocol. A complete SA Protocol is outside the scope of this Internet Draft. A partially defined example is provided in Appendix C. 3. Security Association Attributes The following SA Attributes control the operation of I-NLSP and the mechanisms used to provide protection. The associated values to these attributes shall be set up on SA establishment. The SA Attri- butes are to be stored in some form of database or table, uniquely indexed by DFP destination addresses Security Association Identifiers (SAIDs). The SA Attributes are assumed to be symmetric between the peer I-NLSPEs. Some attributes have recommended default values. I-NLSP is generic by nature and leaves a large number of decisions up to local security policy and implementation. The default values are provided to: sug- gest a minimal set of security services which I-NLSP should provide; aid implementors in providing a core set of functionality in their products that will enable interoperability; and initiate the process of define a globally known table of security algorithms along with their associated attributes. 1. SA Identification: o SAID: Integer of range 0..65535 Coupled with DFP Destination address, uniquely identifies the current SA established with peer I-NLSP entity. Note: Some values have been reserved to identify globally unique SAID values (see Appendix B). 2. DFP Address of peer I-NLSP entity: o Peer_Adr: Address of format specified by DFP. 3. DFP Address of entities served through the remote peer: o Adr_Served: Set of Addresses of format specified by DFP. (Default: Peer_Adr) Glenn [Page 7] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 4. Flags: o Confidentiality: Boolean (Default: false) Flag used to determine if confidentiality is required. o Integrity: Boolean (Default: true) Flag used to determine if integrity is required. 5. ICV mechanism attributes: o ICV_Alg: Object Identifier The value of this attribute shall be an index into an globally known table of security algorithms. This attribute implies certain attributes of the integrity mechanism such as separate generate and check algorithms, initialization vectors, block size, etc. (Default: Index for DES CBC) o ICV_Length: Integer of range 1..8. Specifies the length of the ICV. (Default: 8 octets) o ICV_Gen_Key: length and form defined by ICV_Alg. o ICV_Check_Key: length and form defined by ICV_Alg. (Default: ICV_Gen_Key) 6. Confidentiality Mechanism Attributes: o Enc_Alg: Object Identifier The value of this attribute shall be an index into an globally known table of security algorithms. This attribute implies certain attributes of the confidentiality mechanism such as separate encryption and decryption algorithms, initialization vectors, block size, etc. (Default: Index for DES CBC) o Data_Enc_Key: length and form defined by Enc_Alg. Glenn [Page 8] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 o Data_Dec_Key: length and form defined by Enc_Alg. (Default: Data_Enc_Key) 4. Secure Data Transfer PDU Format All SDT PDUs shall contain an integral number of octets. The format of a Secure Data Transfer PDU shall be as shown in Figure 2. Security services are applied to the SDT PDU such that the integrity mechanism is applied to the SDT PDU Header and portions of the Protected- Octet-String. The confidentiality mechanism is applied to portions of the Protected-Octet-String. +---------+-------------------------+ | Header | Protected_Octet_String | +---------+-------------------------+ Figure 2: Secure Data Transfer PDU Structure 4.1. SDT PDU Header The format of the Header shall be as shown in Figure 3. Bit posi- tions are denoted as integers above the diagram. 1 2 3 0123 4567 8901 2345 6789 0123 4567 8901 +---------+----+----+-------------------+ | Proto |Ver |Flg | Length | +---------+----+----+-------------------+ | SAID | Reserved | +-------------------+-------------------+ Figure 3: SDT PDU Header 1. Proto - This field contains the protocol of the DFP user (TCP/UDP). The length of this field is 8 bits. 2. Ver - This field contains the version number of the protocol represented by this SDT PDU. The length of this field is 4 bits. 3. Flg - This field contains optional flags used by I-NLSP Glenn [Page 9] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 in processing the SDT PDU. The length of this field is 4 bits No values have been idenfied at this time. This field is set to zero when sending and ignored upon receipt. 4. Length - This field contains the length, in octets, of the Protected-Octet-String before the application of the confidentiality mechanism. The length of this field is 16 bits. It is possible for an encryption algorithm to append extra octets to the Protected-Octet-String for its own purposes. The Length field is not modified to reflect this. 5. SAID - The SAID field shall contain the Security Association Identifier used to identify this particular SA. The length of this field is 16 bits. 6. Reserved - This field is reserved for future use. This field is set to zero when sending and ignored upon receipt. 4.2. Protected_Octet_String The Protected_Octet_String field contains the data which has been protected by the I-NLSP security mechanisms. The format of this field, is dependent on which security mechanisms are to be applied. Figure 4 shows the format of the Protected_Octet_String when only Integrity is applied. In this case it is imperative that the ICV mechanism protects the ICV from alteration. When confidentiality is applied, most of the resulting Protected_Octet_String is perceived as a random octet string with no distinguishable characteristics. Figure 5 shows the format of the Protected_Octet_String before confidentiality is applied and integrity is not to be applied. Figure 6 and 7 shows the format of the Protected_Octet_String the application of integrity and confiden- tiality. +-----------+----------+--------+ | Alg_Param | D_Length | Data | +-----------+----------+--------+ | v +-----------+----------+--------+-----+ | Alg_Param | D_Length | Data | ICV | +-----------+----------+--------+-----+ Figure 4. Protected_Octet_String Before and After Integrity. Glenn [Page 10] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 +-----------+----------+--------+------+ | Alg_Param | D_Length | Data | Pad | +-----------+----------+--------+------+ | v +-----------+--------------------------+ | Alg_Param | random octet string | +-----------+--------------------------+ Figure 5. Protected_Octet_String Before and After Confidentiality. +-----------+----------+--------+------+ | Alg_Param | D_Length | Data | Pad | +-----------+----------+--------+------+ | v +-----------+----------+--------+------+-----+ | Alg_Param | D_Length | Data | Pad | ICV | +-----------+----------+--------+------+-----+ | v +-----------+--------------------------------+ | Alg_Param | random octet string | +-----------+--------------------------------+ Figure 6. Protected_Octet_String Before and After Integrity, Before and After Confidentiality. 1. Alg_Param - This field contains information required by the specific integrity and confidentiality algorithms used in protecting the SDT PDU Data (eg., initialization vector). The length and format of this field are defined by the ICV_Alg and Enc_Alg. 2. D_Length - This field contains the length of the SDT PDU Data. The length of this field is two octets. 3. Data - This field contains the data that is to be encapsulated. 4. Pad - This field contains a string of octets with locally defined values. This field is used by the confidentiality mechanism to pad to required lengths. 5. ICV - This field contains the Integrity Check Value (ICV). The length of this field shall be defined by the ICV Length contained in the Security Association attributes. Glenn [Page 11] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 5. I-NLSP Functional Description The following sections describe the functionality of I-NLSP. It is assumed that local security policy and implementation will determine how and when I-NLSP encapsulation is to be applied. Appendix A sug- gests mechanisms to aid the DFP with this decision. For encapsulation, the I-NLSPE determines the security policy and services to be applied to the data; encapsulates the data in the form of a SDT PDU; and forwards to the peer I-NLSPE. For decapsulation, the I-NLSPE determines the security policy and services that were applied to the data; decapsulates the data; and sinks or forwards the data depending on the appropriate mode (ES or IS). Figures 7 and 8 are included to show functional flow and SDT PDU encapsulation. Figures 9 and 10 are included to show functional flow and SDT PDU decapsulation. At many points in the following sections, the I-NLSPE checks that some condition is satisfied. Unless otherwise specified, whenever such a check fails, the I-NLSPE shall discard the DFP data currently being processed. Optionally, the entity may also file an audit/error report. Which failures to be audited is considered to be a local matter. Throughout the following sections, this procedure is known as the error process. 5.1. Encapsulation Function Figure 7 and the associated sections describe in detail the steps required to encapsulate data in a protective envelope. Glenn [Page 12] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 +--------------------------------+ | Obtain SA Attributes | | (Section 5.1.1) | +--------------------------------+ | v +--------------------------------+ | Generate SDT PDU Header | | (Section 5.1.2) | +--------------------------------+ | v +--------------------------------+ | Apply Encapsulation Mechanisms | | (Section 5.1.3) | +--------------------------------+ | v +--------------------------------+ | Forward SDT PDU | | (Section 5.1.4) | +--------------------------------+ Figure 7. Functional Flow of Encapsulation Request 5.1.1. Obtain SA Attributes: 1. I-NLSP shall check that a Security Association has been established between this I-NLSPE and the peer I-NLSPE. The DFP Destination Address is compared against the Adr_Served SA Attribute list. The DFP Destination of the Peer I-NLSPE is then found in the associated Peer_Adr SA attribute. 2. If an association is found and the association does not specify either Integrity or Confidentiality, the data is forwarded normally. Whether or not this is permitted is determined by local security policy. 3. If an association is found and the association does specify either Integrity, Confidentiality, or both, proceed to the next step. 4. If no association is found but an "in-band" SA establishment is supported through a Security Association Protocol (SA-P), attempt to establish a security association with the Destination within a given, locally defined, timeout period is made. If the "in-band" SA establishment is successful, the data is processed as if an association has been discovered. Glenn [Page 13] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 5. If no association is found and a SA cannot be established "in band", I-NLSP will perform the error process described above. 5.1.2. Generate SDT PDU Header 1. Determine Encapsulation Mode (TCP/UDP or DFP). o If the DFP Destination Address is equal to Peer_Adr and the data to be encapsulated is not a fragmented DFP packet, then use TCP/UDP Encapsulation Mode. o If the DFP Destination Address is not equal to Peer_Adr or the data to be encapsulated is a fragmented DFP packet, then use DFP Encapsulation Mode. 2. The Proto field is set to the value appropriate to the Encapsulation Mode. o TCP/UDP for TCP/UDP Encapsulation Mode. o DFP for DFP Encapsulation Mode. 3. The Ver field is set to 0x01. 4. The Flg and reserved fields are set to zero. 5. The SAID is set to the SAID SA Attribute identifying the SA found in section 5.1.1. 6. The Length field is set to D_Length + ICV_Length + 2 (length of D_Length). 5.1.3. Apply Encapsulation Mechanisms Applying encapsulation mechanisms involves ICV generation and data encryption. The Integrity flag SA attribute is used to determine whether an ICV is generated and included in the SDT PDU. The Confi- dentiality flag SA attribute is used to determine whether confiden- tiality is applied to the SDT PDU. The following steps are taken, in order, to generate the complete encapsulated SDT PDU. Errors are processed as described above. 1. If Confidentiality is true, Alg_Param and Pad are added to the SDT PDU as needed. The length of these fields are added to the Length field of the SDT PDU Header. Glenn [Page 14] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 2. If Integrity is true, Alg_Param are added to the SDT PDU as needed. An ICV of length, ICV_Length is generated over the, Alg_Param, D_Length, Data, and Pad, using the ICV algorithm specified by ICV_Alg along with the ICV_Check_Key, If additional padding is required for ICV generation, a pad of zeroes is used. The ICV is appended to the SDT PDU. 3. If Confidentiality is true, the D_Length, Data, Pad, and ICV are encrypted using the confidentiality algorithm specified by Enc_Alg, along with the Data_Enc_Key. 5.1.4. Forward SDT PDU The SDT PDU becomes the payload of a DFP datagram and is forwarded toward the peer I-NLSPE. The DFP Source Address is set to this I- NLSPE DFP Address. The DFP Destination Address is set to the I-NLSPE Peer_Addr. 5.1.5. Complete Encapsulation Diagram +-------------------------------------+ | TCP/UDP Data or DFP Packet | +-------------------------------------+ | | Generate SDT PDU Header V +-----------------------------------------------+ |Pro|Ver|Flgs|Length|SAID|Resv| D_Length | Data | +-----------------------------------------------+ | | Apply Encapsulation Mechanisms V +----------------------------------------------------------+ |Pro|Ver|Flgs|Length|SAID|Resv| Protected_Octet_String | +----------------------------------------------------------+ | | Forward V +-------------------------+ | DFP Header | SDT PDU | +-------------------------+ Figure 8: I-NLSP Encapsulation Glenn [Page 15] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 5.2. Decapsulation Function Figure 9 and the associated sections describe in detail the steps required to decapsulate data from the protective envelope. Errors and mechanism failures are processes as described above. +--------------------------------+ | Verify SDT PDU Header and | | Obtain SA Attributes | | (Section 6.1.1) | +--------------------------------+ | v +--------------------------------+ | Apply Decapsulation Mechanisms | | (Section 6.1.2) | +--------------------------------+ | v +--------------------------------+ | Sink or Forward | | (Section 6.1.3) | +--------------------------------+ Figure 9. Functional Flow of Encapsulation Request 5.2.1. Verify SDT PDU Header and Obtain SA Attributes: 1. The Ver field must be set to 0x01. 2. The Proto field must be set to either TCP/UDP or DFP. 3. I-NLSP shall check that a Security Association has been established between this I-NLSPE and the Peer I-NLSPE. The DFP Source Address is compared with the Peer_Adr SA Attribute and the SAID from the SDT PDU Header is compared to the SAID associated with that Peer_Adr. 4. If an association is found, proceed to the next step. 5. If no association is found the I-NLSPE performs the error process described above. Glenn [Page 16] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 5.2.2. Apply Decapsulation Mechanisms Applying decapsulation mechanisms involves an ICV check and data decryption. The Integrity SA Attribute is used to determine whether an ICV was calculated and placed at the end of the SDT PDU. The Con- fidentiality SA attribute is used to determine whether confidential- ity was applied to the SDT PDU. The following steps are taken to decapsulate the SDT PDU. 1. If Confidentiality is true, decipherment algorithm is applied to the Protected-Octet-String (excluding the Alg_Param field) using the decryption algorithm specified by the Enc_Alg, the Data_Dec_Key, and the parameters specified by the Alg_Param field. 2. If Integrity is true, the portion of the Alg_Param field provided by the Integrity mechanism is removed. The ICV check algorithm is performed on the SDT PDU Header, Alg_Param, D_Length, Data and Pad and Pad fields, using the ICV algorithm specified by ICV_Alg along with the ICV_Check_Key. If additional padding is required for the ICV check, a pad of zeroes is used. 5.2.3. Sink or Forward If the SDT PDU Proto field was set to TCP/UDP the decapsulated data is sent to the TCP/UDP if operating in ES Mode or the data is for- warded if operating in IS Mode. If the SDT PDU Proto field was set to DFP the decapsulated data is processed as a newly received DFP datagram. Glenn [Page 17] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 5.2.4. Decapsulation Diagram +-------------------------+ | DFP Header | SDT PDU | +-------------------------+ | | Verify SDT PDU Header v +-------------------------------------------------------------+ |Pro|Ver|Flgs|Length|SAID|Resv| Protected_Octet_String | +-------------------------------------------------------------+ | | Apply Decapsulation Mechanisms v +-----------------------------------------------------------------+ |Pro|Ver|Flgs|Length|SAID|Resv|Alg_P| D_Length | Data |Pad|ICV| +-----------------------------------------------------------------+ | | Sink or Forward v +--------------------------+ | TCP/UDP or DFP Packet | +--------------------------+ Figure 10: I-NLSP Decapsulation 6. IPv4 And I-NLSP This section contains a functional description of how I-NLSP and IPv4 interoperate with each other. This functionality directly pertains to IPv4 and cannot be described in a more general way. 6.1. TCP/UDP Encapsulation/Decapsulation Mode IPv4 uses the Protocol field that identifies the destination of the IPv4 data. At this time I-NLSP does not have an assigned protocol value. IN-PID is used to temporarily identify I-NLSP. I-NLSP uses the Proto field to identify the final destination of the SDT PDU data. Figure 11 provides an example of how this process works when the SDT PDU Data contains TCP data. In this example the Protocol field of the IPv4 header is set to the protocol value of I-NLSP (IN- PID) and the Proto field of the SDT PDU header is set to the protocol value of TCP (06) [RFC1340]. Glenn [Page 18] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 1 2 3 0123 4567 8901 2345 6789 0123 4567 8901 +----+----+---------+-------------------+ ------------ |Ver |IHL | TOS | Total Length | +-------------------+--+----------------+ | Identifier |Fl| Frag. Offset | +---------+---------+-------------------+ | TTL | Protocol| Header Checksum | IPv4 | | (IN-PID)| | Header +---------+---------+-------------------+ | Source Address | +---------------------------------------+ | Destination Address | +---------------------------------------+ | Options + Padding | +---------+----+----+-------------------+ ----------- | Prot(06)|Ver | Fl | Length | +---------+----+----+-------------------+ SDT PDU | SAID | Reserved | Header +-------------------+-------------------+ ----------- | Alg_Param + D_Length | +-------------------+-------------------+ Protected | TCP | Octet | Data | String +---------------------------------------+ | Pad + ICV | +---------------------------------------+ ----------- Figure 11. Encapsulated TCP Data as Payload of IPv4 6.2. DFP Encapsulation/Decapsulation Mode Figure 12 provides an example of how this process works when the the SDT PDU Data contains an entire IPv4 packet. In this example the Protocol field of the outer most IPv4 header is set to the protocol value of I-NLSP (IN-PID); the Proto field of the SDT PDU header is set to protocol value representing IP-within-IP (94) [RFC1340]; and the Protocol field of the inner most IPv4 header is set to the proto- col value representing TCP (06). Glenn [Page 19] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 1 2 3 0123 4567 8901 2345 6789 0123 4567 8901 +----+----+---------+-------------------+ ------------ |Ver |IHL | TOS | Total Length | +-------------------+--+----------------+ | Identifier |Fl| Frag. Offset | +---------+---------+-------------------+ | TTL | Protocol| Header Checksum | IPv4 | | (IN-PID)| | Header +---------+---------+-------------------+ | Source Address | +---------------------------------------+ | Destination Address | +---------------------------------------+ | Options + Padding | +---------+----+----+-------------------+ ----------- | Prot(94)|Ver | Fl | Length | +---------+----+----+-------------------+ SDT PDU | SAID | Reserved | Header +-------------------+-------------------+ ----------- | Alg_Param + D_Length | +----+----+---------+-------------------+ |Ver |IHL | TOS | Total Length | +-------------------+--+----------------+ | Identifier |Fl| Frag. Offset | +---------+---------+-------------------+ | TTL | Protocol| Header Checksum | Protected | | (06) | | Octet +---------+---------+-------------------+ String | Source Address | +---------------------------------------+ | Destination Address | +---------------------------------------+ | Options + Padding | +---------------------------------------+ | TCP | | Data | +---------------------------------------+ | Pad + ICV | +---------------------------------------+ ----------- Figure 12. Encapsulated IPv4 Packet as Payload of IPv4 7. CLNP And I-NLSP Glenn [Page 20] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 This section contains a functional description of how I-NLSP and CLNP interoperate. This functionality directly pertains to CLNP and can- not be described in a more general way. 7.1. TCP/UDP Encapsulation/Decapsulation Mode CLNP uses the N-SEL portion of the Destination Address to identify the destination of the CLNP data. I-NLSP uses the Proto field to identify the final destination of the SDT PDU Data. Figure 13 pro- vides an example of how this process works when the SDT PDU Data con- tains TCP data. In this example the N-SEL portion of the CLNP Desti- nation Address is set to the protocol value of I-NLSP (IN-PID) and the Protocol field of the SDT PDU is set to the protocol value of TCP (06). Some of the following fields do not necessarily end on a 32bit boundary. A more complete description of the CLNP header can be found in [ISO8473], but is not required for this discussion. Glenn [Page 21] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 1 2 3 0123 4567 8901 2345 6789 0123 4567 8901 +----+----+---------+-------------------+ ------------ | PID | LI | Ver |Life Time| +-------------------+-------------------+ |FL| Type | Segment Length | Check- | +---------+---------+-------------------+ | sum | DA Len | Destination | +---------+---------+ | | Address (NSEL=IN-PID) | CLNP +---------+-----------------------------+ Header | SA Len | Source | +---------+ | | Address | +-------------------+-------------------+ | Data Unit ID | Segment Offset | +-------------------+-------------------+ | Total Length | Options | +-------------------+ | | | +-------------------+-------------------+ ----------- | Prot(06)|Ver | Fl | Length | +---------+----+----+-------------------+ SDT PDU | SAID | Reserved | Header +-------------------+-------------------+ ----------- | Alg_Param + D_Length | +-------------------+-------------------+ Protected | TCP | Octet | Data | String +---------------------------------------+ | Pad + ICV | +---------------------------------------+ ----------- Figure 9. Encapsulated TCP Data as Payload of CLNP 7.2. DFP Encapsulation/Decapsulation Mode Figure 14 provides an example of how this process works when the SDT PDU Data contains an entire CLNP PDU. In this example the N-SEL of the Destination Address of the outer most CLNP header is set to the protocol value of I-NLSP (IN-PID); the Prot field of the SDT PDU header is set to protocol value representing CLNP (129) [ISO8473]; and the N-SEL of the Destination Address of the inner most CLNP header is set to the protocol value representing TCP (06). Glenn [Page 22] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 1 2 3 0123 4567 8901 2345 6789 0123 4567 8901 +----+----+---------+-------------------+ ------------ | PID | LI | Ver |Life Time| +-------------------+-------------------+ |FL| Type | Segment Length | Check- | +---------+---------+-------------------+ | sum | DA Len | Destination | +---------+---------+ | | Address (NSEL=IN-PID) | CLNP +---------+-----------------------------+ Header | SA Len | Source | +---------+ | | Address | +-------------------+-------------------+ | Data Unit ID | Segment Offset | +-------------------+-------------------+ | Total Length | Options | +-------------------+ | | | +-------------------+-------------------+ ----------- |Prot(129)|Ver | Fl | Length | +---------+----+----+-------------------+ SDT PDU | SAID | Reserved | Header +-------------------+-------------------+ ----------- | Alg_Param + D_Length | +----+----+---------+-------------------+ | PID | LI | Ver |Life Time| +-------------------+-------------------+ |FL| Type | Segment Length | Check- | +---------+---------+-------------------+ | sum | DA Len | Destination | +---------+---------+ | Protected | Address (NSEL=06) | Octet +---------+-----------------------------+ String | SA Len | Source | +---------+ | | Address | +-------------------+-------------------+ | Data Unit ID | Segment Offset | +-------------------+-------------------+ | Total Length | Options | +-------------------+ | | | +---------------------------------------+ | TCP | | Data | +---------------------------------------+ | Pad + ICV | +---------------------------------------+ ----------- Glenn [Page 23] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 Figure 10. Encapsulated CLNP Packet as Payload of CLNP A. Policy Mechanisms This section describes filters and flags used locally to help the DFP determine how and when I-NLSP security services are required. o Protected_Mode: Boolean (Default: false) Flag used to determine whether unprotected DFP packets are permitted. o Destination_Filter: Set of DFP Addresses Set of DFP Destination addresses which this I-NLSPE is not permitted to send unprotected DFP packets. o Source_Filter: Set of DFP Addresses Set of DFP Source addresses for which this I-NLSPE will provide I-NLSP services. B. Tables [Initial suggested values for reserved SAID values, Alg_IDs, etc.]. (TBD) C. In-Band Security Association Exchange [Initial description of a Security Association Exchange protocol using the Diffie-Helman algorithm. This section could potentially point to another Internet Draft on this subject]. (TBD) Glenn [Page 24] INTERNET DRAFT May 16, 1994 Expires November 16, 1994 References [IPSEC] On-going Deliberations of the IETF IPSEC WG. [IPng-Criteria] F. Kastenholz, C. Partridge, "Technical Criteria for Choosing IP:The Next Generation (IPng), Internet Draft, March 1994. [ISO8473] ISO/IEC. Information Processing Systems - Data communications for providing the Connectionless-mode Network Service. ISO/IEC, 1988. [ISO11577] ISO/IEC. Information technology - telecommunications and information exchange between systems - network layer security protocol. International Standard 11577, ISO/IEC JTC 1, USA, December 1993. [RFC1340] J. Reynolds, J. Postel, "Assigned Numbers", Internet RFC 1340 June 1992. [RFC1347] R. Callon, "TCP and UDP with Bigger Addresses (TUBA), A Proposal for Internet Addressing and Routing", Internet RFC 1347, June 1992. [Stallings] William Stallings, Data and Computer Communication, Macmillan Publishing Company, Second Edition, 1988 Glenn [Page 25]