idnits 2.17.00 (12 Aug 2021) /tmp/idnits22455/draft-melen-spinat-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 532. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 556. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 27, 2008) is 5045 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Melen 3 Internet-Draft J. Ylitalo 4 Expires: January 28, 2009 P. Salmela 5 Ericsson Research NomadicLab 6 July 27, 2008 8 Security Parameter Index multiplexed Network Address Translation 9 (SPINAT) 10 draft-melen-spinat-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 28, 2009. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This drafts defines a Security Parameter Index multiplexed Network 44 Address Translator (SPINAT). The SPINAT method uses the SPI value of 45 ESP packets to de-multiplex multiple IP addresses on single IP 46 address. The solution presented in this draft requires a state in 47 the SPINAT node and in the peer node. The state establishment 48 requires a control signaling messages carrying the SPI values. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. State Establishment . . . . . . . . . . . . . . . . . . . . . 6 55 3.1. State Establishment at SPINAT Node . . . . . . . . . . . . 6 56 3.2. State Establishment at End-Hosts . . . . . . . . . . . . . 7 57 4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 8 58 4.1. Control Signaling packet handling . . . . . . . . . . . . 8 59 4.2. ESP packet processing . . . . . . . . . . . . . . . . . . 9 60 4.2.1. IP Address and SPI Translation at SPINAT Nodes . . . . 9 61 4.2.2. SPI Translation at End-hosts . . . . . . . . . . . . . 10 62 5. Parameters and packet formats . . . . . . . . . . . . . . . . 11 63 5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 11 64 5.1.1. NAT_ESP_INFO . . . . . . . . . . . . . . . . . . . . . 11 65 5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 11 66 5.2.1. Modifications in I2 . . . . . . . . . . . . . . . . . 11 67 5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 12 68 5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 12 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 76 Intellectual Property and Copyright Statements . . . . . . . . . . 18 78 1. Introduction 80 The IP Network Address Translator (Traditional NAT) functionality is 81 explained in [RFC3022]. From the IP address translation point of 82 view, it is possible to compare the traditional Network Address Port 83 Translation (NAPT) method to SPINAT method, i.e. presented in this 84 draft. A SPINAT node connects a private link to a WAN link, like a 85 NAPT node does. The NAPT method uses port values in TCP/UDP headers 86 for multiplexing IP addresses, while the SPINAT method uses Security 87 Parameter Index (SPI) values in the ESP [RFC4303] headers for that 88 purpose. 90 There are few differences in the operation of SPINAT compared to 91 NAPT. 93 In NAPT the port values in the TCP/UDP headers are not integrity 94 protected, unlike in the SPINAT case where the SPI values in ESP 95 headers are integrity protected. From the SPI translation point 96 of view this is a problem, because the related ESP integrity 97 protection keys are only shared between the end-points, not with 98 the SPINAT nodes. Therefore, the SPINAT nodes cannot 99 transparently translate SPI values like traditional NAPT nodes 100 translate port values. To sustain the integrity of ESP headers 101 and to support SPI translation, the SPINAT nodes MUST inform the 102 sending end-hosts about the translation, unlike the NAPT method 103 about the port translation. 105 When the Security Associations are setup between the end-hosts, 106 the end-hosts will use a separate control signaling to negotiate 107 the SPI values to be used, unlike in NAPT case where the 108 destination port values are well-known and source ports may be 109 randomly selected and modified. Additionally, the ESP header 110 carries only the destination SPI value, thus a separate control 111 signaling (key-exchange) is needed for state establishment at the 112 SPINAT node, instead of using only ESP packets for state 113 establishment. 115 The SPINAT node that is in the forwarding path of the two peer nodes 116 will create its state in two steps. The first step is to create a 117 soft-state for the SPI-to-IP address mapping for ESP payload traffic 118 based on the control signaling (key-exchange). However, the SPINAT 119 method does not require explicit state establishment exchange between 120 SPINAT node and the end-hosts. Therefore, the SPINAT method does not 121 increase the amount of signaling compared to a situation when there 122 does not exist SPINAT nodes on the packet forwarding path. The 123 SPINAT node intercepts a control signaling message received from a 124 private link that carries a SPI value. The SPINAT adds a Type- 125 Length-Value (TLV) field containing the SPI mapping information at 126 the end of the intercepted message before forwarding the message to 127 the WAN link. Next, the state is completed to a hard-state after 128 receiving the first ESP payload packet that carries the SPI 129 corresponding to the SPI-to-IP address mapping. 131 The SPINAT operation does not require any modifications to the ESP 132 processing at the host in the private network, but requires a 133 modification at the peer host that is in the WAN side to allow the 134 SPINAT node to re-write the SPI value on the received ESP packets. 135 The original SPI value is selected by the receiving end-host in the 136 private IP network, and the value is replaced by the SPINAT node with 137 another SPI value. As a result of the key-exchange, both the SPINAT 138 node and the peer host establish a translation state. The end-host 139 implements the same SPI mapping as SPINAT node for integrity 140 protected ESP packets, but in a reverse order. The SPI translation 141 MUST be made after the ESP integrity protection is computed using the 142 original SPI values. 144 2. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 client node 151 The node residing in the private network. 153 SPINAT node 154 The SPI based Network Address Translation node. 156 Peer node 157 The node residing in the public network. 159 3. State Establishment 161 3.1. State Establishment at SPINAT Node 163 This section describes the state establishment and SA mapping setup 164 in the SPINAT node. After the state has been setup the SPINAT node 165 is ready to forward the packets between the peer nodes. 167 +--------+ +--------+ +--------+ 168 | Peer | | SPINAT | | client | 169 +--------+ +--------+ +--------+ 170 | | | 171 | {SPI=3030-->1212}| {SPI=3030}| 172 | \| \| 173 |<-Key-exchange message-------|--------------------------| 174 | | | 175 | | | 176 |{SPI=4545} | | 177 |/ | | 178 |-Key-exchange message------->|------------------------->| 180 Figure 1: A round-trip of a key-exchange containing SPI values 182 Figure 1 illustrates control signaling that contains the SPI values. 183 As a result the SPINAT node creates translation state for the 184 security associations (SAs). The SPI needs to be translated only on 185 the direction from peer to client because only in that directions 186 there is a possibility that two or more clients behind the SPINAT 187 node select the same SPI value for incoming ESP packets causing a SPI 188 collision. 190 +--------+ +--------+ +--------+ 191 | Peer | | SPINAT | | client | 192 +--------+ +--------+ +--------+ 193 | | | 194 |(SA-out) (SA-in-public)|(SA-out-private) (SA-in)| 195 |/ ESP \|/ \| 196 |---------------------------->|------------------------->| 197 | | | 198 | | | 199 |(SA-in) (SA-out-public)|(SA-in-private) (SA-out)| 200 |/ ESP \|/ \| 201 |<----------------------------|--------------------------| 202 Figure 2: Naming the Security Associations (SAs) 204 The translation state contains a incoming SA and a outgoing SA. This 205 pair contains the information needed to forward the packet through 206 the SPINAT node. The information needed in the state is illustrated 207 in the Figure 2 209 The state on the direction from peer to client contains mapping for 210 SPI value on the public side to a SPI value on the private side and 211 the private address of the client. 213 The SPI value selected for the SA-in-public MUST be unique for each 214 ESP incoming association. The SPINAT node selects the SPI value for 215 each connection that goes through the SPINAT node. The selected SPI 216 value is carried in the control signaling message to the peer node. 218 The state on the direction from client to peer contains mapping for 219 client private address to the public address of SPINAT. In this 220 direction there is no need to translate the SPI. 222 The SPI value used in the SA-out-public is selected by the peer node 223 and thus it does not have to be translated. The SPINAT node is able 224 to use on both sides the same SPI value. 226 3.2. State Establishment at End-Hosts 228 This section describes the state needed in the end-hosts to support 229 SPINAT translations. Both End-Hosts create one incoming and outgoing 230 SAs as can be seen from Figure 2. 232 On the client node that resides behind the SPINAT node in the private 233 network there is no additional state information that should be 234 stored. The client node operates as it would operate in other 235 network and stores the same state data as it would store for any 236 other SA. 238 The peer node on the WAN side has to store the SPI mapping 239 information that it has received from the SPINAT node in the control 240 signaling. As the SA is created to peer node it needs to store both 241 the SPI value given by the client and the SPI value given by the 242 SPINAT node to the SA. The SPI value given by the client will be 243 used when constructing the ESP packet and calculating message 244 authentication code. This SPI value will later be replaced by the 245 SPI value given by the SPINAT node. 247 4. Packet Processing 249 4.1. Control Signaling packet handling 251 This section describes the packet processing of the control signaling 252 packets. 254 When a control packet is received from private network following 255 processing steps will be done: 257 1. Upon receipt of a control signaling packet from private network, 258 the SPINAT node parses the packet. 260 2. If there is no state for this pair of end-hosts it will create a 261 state that is used to forward the control signaling packets 262 through the SPINAT node. 264 3. If the packet contains a SPI value the SPINAT node MUST select a 265 unique SPI from its free SPI space. If the packet didn't contain 266 SPI value it will be forwarded and no further processing is 267 applied. 269 4. SPINAT node MUST add to the state that the mapping between the 270 SPI selected by the client host and the SPI that it has chosen. 272 5. The SPINAT node adds the SPI TLV to the original control 273 signaling packet. 275 6. The SPINAT node translates the source address of the packet. 277 7. SPINAT node forwards the packet to recipient. 279 When a control packet is received from WAN network following 280 processing steps will be done: 282 1. Upon receipt of a control signaling packet from WAN network, the 283 SPINAT node looks up the state for the control signaling it has 284 created from previously outgoing packet. If no state is found 285 the packet MUST be discarded. 287 2. The SPINAT node translates the destination address based on the 288 information stored in to the state. 290 3. SPINAT forwards the packet to recipient. 292 4.2. ESP packet processing 294 4.2.1. IP Address and SPI Translation at SPINAT Nodes 296 This section describes the packet processing of the ESP packet. 297 Figure 3 illustrates an example of SPINAT packet processing for ESP 298 packets. 300 +--------+ +--------+ +--------+ 301 | Peer | | SPINAT | | client | 302 +--------+ +--------+ +--------+ 303 | {s=138.76.28.4,| {s=10.0.0.10, | 304 | d=138.76.29.7,| d=138.76.29.7,| 305 | ESP SPI=4545 \| SPI=4545} \| 306 |<----------------------------|--------------------------| 307 | | | 308 | {s=138.76.29.7 | {s=138.76.29.7, | 309 | {d=138.76.29.4, | d=10.0.0.10, | 310 |/ SPI=1212} ESP |/ SPI=3030} | 311 |---------------------------->|------------------------->| 313 Figure 3: SPINAT Operation for ESP protected payload packets 315 When a ESP packet is received from private network following 316 processing steps will be done: 318 1. Upon receipt of a ESP packet from the private network, the SPINAT 319 determines the appropriate translation state, based on the SPI. 320 If no valid state exists for this SPI the SPINAT node MUST 321 discard the packet. 323 2. The SPINAT node translates the source address of the packet. 325 3. SPINAT node forwards the packet to recipient. 327 When a ESP packet is received from WAN network following processing 328 steps will be done: 330 1. Upon receipt of a ESP packet from the WAN network, the SPINAT 331 determines the appropriate translation state, based on the SPI. 332 If no valid state exists for this SPI the SPINAT node MUST 333 discard the packet. 335 2. The SPINAT node translates the destination address and the SPI 336 based on the information in the stored in to the state. 338 3. SPINAT node forwards the packet on to the private network. 340 4.2.2. SPI Translation at End-hosts 342 This section describes the packet processing of ESP packets in the 343 end-hosts. 345 The client node processes the inbound and outbound packets as defined 346 in sections 3.3 and 3.4 of [RFC4303] and in the client host there is 347 no SPI translation takes place. 349 The peer node processes the inbound packets as defined in section 3.4 350 of [RFC4303] and no SPI translation takes place. The outbound 351 packets are first processed as defined in section 3.3 of [RFC4303]. 352 When the ESP payload has been constructed, the SPI will be translated 353 to the one selected by SPINAT node before sending the packet to the 354 client node. 356 5. Parameters and packet formats 358 The control signaling protocol packet carry the SPI value selected by 359 SPINAT node. 361 5.1. New Parameters 363 5.1.1. NAT_ESP_INFO 365 0 1 2 3 366 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Type | Length | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Reserved | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Original SPI | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Translated SPI | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Type XXX 378 Length 12 379 Original SPI Original SPI selected by the peer which is associated 380 with peer's address(es) to this SA. 381 Translated SPI Translated SPI for data sent to address(es) associated 382 with this SA. 384 5.2. HIP ESP Security Association Setup 386 The ESP Security Association is set up during the base exchange. The 387 following subsections define the ESP SA setup procedure both using 388 base exchange messages (I2) and using UPDATE messages. 390 5.2.1. Modifications in I2 392 When HIP is used with ESP, the I2 packet MUST carry an ESP_INFO 393 parameter. Intermediate SPINAT nodes MUST add NAT_ESP_INFO parameter 394 to the I2 packet. The packet is signed for the benefit of the 395 intermediate SPINAT nodes to be able to verify the origin of the 396 packet. 398 The NAT_ESP_INFO contains the translated SPI for this association as 399 well as the sender's original SPI. 401 The following figure shows the contents of a I2 packet after it has 402 passed the SPINAT node processing. 404 The HIP parameters for the I2 packet: 406 IP ( HIP ( ESP_INFO, 407 [R1_COUNTER,] 408 SOLUTION, 409 DIFFIE_HELLMAN, 410 HIP_TRANSFORM, 411 ESP_TRANSFORM, 412 ENCRYPTED { HOST_ID }, 413 [ ECHO_RESPONSE ,] 414 HMAC, 415 HIP_SIGNATURE 416 [, ECHO_RESPONSE], 417 NAT_ESP_INFO ) ) 419 5.3. HIP ESP Rekeying 421 In this section, the procedure for rekeying an existing ESP SA is 422 presented. Only the first packet of the UPDATE packet exchange is 423 modified by the SPINAT node. 425 5.3.1. Initializing Rekeying 427 When HIP is used with ESP, the UPDATE packet is used to initiate 428 rekeying. The UPDATE packet that initiates the rekeying MUST carry 429 an ESP_INFO and MAY carry a DIFFIE_HELLMAN parameter. 431 Intermediate SPINAT nodes will have to inspect HIP UPDATE packets. 432 Those that carry rekeying information the SPINAT node MUST add 433 NAT_ESP_INFO parameter. The packet is signed for the benefit of the 434 intermediate SPINAT nodes to be able to verify the origin of the 435 packet. 437 The following figure shows the contents of a rekeying initialization 438 UPDATE packet after it has passed the SPINAT node processing. 440 The HIP parameters for the UPDATE packet initiating rekeying: 442 IP ( HIP ( ESP_INFO, 443 SEQ, 444 [DIFFIE_HELLMAN, ] 445 HMAC, 446 HIP_SIGNATURE, 447 NAT_ESP_INFO ) ) 449 6. Security Considerations 451 The translated SPI values included in the key-exchange messages and 452 ESP headers are not integrity protected with signatures or HMAC 453 computation. Therefore, a Man-in-the-Middle (MitM) attacker MAY 454 change the SPIs in the packets. However, the SPI value is only an 455 index to a specific IPsec Security Association (SA) at the receiving 456 party. The actual security is based on the shared session keys. 457 Hence, an SPI changing attack does not affect the confidentiality or 458 integrity properties of the protocol. 460 It must be noted that changing SPI values is only possible for an on- 461 path attacker that is able to modify packets on the fly. Such an 462 attacker is not only able to change the SPI values, but he can block 463 all communications between the parties. Therefore, having unsigned 464 and changeable SPIs does not introduce new security vulnerabilities 465 to ESP. A host trusts a SPINAT device to change the SPI values in 466 the same way it trusts the NAPT to change the port values. 468 7. IANA Considerations 469 8. Acknowledgments 471 A number of people have contributed to the text and ideas. The list 472 of these people include Pekka Nikander, Petri Jokela, Raimo 473 Vuopionperae, Yuri Ismailov, Jan Hoeller and Hannes Tschofenig. Our 474 apologies to anyone whose name is missing. 476 9. References 478 9.1. Normative References 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, March 1997. 483 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 484 RFC 4303, December 2005. 486 9.2. Informative References 488 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 489 Address Translator (Traditional NAT)", RFC 3022, 490 January 2001. 492 Authors' Addresses 494 Jan Melen 495 Ericsson Research NomadicLab 496 JORVAS FIN-02420 497 FINLAND 499 Phone: +358 9 299 1 500 Email: jan.melen@nomadiclab.com 502 Jukka Ylitalo 503 Ericsson Research NomadicLab 504 JORVAS FIN-02420 505 FINLAND 507 Phone: +358 9 299 1 508 Email: jukka.ylitalo@nomadiclab.com 510 Patrik Salmela 511 Ericsson Research NomadicLab 512 JORVAS FIN-02420 513 FINLAND 515 Phone: +358 9 299 1 516 Email: patrik.salmela@nomadiclab.com 518 Full Copyright Statement 520 Copyright (C) The IETF Trust (2008). 522 This document is subject to the rights, licenses and restrictions 523 contained in BCP 78, and except as set forth therein, the authors 524 retain all their rights. 526 This document and the information contained herein are provided on an 527 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 528 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 529 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 530 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 531 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 532 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 534 Intellectual Property 536 The IETF takes no position regarding the validity or scope of any 537 Intellectual Property Rights or other rights that might be claimed to 538 pertain to the implementation or use of the technology described in 539 this document or the extent to which any license under such rights 540 might or might not be available; nor does it represent that it has 541 made any independent effort to identify any such rights. Information 542 on the procedures with respect to rights in RFC documents can be 543 found in BCP 78 and BCP 79. 545 Copies of IPR disclosures made to the IETF Secretariat and any 546 assurances of licenses to be made available, or the result of an 547 attempt made to obtain a general license or permission for the use of 548 such proprietary rights by implementers or users of this 549 specification can be obtained from the IETF on-line IPR repository at 550 http://www.ietf.org/ipr. 552 The IETF invites any interested party to bring to its attention any 553 copyrights, patents or patent applications, or other proprietary 554 rights that may cover technology that may be required to implement 555 this standard. Please address the information to the IETF at 556 ietf-ipr@ietf.org. 558 Acknowledgment 560 Funding for the RFC Editor function is provided by the IETF 561 Administrative Support Activity (IASA).