idnits 2.17.1 draft-ietf-ipsec-udp-encaps-01.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 386 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 (2 October 2001) is 8235 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 323, but no explicit reference was found in the text ** 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: 7 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: April 2002 Microsoft 5 T. Kivinen, M. Stenberg 6 SSH Communications Security Corp 7 V. Volpe 8 Cisco Systems 9 L. DiBurro 10 Nortel Networks 11 2 October 2001 13 UDP Encapsulation of IPsec Packets 14 draft-ietf-ipsec-udp-encaps-01.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 April, 2002. 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 46 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. 51 The encapsulation is used whenever negotiated using IKE, as 52 defined in [Kiv00], or another key management protocol. The 53 design choices are documented in [Dixon00]. 55 Change Log 56 Version -01 57 - removed everything related to the AH-protocol 58 - added instructions on how to use the encapsulation with 59 some other key management protocol than IKE 61 1. Introduction 63 It is up to the need of the clients whether transport mode 64 or tunnel mode is to be supported. L2TP/IPsec clients MUST support 65 transport mode, and IPsec tunnel mode clients MUST support tunnel 66 mode. 68 An IKE implementation supporting this draft MUST NOT generate 69 packets where the Initiator Cookie field is all zeroes. This 70 ensures that IKE packets and ESP packets can be distinguished 71 from each other. 73 Usage with another key management protocol is described in 74 a separate section. 76 ESP encapsulation as defined in this document is capable of being 77 used in both IPv4 and IPv6 scenarios. 79 2. Packet Formats 81 2.1 UDP-encapsulated ESP Header Format 83 0 1 2 3 84 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 85 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 | Source Port | Destination Port | 87 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 88 | Length | Checksum | 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 | Non-IKE Marker | 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 | Non-IKE Marker | 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | ESP header [RFC 2406] | 95 ~ ~ 96 | | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 The UDP header is a standard [RFC 768] header, where 100 - Source Port and Destination Port are the same as used by IKE 101 traffic. 102 - Checksum is zero. 104 Non-IKE Marker is 8 bytes of zero aligning with the Initiator 105 Cookie of an IKE packet. 107 2.3 NAT-keepalive Packet Format 109 0 1 2 3 110 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 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Source Port | Destination Port | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Length | Checksum | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | 0xFF | 117 +-+-+-+-+-+-+-+-+ 119 The UDP header is a standard [RFC 768] header, where 120 - Source Port and Destination Port are the same as used by IKE 121 traffic. 122 - Checksum is zero. 124 The sender SHOULD use a one octet long payload with the value 0xFF. 125 The receiver SHOULD ignore a received NAT-keepalive packet. 127 3. Encapsulation and Decapsulation Procedures 129 3.1 Auxiliary Procedures 131 3.1.1 Tunnel Mode Decapsulation NAT Procedure 133 When a tunnel mode has been used to transmit packets, the inner 134 IP header can contain addresses that are not suitable for the 135 current network. This procedure defines how these addresses are 136 to be converted to suitable addresses for the current network. 138 Depending on local policy, one of the following MUST be done: 139 a) If a valid source IP address space has been defined in the policy 140 for the encapsulated packets from the peer, check that the source 141 IP address of the inner packet is valid according to the policy. 142 b) If an address has been assigned for the remote peer, check 143 that the source IP address used in the inner packet is the 144 same as the IP address assigned. 145 c) NAT is performed for the packet, making it suitable for transport 146 in the local network. 148 3.1.2 Transport Mode Decapsulation NAT Procedure 150 When a transport mode has been used to transmit packets, contained 151 TCP or UDP headers will contain incorrect checksums due to the change 152 of parts of the IP header during transit. This procedure defines how 153 to fix these checksums. 155 Depending on local policy, one of the following MUST be done: 156 a) If the protocol header after the ESP header is a TCP/UDP 157 header, zero the checksum field in the TCP/UDP header. 158 b) If the protocol header after the ESP header is a TCP/UDP 159 header, recompute the checksum field in the TCP/UDP header. 160 c) If the protocol header after the ESP header is a TCP/UDP 161 header and the peer's real source IP address has been received 162 according to [Kiv00], incrementally recompute the TCP/UDP checksum: 163 - subtract the IP source address in the received packet 164 from the checksum 165 - add the real IP source address received via IKE to the checksum 167 In addition an implementation MAY fix any contained protocols that 168 have been broken by NAT. 170 3.2 Transport Mode ESP Encapsulation 172 BEFORE APPLYING ESP/UDP 173 ---------------------------- 174 IPv4 |orig IP hdr | | | 175 |(any options)| TCP | Data | 176 ---------------------------- 178 AFTER APPLYING ESP/UDP 179 ------------------------------------------------------------- 180 IPv4 |orig IP hdr | UDP | Non-| ESP | | | ESP | ESP| 181 |(any options)| Hdr | IKE | Hdr | TCP | Data | Trailer |Auth| 182 ------------------------------------------------------------- 183 |<----- encrypted ---->| 184 |<------ authenticated ----->| 186 1) Ordinary ESP encapsulation procedure is used. 187 2) A properly formatted UDP header and a Non-IKE Marker 188 are inserted where shown. 189 3) The Total Length, Protocol and Header Checksum fields in the 190 IP header are edited to match the resulting IP packet. 192 3.3 Transport Mode ESP Decapsulation 194 1) The UDP header and the Non-IKE Marker are removed from 195 the packet. 196 2) The Total Length, Protocol and Header Checksum fields in the 197 new IP header are edited to match the resulting IP packet. 198 3) Ordinary ESP decapsulation procedure is used. 199 4) Transport mode decapsulation NAT procedure is used. 201 3.4 Tunnel Mode ESP Encapsulation 203 BEFORE APPLYING ESP/UDP 204 ---------------------------- 205 IPv4 |orig IP hdr | | | 206 |(any options)| TCP | Data | 207 ---------------------------- 209 AFTER APPLYING ESP/UDP 210 -------------------------------------------------------------------- 211 IPv4 |new h.| UDP | Non-| ESP |orig IP hdr | | | ESP | ESP| 212 |(opts)| Hdr | IKE | Hdr |(any options)| TCP | Data | Trailer |Auth| 213 -------------------------------------------------------------------- 214 |<------------ encrypted ----------->| 215 |<------------- authenticated ------------>| 217 1) Ordinary ESP encapsulation procedure is used. 218 2) A properly formatted UDP header and a Non-IKE Marker 219 are inserted where shown. 220 3) The Total Length, Protocol and Header Checksum fields in the 221 new IP header are edited to match the resulting IP packet. 223 3.5 Tunnel Mode ESP Decapsulation 225 1) The UDP header and the Non-IKE Marker are removed from 226 the packet. 227 2) The Total Length, Protocol and Header Checksum fields in the 228 new IP header are edited to match the resulting IP packet. 229 3) Ordinary ESP decapsulation procedure is used. 230 4) Tunnel mode decapsulation NAT procedure is used. 232 4. NAT Keepalive Procedure 234 The sole purpose of sending NAT-keepalive packets is to keep 235 NAT mappings alive for the duration of a connection between 236 the peers. Reception of NAT-keepalive packets MUST NOT be 237 used to detect liveness of a connection. 239 A peer MAY send a NAT-keepalive packet if there exists one 240 or more phase I or phase II SAs between the peers, or such 241 an SA has existed at most N minutes earlier. N is a locally 242 configurable parameter with a default value of 5 minutes. 244 A peer SHOULD send a NAT-keepalive packet if a need to send such 245 packets is detected according to [Kiv00] and if no other packet to 246 the peer has been sent in M seconds. M is a locally configurable 247 parameter with a default value of 20 seconds. 249 5. Usage with Another Key Management Protocol 251 5.1. Requirements 253 The important requirements when using the encapsulation method 254 with another key management protocol are: 255 a) It must be possible to distinguish key management packets 256 from ESP packets. 257 b) If more than one UDP port pair is being used, all the relevant 258 NAT mappings must be kept alive. 260 5.2. Alternative Encapsulation Method 1 - Common Port 262 ----------------------------------------------------------- 263 IPv4 | IP hdr | UDP | ESP | ...ESP packet... | 264 |(options)| Hdr | Hdr | | 265 ----------------------------------------------------------- 267 ----------------------------------------------------------- 268 IPv4 | IP hdr | UDP | Non-| ...key management packet... | 269 |(options)| Hdr | ESP | | 270 ----------------------------------------------------------- 272 Non-ESP marker in this case is 4 bytes of zero. The same port pair 273 is used for both types of traffic, and the keepalive mechanism is as 274 defined in this document for IKE traffic. It is required that an 275 implementation using this method does not use ESP SPIs that are equal 276 to zero. 278 This method is more efficient than the one defined for IKE traffic 279 because it makes the more frequent packets smaller. 281 5.2. Alternative Encapsulation Method 2 - Separate Ports 283 ----------------------------------------------------------- 284 IPv4 | IP hdr | UDP | ESP | ...ESP packet... | 285 |(options)| Hdr | Hdr | | 286 ----------------------------------------------------------- 288 ----------------------------------------------------------- 289 IPv4 | IP hdr | UDP | ...key management packet... | 290 |(options)| Hdr | | 291 ----------------------------------------------------------- 293 In this method the two types of traffic use different UDP ports, so 294 no non-something markers are needed. Both UDP ports must be kept 295 alive using the keepalive procedure. 297 Whether or not this results in better bandwidth utilization than 298 using a common UDP port depends on the traffic characteristics. There 299 is less overhead per packet, but more need for keepalive packets. 301 6. Intellectual Property Rights 303 The IETF has been notified of intellectual property rights claimed in 304 regard to some or all of the specification contained in this document. 305 For more information consult the online list of claimed rights. 307 SSH Communications Security Corp has notified the working group of one 308 or more patents or patent applications that may be relevant to this 309 internet-draft. SSH Communications Security Corp has already given a 310 licence for those patents to the IETF. For more information consult the 311 online list of claimed rights. 313 7. Acknowledgments 315 Thanks to Joern Sierwald, Tamir Zegman, Larry DiBurro, Tatu Ylonen 316 and Santeri Paavolainen who contributed to the previous drafts 317 about NAT traversal. 319 8. References 321 [RFC 768] Postel, J., "User Datagram Protocol", August 1980 323 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 324 Requirement Levels", March 1997 326 [RFC 2406] Kent, S., "IP Encapsulating Security Payload (ESP)", 327 November 1998 329 [Dixon00] Dixon, W. et. al., 330 draft-ietf-ipsec-udp-encaps-justification-00.txt, 331 "IPSec over NAT Justification for UDP Encapsulation", June 2001 333 [Kiv00] Kivinen, T. et. al., draft-ietf-ipsec-nat-t-ike-00.txt, 334 "Negotiation of NAT-Traversal in the IKE", June 2001 336 9. Authors' Addresses 338 Ari Huttunen 339 F-Secure Corporation 340 Tammasaarenkatu 7 341 FIN-00181 HELSINKI 342 Finland 343 E-mail: Ari.Huttunen@F-Secure.com 345 William Dixon 346 Microsoft 347 One Microsoft Way 348 Redmond WA 98052 349 E-mail: wdixon@microsoft.com 351 Brian Swander 352 Microsoft 353 One Microsoft Way 354 Redmond WA 98052 355 E-mail: briansw@microsoft.com 357 Tero Kivinen 358 SSH Communications Security Corp 359 Fredrikinkatu 42 360 FIN-00100 HELSINKI 361 Finland 362 E-mail: kivinen@ssh.fi 364 Markus Stenberg 365 SSH Communications Security Corp 366 Fredrikinkatu 42 367 FIN-00100 HELSINKI 368 Finland 369 E-mail: mstenber@ssh.com 371 Victor Volpe 372 Cisco Systems 373 124 Grove Street 374 Suite 205 375 Franklin, MA 02038 376 E-mail: vvolpe@cisco.com 378 Larry DiBurro 379 Nortel Networks 380 80 Central Street 381 Boxborough, MA 01719 382 ldiburro@nortelnetworks.com