idnits 2.17.1 draft-ietf-mobileip-nat-traversal-04.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 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 (May 2002) is 8016 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: '4' is defined on line 1325, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '3') ** Downref: Normative reference to an Experimental RFC: RFC 1768 (ref. '4') ** Obsolete normative reference: RFC 3220 (ref. '10') (Obsoleted by RFC 3344) -- Obsolete informational reference (is this intentional?): RFC 1826 (ref. '11') (Obsoleted by RFC 2402) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Levkowetz 3 Internet-Draft ipUnplugged 4 Expires: October 30, 2002 S. Vaarala 5 Netseal 6 May 2002 8 Mobile IP NAT/NAPT Traversal using UDP Tunnelling 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 30, 2002. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 Mobile IP's datagram tunnelling is incompatible with Network Address 41 Translation (NAT). This document presents extensions to the Mobile 42 IP protocol and a tunnelling method which permits mobile nodes using 43 Mobile IP to operate in private address networks which are separated 44 from the public internet by NAT devices. The NAT traversal is based 45 on using the Mobile IP Home Agent UDP port for encapsulated data 46 traffic. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.2 Problem description . . . . . . . . . . . . . . . . . . . . 5 53 1.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2. NAT Traversal Overview . . . . . . . . . . . . . . . . . . . 6 56 2.1 Basic Message Sequence . . . . . . . . . . . . . . . . . . . 6 58 3. New Message Formats . . . . . . . . . . . . . . . . . . . . 7 59 3.1 UDP Tunnel Request Extension . . . . . . . . . . . . . . . . 7 60 3.1.1 F (Force) Flag . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.1.2 R (Registration through FA Required) flag . . . . . . . . . 9 62 3.1.3 Reserved Fields . . . . . . . . . . . . . . . . . . . . . . 9 63 3.1.4 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.1.5 Mobile IP Registration Bits . . . . . . . . . . . . . . . . 9 65 3.2 UDP Tunnel Reply Extension . . . . . . . . . . . . . . . . . 10 66 3.2.1 Reply Code . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 3.3 MIP Tunnel Data Message . . . . . . . . . . . . . . . . . . 11 68 3.4 UDP Tunnelling Flag in Agent Advertisements . . . . . . . . 12 69 3.5 New Registration Reply Codes . . . . . . . . . . . . . . . . 13 71 4. Protocol Behaviour . . . . . . . . . . . . . . . . . . . . . 13 72 4.1 Relation to standard MIP tunnelling . . . . . . . . . . . . 13 73 4.2 Encapsulating IP Headers in UDP . . . . . . . . . . . . . . 14 74 4.3 Decapsulation . . . . . . . . . . . . . . . . . . . . . . . 15 75 4.4 Mobile Node Considerations . . . . . . . . . . . . . . . . . 15 76 4.5 Foreign Agent Considerations . . . . . . . . . . . . . . . . 17 77 4.6 Home Agent Considerations . . . . . . . . . . . . . . . . . 18 78 4.6.1 Error Handling . . . . . . . . . . . . . . . . . . . . . . . 19 79 4.7 MIP signalling versus tunnelling . . . . . . . . . . . . . . 21 80 4.8 Packet fragmentation . . . . . . . . . . . . . . . . . . . . 21 81 4.9 Tunnel Keepalive . . . . . . . . . . . . . . . . . . . . . . 22 82 4.10 Co-located registration through FA . . . . . . . . . . . . . 23 84 5. Implementation Issues . . . . . . . . . . . . . . . . . . . 24 85 5.1 Movement Detection and Private Address Aliasing . . . . . . 24 86 5.2 Mobility Binding Lifetime . . . . . . . . . . . . . . . . . 25 88 6. Security Considerations . . . . . . . . . . . . . . . . . . 25 89 6.1 Traffic Redirection Vulnerabilities . . . . . . . . . . . . 26 90 6.1.1 Manipulation of the Registration Request Message . . . . . . 26 91 6.1.2 Sending a Bogus Keepalive Message . . . . . . . . . . . . . 26 92 6.2 Use of IPsec . . . . . . . . . . . . . . . . . . . . . . . . 27 93 6.3 Firewall Considerations . . . . . . . . . . . . . . . . . . 27 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 96 8. Intellectual property rights . . . . . . . . . . . . . . . . 28 98 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 99 Normative References . . . . . . . . . . . . . . . . . . . . 29 100 Informative References . . . . . . . . . . . . . . . . . . . 30 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 102 Full Copyright Statement . . . . . . . . . . . . . . . . . . 31 104 1. Introduction 106 1.1 Terminology 108 The Mobile IP related terminology described in RFC 3220 [10] is used 109 in this document. In addition, the following terms are used: 111 Forward Tunnel 112 A tunnel that forwards packets towards the mobile node. It 113 starts at the home agent, and ends at the mobile node's care-of 114 address. 116 Reverse Tunnel 117 A tunnel that starts at the mobile node's care-of address and 118 terminates at the home agent. 120 NAT 121 Network Address Translation. "Traditional NAT would allow 122 hosts within a private network to transparently access hosts in 123 the external network, in most cases. In a traditional NAT, 124 sessions are uni-directional, outbound from the private 125 network." -- RFC 2663 [12]. Basic NAT and NAPT are two 126 varieties of NAT. 128 Basic NAT 129 "With Basic NAT, a block of external addresses are set aside 130 for translating addresses of hosts in a private domain as they 131 originate sessions to the external domain. For packets 132 outbound from the private network, the source IP address and 133 related fields such as IP, TCP, UDP and ICMP header checksums 134 are translated. For inbound packets, the destination IP 135 address and the checksums as listed above are translated." -- 136 RFC 2663 [12] 138 NAPT 139 Network Address Port Translation. "NAPT extends the notion of 140 translation one step further by also translating transport 141 identifier (e.g., TCP and UDP port numbers, ICMP query 142 identifiers). This allows the transport identifiers of a 143 number of private hosts to be multiplexed into the transport 144 identifiers of a single external address. NAPT allows a set of 145 hosts to share a single external address. Note that NAPT can 146 be combined with Basic NAT so that a pool of external addresses 147 are used in conjunction with port translation." -- RFC 2663 148 [12] 150 In this document, the more general term NAT is used to cover both 151 NATs and NAPTs. In most deployment cases today, we believe that the 152 NATs used are of the NAPT variety. 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [7]. 158 1.2 Problem description 160 A basic assumption that Mobile IP [10] makes is that mobile nodes and 161 foreign agents are uniquely identifiable by a routable IP address. 162 This assumption breaks down when a mobile node attempts to 163 communicate from behind a NAT. 165 Mobile IP relies on sending traffic from the home network to the 166 mobile node or foreign agent through IP-in-IP tunnelling. IP nodes 167 which communicate from behind a NAT are reachable only through the 168 NAT's public address(es). IP-in-IP tunnelling does not generally 169 contain enough information to permit unique translation from the 170 common public address(es) to the particular care-of address of a 171 mobile node or foreign agent which resides behind the NAT. For this 172 reason, IP-in-IP tunnels cannot in general pass through a NAT, and 173 Mobile IP will not work across a NAT. 175 Mobile IP's Registration Request and Reply will on the other hand be 176 able to pass through NATs and NAPTs on the mobile node or foreign 177 agent side, as they are UDP datagrams originated from the inside of 178 the NAT or NAPT. When passing out, they make the NAT set up an 179 address/port mapping through which the Registration Request will be 180 able to pass in to the correct recipient. The current Mobile IP 181 protocol does however not permit a registration where the mobile 182 node's IP source address is not either the CoA, the Home Address, or 183 0.0.0.0. 185 What is needed is an alternative data tunnelling mechanism for Mobile 186 IP which will provide the means needed for NAT devices to do unique 187 mappings so that address translation will work, and a registration 188 mechanism which will permit such an alternative tunnelling mechanism 189 to be set up when appropriate. 191 1.3 Assumptions 193 The primary assumption in this document is that the network allows 194 communication between an UDP port chosen by the mobile node and the 195 home agent UDP port 434. If this assumption does not hold, neither 196 Mobile IP registration nor data tunnelling will work. 198 This document does NOT assume that mobility is constrained to a 199 common IP address space. On the contrary, the routing fabric between 200 the mobile node and the home agent may be partitioned into a 201 "private" and a "public" network, and the assumption is that some 202 mechanism is needed in addition to vanilla Mobile IP according to RFC 203 3220 [10] in order to achieve mobility within disparate IP address 204 spaces. 206 For a more extensive discussion of the problems with disparate 207 address spaces, and how they may be solved, see RFC 3024 [9]. 209 The reverse tunnels considered here are symmetric, that is, they use 210 the same configuration (encapsulation method, IP address endpoints) 211 as the forward tunnel. 213 2. NAT Traversal Overview 215 This section gives a brief overview of the MIP UDP tunnelling 216 mechanism which may be used to achieve NAT traversal for Mobile IP. 218 In MIP UDP tunnelling, the mobile node may use an extension 219 (described below) in its Registration Request to indicate that it is 220 able to use Mobile IP UDP tunnelling instead of standard Mobile IP 221 tunnelling if the home agent sees that the Registration Request seems 222 to have passed through a NAT. The home agent may then send a 223 registration reply with an extension indicating acceptance (or 224 denial). After assent from the home agent, MIP UDP tunnelling will 225 be available for use for both forward and reverse tunnelling. UDP 226 tunnelled packets sent by the mobile node use the same ports as the 227 registration request message. In particular, the source port may 228 vary between new registrations, but remains the same for all 229 tunnelled data and re-registrations. The destination port is always 230 434. UDP tunnelled packets sent by the home agent uses the same 231 ports, but in reverse. 233 2.1 Basic Message Sequence 235 The message sequence diagram below exemplifies setting up and using a 236 Mobile IP UDP tunnel as described in this document. The tunnel is 237 set up by the use of specific extensions in the initial Mobile IP 238 Registration Request and Reply exchange. Thereafter, any traffic 239 from the home agent to the mobile node is sent through the UDP 240 tunnel. The mobile node may at its discretion use the UDP tunnel for 241 reverse tunnelling or not, although in most cases where MIP UDP 242 tunnelling is needed, reverse tunnelling will also be needed. 244 mobile node NAT home agent 245 | | | 246 | | | 247 | Registration | | 248 | Request with | | 249 |-----------------///--------------->>| 250 |UDP Tunnel Request| | 251 | | + 252 | | || IP Source and 253 | | || CCoA address 254 | | || discrepancy 255 | | || seen 256 | | Registration + 257 | | Reply with | 258 |<<---------------///-----------------| 259 | | UDP Tunnel Reply.| 260 | | | 261 | UDP tunnelled pkg| | 262 |=================///===============>>| 263 | | UDP tunnelled pkg| 264 |<<===============///=================| 265 | | ||absence of 266 | | ||traffic for 267 | | ||UDP keepalive 268 | UDP keepalive | ||period 269 |-----------------///--------------->>+ 270 . . + 271 . . . 272 . . . 274 3. New Message Formats 276 3.1 UDP Tunnel Request Extension 278 This extension is a skippable Extension. It signifies that the 279 sender is capable of handling MIP UDP tunnelling, and optionally that 280 a particular encapsulation format is requested in the MIP UDP tunnel. 281 The format of this extension is as shown below. It adheres to the 282 short extension format described in [10]. 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Type | Length | Sub-Type | Reserved 1 | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 |F|R| Reserved 2| Encapsulation | Reserved 3 | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Type (to be assigned by IANA) (skippable). 293 Length 6. Length in bytes of this extension, not 294 including the Type and Length bytes. 296 Sub-Type (to be assigned by IANA) 298 Reserved 1 Reserved for future use. MUST be set to 0 on 299 sending, MUST be ignored on reception. 301 F F (Force) flag. Indicates that the mobile 302 node wants to force MIP UDP tunnelling to be 303 established. 305 R R (Registration through FA Required) flag. 306 Indicates that the R bit was set in the FA's 307 Agent Advertisement. Registration is being 308 made using a co-located care-of address, but 309 through the FA. 311 Reserved 2 Reserved for future use. MUST be set to 0 on 312 sending, MUST be ignored on reception. 314 Encapsulation Indicates the type of tunnelled data, using 315 the same numbering as the IP Header Protocol 316 Field. 318 Reserved 3 Reserved for future use. MUST be set to 0 on 319 sending, any bit not understood MUST be 0 on 320 receipt. 322 3.1.1 F (Force) Flag 324 Indicates that the mobile node wants to use traversal regardless of 325 the outcome of NAT detection performed by the home agent. This is 326 useful if the route between the mobile node and the home agent works 327 for Mobile IP signalling packets, but not for generic data packets 328 (e.g. because of firewall filtering rules). If the home agent 329 supports this protocol, it SHOULD either accept the traversal and 330 reply with a UDP Tunnel Reply Extension or reject the Registration 331 Request. In case of failed registrations the Home Agent SHOULD send 332 a Registration Reply with Code field set to 129 ("administratively 333 prohibited"). 335 If the HA does not understand the UDP Tunnel Request Extension, it 336 will silently discard it, and if everything else is fine, it will 337 reply with a registration reply with reply code 0 (registration 338 accepted), but without any UDP Tunnel Reply Extension. In this case, 339 the mobile node MUST NOT use MIP UDP tunnelling. 341 3.1.2 R (Registration through FA Required) flag 343 This flag MUST be set by the mobile node when it is using a co- 344 located address, but registering through an FA because it has 345 received an Agent Advertisement with the 'R' bit set. 347 3.1.3 Reserved Fields 349 The 'Reserved 1' and 'Reserved 2' fields must be ignored on receipt, 350 while the 'Reserved 3' field must be 0 on receipt, otherwise this 351 extension MUST be ignored and silently skipped. This permits future 352 additions to this extension to be made which either can co-exist with 353 old implementations, or will force a rejection of the extension from 354 an old implementation. 356 3.1.4 Encapsulation 358 The 'Encapsulation' field defines the mode of encapsulation requested 359 if MIP UDP tunnelling is accepted by the home agent. This field uses 360 the same values as the IP header Protocol field: 362 4 IP header (IP-in-UDP tunnelling) RFC 2003 [5] 364 47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8] 366 55 Minimal IP encapsulation header RFC 2004 [6] 368 If the home agent finds that UDP tunnelling is not needed, the 369 encapsulation will be determined by the 'M' and 'G' flags of the 370 registration request; but if the home agent finds that MIP UDP 371 tunnelling should be done, the encapsulation is determined from the 372 value of the Encapsulation field. If the value of this field is 373 zero, it defaults to the value of 'M' and 'G' fields in the 374 Registration Request message, but if it is non-zero, it indicates 375 that a particular encapsulation is desired. 377 3.1.5 Mobile IP Registration Bits 379 The Mobile IP registration bits S, B, D, M, G and T retain their 380 meaning as described in RFC 3220 [10] and RFC 3024 [9] (except that 381 the significance of the M and G bits may be modified by the 382 Encapsulation field when MIP UDP tunnelling is used, as described 383 above). The use of the M and G bits together with MIP UDP tunnelling 384 is also touched upon in Section 4.1. 386 When the MN requests MIP UDP tunnelling, the 'D' bit (Decapsulation 387 by the mobile node) MUST be set, otherwise UDP tunnelling would not 388 be meaningful. 390 Both the MN and the FA SHOULD set the 'T' bit when requesting MIP UDP 391 tunnelling, even if not all traffic will be reverse tunnelled. This 392 ensures that a HA which is not prepared to accept reverse tunnelling 393 will not accept a registration which may later turn out to be 394 unusable. Also see the discussion of use of the 'T' bit in Foreign 395 Agent Considerations (Section 4.5). 397 3.2 UDP Tunnel Reply Extension 399 This extension is a non-skippable extension. It is sent in reply to 400 a UDP Tunnel Request extension, and indicates whether or not the HA 401 will use MIP UDP tunnelling for the current mobility binding. The 402 format of this extension is as shown below. 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Type | Length | Sub-Type | Reply Code | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 |F|r|E| Reserved 2 | Keepalive Interval | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 Type (to be assigned by IANA) (non-skippable) 414 Length 6. Length in bytes of this extension, not 415 including the Type and Length bytes. 417 Sub-Type (to be assigned by IANA) 419 Reply Code Indicates whether the HA assents or declines 420 to use UDP tunnelling for the current mobility 421 binding. See Section 3.2.1 below. 423 F F (Forced) flag. Indicates that tunnelling is 424 being forced because the F flag was set in the 425 tunnelling request, irrespective of the 426 detection of a NAT or not. 428 E E (Echo) flag. Indicates that icmp echo 429 requests and replies should be used for 430 keepalive messages, rather than registration 431 requests/replies. 433 Keepalive Interval Specifies the NAT keepalive interval that the 434 mobile node SHOULD use. A keepalive packet 435 SHOULD be sent if Keepalive Interval seconds 436 have elapsed without any signalling or data 437 traffic being sent. If this field is set to 438 0, the mobile node MUST use its default 439 configured keepalive interval. 441 r Reserved for future use. MUST be set to 0 on 442 sending, MUST be ignored on reception. 444 Reserved 2 Reserved for future use. MUST be set to 0 on 445 sending, MUST be ignored on reception. 447 3.2.1 Reply Code 449 The Reply Code field of the UDP Tunnel Reply Extension indicates if 450 UDP tunnelling have been accepted and will be used by the HA. Values 451 in the range 0 .. 63 indicate assent, i.e. that tunnelling will be 452 done, while values in the range 64 .. 255 indicate that tunnelling 453 should not be done. More information may be given by the value of 454 the response code. 456 The following response codes are defined for use in the code field of 457 the UDP Tunnel Reply Extension: 459 0 Will do tunnelling 461 64 Tunnelling declined, reason unspecified 463 3.3 MIP Tunnel Data Message 465 This MIP message header serves to differentiate traffic tunnelled 466 through the well-known port 434 from other Mobile IP messages, e.g. 467 Registration Requests and Registration Replies. 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Type | Next Header | Reserved | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Type (to be assigned by IANA) 477 Next Header Indicates the type of tunnelled data, using 478 the same numbering as the IP Header Protocol 479 Field. 481 Reserved Reserved for future use. MUST be set to 0 on 482 sending, MUST be ignored on reception. 484 The Next Header field uses the same values as the IP header Protocol 485 field. Immediately relevant for use with Mobile IP are the following 486 values: 488 4 IP header (IP-in-UDP tunnelling) RFC 2003 [5] 490 47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8] 492 55 Minimal IP encapsulation header RFC 2004 [6] 494 The receiver of a tunnelled packet MUST check that the Next Header 495 value matches the tunnelling mode established for the mobility 496 binding with which the packet was sent. If a discrepancy is 497 detected, the packet MUST be dropped. A log entry MAY be written, 498 but in this case the receiver SHOULD ensure that the amount of log 499 entries written is not excessive. 501 In addition to the encapsulation forms listed above, the MIP UDP 502 tunnelling can potentially support other encapsulations, by use of 503 the Next Header field in the MIP Tunnel Data Header and the 504 Encapsulation Header field of the UDP Tunnel Request Extension 505 (Section 3.1). 507 3.4 UDP Tunnelling Flag in Agent Advertisements 509 The only change to the Mobility Agent Advertisement Extension defined 510 in RFC 3220 [10] is a flag indicating that the foreign agent 511 generating the Agent Advertisement supports MIP UDP Tunnelling. The 512 flag is inserted after the flags defined in [10]. 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Type | Length | Sequence Number | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Lifetime |R|B|H|F|M|G|r|T|U| reserved | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | zero or more Care-of Addresses | 522 | ... | 524 The flag is defined as follows: 526 U UDP Tunnelling support. This Agent supports MIP UDP 527 Tunnelling as specified in this document. This flag SHOULD 528 be set in advertisements sent by a foreign agent which 529 supports MIP UDP tunnelling and is situated behind a NAT. 530 It MUST NOT be set in advertisements from foreign agents 531 which are not situated behind a NAT, and thus has no need to 532 advertise the capability. 534 3.5 New Registration Reply Codes 536 One new registration reply code is defined: 538 ERROR_HA_UDP_ENCAP_UNAVAIL Requested UDP tunnel encapsulation 539 unavailable 541 This is used by the HA to distinguish the registration denial caused 542 by an unavailable UDP tunnel encapsulation mode from a denial caused 543 by unavailable standard tunnel encapsulation requested by use of the 544 'T' bit together with either 'M' or 'G' bit. 546 4. Protocol Behaviour 548 4.1 Relation to standard MIP tunnelling 550 The default encapsulation mode for MIP UDP tunnelling is IP-in-UDP 551 encapsulation. The mobile node MAY request alternative forms of 552 encapsulation to be used with UDP tunnelling by setting the 'M' bit 553 and/or the 'G' bit of a Mobile IP registration request, or by 554 explicitly requesting a particular encapsulation for the MIP UDP 555 tunnel by using the Encapsulation field. The M and G bits retain the 556 meaning as described in RFC 3220 [10] within the context of MIP UDP 557 tunnelling. The UDP tunnelling version of the classic MIP 558 encapsulation methods can be summarised as: 560 IP in UDP. When Mobile IP UDP tunnelling is used, this is the 561 default encapsulation type. Any home agent and mobile node 562 that implements Mobile IP UDP tunnelling MUST implement this 563 encapsulation type. 565 GRE in UDP. If the 'G' bit is set in a registration request and 566 the Encapsulation field is zero, the mobile node requests that 567 its home agent use GRE encapsulation [3] for datagrams 568 tunnelled to the mobile node. If MIP UDP tunnelling is also 569 requested and accepted, GRE-in-UDP encapsulation SHALL be used 570 in the same cases as GRE in IP encapsulation would be used if 571 the MIP UDP tunnelling had not been requested. 573 Minimal encapsulation in UDP. If the 'M' bit is set and the 574 Encapsulation field is zero, the mobile node requests that its 575 home agent use minimal encapsulation [6] for datagrams 576 tunnelled to the mobile node. If MIP UDP tunnelling is also 577 used, minimal encapsulation in UDP SHALL be used in the same 578 cases as minimal encapsulation according to RFC 2004 [6] would 579 be used if the MIP UDP tunnelling had not been requested. 581 When the Encapsulation field is non-zero, a particular encapsulation 582 format is requested for the MIP UDP tunnel. If tunnelling is 583 indicated, the request MUST either be accepted using the requested 584 encapsulation, or rejected with the error code 585 ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel encapsulation 586 unavailable" defined in Section 3.5. On receipt of this error, the 587 mobile node MAY choose to send a new Registration Request with 588 different requirements on MIP UDP tunnelling encapsulation. 590 4.2 Encapsulating IP Headers in UDP 592 MIP IP-in-UDP tunnelling, or UDP tunnelling for short, is done in a 593 manner analogous to that described for IP-in-IP tunnelling in RFC 594 2003 [5], with the exception of the addition of an UDP header [1] and 595 IP Message header [10] between the outer and inner IP header. 597 Mobile IP Registration Requests and Registration Replies are already 598 in the form of UDP messages, and SHALL NOT be tunnelled even when MIP 599 IP-in-UDP tunnelling is in force. 601 To encapsulate an IP datagram using MIP IP-in-UDP encapsulation, an 602 outer IP header [2], UDP header [1] and MIP Message header [10] is 603 inserted before the datagram's existing IP header, as follows: 605 +---------------------------+ 606 | | 607 | Outer IP Header | 608 +---------------------------+ 609 | | 610 | UDP Header | 611 +---------------------------+ 612 | MIP Tunnel Data | 613 | Message Header | 614 +---------------------------+ +---------------------------+ 615 | | | | 616 | IP Header | | IP Header | 617 +---------------------------+ ====> +---------------------------+ 618 | | | | 619 | IP Payload | | IP Payload | 620 | | | | 621 | | | | 622 +---------------------------+ +---------------------------+ 624 The outer IP header Source Address and Destination Address, together 625 with the UDP header Source Port and Destination Port, identify the 626 "endpoints" of the tunnel. The inner IP header Source Address and 627 Destination Addresses identify the original sender and the recipient 628 of the datagram, respectively. The inner IP header is not changed by 629 the encapsulator, except to decrement the TTL by one if the 630 tunnelling is being done as part of forwarding the datagram as noted 631 in RFC 2003 [5], and remains unchanged during its delivery to the 632 tunnel exit point. No change to IP options in the inner header 633 occurs during delivery of the encapsulated datagram through the 634 tunnel. If need be, other protocol headers such as the IP 635 Authentication Header [11] may be inserted between the outer IP 636 header and the UDP header. Note that the security options of the 637 inner IP header MAY affect the choice of security options for the 638 encapsulating (outer) IP header. 640 Minimal Encapsulation and GRE encapsulation is done in an analogous 641 manner, following RFC 2004 [6] for Minimal Encapsulation and RFC 2784 642 [8] for GRE Encapsulation, but using outer IP, UDP and MIP headers in 643 place of the outer IP header. 645 All other provisions and requirements of RFC 2003 [5] and RFC 3024 646 [9] are in force, except in one respect, as covered in Packet 647 Fragmentation (Section 4.8). 649 4.3 Decapsulation 651 IP-in-UDP encapsulated traffic is processed by the receiver simply by 652 stripping of the outer IP, UDP and MIP header, which leaves the 653 original IP packet which is forwarded as is. 655 Minimal IP encapsulation is processed by the receiver conceptually as 656 follows. First, the UDP and the Mobile IP headers are removed from 657 the packet, and the Protocol field of the IP header replaced with the 658 Next Header field in the MIP Tunnel Data header. Second, the 659 remaining IP header total length and checksum are adjusted to match 660 the stripped packet. Third, ordinary minimal IP encapsulation 661 processing is done. 663 GRE encapsulated traffic is processed according to RFC 2784 [8] and 664 RFC 1701 [3], with the delivery header consisting of the outer IP, 665 UDP and MIP headers. 667 4.4 Mobile Node Considerations 669 The UDP Tunnel Request Extension MAY be used in a Mobile IP 670 Registration Request from the mobile node to the home agent when the 671 mobile node uses a co-located care-of address. It SHALL NOT be used 672 by the mobile node when it is registering with a foreign agent care- 673 of address. 675 The purpose of this extension is to indicate to the home agent that 676 the mobile node is able to accept MIP UDP tunnelling if the home 677 agent has an indication that the mobile node resides behind a NAT or 678 NAPT. It thus functions as a conditional solicitation for the use of 679 MIP UDP tunnelling. 681 As per Section 3.2 and 3.6.1.3 of RFC 3220 [10], the mobile node MUST 682 place this Extension before the Mobile-Home Authentication Extension 683 in registration messages, so that it is covered by the Mobile-Home 684 Authentication Extension. 686 If the mobile node includes the UDP Tunnel Request extension in a 687 registration request, but receives a registration reply without a UDP 688 Tunnel Reply extension, it MUST assume that the HA does not 689 understand this extension, and it MUST NOT use UDP tunnelling. If 690 the mobile node is in fact behind a NAT, the registration may then 691 succeed, but traffic will not be able to traverse the NAT. 693 When the mobile node sends MIP UDP tunnelled data, it MUST use the 694 same UDP source port as was used for the original registration 695 request. 697 When the mobile node re-registers without having moved, it MUST take 698 care to use the same source port as was used for the original 699 registration of the current mobility binding. (This does not mean 700 that the home agent should refuse a registration request using MIP 701 UDP tunnelling where a new port have been used, as this might be the 702 result of the NAT dropping state, the mobile node re-booting, 703 changing interface, etc.) 705 If a mobile node is registering through a foreign agent but using a 706 co-located care-of address, and the agent advertisement from the 707 foreign agent had the 'U' bit set, the mobile node MUST set the 'R' 708 flag in its UDP Tunnel Request Extension, in order to make the HA use 709 MIP UDP tunnelling. In this case, the mobile node MUST send a 710 keepalive as soon as its registration has been accepted. The 711 keepalives to be used in this case MUST contain one UDP encapsulated 712 ICMP echo request with the home agent as destination address. 714 If a mobile node is registering through a foreign agent but using a 715 co-located care-of address, and the agent advertisement from the 716 foreign agent does not have the 'U' bit set, the mobile node MUST NOT 717 include a UDP Tunnel Request Extension in the registration request. 719 4.5 Foreign Agent Considerations 721 The UDP Tunnel Request Extension MAY be used by a foreign agent when 722 it is forwarding a Mobile IP Registration Request to a home agent, 723 when the foreign agent is situated behind a NAT or has some other 724 compelling reason to require MIP UDP tunnelling. 726 The purpose of this extension is to indicate to the home agent that 727 the foreign agent is able to accept MIP UDP tunnelling if the home 728 agent has an indication that the foreign agent resides behind a NAT 729 or NAPT. It thus functions as a conditional solicitation for the use 730 of MIP UDP tunnelling. 732 A foreign agent which requires the mobile node to register through a 733 foreign agent by setting the 'R' bit in the agent advertisement, MUST 734 NOT add the UDP Tunnel Request Extension when forwarding a 735 registration request which uses a co-located care-of address, as this 736 will lead to a UDP tunnel being set up from the home agent to the 737 foreign agent instead of to the mobile node. 739 As per Section 3.2 and 3.7.2.2 of RFC 3220 [10], the foreign agent 740 when using this extension MUST place it after the Mobile-Home 741 Authentication Extension in registration messages. If the foreign 742 agent shares a mobility security association with the home agent and 743 therefore appends a Foreign-Home Authentication Extension, the UDP 744 Tunnel Request Extension MUST be placed before the Foreign-Home 745 Authentication Extension. 747 As the home agent detects the presence of a NAT in the path between 748 the sender and itself by seeing a mismatch between the IP source 749 address and the care-of address given in the registration request, it 750 is REQUIRED that the foreign agent, when using this extension, sends 751 the registration request with an IP source address matching the care- 752 of address. Or in other words, the foreign agent should send the IP 753 packet on the interface having the care-of address. 755 A foreign agent using MIP UDP tunnelling to a home agent because it 756 is situated behind a NAT may be configured to encourage reverse 757 tunnelling, or be neutral about it, depending on the characteristics 758 of the NAT. If the NAT translates all source addresses of outgoing 759 packets to its own public address, it will not be possible to 760 maintain sessions when moving away from this network if the mobile 761 node has used triangular routing instead of reverse tunnelling. On 762 the other hand, if it is known that the NAT is smart enough to not 763 translate publicly routable source addresses, AND does not do ingress 764 filtering, triangular routing may succeed. The leg from the home 765 agent to the foreign agent will still use MIP UDP tunnelling to pass 766 through the NAT. 768 Therefore, if it is known when configuring a foreign agent behind a 769 NAT that the NAT will translate public as well as private addresses, 770 or it is known that ingress filtering is being done between the 771 private and public networks, the foreign agent SHOULD reply to 772 registration requests which don't have the 'T' bit set with a reply 773 code 75, "reverse tunnel is mandatory and 'T' bit not set". 775 Conversely, if it is known that the NAT is smart about not 776 translating public addresses, and no ingress filtering is done, so it 777 is reasonable to believe that a mobile node with a publicly routable 778 address may be able to keep up sessions when moving to or from this 779 network, the foreign agent MAY be configured to forward registration 780 requests even if they don't have the 'T' bit set. 782 If the behaviour of the NAT is unknown in this respect, it SHOULD be 783 assumed that it may translate all addresses, thus the foreign agent 784 SHOULD be configured to reply to registration requests which don't 785 have the 'T' bit set with a reply code 75, "reverse tunnel is 786 mandatory and 'T' bit not set". 788 4.6 Home Agent Considerations 790 The purpose of the MIP UDP Tunnel Reply Extension is to indicate 791 whether or not the home agent accepts the use of MIP UDP tunnelling 792 for this mobility binding, and to inform the mobile node or foreign 793 agent of the suggested tunnel keepalive interval to be used. 795 The UDP Tunnel Reply Extension MUST be used in a Mobile IP 796 Registration Reply from the home agent to the mobile node when it has 797 received and accepted a UDP Tunnel Request (Section 3.1) from a 798 mobile node. 800 The home agent MUST use a mismatch between source IP address and 801 care-of address in the Mobile IP Registration Request message as the 802 indication that a mobile node may reside behind a NAT. If the 803 Registration Request also contains the UDP Tunnel Request extension 804 without the 'R' flag set, and the home agent is capable of, and 805 permits MIP UDP tunnelling, the home agent SHALL respond with a 806 registration reply containing an assenting UDP Tunnel Reply Extension 807 as described in Section 3.2. If the 'R' flag is set, special 808 considerations apply, as described below. 810 If the home agent receives a Registration Request with matching 811 source IP address and co-located care-of address which contains a MIP 812 UDP Tunnel Request Extension, the home agent SHOULD respond with a 813 Registration Reply containing an declining UDP Tunnel Reply - unless 814 tunnelling has been explicitly requested by the mobile node using the 815 'F' flag as described in Section 3.1. 817 If the home agent assents to UDP tunnelling, it MUST use the source 818 address of the registration request as the effective care-of address, 819 rather than the care-of address given in the registration request, 820 except in the case where the 'R' flag is set in the UDP Tunnel 821 Request Extension. 823 If the home agent receives a Registration Request with the 'R' flag 824 set in the UDP Tunnel Request Extension, it SHOULD reply with an 825 assenting UDP Tunnel Reply Extension if it is capable of, and permits 826 MIP UDP tunnelling. In this case, however, the source address and 827 port of the registration request may be a NAT'ed version of the 828 foreign agent source address and port. In order to direct tunnelled 829 traffic correctly to the mobile node, the home agent MUST wait for 830 the first keepalive packet from the mobile node to arrive, before it 831 can send traffic back to the correct NAT port (the one which is 832 mapped to the MN). In this case, the home agent MUST check that the 833 outer source address (but not the port) of this keepalive packet is 834 identical with the source address of the corresponding registration 835 request. The inner source address (that of the encapsulated ICMP 836 echo request) MUST be the home address of the mobile node, and the 837 inner destination address MUST be that of the home agent. If all 838 this holds, the outer source address and port of this keepalive 839 packet SHALL be used by the HA as the outer destination address and 840 port of the MIP UDP tunnel when forwarding traffic to the mobile 841 node. 843 The home agent MUST be consistent in acknowledging support for UDP 844 tunnelling or not. A home agent which understands the UDP Tunnel 845 Request Extension and is prepared to respond positively to such a 846 request MUST also respond with a UDP Tunnel Reply Extension 847 containing a declining reply code if use of MIP UDP tunnelling is not 848 indicated for a session. The mobile node MUST NOT assume such 849 behaviour from the home agent, since the home agent may undergo a 850 software change and reboot, and consequently change behaviour. 852 4.6.1 Error Handling 854 The following actions take place when things go wrong. 856 The HA does not support the UDP Tunnel Request extension: 858 The home agent ignores the extension and proceeds normally, 859 which would be to refuse the registration if the IP source 860 address does not match the care-of address, the home address or 861 0.0.0.0. Even if the HA mistakenly does accept the 862 registration, the mobile node will not be able to receive 863 forward tunnelled data if it is behind a NAT. 865 (It would be beneficial to have the mobile node de-register in 866 this case. The mobile node, however, normally has no way of 867 telling that it is behind a NAT if it does not receive a UDP 868 Tunnelling Reply.) 870 NAT detected by home agent, but traversal not allowed: 872 In some cases the home agent may disable NAT traversal even 873 though it supports the UDP Tunnel Request extension and a NAT 874 is detected. In this case, the home agent SHOULD send a 875 Registration Reply with the Code field set to 129, 876 "administratively prohibited". 878 NAT not detected, 'F' flag set, but home agent does not allow forced 879 use of MIP UDP tunnelling: 881 The home agent SHOULD send a Registration Reply with the Code 882 field set to 129, "administratively prohibited". 884 UDP Tunnel Request extension sent by the mobile node, but 'D' bit in 885 registration request header not set: 887 The home agent SHOULD send a Registration Reply with the Code 888 field set to 134, "poorly formed Request". 890 UDP Tunnel Request extension sent by the foreign agent, but 'D' bit 891 is set: 893 The home agent SHOULD send a Registration Reply with the Code 894 field set to 134, "poorly formed Request". 896 Reserved 3 field of UDP Tunnel Request extension is nonzero and the 897 home agent does not recognize the value: 899 The home agent SHOULD send a Registration Reply with the Code 900 field set to 134, "poorly formed Request". 902 Encapsulation type requested in UDP Tunnel Request extension is 903 unsupported. 905 The home agent SHOULD send a Registration Reply with the Code 906 field set to ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel 907 encapsulation unavailable" defined in Section 3.5. 909 4.7 MIP signalling versus tunnelling 911 UDP tunnelling SHALL be used only for data packets, and only when the 912 mobility binding used for sending was established using the UDP 913 Tunnel Request, and accepted by an UDP Tunnel Reply from the home 914 agent. After MIP UDP tunnelling has been established for a mobility 915 binding, data packets that are forward or reverse tunnelled using 916 this mobility binding MUST be tunnelled using MIP UDP tunnelling, not 917 IP-in-IP tunnelling or some other tunnelling method. 919 As a consequence: 921 - Mobile IP signalling is never tunnelled. 923 - When using simultaneous bindings, each binding may have a 924 different type (i.e. UDP tunnelling bindings may be mixed with 925 non-UDP tunnelling bindings). 927 - Tunnelling is only allowed for the duration of the binding 928 lifetime. 930 4.8 Packet fragmentation 932 From RFC 3022 [13]: 934 "Translation of outbound TCP/UDP fragments (i.e., those originating 935 from private hosts) in NAPT set-up are doomed to fail. The reason is 936 as follows. Only the first fragment contains the TCP/UDP header that 937 would be necessary to associate the packet to a session for 938 translation purposes. Subsequent fragments do not contain TCP/UDP 939 port information, but simply carry the same fragmentation identifier 940 specified in the first fragment. Say, two private hosts originated 941 fragmented TCP/UDP packets to the same destination host. And, they 942 happened to use the same fragmentation identifier. When the target 943 host receives the two unrelated datagrams, carrying same 944 fragmentation id, and from the same assigned host address, it is 945 unable to determine which of the two sessions the datagrams belong 946 to. Consequently, both sessions will be corrupted." 948 Because of this, if the mobile node or foreign agent for any reason 949 needs to send fragmented packets, the fragmentation MUST be done 950 prior to the encapsulation. This differs from the case for IP-in-IP 951 tunnelling, where fragmentation may be done before or after 952 encapsulation, although RFC 2003 [5] recommends doing it before 953 encapsulation. 955 A similar issue exists with some firewalls, which may have rules that 956 only permit traffic on certain TCP and UDP ports, and not arbitrary 957 outbound (or inbound) IP traffic. If this is the case and the 958 firewall is not set to do packet reassembly, a home agent behind a 959 firewall will also have to do packet fragmentation before MIP UDP 960 encapsulation. Otherwise, only the first fragment (which contains 961 the UDP header) will be allowed to pass from the home agent out 962 through the firewall. 964 For this reason, the home agent SHOULD do packet fragmentation before 965 it does MIP UDP encapsulation. 967 4.9 Tunnel Keepalive 969 As the existence of the bi-directional UDP tunnel through the NAT is 970 dependent on the NAT keeping state information associated with a 971 session, as described in RFC 2663 [12], and as the NAT may decide 972 that the session has terminated after a certain time, keepalive 973 messages may be needed to keep the tunnel open. The keepalives 974 should be sent more often than the timeout value used by the NAT. 975 This timeout may be assumed to be a couple of minutes, according to 976 RFC 2663 [12], but it is conceivable that shorter timeouts may exist 977 in some NATs. 979 For this reason the extension used to set up the UDP tunnel has the 980 option of setting the keepalive message interval to another value 981 than the default value, see Section 3.2. 983 Sending a keepalive message SHOULD consist of doing a regular Mobile 984 IP Registration Request, exactly as would otherwise have been done 985 before the expiration of the current registration, except in the case 986 where the mobile node has set the 'R' flag in the UDP Tunnel Request 987 Extension. When the keepalive does not consist of a registration 988 request, it MUST instead consist of a properly encapsulated ICMP echo 989 request directed to the home agent. If the home agent because of 990 processing load or other reasons would prefer the mobile node to use 991 ICMP echo requests rather than Registration Requests, it may do so by 992 setting the 'E' flag in the UDP Tunnel Reply Extension. 994 For each mobility binding which has UDP tunnelling established, the 995 node which sent the UDP Tunnel Request Extension MUST send a 996 keepalive packet if no other packet to the HA has been sent in K 997 seconds, where K is a parameter with a default value of 20 seconds. 998 K may be set to another value by the HA as described in the UDP 999 tunnelling reply extension (Section 3.2). 1001 Except for the case where the mobile node registers with co-located 1002 address through an FA (see Section 4.10) MIP UDP tunnelling is done 1003 using the same ports that have already been used for the registration 1004 request / reply exchange, the MN will send its first keepalive 1005 message at the earliest K seconds after the registration request was 1006 sent. The mobile node MUST use the same UDP source port for the 1007 keepalive messages as was used for the original Registration Messages 1008 and for data messages. The home agent MUST be prepared to receive 1009 re-registration requests at the rate indicated by the Keepalive 1010 Interval in the UDP Tunnel Reply Extension. 1012 4.10 Co-located registration through FA 1014 This section summarizes the protocol details which have been 1015 necessary in order to handle and support the case when a mobile node 1016 registers with a co-located address through a foreign agent, due to 1017 the FA advertisements having the 'R' bit set. It gives background 1018 information, but lists no new requirements. 1020 When a mobile registers a co-located care-of address through an FA, 1021 the registration request which reaches the HA will have a different 1022 care-of address in the registration request compared to the source 1023 address in the registration request IP-header. If the registration 1024 request also contains a UDP Tunnel Request Extension, the HA will 1025 erroneously set up a UDP tunnel, which will go to the FA instead of 1026 the MN. For this reason, as mentioned in Section 4.4, the mobile 1027 node must not include a UDP Tunnel Request Extension in the 1028 registration if it is registering a co-located address through an FA 1029 which does not have the 'U' bit set in its advertisements. 1031 In order to still be able to use MIP UDP tunnelling in this case, 1032 foreign agents which are situated behind a NAT are encouraged to send 1033 advertisements which have the 'U' bit set, as described in Section 1034 3.4. 1036 If the FA advertisement has the 'U' bit set, indicating that it is 1037 behind a NAT, and also the 'R' bit set, and the mobile node wishes to 1038 use a co-located care-of address, it MUST set the 'R' flag in the UDP 1039 Tunnel Request Extension, in order to inform the HA of the situation 1040 so that it may act appropriately, as described in Section 4.4. 1042 The use of MIP UDP tunnelling with a co-located care-of address when 1043 registering through a foreign agent brings another problem too. The 1044 use of re-registration requests as tunnel keepalives does not work in 1045 this case, as registration is done through the foreign agent, not 1046 directly on the same path as the tunnel. For this reason, 1047 alternative keepalives has to be used. As described in Section 4.4, 1048 ICMP echo requests are to be used in this case. Compared to sending 1049 an empty packet, these have the benefit of soliciting a return 1050 packet, which will let the mobile node know that it has connectivity 1051 with the HA through the tunnel. 1053 Because the UDP tunnel is now taking another path than the 1054 registration requests, the home agent, when handling registrations of 1055 this type, must wait till the arrival of the first keepalive packet 1056 before it can set up the tunnel to the correct address and port. To 1057 reduce the possibility of tunnel hijacking by sending a keepalive 1058 with a phony source address, it is required that only the port of the 1059 keepalive packet may be different from that of the registration 1060 request; the source address must be the same. This means that if the 1061 FA and MN are communicating with the HA through different NATs, the 1062 connection will fail. 1064 5. Implementation Issues 1066 5.1 Movement Detection and Private Address Aliasing 1068 In providing a mobile node with a mechanism for NAT traversal of 1069 Mobile IP traffic, we expand the address space where a mobile node 1070 may function and acquire care-of addresses. With this comes a new 1071 problem of movement detection and address aliasing. We here have a 1072 case which may not occur frequently, but is mentioned for 1073 completeness: 1075 Since private networks use overlapping address spaces, they may be 1076 mistaken for one another in some situations; this is referred to as 1077 private address aliasing in this document. For this reason, it may 1078 be necessary for mobile nodes implementing this specification to 1079 monitor the link layer address(es) of the gateway(s) used for sending 1080 packets. A change in the link layer address indicates probable 1081 movement to a new network, even if the IP address remains reachable 1082 using a new link layer address. 1084 For instance, a mobile node may obtain the co-located care-of address 1085 10.0.0.1, netmask 255.0.0.0, and gateway 10.255.255.254 using DHCP 1086 from network #1. It then moves to network #2, which uses an 1087 identical addressing scheme. The only difference for the mobile node 1088 is the gateway's link layer address. The mobile node should store 1089 the link layer address it initially obtains for the gateway (using 1090 ARP, for instance). The mobile node may then detect changes in the 1091 link layer address in successive ARP exchanges as part of its 1092 ordinary movement detection mechanism. 1094 In rare cases the mobile nodes may not be able to monitor the link 1095 layer address of the gateway(s) it is using, and may thus confuse one 1096 point of attachment with another. This specification does not 1097 explicitly address this issue. The potential traffic blackout caused 1098 by this situation may be limited by ensuring that the mobility 1099 binding lifetime is short enough; the re-registration caused by 1100 expiration of the mobility binding fixes the problem (see Section 1101 5.2). 1103 5.2 Mobility Binding Lifetime 1105 When responding to a registration request with a registration reply, 1106 the home agent is allowed to decrease the lifetime indicated in the 1107 registration request, as covered in RFC 3220 [10]. When using UDP 1108 tunnelling, there are some cases where a short lifetime is 1109 beneficial. 1111 First, if the NAT mapping maintained by the NAT device is dropped, a 1112 connection blackout will arise. New packets sent by the mobile node 1113 (or the foreign agent) will establish a new NAT mapping, which the 1114 home agent will not recognize until a new mobility binding is 1115 established by a new registration request. 1117 A second case where a short lifetime is useful is related to the 1118 aliasing of private network addresses. In case the mobile node is 1119 not able to detect mobility and ends up behind a new NAT device (as 1120 described in Section 5.1), a short lifetime will ensure that the 1121 traffic blackout will not be exceedingly long, and is terminated by a 1122 re-registration. 1124 The definition of "short lifetime" in this context is dependent on 1125 the requirements of the usage scenario. Suggested maximum lifetime 1126 returned by the home agent is 60 seconds, but in case the 1127 abovementioned scenarios are not considered a problem, longer 1128 lifetimes may of course be used. 1130 6. Security Considerations 1132 The ordinary Mobile IP security mechanisms are also used with the NAT 1133 traversal mechanism described in this document. However, there is 1134 one noticeable change: the NAT traversal mechanism requires that the 1135 HA trust unauthenticated address (and port) fields possibly modified 1136 by NATs. 1138 Relying on unauthenticated address information when forming or 1139 updating a mobility binding leads to several redirection attack 1140 vulnerabilities. In essence, an attacker may do what NATs do, i.e. 1141 modify addresses and ports and thus cause traffic to be redirected to 1142 a chosen address. The same vulnerabilities apply to both MN-HA and 1143 FA-HA NAT traversal. 1145 In more detail: without a NAT, the care-of address in the 1146 registration request will be directly used by the HA to send traffic 1147 back to the MN (or the FA), and the care-of address is protected by 1148 the MN-HA (or FA-HA) authentication extension. When communicating 1149 across a NAT, the effective care-of address from the HA point of view 1150 is that of the NAT, which is not protected by any authentication 1151 extension, but inferred from the apparent IP source address of 1152 received packets. This means that by using the mobile IP 1153 registration extensions described in this document to enable 1154 traversal of NATs, one is opening oneself up to having the care-of 1155 address of a MN (or a FA) maliciously changed by an attacker. 1157 Some, but not all, of the attacks could be alleviated to some extent 1158 by using a simple routability check. However, this document does not 1159 specify such a mechanism for simplicity reasons and because the 1160 mechanism would not protect against all redirection attacks. To 1161 limit the duration of such redirection attacks, it is RECOMMENDED to 1162 use a conservative (that is, short) mobility binding lifetime when 1163 using the NAT traversal mechanism specified in this document, and 1164 also use registration request keepalives rather than ICMP echo 1165 request keepalives. 1167 The known security issues are described in the sections that follow. 1169 6.1 Traffic Redirection Vulnerabilities 1171 6.1.1 Manipulation of the Registration Request Message 1173 An attacker on the route between the mobile node (or foreign agent) 1174 and the home agent may redirect mobility bindings to a desired 1175 address simply by modifying the IP and UDP headers of the 1176 Registration Request message. Having modified the binding, the 1177 attacker no longer needs to listen to (or manipulate) the traffic. 1178 The redirection is in force until the mobility binding expires or the 1179 mobile node re-registers. 1181 This vulnerability may be used by an attacker to read traffic 1182 destined to a mobile node, and to send traffic impersonating the 1183 mobile node. The vulnerability may also be used to redirect traffic 1184 to a victim host in order to cause denial-of-service on the victim. 1186 The only defence against this vulnerability is to have a short time 1187 between re-registrations, which limits the duration of the 1188 redirection attack after the attacker has stopped modifying 1189 registration messages. 1191 6.1.2 Sending a Bogus Keepalive Message 1193 When registering through a FA using a co-located care-of address, 1194 another redirection vulnerability opens up. Having exchanged RRQ/RRP 1195 messages with the HA through the FA, the MN is expected to send the 1196 first keepalive message to the HA, thus finalizing the mobility 1197 binding (the binding will remain in a "half open" state until the 1198 keepalive is received). 1200 Having observed a RRQ/RRP exchange, an attacker may send a bogus 1201 keepalive message assuming that the mobility binding is in the "half 1202 open" state. This opens up a similar redirection attack as discussed 1203 in Section 6.1.1. Note, however, that the attacker does not need to 1204 be able to modify packets in flight; simply being able to observe the 1205 RRQ/RRP message exchange is sufficient to mount the attack. 1207 With this in mind, the home agent MUST NOT accept a keepalive message 1208 from a different source IP address than where the RRQ came from, as 1209 specified in Section 4.6. This requirement limits the extent of the 1210 attack to redirecting the traffic to a bogus UDP port, while the IP 1211 address must remain the same as in the initial RRQ. 1213 The only defences against this vulnerability are: (1) to have a short 1214 time between re-registrations, which limits the duration of the 1215 redirection attack after the attacker has stopped sending bogus 1216 keepalive messages, and (2) to minimize the time the binding is in a 1217 "half open" state by having the mobile node send the first keepalive 1218 message immediately after receiving an affirmative registration 1219 reply. 1221 6.2 Use of IPsec 1223 If the intermediate network is considered insecure, it is recommended 1224 that IPsec be used to protect user data traffic. However, IPsec does 1225 not protect against the redirection attacks described previously, 1226 other than to protect confidentiality of hijacked user data traffic. 1228 The NAT traversal mechanism described in this document allows all 1229 IPsec-related traffic to go through NATs without any modifications to 1230 IPsec. In addition, the IPsec security associations do not need to 1231 be re-established when the mobile node moves. 1233 6.3 Firewall Considerations 1235 This document does not specify a general firewall traversal 1236 mechanism. However, the mechanism makes it possible to use only a 1237 single address and a port for all MN-HA (or FA-HA) communication. 1238 Furthermore, using the same port for the MIP UDP tunnelled traffic as 1239 for control messages makes it quite probable that if a MIP 1240 registration can reach the home agent, MIP tunnelling and reverse 1241 tunnelling using the described mechanism will also work. 1243 7. IANA Considerations 1245 The numbers for the extensions defined in this I-D should be taken 1246 from the numbering space defined for Mobile IP messages, registration 1247 extensions and error codes defined in RFC 3220 [10]. This draft 1248 proposes one new message, three new extensions and a new error code 1249 that require type numbers and error code value to be assigned by 1250 IANA. 1252 Section 3.1 defines a new Mobile IP extension, the UDP Tunnel Request 1253 Extension. The type number for this extension should be of type 1254 skippable. 1256 Section 3.2 defines a new Mobile IP extension, the UDP Tunnel Reply 1257 Extension . The type value for this extension should be of type non- 1258 skippable. 1260 Section 3.3 defines a new Mobile IP message, the Tunnel Data message. 1261 The type value for this message should be taken from the numbering 1262 space defined for Mobile IP messages. 1264 Section 3.5 defines a new error code, ERROR_HA_UDP_ENCAP_UNAVAIL: 1265 "Requested UDP tunnel encapsulation unavailable", from the numbering 1266 space for values defined for use with the Code field of Mobile IP 1267 Registration Reply Messages. This code should be taken from the 1268 subset "Error Codes from the Home Agent". 1270 The values for the Next Header field in the MIP Tunnel Data Message 1271 (Section 3.3) shall be the same as those used for the Protocol field 1272 of the IP header[2], and requires no new number assignment. 1274 8. Intellectual property rights 1276 The IETF has been notified of intellectual property rights claimed in 1277 regard to some or all of the specification contained in this 1278 document. For more information consult the online list of claimed 1279 rights. 1281 ipUnplugged has notified the working group of one or more patents or 1282 patent applications that may be relevant to this internet-draft. 1283 ipUnplugged has given a licence for those patents to the IETF. For 1284 more information consult the online list of claimed rights. 1286 9. Acknowledgements 1288 Much of the text in Section 4.2 has been taken almost verbatim from 1289 RFC 2003, IP Encapsulation within IP [5]. 1291 Adding support for the FA case was suggested by George Tsirtsis and 1292 Frode B. Nilsen. Roy Jose pointed out a problem with binding 1293 updates, and Frode, Roy and George pointed out that there are cases 1294 where triangular routes may work, and suggested that reverse 1295 tunnelling need not be mandatory. Roy and Qiang Zhang drew attention 1296 to a number of sections which needed to be corrected or stated more 1297 clearly. 1299 Phil Roberts helped remove a number of rough edges, and suggested the 1300 'E' bit to permit an HA to indicate preference for icmp echo request 1301 keepalives. Farid Adrangi pointed out the DoS issue now covered in 1302 Security Considerations (Section 6). Francis Dupont's helpful 1303 comments made us extend the Security Considerations section to make 1304 it more comprehensive and clear. Milind Kulkarni and Madhavi Chandra 1305 pointed out the required match between the FA source and care-of 1306 addresses when the mechanism is used by an FA, and also contributed a 1307 number of clarifications to the text. 1309 Thanks also to our co-workers, Ilkka Pietikainen, Antti Nuopponen and 1310 Timo Aalto at Netseal and Hans Sjostrand, Fredrik Johansson and Erik 1311 Liden at ipUnplugged. They have read and re-read the text, and 1312 contributed many valuable corrections and insights. 1314 Normative References 1316 [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1317 1980. 1319 [2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1320 1981. 1322 [3] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic 1323 Routing Encapsulation (GRE)", RFC 1701, October 1994. 1325 [4] Marlow, D., "Host Group Extensions for CLNP Multicasting", RFC 1326 1768, March 1995. 1328 [5] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1329 1996. 1331 [6] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 1332 October 1996. 1334 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1335 Levels", BCP 14, RFC 2119, March 1997. 1337 [8] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, 1338 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 1340 [9] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 1341 3024, January 2001. 1343 [10] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, January 1344 2002. 1346 Informative References 1348 [11] Atkinson, R., "IP Authentication Header", RFC 1826, August 1349 1995. 1351 [12] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 1352 (NAT) Terminology and Considerations", RFC 2663, August 1999. 1354 [13] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 1355 Translator (Traditional NAT)", RFC 3022, January 2001. 1357 Authors' Addresses 1359 O. Henrik Levkowetz 1360 ipUnplugged AB 1361 Arenavagen 33 1362 Stockholm S-121 28 1363 SWEDEN 1365 Phone: +46 8 725 9513 1366 EMail: henrik@levkowetz.com 1368 Sami Vaarala 1369 Netseal 1370 Niittykatu 6 1371 Espoo 02201 1372 FINLAND 1374 Phone: +358 9 435 310 1375 EMail: sami.vaarala@iki.fi 1377 Full Copyright Statement 1379 Copyright (C) The Internet Society (2002). All Rights Reserved. 1381 This document and translations of it may be copied and furnished to 1382 others, and derivative works that comment on or otherwise explain it 1383 or assist in its implementation may be prepared, copied, published 1384 and distributed, in whole or in part, without restriction of any 1385 kind, provided that the above copyright notice and this paragraph are 1386 included on all such copies and derivative works. However, this 1387 document itself may not be modified in any way, such as by removing 1388 the copyright notice or references to the Internet Society or other 1389 Internet organizations, except as needed for the purpose of 1390 developing Internet standards in which case the procedures for 1391 copyrights defined in the Internet Standards process must be 1392 followed, or as required to translate it into languages other than 1393 English. 1395 The limited permissions granted above are perpetual and will not be 1396 revoked by the Internet Society or its successors or assigns. 1398 This document and the information contained herein is provided on an 1399 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1400 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1401 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1402 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1403 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1405 Acknowledgement 1407 Funding for the RFC Editor function is currently provided by the 1408 Internet Society.