idnits 2.17.1 draft-ietf-tuba-inlsp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-tuba-inlsp-00.txt)', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-tuba-inlsp-00.txt)', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-tuba-inlsp-00.txt)', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-tuba-inlsp-00.txt)', but the file name used is 'draft-ietf-tuba-inlsp-00' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 23 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 16 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 190 has weird spacing: '...payload of a ...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IPSEC' is defined on line 1007, but no explicit reference was found in the text == Unused Reference: 'ISO11577' is defined on line 1017, but no explicit reference was found in the text == Unused Reference: 'RFC1347' is defined on line 1025, but no explicit reference was found in the text == Unused Reference: 'Stallings' is defined on line 1029, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPng-Criteria' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO8473' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO11577' ** Obsolete normative reference: RFC 1340 (Obsoleted by RFC 1700) ** Downref: Normative reference to an Historic RFC: RFC 1347 -- Possible downref: Non-RFC (?) normative reference: ref. 'Stallings' Summary: 16 errors (**), 1 flaw (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TUBA Working Group K. Robert Glenn (NIST) 2 INTERNET-DRAFT 4 Integrated Network Layer Security Protocol 5 For TUBA 7 (draft-ietf-tuba-inlsp-00.txt) 9 (Posted: May 16, 1994/Expires: November 16, 1994) 11 Status of This Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), it's Areas, 15 and it's Working Groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months. Internet-Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet- 21 Drafts as reference material or to cite them other than as a "working 22 draft" or "work in progress." 24 To learn the status of any Internet-Draft, please check the 1id- 25 abstract.txt listing contained in the Internet-Drafts Shadow Direc- 26 tories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, 27 or munnari.oz.au. 29 It is intended that this document will be submitted to the IESG for 30 consideration as a standards document. Distribution of this document 31 is unlimited. 33 Abstract 35 This Internet Draft specifies a protocol that may be used by End Sys- 36 tems (ESs) and Intermediate Systems (ISs) in order to provide secu- 37 rity services in support of TUBA. The TUBA deployment and transition 38 plan relies on a dual-stack (i.e., CLNP and IPv4) approach to evolv- 39 ing the Internet to IPng. Thus, to provide secure operation in an 40 TUBA environment this Internet Draft defines a simple Integrated Net- 41 work Layer Security Protocol (I-NLSP) that provides confidentiality 42 and integrity services for both CLNP and IPv4. TUBA systems 43 supporting I-NLSP will be capable of secure operations with: (1) 44 other TUBA/I-NLSP systems using either CLNP or IP, and or (2) exist- 45 ing IPv4 operating behind TUBA/I-NLSP capable secure ISs. 47 Contents 49 Section 1. Introduction.......................................... 3 50 Section 2. Functional Overview of I-NLSP......................... 4 51 Section 2.1. ES Mode............................................. 5 52 Section 2.2. IS Mode............................................. 5 53 Section 2.3. TCP/UDP Encapsulation/Decapsulation Mode............ 6 54 Section 2.4. DFP Encapsulation/Decapsulation Mode................ 6 55 Section 2.5. Security Association................................ 6 56 Section 3. Security Association Attributes....................... 7 57 Section 4. Secure Data Transfer PDU Format....................... 9 58 Section 4.1. SDT PDU Header...................................... 9 59 Section 4.2. Protected_Octet_String.............................. 10 60 Section 5. I-NLSP Functional Description......................... 12 61 Section 5.1. Encapsulation Function.............................. 12 62 Section 5.1.1. Obtain SA Attributes.............................. 13 63 Section 5.1.2. Generate SDT PDU Header........................... 14 64 Section 5.1.3. Apply Encapsulation Mechanisms.................... 14 65 Section 5.1.4. Forward SDT PDU................................... 15 66 Section 5.1.5. Complete Encapsulation Diagram.................... 15 67 Section 5.2. Decapsulation Function.............................. 16 68 Section 5.2.1. Verify SDT PDU Header and Obtain SA Attributes.... 16 69 Section 5.2.2. Apply Decapsulation Mechanisms.................... 17 70 Section 5.2.3. Sink or Forward................................... 17 71 Section 5.2.4. Decapsulation Diagram............................. 18 72 Section 6. IPv4 And I-NLSP....................................... 18 73 Section 6.1. TCP/UDP Encapsulation/Decapsulation Mode............ 18 74 Section 6.2. DFP Encapsulation/Decapsulation Mode................ 19 75 Section 7. CLNP And I-NLSP....................................... 20 76 Section 7.1. TCP/UDP Encapsulation/Decapsulation Mode............ 21 77 Section 7.2. DFP Encapsulation/Decapsulation Mode................ 22 78 Appendix A. Policy Mechanisms..................................... 24 79 Appendix B. Tables................................................ 24 80 Appendix C. In-Band Security Association Exchange................. 24 81 References........................................................ 25 82 1. Introduction 84 The capability for "secure operation" is identified [IPng-Criteria] 85 as a required integral component of any IPng proposal. It is also 86 widely recognized that the evolution to any IPng may be slow and will 87 require IPng to coexist and inter-operate with IPv4 systems for an 88 extended period of time. As such, the security mechanisms of an IPng 89 must address their coexistence and inter-operation with IPv4 systems 90 also. 92 This Internet Draft specifies a protocol that may be used by End Sys- 93 tems (ESs) and Intermediate Systems (ISs) in order to provide secu- 94 rity services in support of TUBA. The TUBA deployment and transition 95 plan relies on a dual-stack (i.e., CLNP and IPv4) approach to evolv- 96 ing the Internet to IPng. Thus, to provide secure operation in an 97 TUBA environment this Internet Draft defines a simple Integrated Net- 98 work Layer Security Protocol (I-NLSP) that provides confidentiality 99 and integrity services for both CLNP and IPv4. TUBA systems support- 100 ing I-NLSP will be capable of secure operations with: (1) other 101 TUBA/I-NLSP systems using either CLNP or IP, and or (2) existing IPv4 102 operating behind TUBA/I-NLSP capable secure ISs. 104 It should be noted that I-NLSP may be suitable for other, non-TUBA 105 related, scenarios (e.g., implementation and general use in "IPv4 106 only" and "CLNP only" systems, extensions to support other connec- 107 tionless network protocols). These other applications of I-NLSP are 108 beyond the scope of this document. 110 This Internet Draft specifies the following services: 112 1. Connectionless Confidentiality: Access to information is 113 restricted to authorized individuals, entities, and processes. 114 Confidentiality is provided by encrypting the information 115 requiring protection. 117 2. Connectionless Integrity: Information cannot be altered without 118 detection. Integrity is provided by calculating a secured checksum 119 over the information requiring protection. 121 Although the degree of protection afforded by some security services 122 depends on the use of some specific cryptographic techniques, correct 123 operation of this protocol is not dependent on the choice of a par- 124 ticular integrity or confidentiality mechanisms; that is left as a 125 local matter for the communicating systems. 127 Only those ESs and ISs requiring secure communications will be 128 required to alter their existing IP or CLNP implementations. ESs 129 running IPv4 or CLNP without I-NLSP will be able to continue communi- 130 cating with other ESs and ISs running IPv4 or CLNP with or without 131 I-NLSP in a non-protected fashion. ISs with existing implementations 132 of IPv4 or CLNP will not require any changes to be able to forward 133 datagrams protected by I-NLSP. 135 The remainder of this Internet Draft contains a functional descrip- 136 tion of the I-NLSP protocol and it's components. Also included, are 137 Appendices that contain descriptions of local security policy mechan- 138 isms; descriptions and contents of globally known tables to be used 139 by I-NLSP; and an example Key/Security Association Exchange protocol 140 to be used with I-NLSP. 142 2. Functional Overview of I-NLSP 144 I-NLSP supports the ability to transfer protected or unprotected con- 145 nectionless datagrams between peer DFP ESs and ISs. Protection is 146 defined as the application of one or more of the security services 147 offered by I-NLSP. I-NLSP resides in the Network Layer and is a 148 functional component of the Datagram Forwarding Protocol (DFP) as 149 shown in Figure 1. The term DFP is used throughout this document to 150 generically represent the services offered by either IP or CLNP. 152 TCP/UDP 153 ------------------------------ 154 ^ 155 | 156 v 157 +---------------+ 158 Network | | 159 Layer | DFP + | 160 | I-NLSP | 161 | functions | 162 | | 163 +---------------+ 164 ^ 165 | 166 v 167 ------------------------------ 168 Subnetwork 170 Figure 1: I-NLSP within the Network Layer 172 I-NLSP performs two functions, Encapsulation and Decapsulation. 173 Within the Network Layer, there are two distinct modes of operation 174 for which these functions are performed, ES Mode and IS Mode. Within 175 I-NLSP there are two modes of Encapsulation/Decapsulation, TCP/UDP 176 Encapsulation/Decapsulation Mode and DFP Encapsulation/Decapsulation 177 Mode. The following sections provide an overview of these four modes 178 of operation. 180 2.1. ES Mode 182 When the DFP receives data from TCP/UDP to be forwarded, local secu- 183 rity policy is checked to determine if I-NLSP security services are 184 required for the destination address. Local security policy dictates 185 whether non-protected communication with the destination is permit- 186 ted. If these services are required, I-NLSP functions are invoked. 187 I-NLSP generates a Secure Data Transfer (SDT) PDU and encapsulates 188 the data within the SDT PDU. The Encapsulation Function applies 189 either integrity, confidentiality, or both depending on local secu- 190 rity policy. The SDT PDU becomes the payload of a DFP datagram and 191 is forwarded towards the peer I-NLSP Entity (I-NLSPE). 193 When the DFP receives data from the subnet, local security policy and 194 the DFP header are checked to determine if I-NLSP security services 195 have been applied. Local security policy dictates whether non- 196 protected communication with the source is permitted. If I-NLSP 197 security services have been applied, I-NLSP functions are invoked. 198 I-NLSP decapsulates the SDT PDU. The Decapsulation Function checks 199 for integrity, confidentiality, or both depending on local security 200 policy. The decapsulated data is then passed to TCP/UDP or treated 201 as a new DFP packet depending on which mode of Encapsulation was 202 used. 204 2.2. IS Mode 206 When the DFP receives a DFP packet from the subnet to be forwarded, 207 local security policy is checked to determine if I-NLSP security ser- 208 vices are required for the destination address. Local security pol- 209 icy dictates whether non-protected communication with the destination 210 is permitted. If these services are required, I-NLSP functions are 211 invoked. I-NLSP generates a SDT PDU and encapsulates the data within 212 the SDT PDU. The Encapsulation Function applies either integrity, 213 confidentiality, or both depending on local security policy. The SDT 214 PDU becomes the payload of a DFP datagram and is forwarded towards 215 the peer I-NLSPE. 217 When the DFP receives data from the subnet, local security policy and 218 the DFP header are checked to determine if I-NLSP security services 219 have been applied. Local security policy dictates whether non- 220 protected communication with the source is permitted. If I-NLSP 221 security services have been applied, I-NLSP functions are invoked. 222 I-NLSP decapsulates the SDT PDU. The Decapsulation Function checks 223 for integrity, confidentiality, or both depending on local security 224 policy. The decapsulated data is then forwarded toward its final 225 destination. 227 2.3. TCP/UDP Encapsulation/Decapsulation Mode 229 TCP/UDP Encapsulation/Decapsulation mode dictates that the SDT PDU 230 contains TCP/UDP Data. The remainder of this section explains the 231 cases in which this mode is used. 233 When an ES I-NLSPE is communicating with another ES I-NLSPE, it is 234 preferable for the I-NLSPE to only encapsulate the TCP/UDP data and 235 avoid the overhead generated by the DFP Encapsulation/Decapsulation 236 Mode. IS I-NLSPEs communicating with ES I-NLSPEs could also use this 237 mode but there are problems associated with fragmentation before 238 encapsulation. As a result of these problems it is recommended that 239 ISs always use the DFP Encapsulation/Decapsulation Mode. 241 2.4. DFP Encapsulation/Decapsulation Mode 243 DFP Encapsulation/Decapsulation mode dictates that the SDT PDU con- 244 tains an entire DFP packet. The remainder of this section explains 245 the cases in which this mode is used. 247 When an I-NLSPE (ES or IS) is communicating with an IS I-NLSPE two 248 destination addresses are required (one to get the DFP packet to the 249 IS and another to get the packet to the destination ES). By encapsu- 250 lating an entire DFP packet, both destination addresses are 251 preserved. Encapsulating the entire DFP packet also preserves frag- 252 mentation information kept in the DFP packet header, allowing the 253 encapsulated data to be reassembled by the peer I-NLSPE. 255 2.5. Security Association 257 A Security Association(SA) is defined as a relationship between com- 258 municating lower layer entities for which there exists a common set 259 of corresponding attributes. These SA attributes define the 260 particular mechanisms and how they are to be used by I-NLSP to pro- 261 vide security services between peer I-NLSPEs. In order to protect an 262 instance of connectionless communication, an existing suitable SA is 263 used. If no suitable SA exists, one needs to be established between 264 the communicating parties. The Security Association may be esta- 265 blished "out-of-band" or using an "in-band" SA Protocol. A complete 266 SA Protocol is outside the scope of this Internet Draft. A partially 267 defined example is provided in Appendix C. 269 3. Security Association Attributes 271 The following SA Attributes control the operation of I-NLSP and the 272 mechanisms used to provide protection. The associated values to 273 these attributes shall be set up on SA establishment. The SA Attri- 274 butes are to be stored in some form of database or table, uniquely 275 indexed by DFP destination addresses Security Association Identifiers 276 (SAIDs). The SA Attributes are assumed to be symmetric between the 277 peer I-NLSPEs. 279 Some attributes have recommended default values. I-NLSP is generic 280 by nature and leaves a large number of decisions up to local security 281 policy and implementation. The default values are provided to: sug- 282 gest a minimal set of security services which I-NLSP should provide; 283 aid implementors in providing a core set of functionality in their 284 products that will enable interoperability; and initiate the process 285 of define a globally known table of security algorithms along with 286 their associated attributes. 288 1. SA Identification: 290 o SAID: Integer of range 0..65535 292 Coupled with DFP Destination address, uniquely identifies 293 the current SA established with peer I-NLSP entity. 295 Note: Some values have been reserved to identify globally 296 unique SAID values (see Appendix B). 298 2. DFP Address of peer I-NLSP entity: 300 o Peer_Adr: Address of format specified by DFP. 302 3. DFP Address of entities served through the remote peer: 304 o Adr_Served: Set of Addresses of format specified by DFP. 305 (Default: Peer_Adr) 306 4. Flags: 308 o Confidentiality: Boolean (Default: false) 310 Flag used to determine if confidentiality is required. 312 o Integrity: Boolean (Default: true) 314 Flag used to determine if integrity is required. 316 5. ICV mechanism attributes: 318 o ICV_Alg: Object Identifier 320 The value of this attribute shall be an index into an globally 321 known table of security algorithms. This attribute implies 322 certain attributes of the integrity mechanism such as separate 323 generate and check algorithms, initialization vectors, block 324 size, etc. 326 (Default: Index for DES CBC) 328 o ICV_Length: Integer of range 1..8. 330 Specifies the length of the ICV. 332 (Default: 8 octets) 334 o ICV_Gen_Key: length and form defined by ICV_Alg. 336 o ICV_Check_Key: length and form defined by ICV_Alg. 338 (Default: ICV_Gen_Key) 340 6. Confidentiality Mechanism Attributes: 342 o Enc_Alg: Object Identifier 344 The value of this attribute shall be an index into an globally 345 known table of security algorithms. This attribute implies 346 certain attributes of the confidentiality mechanism such as 347 separate encryption and decryption algorithms, initialization 348 vectors, block size, etc. 350 (Default: Index for DES CBC) 352 o Data_Enc_Key: length and form defined by Enc_Alg. 354 o Data_Dec_Key: length and form defined by Enc_Alg. 356 (Default: Data_Enc_Key) 358 4. Secure Data Transfer PDU Format 360 All SDT PDUs shall contain an integral number of octets. The format 361 of a Secure Data Transfer PDU shall be as shown in Figure 2. Security 362 services are applied to the SDT PDU such that the integrity mechanism 363 is applied to the SDT PDU Header and portions of the Protected- 364 Octet-String. The confidentiality mechanism is applied to portions 365 of the Protected-Octet-String. 367 +---------+-------------------------+ 368 | Header | Protected_Octet_String | 369 +---------+-------------------------+ 371 Figure 2: Secure Data Transfer PDU Structure 373 4.1. SDT PDU Header 375 The format of the Header shall be as shown in Figure 3. Bit posi- 376 tions are denoted as integers above the diagram. 378 1 2 3 379 0123 4567 8901 2345 6789 0123 4567 8901 380 +---------+----+----+-------------------+ 381 | Proto |Ver |Flg | Length | 382 +---------+----+----+-------------------+ 383 | SAID | Reserved | 384 +-------------------+-------------------+ 386 Figure 3: SDT PDU Header 388 1. Proto - This field contains the protocol of the DFP user 389 (TCP/UDP). The length of this field is 8 bits. 391 2. Ver - This field contains the version number of the protocol 392 represented by this SDT PDU. The length of this field 393 is 4 bits. 395 3. Flg - This field contains optional flags used by I-NLSP 396 in processing the SDT PDU. The length of this field is 4 bits 397 No values have been idenfied at this time. This field 398 is set to zero when sending and ignored upon receipt. 400 4. Length - This field contains the length, in octets, of the 401 Protected-Octet-String before the application of the confidentiality 402 mechanism. The length of this field is 16 bits. It is possible for 403 an encryption algorithm to append extra octets to the 404 Protected-Octet-String for its own purposes. The Length field 405 is not modified to reflect this. 407 5. SAID - The SAID field shall contain the Security Association 408 Identifier used to identify this particular SA. The length of 409 this field is 16 bits. 411 6. Reserved - This field is reserved for future use. This field 412 is set to zero when sending and ignored upon receipt. 414 4.2. Protected_Octet_String 416 The Protected_Octet_String field contains the data which has been 417 protected by the I-NLSP security mechanisms. The format of this 418 field, is dependent on which security mechanisms are to be applied. 419 Figure 4 shows the format of the Protected_Octet_String when only 420 Integrity is applied. In this case it is imperative that the ICV 421 mechanism protects the ICV from alteration. 423 When confidentiality is applied, most of the resulting 424 Protected_Octet_String is perceived as a random octet string with no 425 distinguishable characteristics. Figure 5 shows the format of the 426 Protected_Octet_String before confidentiality is applied and 427 integrity is not to be applied. Figure 6 and 7 shows the format of 428 the Protected_Octet_String the application of integrity and confiden- 429 tiality. 431 +-----------+----------+--------+ 432 | Alg_Param | D_Length | Data | 433 +-----------+----------+--------+ 434 | 435 v 436 +-----------+----------+--------+-----+ 437 | Alg_Param | D_Length | Data | ICV | 438 +-----------+----------+--------+-----+ 440 Figure 4. Protected_Octet_String Before and After Integrity. 442 +-----------+----------+--------+------+ 443 | Alg_Param | D_Length | Data | Pad | 444 +-----------+----------+--------+------+ 445 | 446 v 447 +-----------+--------------------------+ 448 | Alg_Param | random octet string | 449 +-----------+--------------------------+ 451 Figure 5. Protected_Octet_String Before and After Confidentiality. 453 +-----------+----------+--------+------+ 454 | Alg_Param | D_Length | Data | Pad | 455 +-----------+----------+--------+------+ 456 | 457 v 458 +-----------+----------+--------+------+-----+ 459 | Alg_Param | D_Length | Data | Pad | ICV | 460 +-----------+----------+--------+------+-----+ 461 | 462 v 463 +-----------+--------------------------------+ 464 | Alg_Param | random octet string | 465 +-----------+--------------------------------+ 467 Figure 6. Protected_Octet_String Before and After Integrity, 468 Before and After Confidentiality. 470 1. Alg_Param - This field contains information required by the 471 specific integrity and confidentiality algorithms used in 472 protecting the SDT PDU Data (eg., initialization vector). The 473 length and format of this field are defined by the ICV_Alg and 474 Enc_Alg. 476 2. D_Length - This field contains the length of the SDT PDU Data. 477 The length of this field is two octets. 479 3. Data - This field contains the data that is to be encapsulated. 481 4. Pad - This field contains a string of octets with locally defined 482 values. This field is used by the confidentiality mechanism to 483 pad to required lengths. 485 5. ICV - This field contains the Integrity Check Value (ICV). 486 The length of this field shall be defined by the ICV 487 Length contained in the Security Association attributes. 489 5. I-NLSP Functional Description 491 The following sections describe the functionality of I-NLSP. It is 492 assumed that local security policy and implementation will determine 493 how and when I-NLSP encapsulation is to be applied. Appendix A sug- 494 gests mechanisms to aid the DFP with this decision. 496 For encapsulation, the I-NLSPE determines the security policy and 497 services to be applied to the data; encapsulates the data in the form 498 of a SDT PDU; and forwards to the peer I-NLSPE. For decapsulation, 499 the I-NLSPE determines the security policy and services that were 500 applied to the data; decapsulates the data; and sinks or forwards 501 the data depending on the appropriate mode (ES or IS). Figures 7 and 502 8 are included to show functional flow and SDT PDU encapsulation. 503 Figures 9 and 10 are included to show functional flow and SDT PDU 504 decapsulation. 506 At many points in the following sections, the I-NLSPE checks that 507 some condition is satisfied. Unless otherwise specified, whenever 508 such a check fails, the I-NLSPE shall discard the DFP data currently 509 being processed. Optionally, the entity may also file an audit/error 510 report. Which failures to be audited is considered to be a local 511 matter. Throughout the following sections, this procedure is known 512 as the error process. 514 5.1. Encapsulation Function 516 Figure 7 and the associated sections describe in detail the steps 517 required to encapsulate data in a protective envelope. 519 +--------------------------------+ 520 | Obtain SA Attributes | 521 | (Section 5.1.1) | 522 +--------------------------------+ 523 | 524 v 525 +--------------------------------+ 526 | Generate SDT PDU Header | 527 | (Section 5.1.2) | 528 +--------------------------------+ 529 | 530 v 531 +--------------------------------+ 532 | Apply Encapsulation Mechanisms | 533 | (Section 5.1.3) | 534 +--------------------------------+ 535 | 536 v 537 +--------------------------------+ 538 | Forward SDT PDU | 539 | (Section 5.1.4) | 540 +--------------------------------+ 542 Figure 7. Functional Flow of Encapsulation Request 544 5.1.1. Obtain SA Attributes: 546 1. I-NLSP shall check that a Security Association has been established 547 between this I-NLSPE and the peer I-NLSPE. The DFP Destination 548 Address is compared against the Adr_Served SA Attribute list. The 549 DFP Destination of the Peer I-NLSPE is then found in the associated 550 Peer_Adr SA attribute. 552 2. If an association is found and the association does not specify 553 either Integrity or Confidentiality, the data is forwarded normally. 554 Whether or not this is permitted is determined by local security 555 policy. 557 3. If an association is found and the association does specify either 558 Integrity, Confidentiality, or both, proceed to the next step. 560 4. If no association is found but an "in-band" SA establishment is 561 supported through a Security Association Protocol (SA-P), attempt 562 to establish a security association with the Destination within a 563 given, locally defined, timeout period is made. If the "in-band" 564 SA establishment is successful, the data is processed as 565 if an association has been discovered. 567 5. If no association is found and a SA cannot be established 568 "in band", I-NLSP will perform the error process described above. 570 5.1.2. Generate SDT PDU Header 572 1. Determine Encapsulation Mode (TCP/UDP or DFP). 574 o If the DFP Destination Address is equal to Peer_Adr and 575 the data to be encapsulated is not a fragmented DFP packet, then 576 use TCP/UDP Encapsulation Mode. 578 o If the DFP Destination Address is not equal to Peer_Adr or 579 the data to be encapsulated is a fragmented DFP packet, then 580 use DFP Encapsulation Mode. 582 2. The Proto field is set to the value appropriate to the Encapsulation 583 Mode. 585 o TCP/UDP for TCP/UDP Encapsulation Mode. 587 o DFP for DFP Encapsulation Mode. 589 3. The Ver field is set to 0x01. 591 4. The Flg and reserved fields are set to zero. 593 5. The SAID is set to the SAID SA Attribute identifying the SA found 594 in section 5.1.1. 596 6. The Length field is set to D_Length + ICV_Length + 2 (length 597 of D_Length). 599 5.1.3. Apply Encapsulation Mechanisms 601 Applying encapsulation mechanisms involves ICV generation and data 602 encryption. The Integrity flag SA attribute is used to determine 603 whether an ICV is generated and included in the SDT PDU. The Confi- 604 dentiality flag SA attribute is used to determine whether confiden- 605 tiality is applied to the SDT PDU. The following steps are taken, in 606 order, to generate the complete encapsulated SDT PDU. Errors are 607 processed as described above. 609 1. If Confidentiality is true, Alg_Param and Pad are 610 added to the SDT PDU as needed. The length of these fields 611 are added to the Length field of the SDT PDU Header. 613 2. If Integrity is true, Alg_Param are added to the SDT PDU as needed. 614 An ICV of length, ICV_Length is generated over the, Alg_Param, 615 D_Length, Data, and Pad, using the ICV algorithm specified by 616 ICV_Alg along with the ICV_Check_Key, If additional padding is 617 required for ICV generation, a pad of zeroes is used. The ICV is 618 appended to the SDT PDU. 620 3. If Confidentiality is true, the D_Length, Data, 621 Pad, and ICV are encrypted using the confidentiality algorithm 622 specified by Enc_Alg, along with the Data_Enc_Key. 624 5.1.4. Forward SDT PDU 626 The SDT PDU becomes the payload of a DFP datagram and is forwarded 627 toward the peer I-NLSPE. The DFP Source Address is set to this I- 628 NLSPE DFP Address. The DFP Destination Address is set to the I-NLSPE 629 Peer_Addr. 631 5.1.5. Complete Encapsulation Diagram 633 +-------------------------------------+ 634 | TCP/UDP Data or DFP Packet | 635 +-------------------------------------+ 636 | 637 | Generate SDT PDU Header 638 V 639 +-----------------------------------------------+ 640 |Pro|Ver|Flgs|Length|SAID|Resv| D_Length | Data | 641 +-----------------------------------------------+ 642 | 643 | Apply Encapsulation Mechanisms 644 V 645 +----------------------------------------------------------+ 646 |Pro|Ver|Flgs|Length|SAID|Resv| Protected_Octet_String | 647 +----------------------------------------------------------+ 648 | 649 | Forward 650 V 651 +-------------------------+ 652 | DFP Header | SDT PDU | 653 +-------------------------+ 655 Figure 8: I-NLSP Encapsulation 656 5.2. Decapsulation Function 658 Figure 9 and the associated sections describe in detail the steps 659 required to decapsulate data from the protective envelope. Errors 660 and mechanism failures are processes as described above. 662 +--------------------------------+ 663 | Verify SDT PDU Header and | 664 | Obtain SA Attributes | 665 | (Section 6.1.1) | 666 +--------------------------------+ 667 | 668 v 669 +--------------------------------+ 670 | Apply Decapsulation Mechanisms | 671 | (Section 6.1.2) | 672 +--------------------------------+ 673 | 674 v 675 +--------------------------------+ 676 | Sink or Forward | 677 | (Section 6.1.3) | 678 +--------------------------------+ 680 Figure 9. Functional Flow of Encapsulation Request 682 5.2.1. Verify SDT PDU Header and Obtain SA Attributes: 684 1. The Ver field must be set to 0x01. 686 2. The Proto field must be set to either TCP/UDP or DFP. 688 3. I-NLSP shall check that a Security Association has been established 689 between this I-NLSPE and the Peer I-NLSPE. The DFP Source Address 690 is compared with the Peer_Adr SA Attribute and the SAID from the 691 SDT PDU Header is compared to the SAID associated with that 692 Peer_Adr. 694 4. If an association is found, proceed to the next step. 696 5. If no association is found the I-NLSPE performs the error process 697 described above. 699 5.2.2. Apply Decapsulation Mechanisms 701 Applying decapsulation mechanisms involves an ICV check and data 702 decryption. The Integrity SA Attribute is used to determine whether 703 an ICV was calculated and placed at the end of the SDT PDU. The Con- 704 fidentiality SA attribute is used to determine whether confidential- 705 ity was applied to the SDT PDU. The following steps are taken to 706 decapsulate the SDT PDU. 708 1. If Confidentiality is true, 709 decipherment algorithm is applied to the 710 Protected-Octet-String (excluding the Alg_Param field) using 711 the decryption algorithm specified by the Enc_Alg, the 712 Data_Dec_Key, and the parameters specified by the Alg_Param field. 714 2. If Integrity is true, the portion of the Alg_Param field 715 provided by the Integrity mechanism is removed. The ICV 716 check algorithm is performed on the SDT PDU Header, Alg_Param, 717 D_Length, Data and Pad and Pad fields, using the ICV algorithm 718 specified by ICV_Alg along with the ICV_Check_Key. 719 If additional padding is required for the ICV 720 check, a pad of zeroes is used. 722 5.2.3. Sink or Forward 724 If the SDT PDU Proto field was set to TCP/UDP the decapsulated data 725 is sent to the TCP/UDP if operating in ES Mode or the data is for- 726 warded if operating in IS Mode. If the SDT PDU Proto field was set 727 to DFP the decapsulated data is processed as a newly received DFP 728 datagram. 730 5.2.4. Decapsulation Diagram 732 +-------------------------+ 733 | DFP Header | SDT PDU | 734 +-------------------------+ 735 | 736 | Verify SDT PDU Header 737 v 738 +-------------------------------------------------------------+ 739 |Pro|Ver|Flgs|Length|SAID|Resv| Protected_Octet_String | 740 +-------------------------------------------------------------+ 741 | 742 | Apply Decapsulation Mechanisms 743 v 744 +-----------------------------------------------------------------+ 745 |Pro|Ver|Flgs|Length|SAID|Resv|Alg_P| D_Length | Data |Pad|ICV| 746 +-----------------------------------------------------------------+ 747 | 748 | Sink or Forward 749 v 750 +--------------------------+ 751 | TCP/UDP or DFP Packet | 752 +--------------------------+ 754 Figure 10: I-NLSP Decapsulation 756 6. IPv4 And I-NLSP 758 This section contains a functional description of how I-NLSP and IPv4 759 interoperate with each other. This functionality directly pertains to 760 IPv4 and cannot be described in a more general way. 762 6.1. TCP/UDP Encapsulation/Decapsulation Mode 764 IPv4 uses the Protocol field that identifies the destination of the 765 IPv4 data. At this time I-NLSP does not have an assigned protocol 766 value. IN-PID is used to temporarily identify I-NLSP. I-NLSP uses 767 the Proto field to identify the final destination of the SDT PDU 768 data. Figure 11 provides an example of how this process works when 769 the SDT PDU Data contains TCP data. In this example the Protocol 770 field of the IPv4 header is set to the protocol value of I-NLSP (IN- 771 PID) and the Proto field of the SDT PDU header is set to the protocol 772 value of TCP (06) [RFC1340]. 774 1 2 3 775 0123 4567 8901 2345 6789 0123 4567 8901 776 +----+----+---------+-------------------+ ------------ 777 |Ver |IHL | TOS | Total Length | 778 +-------------------+--+----------------+ 779 | Identifier |Fl| Frag. Offset | 780 +---------+---------+-------------------+ 781 | TTL | Protocol| Header Checksum | IPv4 782 | | (IN-PID)| | Header 783 +---------+---------+-------------------+ 784 | Source Address | 785 +---------------------------------------+ 786 | Destination Address | 787 +---------------------------------------+ 788 | Options + Padding | 789 +---------+----+----+-------------------+ ----------- 790 | Prot(06)|Ver | Fl | Length | 791 +---------+----+----+-------------------+ SDT PDU 792 | SAID | Reserved | Header 793 +-------------------+-------------------+ ----------- 794 | Alg_Param + D_Length | 795 +-------------------+-------------------+ Protected 796 | TCP | Octet 797 | Data | String 798 +---------------------------------------+ 799 | Pad + ICV | 800 +---------------------------------------+ ----------- 802 Figure 11. Encapsulated TCP Data as Payload of IPv4 804 6.2. DFP Encapsulation/Decapsulation Mode 806 Figure 12 provides an example of how this process works when the the 807 SDT PDU Data contains an entire IPv4 packet. In this example the 808 Protocol field of the outer most IPv4 header is set to the protocol 809 value of I-NLSP (IN-PID); the Proto field of the SDT PDU header is 810 set to protocol value representing IP-within-IP (94) [RFC1340]; and 811 the Protocol field of the inner most IPv4 header is set to the proto- 812 col value representing TCP (06). 814 1 2 3 815 0123 4567 8901 2345 6789 0123 4567 8901 816 +----+----+---------+-------------------+ ------------ 817 |Ver |IHL | TOS | Total Length | 818 +-------------------+--+----------------+ 819 | Identifier |Fl| Frag. Offset | 820 +---------+---------+-------------------+ 821 | TTL | Protocol| Header Checksum | IPv4 822 | | (IN-PID)| | Header 823 +---------+---------+-------------------+ 824 | Source Address | 825 +---------------------------------------+ 826 | Destination Address | 827 +---------------------------------------+ 828 | Options + Padding | 829 +---------+----+----+-------------------+ ----------- 830 | Prot(94)|Ver | Fl | Length | 831 +---------+----+----+-------------------+ SDT PDU 832 | SAID | Reserved | Header 833 +-------------------+-------------------+ ----------- 834 | Alg_Param + D_Length | 835 +----+----+---------+-------------------+ 836 |Ver |IHL | TOS | Total Length | 837 +-------------------+--+----------------+ 838 | Identifier |Fl| Frag. Offset | 839 +---------+---------+-------------------+ 840 | TTL | Protocol| Header Checksum | Protected 841 | | (06) | | Octet 842 +---------+---------+-------------------+ String 843 | Source Address | 844 +---------------------------------------+ 845 | Destination Address | 846 +---------------------------------------+ 847 | Options + Padding | 848 +---------------------------------------+ 849 | TCP | 850 | Data | 851 +---------------------------------------+ 852 | Pad + ICV | 853 +---------------------------------------+ ----------- 855 Figure 12. Encapsulated IPv4 Packet as Payload of IPv4 857 7. CLNP And I-NLSP 858 This section contains a functional description of how I-NLSP and CLNP 859 interoperate. This functionality directly pertains to CLNP and can- 860 not be described in a more general way. 862 7.1. TCP/UDP Encapsulation/Decapsulation Mode 864 CLNP uses the N-SEL portion of the Destination Address to identify 865 the destination of the CLNP data. I-NLSP uses the Proto field to 866 identify the final destination of the SDT PDU Data. Figure 13 pro- 867 vides an example of how this process works when the SDT PDU Data con- 868 tains TCP data. In this example the N-SEL portion of the CLNP Desti- 869 nation Address is set to the protocol value of I-NLSP (IN-PID) and 870 the Protocol field of the SDT PDU is set to the protocol value of TCP 871 (06). Some of the following fields do not necessarily end on a 32bit 872 boundary. A more complete description of the CLNP header can be 873 found in [ISO8473], but is not required for this discussion. 875 1 2 3 876 0123 4567 8901 2345 6789 0123 4567 8901 877 +----+----+---------+-------------------+ ------------ 878 | PID | LI | Ver |Life Time| 879 +-------------------+-------------------+ 880 |FL| Type | Segment Length | Check- | 881 +---------+---------+-------------------+ 882 | sum | DA Len | Destination | 883 +---------+---------+ | 884 | Address (NSEL=IN-PID) | CLNP 885 +---------+-----------------------------+ Header 886 | SA Len | Source | 887 +---------+ | 888 | Address | 889 +-------------------+-------------------+ 890 | Data Unit ID | Segment Offset | 891 +-------------------+-------------------+ 892 | Total Length | Options | 893 +-------------------+ | 894 | | 895 +-------------------+-------------------+ ----------- 896 | Prot(06)|Ver | Fl | Length | 897 +---------+----+----+-------------------+ SDT PDU 898 | SAID | Reserved | Header 899 +-------------------+-------------------+ ----------- 900 | Alg_Param + D_Length | 901 +-------------------+-------------------+ Protected 902 | TCP | Octet 903 | Data | String 904 +---------------------------------------+ 905 | Pad + ICV | 906 +---------------------------------------+ ----------- 908 Figure 9. Encapsulated TCP Data as Payload of CLNP 910 7.2. DFP Encapsulation/Decapsulation Mode 912 Figure 14 provides an example of how this process works when the SDT 913 PDU Data contains an entire CLNP PDU. In this example the N-SEL of 914 the Destination Address of the outer most CLNP header is set to the 915 protocol value of I-NLSP (IN-PID); the Prot field of the SDT PDU 916 header is set to protocol value representing CLNP (129) [ISO8473]; 917 and the N-SEL of the Destination Address of the inner most CLNP 918 header is set to the protocol value representing TCP (06). 920 1 2 3 921 0123 4567 8901 2345 6789 0123 4567 8901 922 +----+----+---------+-------------------+ ------------ 923 | PID | LI | Ver |Life Time| 924 +-------------------+-------------------+ 925 |FL| Type | Segment Length | Check- | 926 +---------+---------+-------------------+ 927 | sum | DA Len | Destination | 928 +---------+---------+ | 929 | Address (NSEL=IN-PID) | CLNP 930 +---------+-----------------------------+ Header 931 | SA Len | Source | 932 +---------+ | 933 | Address | 934 +-------------------+-------------------+ 935 | Data Unit ID | Segment Offset | 936 +-------------------+-------------------+ 937 | Total Length | Options | 938 +-------------------+ | 939 | | 940 +-------------------+-------------------+ ----------- 941 |Prot(129)|Ver | Fl | Length | 942 +---------+----+----+-------------------+ SDT PDU 943 | SAID | Reserved | Header 944 +-------------------+-------------------+ ----------- 945 | Alg_Param + D_Length | 946 +----+----+---------+-------------------+ 947 | PID | LI | Ver |Life Time| 948 +-------------------+-------------------+ 949 |FL| Type | Segment Length | Check- | 950 +---------+---------+-------------------+ 951 | sum | DA Len | Destination | 952 +---------+---------+ | Protected 953 | Address (NSEL=06) | Octet 954 +---------+-----------------------------+ String 955 | SA Len | Source | 956 +---------+ | 957 | Address | 958 +-------------------+-------------------+ 959 | Data Unit ID | Segment Offset | 960 +-------------------+-------------------+ 961 | Total Length | Options | 962 +-------------------+ | 963 | | 964 +---------------------------------------+ 965 | TCP | 966 | Data | 967 +---------------------------------------+ 968 | Pad + ICV | 969 +---------------------------------------+ ----------- 970 Figure 10. Encapsulated CLNP Packet as Payload of CLNP 972 A. Policy Mechanisms 974 This section describes filters and flags used locally to help the DFP 975 determine how and when I-NLSP security services are required. 977 o Protected_Mode: Boolean (Default: false) 979 Flag used to determine whether unprotected DFP packets are 980 permitted. 982 o Destination_Filter: Set of DFP Addresses 984 Set of DFP Destination addresses which this I-NLSPE is not 985 permitted to send unprotected DFP packets. 987 o Source_Filter: Set of DFP Addresses 989 Set of DFP Source addresses for which this I-NLSPE will 990 provide I-NLSP services. 992 B. Tables 994 [Initial suggested values for reserved SAID values, Alg_IDs, etc.]. 996 (TBD) 998 C. In-Band Security Association Exchange 1000 [Initial description of a Security Association Exchange protocol 1001 using the Diffie-Helman algorithm. This section could potentially point 1002 to another Internet Draft on this subject]. 1004 (TBD) 1005 References 1007 [IPSEC] On-going Deliberations of the IETF IPSEC WG. 1009 [IPng-Criteria] F. Kastenholz, C. Partridge, "Technical Criteria 1010 for Choosing IP:The Next Generation (IPng), 1011 Internet Draft, March 1994. 1013 [ISO8473] ISO/IEC. Information Processing Systems - Data 1014 communications for providing the Connectionless-mode 1015 Network Service. ISO/IEC, 1988. 1017 [ISO11577] ISO/IEC. Information technology - telecommunications and 1018 information exchange between systems - network layer 1019 security protocol. International Standard 11577, 1020 ISO/IEC JTC 1, USA, December 1993. 1022 [RFC1340] J. Reynolds, J. Postel, "Assigned Numbers", Internet RFC 1023 1340 June 1992. 1025 [RFC1347] R. Callon, "TCP and UDP with Bigger Addresses (TUBA), A 1026 Proposal for Internet Addressing and Routing", 1027 Internet RFC 1347, June 1992. 1029 [Stallings] William Stallings, Data and Computer Communication, 1030 Macmillan Publishing Company, Second Edition, 1988