idnits 2.17.1 draft-melia-mipshop-mstp-solution-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 883. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 894. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 901. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 907. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 52 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 18, 2007) is 6065 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: 'RFC1536' is defined on line 786, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 793, but no explicit reference was found in the text == Unused Reference: 'RFC2988' is defined on line 805, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-bajko-mos-dhcp-options-00 == Outdated reference: A later version (-01) exists of draft-bajko-mos-dns-discovery-00 ** Downref: Normative reference to an Informational draft: draft-ietf-dnsop-dnssec-operational-practices (ref. 'I-D.ietf-dnsop-dnssec-operational-practices') == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-05 == Outdated reference: A later version (-05) exists of draft-ietf-mipshop-mis-ps-03 ** Downref: Normative reference to an Informational draft: draft-ietf-mipshop-mis-ps (ref. 'I-D.ietf-mipshop-mis-ps') == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-udp-guidelines-03 ** Obsolete normative reference: RFC 1533 (Obsoleted by RFC 2132) ** Downref: Normative reference to an Informational RFC: RFC 1536 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2486 (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 3849 ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 14 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mipshop WG T. Melia, Ed. 3 Internet-Draft NEC 4 Intended status: Standards Track G. Bajko 5 Expires: March 21, 2008 Nokia 6 S. Das 7 Telcordia 8 N. Golmie 9 NIST 10 S. Xia 11 Huawei 12 JC. Zuniga 13 InterDigital 14 September 18, 2007 16 Mobility Services Transport Protocol Design 17 draft-melia-mipshop-mstp-solution-00 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on March 21, 2008. 44 Copyright Notice 46 Copyright (C) The IETF Trust (2007). 48 Abstract 50 To be edited. 52 Requirements Language 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [RFC2119]. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 4 63 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.2. MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . . . . 7 66 5. MoS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. MoS Discovery in the home network while attached to 68 the home link . . . . . . . . . . . . . . . . . . . . . . 8 69 5.2. MoS Discovery in the local network and Services are 70 local . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5.3. MOS Discovery in a roaming Network and Services are at 72 Home . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 5.4. MoS discovery in a remote network . . . . . . . . . . . . 11 74 6. MIH Transport . . . . . . . . . . . . . . . . . . . . . . . . 12 75 6.1. MIH Message size . . . . . . . . . . . . . . . . . . . . . 13 76 6.2. MIH Message rate . . . . . . . . . . . . . . . . . . . . . 13 77 6.3. Retransmission . . . . . . . . . . . . . . . . . . . . . . 14 78 6.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 14 79 6.5. General guidelines . . . . . . . . . . . . . . . . . . . . 14 80 7. Operation Flows . . . . . . . . . . . . . . . . . . . . . . . 14 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 88 Intellectual Property and Copyright Statements . . . . . . . . . . 21 90 1. Introduction 92 This document proposes a solution to the issues identified in the 93 problem statement document [I-D.ietf-mipshop-mis-ps] for the 94 transport of IEEE 802.21 MIH protocols. 96 The MIH Layer 3 transport problem is divided in two main parts: the 97 discovery of mobility services (MoS) and the transport of the 98 information between MN and MoS. The discovery process is required 99 for MIH function located in the MN to discover the peer MIHF (e.g. 100 the IP address) of the MoS in the network (e.g. the Point of Service, 101 PoS) either during attachment or during handover. Upon successful 102 discovery, the MIH peers can then exchange information in the form of 103 MIH messages. 105 This document considers firstly standard track IETF-based solutions 106 for the design and recommendations of the discovery and transport 107 protocol components. 109 2. Terminology 111 The following terminology is being used: 113 MIH Media Independent Handover 115 MIHF Media Independent Handover Function 117 MIHF USER MIH client initiating and terminating MIH signalling 119 MIHFID Media Independent Handover Function Identifier 121 MoS As defined in the problem statement document it includes IS, CS, 122 ES services defined by the IEEE 802.21 standard. 124 MoSh Mobility Services assigned in the Home Network 126 MoSv Mobility Services assigned in the Visited Network 128 MoS3 Mobility Services assigned in a 3rd Party Network 130 MN Mobile Node 132 NN Network Node 134 3. Deployment Scenarios 136 The following scenarios have been identified: 138 S1 Home Network MoS, the MN and the services are located in the home 139 network. We refer to this as MoSh as in Figure 1. 141 +--------------+ +====+ 142 | HOME NETWORK | |MoSh| 143 +--------------+ +====+ 144 /\ 145 || 146 \/ 147 +--------+ 148 | MN | 149 +--------+ 151 Figure 1: MoS in the Home network 153 S2 Visited Network MoS, MN is in the visited network and mobility 154 services are also provided by the visited network. We refer to 155 this as MoSv ans in Figure 2. 157 +--------------+ 158 | HOME NETWORK | 159 +--------------+ 160 /\ 161 || 162 \/ 163 +====+ +-----------------+ 164 |MoSv| | VISITED NETWORK | 165 +====+ +-----------------+ 166 /\ 167 || 168 \/ 169 +--------+ 170 | MN | 171 +--------+ 173 Figure 2: MoSV in the Visited Network 175 S3 Roaming MoS, MN is in the visited network and all services are 176 provided by the home network. 178 +====+ +--------------+ 179 |MoSh| | HOME NETWORK | 180 +====+ +--------------+ 181 /\ 182 || 183 \/ 184 +-----------------+ 185 | VISITED NETWORK | 186 +-----------------+ 187 /\ 188 || 189 \/ 190 +--------+ 191 | MN | 192 +--------+ 194 Figure 3: MoS provided by the home while in visited 196 S4 Third party MoS, MN is in home or visited network and services are 197 provided by a 3rd party network. We refer to this as MoS3 as in 198 Figure 4 200 +--------------+ 201 | HOME NETWORK | 202 +====+ +--------------+ +--------------+ 203 |MoS3| | THIRD PARTY | <===> /\ 204 +====+ +--------------+ || 205 \/ 206 +-----------------+ 207 | VISITED NETWORK | 208 +-----------------+ 209 /\ 210 || 211 \/ 212 +--------+ 213 | MN | 214 +--------+ 216 Figure 4: MoS form a third party 218 MoS can be provided independently and there is no strict relationship 219 between ES, CS and IS. However, while IS contain more a static sort 220 of information, ES and CS are services of a dynamic nature and 221 sometimes some relationships between them could be expected, e.g. a 222 handover command could be issued upon reception of a link event. 223 Hence, while in theory services can be implemented in different 224 locations, it is expected that ES and CS will be collocated, whereas 225 IS can either be collocated with ES/CS or not. Therefore, having the 226 flexibility at the MSTP to discover different services in different 227 locations is an important feature 229 4. Solution Overview 231 As mentioned in Section 1 the solution space is being divided in 232 discovery and transport. The following assumptions have been made: 234 o The solution is aimed at supporting 802.21 MIH services, namely 235 Information Services (IS), Event Services (ES), and Command 236 Services (CS). 238 o If the MIHFID is available, FQDN or NAI's realm is used for 239 mobility service discovery. The recommendation to the IEEE 802.21 240 WG is to restrict to only these two. 242 o The solutions are chosen to cover all possible deployment 243 scenarios as described in Section 3. 245 o MIHF discovery can be performed during initial network attachment 246 or thereafter. 248 For the discovering the location of an MoS, the MN could either be 249 pre-configured with the address of the MoS, or this address could be 250 dynamically assigned through DHCP or DNS by the network. The dynamic 251 assignation methods are described in Section 5. 253 The configuration of the MoS could be executed either upon network 254 attachment or after successful IP configuration. The methodology to 255 be used depends on the considered deployment scenario. 257 Once the MIHF peer has been discovered, MIH information can be 258 exchanged between peers over UDP and TCP. The usage of these 259 protocols is described in Section 6. 261 4.1. Architecture 263 The following Figure 5 depicts the MSTP reference model and its 264 components within a node. 266 +--------------------------+ 267 | MIHF USER | 268 +--------------------------+ 269 || 270 +--------------------------+ 271 | MIHF | 272 +--------------------------+ 273 || || || 274 +---------+ +------+ +-----+ 275 | TCP/UDP | | DHCP | | DNS | 276 +---------+ +------+ +-----+ 278 Figure 5: MN stack 280 As it can be seen, the MIHF relies on the services provided by TCP 281 and UDP for transport, as well as DHCP and DNS for peer discovery. 282 In cases where peer MIHF IP address is not pre-configured, source 283 MIHF needs to discover it either via DHCP or DNS or using a 284 combination of both as described in Section 5. Once peer MIHF is 285 discovered, MIHF must exchange messages with its peer over either UDP 286 or TCP. Specific recommendations on choice of transport protocols 287 are provided in Section 6. 289 The above reference architecture however does not provide the model 290 for other services such as, fragmentation and security. Depending 291 upon the MIH services (e.g., ES, CS and IS) the message size can be 292 very large. In cases where underlying layer does not support 293 fragmentation, this may be an issue. There is no security available 294 currently at the MIH protocol level. However, security can be 295 provided either at the transport or IP layer where it is necessary. 296 Section 8 provides some guidelines and recommendations for security. 298 4.2. MIHF Identifiers (FQDN, NAI) 300 An MIHFID is an identifier required to uniquely identify the MIHF end 301 points for delivering the mobility services (MoS). Thus an MIHF 302 identifier needs to be unique within a domain whereby mobility 303 services are provided and invariant to interface IP addresses. An 304 MIHFID MUST be represented either in the form of an FQDN [RFC2181] or 305 NAI [RFC2486]. An MIHFID can be pre-configured or discovered through 306 the discovery methods as described in Section 5. 308 5. MoS Discovery 310 The MoS discovery method depends on whether the MN wants to discover 311 an MoS in the local network, home network or a remote network other 312 than home network. 314 In case MoS is provided locally (scenarios S1 and S2) 315 [I-D.bajko-mos-dhcp-options] and [I-D.bajko-mos-dns-discovery] could 316 be used to transfer MoS information from the network to the MN (via 317 DHCP or DNS). In case MoS is provided in the home while the MN is 318 attached in visited (scenario S3) an interaction between the DHCP and 319 AAA infrastructure is required similarly to what specified in 320 [I-D.ietf-mip6-bootstrapping-integrated-dhc]. It is assumed 321 therefore that MoS assignment is performed during access 322 authentication and authorization. In case MoS is provided in a 323 remote network other than visited or home (scenario S4) only DNS 324 based methods apply. 326 5.1. MoS Discovery in the home network while attached to the home link 328 To discover an MoS in the home network, the MN SHOULD use the DNS 329 based MoS discovery method described in 330 [I-D.bajko-mos-dns-discovery]. In order to use that, the MN MUST 331 first find out the domain name of its home network. Home domains are 332 usually pre-configured in the MNs, thus the MN can simply read its 333 configuration data to find out the home domain name (scenario S1). 334 Alternatively, the MN MAY use the DHCP options for MoS 335 discovery[I-D.bajko-mos-dhcp-options]. Figure 6 provides such model. 337 +-------+ 338 +----+ |Domain | 339 | MN |-------->|Name | 340 +----+ |Server | 341 +-------+ 342 MN@xyz.com 344 (a) using DNS Query 346 +-----+ +------+ 347 +----+ | | |DHCP | 348 | MN |<----->| DHCP|<---->|Server| 349 +----+ |Relay| | | 350 +-----+ +------+ 352 (b) Using DHCP Option 354 Figure 6: MOS Discovery (a) Using DNS query, (b) using DHCP option 356 5.2. MoS Discovery in the local network and Services are local 358 To discover an MoS in the visited network, the MN SHOULD attempt to 359 use the DHCP options for MoS discovery [I-D.bajko-mos-dhcp-options]. 360 If the DHCP method fails, the MN SHOULD attempt to use the DNS based 361 MoS discovery method described in [[I-D.bajko-mos-dns-discovery]. In 362 order to use that, the MN MUST first learn the domain name of the 363 local network. There are a number of ways how the domain name of a 364 network can be learned: 366 DHCP -- In order to find out the domain name of the local network, 367 the MN SHOULD use the dhcpv4 option 15 for learning the domain 368 name [RFC1533]. Similar solution is available for dhcpv6 369 [I-D.ietf-dhc-dhcpv6-opt-dnsdomain] . 371 Reverse dns query -- When DHCP does not provide the required domain 372 name, the MN MAY use reverse DNS (DNS PTR record) to find the 373 domain name associated with the IP address it is using in the 374 local network. Note, that when a NAT device exists between the MN 375 and the local network, the MN will first need to find out the 376 external IP address of the NAT device. Some possible methods for 377 determining the NAT's external IP address are STUN [RFC3849] or 378 UPnP [UPnP_IDG_DCP]. Once the MN determined the external IP 379 address of the NAT device, it MUST use that address in the reverse 380 DNS query. 382 Figure 7 provides such model. 384 +-----+ +------+ 385 +----+ | | |DHCP | 386 | MN |<----->| DHCP|<---->|Server| 387 +----+ |Relay| | | 388 +-----+ +------+ 390 (a) MOS Discovery using DHCP options 392 +-------+ 393 +----+ |Domain | 394 | MN |-------->|Name | 395 +----+ |Server | 396 +-------+ 398 (b) Reverse DNS Query (starting from the IP address) 400 Figure 7: Discovery (a) using DHCP option, (b) Using DNS 402 5.3. MOS Discovery in a roaming Network and Services are at Home 404 To discover an MoS in the roaming network when services are provided 405 by the home network MN SHOULD use the DHCP option along with network 406 access authentication. Upon network access authentication and 407 interaction with the NAS the AAAh verifies in the AAA profile that 408 the MN is allowed to use the MoS in home. The AAAh assigns the MoS 409 in the home and sends back the information to the NAS. MN sends a 410 DHCP information request as per [RFC3315] containing Home Network 411 Identifier Option indicating the need to allocate the MoS in the 412 home. The relay agent intercepts the Information request from the MN 413 and it forwards to the DHCP server inserting the MIH Relay Agent 414 Option containing the info received by the AAAh. The DHCP server can 415 then reply to the MN by sending the Home Network Information Option. 416 The MN receives the MoS address. 418 It should be noted that the AAAh does not know what are the 419 preferences of the MN, i.e. whether the MoS should be allocated in 420 the home or in visited. The MoS info is stored at the relay agent 421 and forwarded to the MN according to the flags in the Home Network 422 Identifier Option. Figure 8 describes such a model. 424 Visited | Home 425 | 426 | 427 +-------+ | +-------+ 428 | | | | | 429 |AAAV |-----------|--------|AAAH | 430 | | | | | 431 | | | | | 432 +-------+ | +-------+ 433 | | 434 | | 435 | | 436 | | 437 | | +--------+ 438 | | | | 439 | | | MoSh | 440 +-----+ +------+ | +--------+ 441 +----+ | | |DHCP | | 442 | MN |------| NAS/|----|Server| | 443 +----+ | DHCP| | | | 444 |Relay| | | | 445 +-----+ +------+ | 446 | 448 AAAv -- Visited AAA 449 AAAH -- Home AAA 450 NAS -- Network Access Server 452 Figure 8: MOS Discovery using Network Access Authentication and DHCP 453 options 455 5.4. MoS discovery in a remote network 457 To discover an MoS in a remote network other than home network, the 458 MN MUST use the DNS based MoS discovery method described in 459 [I-D.bajko-mos-dns-discovery]. In order to use that, the MN MUST 460 first learn the domain name of the network it is looking for an MoS 461 in. If the MN does not yet know the domain name of the network, 462 learning it may require more than one operation, as pre-configuration 463 and DHCP methods can not be used. The MN MAY attempt to first 464 discover an MoS in either the local or home network (as in Figure 9 465 part (a)) and query that MoS to find out the domain name of a 466 specific network or the domain name of a network at a specific 467 location (as in Figure 9 part (b)). Alternatively, the MN MAY query 468 an MoS previously known to learn the domain name of the desired 469 network (e.g., via an IS Query). Finally the MN can use DNS queries 470 to find MoS in the remote network as inFigure 9 part(c). It should 471 be noted that step c can only be performed upon obtaining the domain 472 name of the remote network. 474 +-------+ 475 +----+ |DHCP | 476 | MN |-------->| | 477 +----+ |Server | 478 +-------+ 479 MN@xyz.com 481 (a) Discover MoS in local network with DHCP 482 +------------+ 483 +----+ | | 484 | | |Information | 485 | MN |-------->| Server | 486 | | |(previously | 487 +----+ |discovered) | 488 +------------+ 490 (b) Using IS query to find the FQDN on the remote network 492 +-------+ 493 +----+ |Domain | 494 | MN |-------->|Name | 495 +----+ |Server | 496 +-------+ 497 MN@xyz.com 499 (c) using DNS Query in the remote network 501 Figure 9: MOS Discovery using (a) DNS Query, (b) IS Query to a known 502 Server 504 6. MIH Transport 506 Once the Mobility Services have been discovered, MIH peers MUST 507 exchange information over either TCP or UDP. While either protocol 508 can provide the basic transport functionality required, there are 509 performance trade-offs and unique characteristics with each that need 510 to be considered in the context of the MIH services for different 511 network loss and congestion conditions. Thus, the objectives of this 512 section are to discuss these trade-offs for different MIH settings 513 such as the MIH message size and rate, and the retransmission 514 parameters. In addition, factors such as NAT traversal are also 515 discussed. Given the reliability requirements for the MIH transport, 516 it is assumed in this discussion that the MIH ACK mechanism is to be 517 used in conjunction with UDP, while it is preferred to avoid using 518 with TCP since TCP includes a similar functionality. 520 6.1. MIH Message size 522 Although the MIH message size varies widely from about 30 bytes (for 523 a broadcast capability discovery request) to around 65000 bytes (for 524 an IS MIH_Get_Information response primitive), a typical MIH message 525 size for the ES/CS service ranges between 50 to100 bytes. Thus, 526 considering the effects of the MIH message size on the performance of 527 the transport protocol brings us to discussing two main issues, 528 related to fragmentation of long messages in the context of UDP and 529 the concatenation of short messages in the context of TCP. Since 530 transporting long MIH messages may require fragmentation that is not 531 available in UDP, using UDP a limit MUST be set on the size of the 532 MIH message, unless fragmentation functionality is added to the MIH 533 layer or IP layer fragmentation is used instead. In this latter 534 case, the loss of an IP fragment leads to the retransmission of an 535 entire MIH message, which in turn leads to poor end-to-end delay 536 performance in addition to wasted bandwidth utilization. Additional 537 recommendations in [I-D.ietf-tsvwg-udp-guidelines] apply for limiting 538 the size of the MIH message when using UDP and assuming IP layer 539 fragmentation. In terms of dealing with short messages, TCP has the 540 capability to concatenate very short messages in order to reduce the 541 overall bandwidth overhead. However, this reduced overhead comes at 542 the cost of additional delay to complete an MIH transaction, which 543 may not be acceptable for CS and ES services. 545 6.2. MIH Message rate 547 The frequency of MIH messages varies according to the MIH service 548 type. It is expected that CS/ES message arrive at a rate of one in 549 hundreds of milliseconds in order to capture quick changes in the 550 environment and/ or process handover commands. On the other hand, IS 551 messages are exchanged mainly every time a new network is visited 552 which may be in order of hours or days. Therefore a burst of either 553 short CS/ES messages or long IS message exchanges (in the case of 554 multiple MIH nodes requesting information) may lead to network 555 congestion. While the built-in rate-limiting controls available in 556 TCP may be well suited for dealing with these congestion conditions, 557 this may result in large transmission delays that may be unacceptable 558 for the timely delivery of ES/CS messages. On the other hand, if UDP 559 is used, a rate-limiting effect similar to the one obtained with TCP 560 may be obtained by adequately adjusting the token bucket parameters 561 defined in the MIH specifications. Recommendations for parameter 562 settings are specific to the scenario considered. 564 6.3. Retransmission 566 For TCP, the retransmission timeout is adjusted according to the 567 measured RTT. However due to the exponential backoff mechanism, the 568 retransmission timeouts may increase significantly with increased 569 packet loss. 571 6.4. NAT Traversal 573 There are no known issues for NAT traversal when using TCP. The 574 default connection timeout of 24 hours is considered adequate for MIH 575 transport purposes. However, issues with NAT traversal using UDP are 576 documented in [I-D.ietf-tsvwg-udp-guidelines]. Communication 577 failures are experienced when middleboxes destroy the per-flow state 578 associated with an application session during periods when the 579 application does not exchange any UDP traffic. Hence, communication 580 between the MN and the MoS SHOULD be able to gracefully handle such 581 failures and implement mechanisms to re-establish their UDP sessions. 582 In addition and in order to avoid such failures, MIH messages MAY be 583 sent periodically, similarly to keep-alive messages, to attempt to 584 refresh middlebox state (e.g. ES reports could be used for this 585 purpose). As [RFC4787] requires a minimum state timeout of two 586 minutes or more, MIH messages using UDP as transport SHOULD be sent 587 once every two minutes. 589 6.5. General guidelines 591 Since ES and CS messages are small in nature and have tight latency 592 requirements, UDP in combination with MIH acknowledgement SHOULD be 593 used for transporting ES and CS messages. On the other hand, IS 594 messages are more resilient in terms of latency constraints and some 595 long IS messages could exceed the MTU of the path to the destination. 596 Therefore, TCP SHOULD be used for transporting IS messages. For both 597 UDP and TCP cases, if a port number is not explicitly assigned (e.g. 598 by the DNS SRV), MIH messages sent over UDP or TCP MUST use the 599 default port number. 601 7. Operation Flows 603 Following Figure 10 gives an example operation flow between MIHF 604 peers when an MIH user requests for an IS service. Scenario 1 is 605 chosen whereby DHCP is used for MoS discovery and TCP is used for 606 establishing a transport connection. When MOS is not pre-configured, 607 MIH user needs to discover the IP address of MOS to communicate with 608 the remote MIHF. Therefore MIH user requests the local MIHF via a 609 discovery message as defined in IEEE 802.21. 611 In this example, we assume that MoS discovery is performed before a 612 transport connection is established with the remote MIHF and the DHCP 613 client process is invoked via some internal APIs. DHCP Client sends 614 DHCP INFORM message according to standard DHCP and with the MoS 615 option as defines in [I-D.bajko-mos-dhcp-options]. DHCP server 616 replies via DHCP ACK message with the IP address of the MoS. The MOS 617 address is then passed to the MIHF locally via some internal APIs. 618 MIHF generates the discovery response message and passes it on to the 619 corresponding MIH user. MIH user then generates an IS query 620 addressed to the remote MoS. MIHF invokes the underlying TCP client 621 which then establishes a transport connection with the remote peer. 622 Once transport connection is available, MIHF sends the IS query via 623 MIH protocol REQUEST message. The message arrives to the destination 624 MIHF and MIH user respectively. MIH user responds to the 625 corresponding IS query and the remote MIHF sends the IS response via 626 MIH protocol RESPONSE message. Thus it arrives to the source MIHF 627 which passes it on to the corresponding MIH user. 629 MN MoS 630 |======================================| |======| |======================| 631 +------+ +-----+ +------+ +------+ +------+ +------+ +----+ +----+ 632 | MIH | |MIHF | | TCP | |DHCP | |DHCP | | TCP | |MIHF| |MIH | 633 | User | | | |Client| |Client| |Server| |Server| | | |User| 634 +------+ +-----+ +------+ +------+ +------+ +------+ +----+ +----+ 635 | | | | | | | | 636 |Discovery| | | | | | | 637 | Request |Invoke DHCP Client |DHCP INFORM | | | | 638 |========>|===================>|===========>| | | | 639 | | (internal process)| with MOS | | | | 640 | | | | option | | | | 641 | | | | | | | | 642 | | | | DHCP ACK | | | | 643 | | | |<===========| | | | 644 | | Inform MoS address | | | | | 645 | |<===================| | | | | 646 | | (internal process) | | | | | 647 |Discovery| | | | | | | 648 |response | | | | | | | 649 |<========| | | | | | | 650 | | | | | | | | 651 |IS Query | | | | | | | 652 |========>| | | | | | | 653 | | | | | | | | 654 | |Invoke TCP| | | | | | 655 | |=========>| | | | | | 656 | | client | TCP connection established | | | 657 | | |<===============================>| | | 658 | | | | | | | | 659 | | | | | | | | 660 | | | | | | | | 661 | | | IS QUERY REQUEST (via MIH protocol) | | 662 | |====================================================>| | 663 | | | | | | |IS | 664 | | | | | | |QUERY | 665 | | | | | | |REQUEST| 666 | | | | | | |======>| 667 | | | | | | | | 668 | | | | | | |QUERY | 669 | | | | | | |RESPONSE 670 | | | | | | |<======| 671 | | | | | | | | 672 | | | IS QUERY RESPONSE (via MIH protocol) | | 673 | |<====================================================| | 674 | | | | | | | | 675 | IS | | | | | | | 676 |RESPONSE | | | | | | | 677 |<========| | | | | | | 678 | | | | | | | | 679 | | | | | | | | 681 Figure 10: Example Flow of Operation Involving MIH User 683 8. Security Considerations 685 There are a number of security issues that need to be taken into 686 account during node discovery and information exchange via a 687 transport connection [I-D.ietf-mipshop-mis-ps] 689 In case where DHCP is used for node discovery and authentication of 690 the source and content of DHCP messages are required, it is 691 recommended that network administrators should use DHCP 692 authentication option described in [RFC3118]. This will also protect 693 the denial of service attacks to DHCP server.[RFC3118] provides 694 mechanisms for both entity authentication and message authentication. 696 In case where DNS is used for discovering MoS, fake DNS requests and 697 responses may cause DoS and the inability of the MN to perform a 698 proper handover, respectively. Where networks are exposed to such 699 DoS, it is recommended that DNS service providers use the Domain Name 700 System Security Extensions (DNSSEC) as described in [RFC4033]. 701 Readers may also refer to 702 [I-D.ietf-dnsop-dnssec-operational-practices] to consider the aspects 703 of DNSSEC Operational Practices. 705 In case where reliable transport protocol such as TCP is used for 706 transport connection between two MIHF peers, TLS [RFC4346] should be 707 used for message confidentiality and data integrity. In particular, 708 TLS is designed for client/server applications and to prevent 709 eavesdropping, tampering, or message forgery. Readers should also 710 follow the recommendations in [RFC4366] that provides generic 711 extension mechanisms for the TLS protocol suitable for wireless 712 environments. 714 In case where unreliable transport protocol such as UDP is used for 715 transport connection between two MIHF peers, DTLS [RFC4347] should be 716 used for message confidentiality and data integrity. The DTLS 717 protocol is based on the Transport Layer Security (TLS) protocol and 718 provides equivalent security guarantees. 720 Alternatively, generic IP layer security, such as IPSec [RFC2401] may 721 be used instead of a specific transport layer secuity for a specific 722 transport. 724 9. IANA Considerations 726 This document registers the following TCP and UDP port(s) with IANA: 728 Keyword Decimal Description 729 ------- ------- ----------- 730 ieee-mih-IS XXX/tcp Media Independent Handover Information Services 731 ieee-mih-IS XXX/udp Media Independent Handover Information Services 732 ieee-mih-ES XXX/tcp Media Independent Handover Event Services 733 ieee-mih-ES XXX/udp Media Independent Handover Event Services 734 ieee-mih-CS XXX/tcp Media Independent Handover Command Services 735 ieee-mih-CS XXX/udp Media Independent Handover Command Services 737 10. Acknowledgements 739 The authors would like to thank Patrick Stupar for his valuable 740 comments and fruitful discussions. 742 11. References 744 11.1. Normative References 746 [I-D.bajko-mos-dhcp-options] 747 Bajko, G., "Dynamic Host Configuration Protocol (DHCPv4 748 and DHCPv6) Options for Mobility Servers (MoS)", 749 draft-bajko-mos-dhcp-options-00 (work in progress), 750 August 2007. 752 [I-D.bajko-mos-dns-discovery] 753 Bajko, G., "Locating Mobility Servers", 754 draft-bajko-mos-dns-discovery-00 (work in progress), 755 August 2007. 757 [I-D.ietf-dhc-dhcpv6-opt-dnsdomain] 758 Yan, R., "Domain Suffix Option for DHCPv6", 759 draft-ietf-dhc-dhcpv6-opt-dnsdomain-04 (work in progress), 760 June 2007. 762 [I-D.ietf-dnsop-dnssec-operational-practices] 763 Gieben, R. and O. Kolkman, "DNSSEC Operational Practices", 764 draft-ietf-dnsop-dnssec-operational-practices-08 (work in 765 progress), March 2006. 767 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 768 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 769 Integrated Scenario", 770 draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in 771 progress), July 2007. 773 [I-D.ietf-mipshop-mis-ps] 774 Melia, T., "Mobility Services Transport: Problem 775 Statement", draft-ietf-mipshop-mis-ps-03 (work in 776 progress), August 2007. 778 [I-D.ietf-tsvwg-udp-guidelines] 779 Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for 780 Application Designers", draft-ietf-tsvwg-udp-guidelines-03 781 (work in progress), September 2007. 783 [RFC1533] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 784 Extensions", RFC 1533, October 1993. 786 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 787 Miller, "Common DNS Implementation Errors and Suggested 788 Fixes", RFC 1536, October 1993. 790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 791 Requirement Levels", BCP 14, RFC 2119, March 1997. 793 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 794 Extensions", RFC 2132, March 1997. 796 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 797 Specification", RFC 2181, July 1997. 799 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 800 Internet Protocol", RFC 2401, November 1998. 802 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 803 RFC 2486, January 1999. 805 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 806 Timer", RFC 2988, November 2000. 808 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 809 Messages", RFC 3118, June 2001. 811 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 812 and M. Carney, "Dynamic Host Configuration Protocol for 813 IPv6 (DHCPv6)", RFC 3315, July 2003. 815 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 816 Reserved for Documentation", RFC 3849, July 2004. 818 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 819 Rose, "DNS Security Introduction and Requirements", 820 RFC 4033, March 2005. 822 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 823 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 825 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 826 Security", RFC 4347, April 2006. 828 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 829 and T. Wright, "Transport Layer Security (TLS) 830 Extensions", RFC 4366, April 2006. 832 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 833 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 834 RFC 4787, January 2007. 836 11.2. Informative References 838 Authors' Addresses 840 Telemaco Melia (editor) 841 NEC 843 Email: telemaco.melia@nw.neclab.eu 844 Gabor Bajko 845 Nokia 847 Email: Gabor.Bajko@nokia.com 849 Subir Das 850 Telcordia 852 Email: subir@research.telcordia.com 854 Nada Golmie 855 NIST 857 Email: nada.golmie@nist.gov 859 Sam Xia 860 Huawei 862 Email: xiazhongqi@huawei.com 864 Juan Carlos Zuniga 865 InterDigital 867 Email: j.c.zuniga@ieee.org 869 Full Copyright Statement 871 Copyright (C) The IETF Trust (2007). 873 This document is subject to the rights, licenses and restrictions 874 contained in BCP 78, and except as set forth therein, the authors 875 retain all their rights. 877 This document and the information contained herein are provided on an 878 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 879 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 880 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 881 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 882 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 883 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 885 Intellectual Property 887 The IETF takes no position regarding the validity or scope of any 888 Intellectual Property Rights or other rights that might be claimed to 889 pertain to the implementation or use of the technology described in 890 this document or the extent to which any license under such rights 891 might or might not be available; nor does it represent that it has 892 made any independent effort to identify any such rights. Information 893 on the procedures with respect to rights in RFC documents can be 894 found in BCP 78 and BCP 79. 896 Copies of IPR disclosures made to the IETF Secretariat and any 897 assurances of licenses to be made available, or the result of an 898 attempt made to obtain a general license or permission for the use of 899 such proprietary rights by implementers or users of this 900 specification can be obtained from the IETF on-line IPR repository at 901 http://www.ietf.org/ipr. 903 The IETF invites any interested party to bring to its attention any 904 copyrights, patents or patent applications, or other proprietary 905 rights that may cover technology that may be required to implement 906 this standard. Please address the information to the IETF at 907 ietf-ipr@ietf.org. 909 Acknowledgment 911 Funding for the RFC Editor function is provided by the IETF 912 Administrative Support Activity (IASA).