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]