idnits 2.17.1 draft-ietf-ipsec-udp-encaps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 452 lines 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([Kiv00], [Dixon00]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (18 June 2001) is 8341 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) == Unused Reference: 'RFC-2119' is defined on line 386, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Possible downref: Normative reference to a draft: ref. 'Dixon00' == Outdated reference: A later version (-08) exists of draft-ietf-ipsec-nat-t-ike-00 Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Security Protocol Working Group (IPSEC) A. Huttunen 2 INTERNET-DRAFT F-Secure Corporation 3 Category: Standards track W. Dixon, B. Swander 4 Expires: 18 December 2001 Microsoft 5 T. Kivinen, M. Stenberg 6 SSH Communications Security Corp 7 V. Volpe 8 Cisco Systems 9 L. DiBurro 10 Nortel Networks 11 18 June 2001 13 UDP Encapsulation of IPsec Packets 14 draft-ietf-ipsec-udp-encaps-00.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December, 2001. 39 Copyright Notice 41 Copyright (C) The Internet Society (2001). All Rights Reserved. 43 Abstract 45 This draft defines methods to encapsulate and decapsulate ESP and 46 AH packets inside UDP packets for the purpose of traversing NATs. 48 ESP encapsulation as defined in this document is capable of being 49 used in both IPv4 and IPv6 scenarios. AH encapsulation is defined 50 for IPv4 scenarios only. 52 The encapsulation is used whenever negotiated using IKE, as 53 defined in [Kiv00]. The design choices are documented in [Dixon00]. 55 1. Introduction 57 UDP encapsulation of ESP packets MUST be supported. It is up to 58 the need of the clients whether transport mode or tunnel mode is to 59 be supported. L2TP/IPsec clients MUST support transport mode, and 60 IPsec tunnel mode clients MUST support tunnel mode. 62 An IKE implementation supporting this draft MUST NOT generate 63 packets where the Initiator Cookie field is all zeroes. 65 UDP encapsulation of AH MAY be supported. 67 An IKE implementation supporting this draft for AH use MUST NOT 68 generate ESP SPIs that are all zeroes. 70 ESP encapsulation as defined in this document is capable of being 71 used in both IPv4 and IPv6 scenarios. AH encapsulation is defined 72 for IPv4 scenarios only. 74 2. Packet Formats 76 2.1 UDP-encapsulated ESP Header Format 78 0 1 2 3 79 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 80 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 81 | Source Port | Destination Port | 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 | Length | Checksum | 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 | Non-IKE Marker | 86 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 | Non-IKE Marker | 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | ESP header [RFC 2406] | 90 ~ ~ 91 | | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 The UDP header is a standard [RFC 768] header, where 95 - Source Port and Destination Port are the same as used by IKE 96 traffic. 97 - Checksum is zero. 99 Non-IKE Marker is 8 bytes of zero aligning with the Initiator 100 Cookie of an IKE packet. 102 2.2 UDP-encapsulated AH Header Format 104 0 1 2 3 105 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 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Source Port | Destination Port | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Length | Checksum | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Non-IKE Marker | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Non-IKE Marker | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Non-ESP Marker | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 |Version| Reserved | IHL | Identification | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | AH header [RFC 2402] | 120 ~ ~ 121 | | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 The UDP header is a standard [RFC 768] header, where 125 - Source Port and Destination Port are the same as used by IKE 126 traffic. 127 - Checksum is zero. 129 Non-IKE Marker is 8 bytes of zero aligning with the Initiator 130 Cookie of an IKE packet. 132 Non-ESP Marker is 4 bytes of zero aligning with the SPI field 133 of an ESP packet. 135 Version is a copy of the original header IP version field. 137 When version is IPv4, the following fields are defined: 138 - Reserved field MUST be zero. 139 - IHL is a copy of the original header length field of the IP packet. 140 - Identification is a copy of the original Identification field 141 of the IP packet. 143 Version, Reserved, IHL and Identification fields are later referred to 144 as AH Envelope. 146 2.3 NAT-keepalive Packet Format 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Source Port | Destination Port | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Length | Checksum | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | 0xFF | 156 +-+-+-+-+-+-+-+-+ 158 The UDP header is a standard [RFC 768] header, where 159 - Source Port and Destination Port are the same as used by IKE 160 traffic. 161 - Checksum is zero. 163 The sender SHOULD use a one octet long payload with the value 0xFF. 164 The receiver SHOULD ignore a received NAT-keepalive packet. 166 3. Encapsulation and Decapsulation Procedures 168 3.1 Auxiliary Procedures 170 3.1.1 Tunnel Mode Decapsulation NAT Procedure 172 When a tunnel mode has been used to transmit packets, the inner 173 IP header can contain addresses that are not suitable for the 174 current network. This procedure defines how these addresses are 175 to be converted to suitable addresses for the current network. 177 Depending on local policy, one of the following MUST be done: 178 a) If a valid source IP address space has been defined in the policy 179 for the encapsulated packets from the peer, check that the source 180 IP address of the inner packet is valid according to the policy. 181 b) If an address has been assigned for the remote peer, check 182 that the source IP address used in the inner packet is the 183 same as the IP address assigned. 184 c) NAT is performed for the packet, making it suitable for transport 185 in the local network. 187 3.1.2 Transport Mode Decapsulation NAT Procedure 189 When a transport mode has been used to transmit packets, contained 190 TCP or UDP headers will contain incorrect checksums due to the change 191 of parts of the IP header during transit. This procedure defines how 192 to fix these checksums. 194 Depending on local policy, one of the following MUST be done: 195 a) If the protocol header after the ESP/AH header is a TCP/UDP 196 header, zero the checksum field in the TCP/UDP header. 197 b) If the protocol header after the ESP/AH header is a TCP/UDP 198 header, recompute the checksum field in the TCP/UDP header. 199 c) If the protocol header after the ESP/AH header is a TCP/UDP 200 header and the peer's real source IP address has been received 201 according to [Kiv00], incrementally recompute the TCP/UDP checksum: 202 - subtract the IP source address in the received packet 203 from the checksum 204 - add the real IP source address received via IKE to the checksum 206 In addition an implementation MAY fix any contained protocols that 207 have been broken by NAT. 209 3.2 Transport Mode ESP Encapsulation 211 BEFORE APPLYING ESP/UDP 212 ---------------------------- 213 IPv4 |orig IP hdr | | | 214 |(any options)| TCP | Data | 215 ---------------------------- 217 AFTER APPLYING ESP/UDP 218 ------------------------------------------------------------- 219 IPv4 |orig IP hdr | UDP | Non-| ESP | | | ESP | ESP| 220 |(any options)| Hdr | IKE | Hdr | TCP | Data | Trailer |Auth| 221 ------------------------------------------------------------- 222 |<----- encrypted ---->| 223 |<------ authenticated ----->| 225 1) Ordinary ESP encapsulation procedure is used. 226 2) A properly formatted UDP header and a Non-IKE Marker 227 are inserted where shown. 228 3) The Total Length, Protocol and Header Checksum fields in the 229 IP header are edited to match the resulting IP packet. 231 3.3 Transport Mode ESP Decapsulation 233 1) The UDP header and the Non-IKE Marker are removed from 234 the packet. 235 2) The Total Length, Protocol and Header Checksum fields in the 236 new IP header are edited to match the resulting IP packet. 237 3) Ordinary ESP decapsulation procedure is used. 238 4) Transport mode decapsulation NAT procedure is used. 240 3.4 Tunnel Mode ESP Encapsulation 242 BEFORE APPLYING ESP/UDP 243 ---------------------------- 244 IPv4 |orig IP hdr | | | 245 |(any options)| TCP | Data | 246 ---------------------------- 248 AFTER APPLYING ESP/UDP 249 -------------------------------------------------------------------- 250 IPv4 |new h.| UDP | Non-| ESP |orig IP hdr | | | ESP | ESP| 251 |(opts)| Hdr | IKE | Hdr |(any options)| TCP | Data | Trailer |Auth| 252 -------------------------------------------------------------------- 253 |<------------ encrypted ----------->| 254 |<------------- authenticated ------------>| 256 1) Ordinary ESP encapsulation procedure is used. 257 2) A properly formatted UDP header and a Non-IKE Marker 258 are inserted where shown. 259 3) The Total Length, Protocol and Header Checksum fields in the 260 new IP header are edited to match the resulting IP packet. 262 3.5 Tunnel Mode ESP Decapsulation 264 1) The UDP header and the Non-IKE Marker are removed from 265 the packet. 266 2) The Total Length, Protocol and Header Checksum fields in the 267 new IP header are edited to match the resulting IP packet. 268 3) Ordinary ESP decapsulation procedure is used. 269 4) Tunnel mode decapsulation NAT procedure is used. 271 3.6 Transport Mode AH Encapsulation 273 BEFORE APPLYING AH/UDP 274 ---------------------------- 275 IPv4 |orig IP hdr | | | 276 |(any options)| TCP | Data | 277 ---------------------------- 279 AFTER APPLYING AH/UDP 280 ---------------------------------------------------------- 281 IPv4 |orig IP hdr | UDP | Non-| Non-| AH | | | | 282 |(any options)| Hdr | IKE | ESP | Env. | AH | TCP | Data | 283 ---------------------------------------------------------- 284 |<--auth.---->| |<---auth.------->| 285 except for 286 mutable fields 288 1) If the Version number field in the IP header is not 4, 289 drop the packet, otherwise continue. 290 2) Ordinary AH encapsulation procedure is used. 291 3) A properly formatted UDP header, Non-IKE marker, Non-ESP marker 292 and AH Envelope are inserted where shown. 293 4) The AH Envelope is filled with information from the IP header. 294 5) The Total Length, Protocol and Header Checksum fields in the 295 IP header are edited to match the resulting IP packet. 297 3.7 Transport Mode AH Decapsulation 299 1) If the Version number field in the AH envelope and the outer 300 IP header are not both 4, drop the packet, otherwise continue. 301 2) The values in the AH Envelope are copied to the IP header. 302 3) The UDP header, Non-IKE marker, Non-ESP marker and AH Envelope 303 are removed from the packet. 304 4) The Total Length, Protocol and Header Checksum fields in the 305 IP header are edited to match the resulting IP packet. 306 5) Ordinary AH decapsulation procedure is used. 307 6) Transport mode decapsulation NAT procedure is used. 309 3.8 Tunnel Mode AH Encapsulation 311 BEFORE APPLYING AH/UDP 312 ---------------------------- 313 IPv4 |orig IP hdr | | | 314 |(any options)| TCP | Data | 315 ---------------------------- 317 AFTER APPLYING AH/UDP 318 ------------------------------------------------------------------ 319 IPv4 |new h. | UDP | Non-| Non-| AH | |orig IP hdr | | | 320 |(opts) | Hdr | IKE | ESP | Env. | AH |(any options)| TCP | Data | 321 ------------------------------------------------------------------ 322 |<--auth.---->| |<----authenticated------------>| 323 except for 324 mutable fields 326 1) If the Version number field in the IP header is not 4, 327 drop the packet, otherwise continue. 328 2) Ordinary AH encapsulation procedure is used. 329 3) A properly formatted UDP header, Non-IKE marker, Non-ESP marker 330 and AH Envelope are inserted where shown. 331 4) The AH Envelope is filled with information from the new IP header. 332 5) The Total Length, Protocol and Header Checksum fields in the 333 new IP header are edited to match the resulting IP packet. 335 3.9 Tunnel Mode AH Decapsulation 337 1) If the Version number field in the AH envelope and the outer 338 IP header are not both 4, drop the packet, otherwise continue. 339 2) The values in the AH Envelope are copied to the outer IP header. 340 3) The UDP header, Non-IKE marker, Non-ESP marker and AH Envelope 341 are removed from the packet. 342 4) The Total Length, Protocol and Header Checksum fields in the 343 IP header are edited to match the resulting IP packet. 344 5) Ordinary AH decapsulation procedure is used. 345 6) Tunnel mode decapsulation NAT procedure is used. 347 4. NAT Keepalive Procedure 349 The sole purpose of sending NAT-keepalive packets is to keep 350 NAT mappings alive for the duration of a connection between 351 the peers. Reception of NAT-keepalive packets MUST NOT be 352 used to detect liveness of a connection. 354 A peer MAY send a NAT-keepalive packet if there exists one 355 or more phase I or phase II SAs between the peers, or such 356 an SA has existed at most N minutes earlier. N is a locally 357 configurable parameter with a default value of 5 minutes. 359 A peer SHOULD send a NAT-keepalive packet if a need to send such 360 packets is detected according to [Kiv00] and if no other packet to 361 the peer has been sent in M seconds. M is a locally configurable 362 parameter with a default value of 20 seconds. 364 5. Intellectual property rights 366 The IETF has been notified of intellectual property rights claimed in 367 regard to some or all of the specification contained in this document. 368 For more information consult the online list of claimed rights. 370 SSH Communications Security Corp has notified the working group of one 371 or more patents or patent applications that may be relevant to this 372 internet-draft. SSH Communications Security Corp has already given a 373 licence for those patents to the IETF. For more information consult the 374 online list of claimed rights. 376 6. Acknowledgments 378 Thanks to Joern Sierwald, Tamir Zegman, Larry DiBurro, Tatu Ylonen 379 and Santeri Paavolainen who contributed to the previous drafts 380 about NAT traversal. 382 7. References 384 [RFC 768] Postel, J., "User Datagram Protocol", August 1980 386 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 387 Requirement Levels", March 1997 389 [RFC 2402] Kent, S., "IP Authentication Header", November 1998 391 [RFC 2406] Kent, S., "IP Encapsulating Security Payload (ESP)", 392 November 1998 394 [Dixon00] Dixon, W. et. al., 395 draft-ietf-ipsec-udp-encaps-justification-00.txt, 396 "IPSec over NAT Justification for UDP Encapsulation", June 2001 398 [Kiv00] Kivinen, T. et. al., draft-ietf-ipsec-nat-t-ike-00.txt, 399 "Negotiation of NAT-Traversal in the IKE", June 2001 401 8. Authors' Addresses 403 Ari Huttunen 404 F-Secure Corporation 405 Tammasaarenkatu 7, 406 FIN-00181 HELSINKI 407 Finland 408 E-mail: Ari.Huttunen@F-Secure.com 410 William Dixon 411 Microsoft 412 One Microsoft Way 413 Redmond WA 98052 414 E-mail: wdixon@microsoft.com 416 Brian Swander 417 Microsoft 418 One Microsoft Way 419 Redmond WA 98052 420 E-mail: briansw@microsoft.com 422 Tero Kivinen 423 SSH Communications Security Corp 424 Fredrikinkatu 42 425 FIN-00100 HELSINKI 426 Finland 427 E-mail: kivinen@ssh.fi 429 Markus Stenberg 430 SSH Communications Security Corp 431 Fredrikinkatu 42 432 FIN-00100 HELSINKI 433 Finland 434 E-mail: mstenber@ssh.com 436 Victor Volpe 437 Cisco Systems 438 124 Grove Street 439 Suite 205 440 Franklin, MA 02038 441 E-mail: vvolpe@cisco.com 443 Larry DiBurro 444 Nortel Networks 445 80 Central Street 446 Boxborough, MA 01719 447 ldiburro@nortelnetworks.com