idnits 2.17.1 draft-ietf-mipshop-mstp-solution-06.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1029. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1040. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1047. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1053. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 3, 2008) is 5712 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) == Outdated reference: A later version (-14) exists of draft-ietf-mipshop-mos-dhcp-options-03 == Outdated reference: A later version (-07) exists of draft-ietf-mipshop-mos-dns-discovery-01 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-udp-guidelines-10 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4641 (Obsoleted by RFC 6781) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mipshop WG T. Melia, Ed. 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track G. Bajko 5 Expires: March 7, 2009 Nokia 6 S. Das 7 Telcordia Technologies Inc. 8 N. Golmie 9 NIST 10 JC. Zuniga 11 InterDigital Communications, LLC 12 September 3, 2008 14 Mobility Services Framework Design (MSFD) 15 draft-ietf-mipshop-mstp-solution-06 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on March 7, 2009. 42 Abstract 44 This document describes a mobility services framework design (MSFD) 45 for the IEEE 802.21 Media Independent Handover (MIH) protocol that 46 addresses identified issues associated with the transport of MIH 47 messages. The document also describes mechanisms for mobility 48 service (MoS) discovery and transport layer mechanisms for the 49 reliable delivery of MIH messages. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [RFC2119]. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Scenario S1: Home Network MoS . . . . . . . . . . . . . . 6 63 3.2. Scenario S2: Visited Network MoS . . . . . . . . . . . . . 6 64 3.3. Scenario S3: Third party MoS . . . . . . . . . . . . . . . 7 65 3.4. Scenario S4: Roaming MoS . . . . . . . . . . . . . . . . . 7 66 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.2. MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . . . . 10 69 5. MoS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 11 70 5.1. MoS Discovery when MN and MoSh are in the home network 71 (Scenario S1) . . . . . . . . . . . . . . . . . . . . . . 11 72 5.2. MoS Discovery when MN is in visited network and MoSv 73 is also in visited network (Scenario S2) . . . . . . . . . 12 74 5.3. MoS discovery when MIH services are in a 3rd party 75 remote network (scenario S3) . . . . . . . . . . . . . . . 12 76 5.4. MoS Discovery when the MN is in a visited Network and 77 Services are at the Home network . . . . . . . . . . . . . 13 78 6. MIH Transport Options . . . . . . . . . . . . . . . . . . . . 13 79 6.1. MIH Message size . . . . . . . . . . . . . . . . . . . . . 14 80 6.2. MIH Message rate . . . . . . . . . . . . . . . . . . . . . 15 81 6.3. Retransmission . . . . . . . . . . . . . . . . . . . . . . 15 82 6.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 16 83 6.5. General guidelines . . . . . . . . . . . . . . . . . . . . 16 84 7. Operation Flows . . . . . . . . . . . . . . . . . . . . . . . 17 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 92 Intellectual Property and Copyright Statements . . . . . . . . . . 23 94 1. Introduction 96 This document proposes a solution to the issues identified in the 97 problem statement document [RFC5164] for the layer 3 transport of 98 IEEE 802.21 MIH protocols. 100 The MIH Layer 3 transport problem is divided in two main parts: the 101 discovery of a node that supports specific Mobility Services (MoS) 102 and the transport of the information between a mobile node (MN) and 103 the discovered node. The discovery process is required for the MN to 104 obtain the information needed for MIH protocol communication with a 105 peer node. The information includes the transport address (e.g., the 106 IP address) of the peer node and the types of MoS provided by the 107 peer node. 109 This document lists the major MoS deployment scenarios. It describes 110 the solution architecture, including the MSFD reference model and 111 MIHF identifiers. MoS discovery procedures explain how the MN 112 discovers MoS in its home network, in a visited network or in a third 113 party network. The remainder of this document describes the MIH 114 transport architecture, example message flows for several signaling 115 scenarios, and security issues. 117 2. Terminology 119 The following acronyms and terminology are used in this document: 121 MIH Media Independent Handover: the handover support architecture 122 defined by the IEEE 802.21 working group that consists of the MIH 123 Function (MIHF), MIH Network Entities and MIH protocol messages. 125 MIHF Media Independent Handover Function: a switching function that 126 provides handover services including the Event Service (ES), 127 Information Service (IS), and Command Service (CS), through 128 service access points (SAPs) defined by the IEEE 802.21 working 129 group [IEEE80221]. 131 MIHF User An entity that uses the MIH SAPs to access MIHF services, 132 and which is responsible for initiating and terminating MIH 133 signaling. 135 MIHFID Media Independent Handover Function Identifier: an identifier 136 required to uniquely identify the MIHF endpoints for delivering 137 mobility services (MoS); it is implemented as either a FQDN or 138 NAI. 140 MoS Mobility Services: those services, as defined in the MIH problem 141 statement document [RFC5164] , which includes the MIH IS, CS, and 142 ES services defined by the IEEE 802.21 standard. 144 MoSh: Mobility Services assigned in the mobile node's Home Network 146 MoSv: Mobility Services assigned in the Visited Network, which is 147 any network other than the mobile node's home network 149 MoS3: Mobility Services assigned in a 3rd Party Network, which is a 150 network that is neither the Home Network nor the current Visited 151 Network. 153 MN Mobile Node: an Internet device whose location changes, along with 154 its point of connection to the network. 156 MSTP Mobility Services Transport Protocol: a protocol that is used 157 to deliver MIH protocol messages from an MIHF to other MIH-aware 158 nodes in a network. 160 IS Information Service: a MoS that originates at the lower or upper 161 layers of the protocol stack and sends information to the local or 162 remote upper or lower layers of the protocol stack. The purpose 163 of IS is to exchange information elements (IEs) relating to 164 various neighboring network information. 166 ES Event Service: a MoS that originates at a remote MIHF or the lower 167 layers of protocol stack and sends information to the local MIHF 168 or local higher layers. The purpose of the ES is to report 169 changes in link status (e.g. Link Going Down messages) and 170 various lower layer events. 172 CS Command Service: MoS that sends commands from the remote MIHF or 173 local upper layers to the remote or local lower layers of the 174 protocol stack to switch links or to get link status. 176 FQDN: Fully-Qualified Domain Name: a complete domain name for a host 177 on the Internet, consisting of a host name followed by a domain 178 name (e.g. myexample.example.org) 180 NAI Network Access Identifier: the user ID that a user submits 181 during network access authentication[RFC4282]. For mobile users, 182 the NAI identifies the user and helps to route the authentication 183 request message. 185 NAT Network Address Translator: A device that implements the Network 186 Address Translation function described in [RFC3022], in which 187 local or private network layer addresses are mapped to valid 188 network addresses and port numbers. 190 DHCP Dynamic Host Configuration Protocol: a protocol described in 191 [RFC2131] and [RFC3315] that allows Internet devices to obtain 192 respectively IPv4 and IPv6 addresses, subnet masks, default 193 gateway addresses, and other IP configuration information from 194 DHCP servers. 196 DNS Domain Name System: a protocol described in [RFC1035] that 197 translates domain names to IP addresses. 199 AAA Authentication, Authorization and Accounting: a set of network 200 management services that respectively determine the validity of a 201 user's ID, determine whether a user is allowed to use network 202 resources, and track users' use of network resources. 204 Home AAA AAAh: an AAA server located on the MN's home network. 206 Visited AAA AAAv: an AAA server located in a visited network that is 207 not the MN's home network. 209 MIH ACK MIH Acknowledgement Message: a MIH signaling message that a 210 MIHF sends in response to an MIH message from a sending MIHF, when 211 UDP is used as the MSTP. 213 PoS Point of Service: a network-side MIHF instance that exchanges 214 MIH messages with a MN-based MIHF. 216 NAS Network Access Server: a server to which a MN initially connects 217 when it is trying to gain a connection to a network and which 218 determines whether the MN is allowed to connect to the NAS's 219 network. 221 UDP User Datagram Protocol: a connectionless transport layer 222 protocol used to send datagrams between a source and a destination 223 at a given port, defined in RFC 768. 225 TCP Transmission Control Protocol: a stream-oriented transport layer 226 protocol that provides a reliable delivery service with congestion 227 control, defined in RFC 793. 229 RTT Round-Trip Time: an estimation of the time required for a 230 segment to travel from a source to a destination and an 231 acknowledgement to return to the source that is used by TCP in 232 connection with timer expirations to determine when a segment is 233 considered lost and should be resent. 235 MTU Maximum Transmission Unit: the largest size packet that can be 236 sent on a network without requiring fragmentation [RFC1191]. 238 PMTU Path MTU. 240 TLS Transport Layer Security Protocol: an application layer protocol 241 that primarily assures privacy and data integrity between two 242 communicating network entities [RFC5246]. 244 SMSS Sender Maximum Segment Size: size of the largest segment that 245 the sender can transmit as per [RFC2581] 247 3. Deployment Scenarios 249 This section describes the various possible deployment scenarios for 250 the MN and the MoS. The relative positioning of MN and MoS affects 251 MoS discovery as well as the performance of the MIH signaling 252 service. 254 3.1. Scenario S1: Home Network MoS 256 In this scenario, the MN and the services are located in the home 257 network. We refer to this set of services as MoSh as in Figure 1. 258 The MoSh can be located at the access network the MN uses to connect 259 to the home network, or it can be located elsewhere. 261 +--------------+ +====+ 262 | HOME NETWORK | |MoSh| 263 +--------------+ +====+ 264 /\ 265 || 266 \/ 267 +--------+ 268 | MN | 269 +--------+ 271 Figure 1: MoS in the Home network 273 3.2. Scenario S2: Visited Network MoS 275 In this scenario, the MN is in the visited network and mobility 276 services are provided by the visited network. We refer to this as 277 MoSv as shown in Figure 2. 279 +--------------+ 280 | HOME NETWORK | 281 +--------------+ 282 /\ 283 || 284 \/ 285 +====+ +-----------------+ 286 |MoSv| | VISITED NETWORK | 287 +====+ +-----------------+ 288 /\ 289 || 290 \/ 291 +--------+ 292 | MN | 293 +--------+ 295 Figure 2: MoSV in the Visited Network 297 3.3. Scenario S3: Third party MoS 299 In this scenario, the MN is in its home network or in a visited 300 network and services are provided by a 3rd party network. We refer 301 to this situation as MoS3 as shown in Figure 3. (Note that MoS can 302 exist both in home and in visited networks). 304 +--------------+ 305 | HOME NETWORK | 306 +====+ +--------------+ +--------------+ 307 |MoS3| | THIRD PARTY | <===> /\ 308 +====+ +--------------+ || 309 \/ 310 +-----------------+ 311 | VISITED NETWORK | 312 +-----------------+ 313 /\ 314 || 315 \/ 316 +--------+ 317 | MN | 318 +--------+ 320 Figure 3: MoS form a third party 322 3.4. Scenario S4: Roaming MoS 324 In this scenario, the MN is located in the visited network and all 325 MIH services are provided by the home network, as shown in Figure 4. 327 +====+ +--------------+ 328 |MoSh| | HOME NETWORK | 329 +====+ +--------------+ 330 /\ 331 || 332 \/ 333 +-----------------+ 334 | VISITED NETWORK | 335 +-----------------+ 336 /\ 337 || 338 \/ 339 +--------+ 340 | MN | 341 +--------+ 343 Figure 4: MoS provided by the home while in visited 345 Different types of MoS can be provided independently of other types 346 and there is no strict relationship between ES, CS and IS, nor is 347 there a requirement that the entities that provide these services 348 should be co-located. However, while IS tends to involve a large 349 amounts of static information, ES and CS are dynamic services and 350 some relationships between them can be expected, e.g., a handover 351 command (CS) could be issued upon reception of a link event (ES). 352 This document does not make any assumption on the location of the MoS 353 (although there might be some preferred configurations), and aims at 354 flexible MSFD to discover different services in different locations 355 to optimize handover performance. MoS discovery is discussed in more 356 detail in Section 5. 358 4. Solution Overview 360 As mentioned in Section 1, the solution space is being divided into 361 two functional domains: discovery and transport. The following 362 assumptions have been made: 364 o The solution is primarily aimed at supporting IEEE 802.21 MIH 365 services, namely Information Service (IS), Event Service (ES), and 366 Command Service (CS). 368 o If the MIHFID is available, FQDN or NAI's realm is used for 369 mobility service discovery. 371 o The solutions are chosen to cover all possible deployment 372 scenarios as described in Section 3. 374 o MoS discovery can be performed during initial network attachment 375 or at any time thereafter. 377 The MN may know the realm of the MoS to be discovered. The MN may 378 also be pre-configured with the address of the MoS to be used. In 379 case the MN does not know what realm/MoS to query, dynamic assignment 380 methods are described in Section 5. 382 The discovery of the MoS (and the related configuration at MIHF 383 level) is required to bind two MIHF peers (e.g. MN and MoS) with 384 their respective IP addresses. Discovery MUST be executed in the 385 following conditions: 387 o Bootstrapping: upon successful layer 2 network attachment the MN 388 MAY be required to use DHCP for address configuration. These 389 procedures can carry the required information for MoS 390 configuration in specific DHCP options. 392 o If the MN does not receive MoS information during network 393 attachment and the MN does not have a pre-configured MoS, it MUST 394 run a discovery procedure upon initial IP address configuration. 396 o If the MN changes its IP address (e.g. upon handover) it MUST 397 refresh MIHF peers binding (i.e. MIHF registration process). In 398 case the MoS used is not suitable anymore (e.g. too large RTT 399 experienced) the MN MAY need to perform a new discovery procedure. 401 o if the MN is a multi-homed device and it communicates with the 402 same MoS via different IP addresses it MAY run discovery 403 procedures if one of the IP addresses changes. 405 Once the MIHF peer has been discovered, MIH information can be 406 exchanged between MIH peers over a transport protocol such as UDP or 407 TCP. The usage of transport protocols is described in Section 6 and 408 packing of the MIH messages does not require extra framing since the 409 MIH protocol defined in [IEEE80221] already contains a length field. 411 4.1. Architecture 413 Figure 5 depicts the MSFD reference model and its components within a 414 node. The topmost layer is the MIHF user. This set of applications 415 consists of one or more MIH clients that are responsible for 416 operations such as generating query and response, processing Layer 2 417 triggers as part of the ES, and initiating and carrying out handover 418 operations as part of the CS. Beneath the MIHF user is the MIHF 419 itself. This function is responsible for MoS discovery, as well as 420 creating, maintaining, modifying, and destroying MIH signaling 421 associations with other MIHFs located in MIH peer nodes. Below the 422 MIHF are various transport layer protocols as well as address 423 discovery functions. 425 +--------------------------+ 426 | MIHF User | 427 +--------------------------+ 428 || 429 +--------------------------+ 430 | MIHF | 431 +--------------------------+ 432 || || || 433 || +------+ +-----+ 434 || | DHCP | | DNS | 435 || +------+ +-----+ 436 || || || 437 +--------------------------+ 438 | TCP/UDP | 439 +--------------------------+ 441 Figure 5: MN stack 443 The MIHF relies on the services provided by TCP and UDP for 444 transporting MIH messages, and relies on DHCP and DNS for peer 445 discovery. In cases where the peer MIHF IP address is not pre- 446 configured, the source MIHF needs to discover it either via DHCP or 447 DNS as described in Section 5. Once the peer MIHF is discovered, 448 MIHF must exchange messages with its peer over either UDP or TCP. 449 Specific recommendations regarding the choice of transport protocols 450 are provided in Section 6. 452 There are no security features currently defined as part of the MIH 453 protocol level. However, security can be provided either at the 454 transport or IP layer where it is necessary. Section 8 provides 455 guidelines and recommendations for security. 457 4.2. MIHF Identifiers (FQDN, NAI) 459 MIHFID is an identifier required to uniquely identify the MIHF end 460 points for delivering the mobility services (MoS). Thus an MIHF 461 identifier needs to be unique within a domain where mobility services 462 are provided and independent of the configured IP addresse(s). An 463 MIHFID MUST be represented either in the form of an FQDN [RFC2181] or 464 NAI [RFC4282]. An MIHFID can be pre-configured or discovered through 465 the discovery methods described in Section 5. 467 5. MoS Discovery 469 The MoS discovery method depends on whether the MN attempts to 470 discover an MoS in the home network, in the visited network, or in a 471 3rd party remote network that is neither the home network nor the 472 visited network. In the case the MN has already a MoS address pre- 473 configured it is not necessary to run the discovery procedure. If 474 the MN does not have pre-configured MoS the following procedure 475 applies. 477 In the case where MoS is provided locally (scenarios S1 and S2) , the 478 discovery techniques described in [I-D.ietf-mipshop-mos-dhcp-options] 479 and [I-D.ietf-mipshop-mos-dns-discovery] are both applicable as 480 described in Section 5.1 and Section 5.2 482 In the case where MoS is provided in the home network while the MN is 483 in the visited network (scenario S4), the DNS based discovery 484 described in [I-D.ietf-mipshop-mos-dns-discovery] is applicable. 486 In the case where MoS is provided by a third party network which is 487 different from the current visited network (scenario S3), only the 488 DNS based discovery method described in 489 [I-D.ietf-mipshop-mos-dns-discovery] is applicable. 491 It should be noted that authorization of a MN to use a specific MoS 492 server is neither in scope of this document nor is currently 493 specified in [IEEE80221]. We further assume all devices can access 494 discovered MoS. In case future deployments will implement 495 authorization policies the mobile nodes should fall back to other 496 learned MoS if authorization is denied. 498 5.1. MoS Discovery when MN and MoSh are in the home network (Scenario 499 S1) 501 To discover an MoS in the home network, the MN SHOULD use the DNS 502 based MoS discovery method described in 503 [I-D.ietf-mipshop-mos-dns-discovery]. In order to use that 504 mechanism, the MN MUST have the home domain pre-configured in the MNs 505 (i.e. subscription is tied to a network). The DNS query option is 506 shown in Figure 6a. Alternatively, the MN MAY use the DHCP options 507 for MoS discovery[I-D.ietf-mipshop-mos-dhcp-options] as shown 508 inFigure 6b (in some deployments DHCP relay may not be present). 510 +-------+ 511 +----+ |Domain | 512 | MN |-------->|Name | 513 +----+ |Server | 514 +-------+ 515 MN@xyz.com 517 (a) using DNS Query 519 +-----+ +------+ 520 +----+ | | |DHCP | 521 | MN |<----->| DHCP|<---->|Server| 522 +----+ |Relay| | | 523 +-----+ +------+ 525 (b) Using DHCP Option 527 Figure 6: MOS Discovery (a) Using DNS query, (b) using DHCP option 529 5.2. MoS Discovery when MN is in visited network and MoSv is also in 530 visited network (Scenario S2) 532 To discover an MoS in the visited network, the MN SHOULD attempt to 533 use the DHCP options for MoS discovery 534 [I-D.ietf-mipshop-mos-dhcp-options] as shown in Figure 7. 536 +-----+ +------+ 537 +----+ | | |DHCP | 538 | MN |<----->| DHCP|<---->|Server| 539 +----+ |Relay| | | 540 +-----+ +------+ 542 MoS Discovery using DHCP options 544 Figure 7: Discovery using DHCP option 546 5.3. MoS discovery when MIH services are in a 3rd party remote network 547 (scenario S3) 549 To discover an MoS in a remote network other than home network, the 550 MN MUST use the DNS based MoS discovery method described in 551 [I-D.ietf-mipshop-mos-dns-discovery]. The MN MUST first learn the 552 domain name of the network containing the MoS it is searching for. 553 The MN can query its current MoS to find out the domain name of a 554 specific network or the domain name of a network at a specific 555 location (as in Figure 8 part (a), IEEE 802.21 defines information 556 elements such as OPERATOR ID and SERVICE PROVIDER ID which can be a 557 domain name. An IS query can provide this information, see 558 [IEEE80221]). 560 Alternatively, the MN MAY query a MoS previously known to learn the 561 domain name of the desired network . Finally, the MN MUST use DNS 562 based discovery mechanisms to find MoS in the remote network as 563 inFigure 8 part(b). It should be noted that step b can only be 564 performed upon obtaining the domain name of the remote network. 566 +------------+ 567 +----+ | | 568 | | |Information | 569 | MN |-------->| Server | 570 | | |(previously | 571 +----+ |discovered) | 572 +------------+ 574 (a) Using IS query to find the FQDN on the remote network 576 +-------+ 577 +----+ |Domain | 578 | MN |-------->|Name | 579 +----+ |Server | 580 +-------+ 581 MN@xyz.com 583 (b) using DNS Query in the remote network 585 Figure 8: MOS Discovery using (a) IS Query to a known IS Server, (b) 586 DNS Query 588 5.4. MoS Discovery when the MN is in a visited Network and Services are 589 at the Home network 591 To discover an MoS in the visited network when MIH services are 592 provided by the home network, the DNS based discovery method 593 described in [I-D.ietf-mipshop-mos-dns-discovery] is applicable. To 594 discover the MoS at home while in a visited network using DNS, the MN 595 SHOULD use the procedures described in Section 5.1. 597 6. MIH Transport Options 599 Once the Mobility Services have been discovered, MIH peers run a 600 capability discovery and subscription procedures as specified in 601 [IEEE80221]. MIH peers MAY exchange information over TCP, UDP or any 602 other transport supported by both the server and the client. The 603 client MAY use the DNS discovery mechanism to discover which 604 transport protocols are supported by the server in addition to TCP 605 and UDP that are recommended in this document. While either protocol 606 can provide the basic transport functionality required, there are 607 performance trade-offs and unique characteristics associated with 608 each that need to be considered in the context of the MIH services 609 for different network loss and congestion conditions. The objectives 610 of this section are to discuss these trade-offs for different MIH 611 settings such as the MIH message size and rate, and the 612 retransmission parameters. In addition, factors such as NAT 613 traversal are also discussed. Given the reliability requirements for 614 the MIH transport, it is assumed in this discussion that the MIH ACK 615 mechanism is to be used in conjunction with UDP, while it is 616 preferred to avoid using MIH ACKs with TCP since TCP includes 617 acknowledgement and retransmission functionality. 619 6.1. MIH Message size 621 Although the MIH message size varies widely from about 30 bytes (for 622 a capability discovery request) to around 65000 bytes (for an IS 623 MIH_Get_Information response primitive), a typical MIH message size 624 for the ES/CS service ranges between 50 to 100 bytes [IEEE80221]. 625 Thus, considering the effects of the MIH message size on the 626 performance of the transport protocol brings us to discussing two 627 main issues, related to fragmentation of long messages in the context 628 of UDP and the concatenation of short messages in the context of TCP. 630 Since transporting long MIH messages may require fragmentation that 631 is not available in UDP, if MIH is using UDP a limit MUST be set on 632 the size of the MIH message based on the path MTU to destination (or 633 the minimum where PMTU is not implemented). The minimum PMTU depends 634 on the IP version used for transmission, and is the lesser of 576 635 bytes for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC2460], although 636 applications may reduce these values to guard against the presence of 637 tunnels. 639 It should be noted that MIH layer fragmentation MUST NOT be used 640 together with IP layer fragmentation as specified in [IEEE80221]. 642 The loss of an IP fragment leads to the retransmission of an entire 643 MIH message, which in turn leads to poor end-to-end delay performance 644 in addition to wasted bandwidth. Additional recommendations in 645 [I-D.ietf-tsvwg-udp-guidelines] apply for limiting the size of the 646 MIH message when using UDP and assuming IP layer fragmentation. In 647 terms of dealing with short messages, TCP has the capability to 648 concatenate very short messages in order to reduce the overall 649 bandwidth overhead. However, this reduced overhead comes at the cost 650 of additional delay to complete an MIH transaction, which may not be 651 acceptable for CS and ES services. Note also that TCP is a stream 652 oriented protocol and measures data flow in terms of bytes, not 653 messages. Thus it is possible to split messages across multiple TCP 654 segments if they are long enough. Even short messages can be split 655 across two segments. This can also cause unacceptable delays, 656 especially if the link quality is severely degraded as is likely to 657 happen when the MN is exiting a wireless access coverage area. The 658 use of the PUSH bit can alleviate this problem by triggering 659 transmission of a segment less than the SMSS. 661 6.2. MIH Message rate 663 The frequency of MIH messages varies according to the MIH service 664 type. It is expected that CS/ES message arrive at a rate of one in 665 hundreds of milliseconds in order to capture quick changes in the 666 environment and/ or process handover commands. On the other hand, IS 667 messages are exchanged mainly every time a new network is visited 668 which may be in order of hours or days. Therefore a burst of either 669 short CS/ES messages or long IS message exchanges (in the case where 670 multiple MIH nodes request information) may lead to network 671 congestion. While the built-in rate-limiting controls available in 672 TCP may be well suited for dealing with these congestion conditions, 673 this may result in large transmission delays that may be unacceptable 674 for the timely delivery of ES/CS messages. On the other hand, if UDP 675 is used, a rate-limiting effect similar to the one obtained with TCP 676 may be obtained by adequately adjusting the parameters of a token 677 bucket regulator as defined in the MIH specifications [IEEE80221]. 678 Recommendations for token bucket parameter settings are as follow: 680 o If MIHF knows the RTT, the rate can be based upon this 682 o If not, then on average it SHOULD NOT send more than one UDP 683 message every 3 seconds. 685 6.3. Retransmission 687 For TCP, the retransmission timeout is adjusted according to the 688 measured RTT. However due to the exponential backoff mechanism, the 689 delay associated with retransmission timeouts may increase 690 significantly with increased packet loss. 692 If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs. 693 An MIH message is retransmitted if its corresponding MIH ACK is not 694 received by the generating node within a timeout interval set by the 695 MIHF. This approach does not include an exponential backoff and 696 therefore tends to degrade more gracefully than TCP when the packet 697 loss rate becomes large, in the sense that the expected delay does 698 not increase exponentially. The number of retransmissions is 699 limited, which reduces head-of-line blocking of other MIH messages, 700 but this can cause important ES/CS messages to be lost. The default 701 number of retransmissions is set to 2 and retransmissions are 702 controlled by a timer with a default value of 10s. No backoff 703 mechanism is specified. 705 6.4. NAT Traversal 707 There are no known issues for NAT traversal when using TCP. The 708 default connection timeout of 24 hours is considered adequate for MIH 709 transport purposes. However, issues with NAT traversal using UDP are 710 documented in [I-D.ietf-tsvwg-udp-guidelines]. Communication 711 failures are experienced when middleboxes destroy the per-flow state 712 associated with an application session during periods when the 713 application does not exchange any UDP traffic. Hence, communication 714 between the MN and the MoS SHOULD be able to gracefully handle such 715 failures and implement mechanisms to re-establish their UDP sessions. 716 In addition and in order to avoid such failures, MIH messages MAY be 717 sent periodically, similarly to keep-alive messages, to attempt to 718 refresh middlebox state. As [RFC4787] requires a minimum state 719 timeout of two minutes or more, MIH messages using UDP as transport 720 SHOULD be sent once every two minutes. Re-registration or Event 721 indication messages as defined in [IEEE80221] MAY be used for this 722 purpose. 724 6.5. General guidelines 726 Since ES and CS messages are small in nature and have tight latency 727 requirements, UDP in combination with MIH acknowledgement MAY be used 728 for transporting ES and CS messages. On the other hand, IS messages 729 are more resilient in terms of latency constraints and some long IS 730 messages could exceed the MTU of the path to the destination. For 731 both UDP and TCP cases, if a port number is not explicitly assigned 732 (e.g. by the DNS SRV), MIH messages sent over UDP, TCP or other 733 supported transport MUST use the default port number defined for that 734 particular transport. 736 MoS server MUST support both UDP and TCP for MIH transport and the MN 737 MUST support TCP. Additionally, the server and MN MAY support 738 additional transport mechanisms. The MN MAY use the procedures 739 defined in [I-D.ietf-mipshop-mos-dns-discovery] to discover 740 additional transport protocols supported by the server. 742 7. Operation Flows 744 Figure 9 gives an example operation flow between MIHF peers when an 745 MIH user requests an IS service and both the MN and the MoS are in 746 the MN's home network. DHCP is used for MoS discovery and TCP is 747 used for establishing a transport connection to carry the IS 748 messages. When MoS is not pre-configured, the MIH user needs to 749 discover the IP address of MoS to communicate with the remote MIHF. 750 Therefore the MIH user sends a discovery request message to the local 751 MIHF as defined in [IEEE80221]. 753 In this example (one could draw similar mechanisms with DHCPv6), we 754 assume that MoS discovery is performed before a transport connection 755 is established with the remote MIHF, and the DHCP client process is 756 invoked via some internal APIs. DHCP Client sends DHCP INFORM 757 message according to standard DHCP and with the MoS option as defined 758 in [I-D.ietf-mipshop-mos-dhcp-options]. DHCP server replies via DHCP 759 ACK message with the IP address of the MoS. The MoS address is then 760 passed to the MIHF locally via some internal APIs. MIHF generates 761 the discovery response message and passes it on to the corresponding 762 MIH user. The MIH user generates an IS query addressed to the remote 763 MoS. MIHF invokes the underlying TCP client which establishes a 764 transport connection with the remote peer. Once the transport 765 connection is established, MIHF sends the IS query via MIH protocol 766 REQUEST message. The message and query arrive at the destination 767 MIHF and MIH user respectively. The MoS MIH user responds to the 768 corresponding IS query and the MoS MIHF sends the IS response via MIH 769 protocol RESPONSE message. The message arrives at the source MIHF 770 which passes the IS response on to the corresponding MIH user. 772 MN MoS 773 |===================================| |======| |===================| 774 + ---------+ + ---------+ 775 | MIH USER | +------+ +------+ +------+ +------+ | MIH USER | 776 | +------+ | | TCP | |DHCP | |DHCP | | TCP | | +------+ | 777 | | MIHF | | |Client| |Client| |Server| |Server| | | MIHF | | 778 +----------+ +------+ +------+ +------+ +------+ +----------+ 779 | | | | | | 780 |MIH Discovery | | | | | 781 |Request | | | | | 782 |(MIH User-> MIHF)| | | | | 783 |======> | | | | | 784 | | | | | | 785 |Invoke DHCP Client | | | | 786 |(Internal process with MoS)|DHCP INFORM| | | 787 |==========================>|==========>| | | 788 | | | | | | 789 | | | | | | 790 | | | DHCP ACK | | | 791 | | |<==========| | | 792 | Inform MoS address | | | | 793 |<==========================| | | | 794 | (internal process) | | | | 795 | | | | | 796 |Discovery | | | | | 797 |Response | | | | | 798 |<====== | | | | | 799 |(MIH User<- MIHF)| | | | | 800 | | | | | | 801 |IS Query | | | | | 802 |=======> | | | | | 803 |(MIH User-> MIHF)| | | | | 804 | | | | | | 805 |Invoke TCP Client| | | | | 806 |================>| | | | | 807 |(Internal process| | | | | 808 |with MOS) | | | | | 809 | | | | | | 810 | | TCP connection established | | 811 | |<=============================>| | 812 | | | | | | 813 | | | | | | 814 | | | | | | 815 | IS QUERY REQUEST (via MIH protocol) | 816 |===========================================================>| 817 | | | | | | 818 | | | | | | 819 | | | | | | 820 | | | | | IS QUERY| 821 | | | | | REQUEST| 822 | | | | | =====>| 823 | | | | (MIHF-> MIH User)| 824 | | | | | | 825 | | | | | QUERY| 826 | | | | | RESPONSE| 827 | | | | | <=====| 828 | | | | (MIHF <-MIH User) | 829 | | | | | | 830 | | IS QUERY RESPONSE (via MIH protocol) | 831 |<===========================================================| 832 | | | | | | 833 | IS | | | | | 834 |RESPONSE | | | | | 835 |<======== | | | | | 836 |(MIH User <-MIHF)| | | | | 837 | | | | | | 838 Figure 9: Example Flow of Operation Involving MIH User 840 8. Security Considerations 842 There are a number of security issues that need to be taken into 843 account during node discovery and information exchange via a 844 transport connection [RFC5164] 846 In the case where DHCP is used for node discovery and authentication 847 of the source and content of DHCP messages is required, network 848 administrators SHOULD use DHCP authentication option described in 849 [RFC3118], where available or rely upon link layer security. This 850 will also protect the DHCP server against denial of service attacks 851 to. [RFC3118] provides mechanisms for both entity authentication and 852 message authentication. In case where DHCP authentication mechanism 853 is not available administrators may need to rely upon underlying link 854 layer security. In such cases the link between DHCP client and 855 layer-2 termination point may be protected but the DHCP message 856 source and its messages can not be authenticated or check integrity 857 protection unless there exits a security binding between link layer 858 and DHCP layer. 860 In the case where DNS is used for discovering MoS, fake DNS requests 861 and responses may cause DoS and the inability of the MN to perform a 862 proper handover, respectively. Where networks are exposed to such 863 DoS, it is RECOMMENDED that DNS service providers use the Domain Name 864 System Security Extensions (DNSSEC) as described in [RFC4033]. 865 Readers may also refer to [RFC4641] to consider the aspects of DNSSEC 866 Operational Practices. 868 In the case where reliable transport protocol such as TCP is used for 869 transport connection between two MIHF peers, TLS [RFC5246] with 870 server-side certificates SHOULD be used for server only 871 authentication, message confidentiality and data integrity. Certain 872 subscriptions may include client certificates, and in those cases 873 servers MAY require the clients to authenticate themselves using 874 client-side certificates. Readers should also follow the 875 recommendations in [RFC5246] that provides generic extension 876 mechanisms for the TLS protocol suitable for wireless environments. 878 In the case where unreliable transport protocol such as UDP is used 879 for transport connection between two MIHF peers, DTLS [RFC4347] 880 SHOULD be used for message confidentiality and data integrity. The 881 DTLS protocol is based on the Transport Layer Security (TLS) protocol 882 and provides equivalent security guarantees. 884 9. IANA Considerations 886 This document registers the following TCP and UDP port(s) with IANA: 888 Keyword Decimal Description 889 -------- --------------- ------------ 890 ieee-mih TBD_BY_IANA/tcp MIH Services 891 ieee-mih TBD_BY_IANA/udp MIH Services 893 10. Acknowledgements 895 The authors would like to thank Yoshihiro Ohba, David Griffith, Kevin 896 Noll, Vijay Devarapalli, Patrick Stupar and Sam Xia for their 897 valuable comments, reviews and fruitful discussions. 899 11. References 901 11.1. Normative References 903 [I-D.ietf-mipshop-mos-dhcp-options] 904 Bajko, G. and S. Das, "Dynamic Host Configuration Protocol 905 (DHCPv4 and DHCPv6) Options for Mobility Server (MoS) 906 discovery", draft-ietf-mipshop-mos-dhcp-options-03 (work 907 in progress), June 2008. 909 [I-D.ietf-mipshop-mos-dns-discovery] 910 Bajko, G., "Locating Mobility Servers using DNS", 911 draft-ietf-mipshop-mos-dns-discovery-01 (work in 912 progress), May 2008. 914 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 915 Requirement Levels", BCP 14, RFC 2119, March 1997. 917 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 918 Specification", RFC 2181, July 1997. 920 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 921 Messages", RFC 3118, June 2001. 923 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 924 and M. Carney, "Dynamic Host Configuration Protocol for 925 IPv6 (DHCPv6)", RFC 3315, July 2003. 927 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 928 Rose, "DNS Security Introduction and Requirements", 929 RFC 4033, March 2005. 931 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 932 Network Access Identifier", RFC 4282, December 2005. 934 11.2. Informative References 936 [I-D.ietf-tsvwg-udp-guidelines] 937 Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 938 for Application Designers", 939 draft-ietf-tsvwg-udp-guidelines-10 (work in progress), 940 August 2008. 942 [IEEE80221] 943 "Draft IEEE Standard for Local and Metropolitan Area 944 Networks: Media Independent Handover Services", IEEE LAN/ 945 MAN Draft IEEE P802.21/D13.00, August 2008. 947 [RFC1035] Mockapetris, P., "Domain names - implementation and 948 specification", STD 13, RFC 1035, November 1987. 950 [RFC1122] Braden, R., "Requirements for Internet Hosts - 951 Communication Layers", STD 3, RFC 1122, October 1989. 953 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 954 November 1990. 956 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 957 RFC 2131, March 1997. 959 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 960 (IPv6) Specification", RFC 2460, December 1998. 962 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 963 Control", RFC 2581, April 1999. 965 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 966 Address Translator (Traditional NAT)", RFC 3022, 967 January 2001. 969 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 970 Security", RFC 4347, April 2006. 972 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 973 RFC 4641, September 2006. 975 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 976 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 977 RFC 4787, January 2007. 979 [RFC5164] Melia, T., "Mobility Services Transport: Problem 980 Statement", RFC 5164, March 2008. 982 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 983 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 985 Authors' Addresses 987 Telemaco Melia (editor) 988 Alcatel-Lucent 989 Route de Villejust 990 Nozay 91620 991 France 993 Email: telemaco.melia@gmail.com 995 Gabor Bajko 996 Nokia 998 Email: Gabor.Bajko@nokia.com 1000 Subir Das 1001 Telcordia Technologies Inc. 1003 Email: subir@research.telcordia.com 1005 Nada Golmie 1006 NIST 1008 Email: nada.golmie@nist.gov 1010 Juan Carlos Zuniga 1011 InterDigital Communications, LLC 1013 Email: j.c.zuniga@ieee.org 1015 Full Copyright Statement 1017 Copyright (C) The IETF Trust (2008). 1019 This document is subject to the rights, licenses and restrictions 1020 contained in BCP 78, and except as set forth therein, the authors 1021 retain all their rights. 1023 This document and the information contained herein are provided on an 1024 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1025 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1026 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1027 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1028 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1029 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1031 Intellectual Property 1033 The IETF takes no position regarding the validity or scope of any 1034 Intellectual Property Rights or other rights that might be claimed to 1035 pertain to the implementation or use of the technology described in 1036 this document or the extent to which any license under such rights 1037 might or might not be available; nor does it represent that it has 1038 made any independent effort to identify any such rights. Information 1039 on the procedures with respect to rights in RFC documents can be 1040 found in BCP 78 and BCP 79. 1042 Copies of IPR disclosures made to the IETF Secretariat and any 1043 assurances of licenses to be made available, or the result of an 1044 attempt made to obtain a general license or permission for the use of 1045 such proprietary rights by implementers or users of this 1046 specification can be obtained from the IETF on-line IPR repository at 1047 http://www.ietf.org/ipr. 1049 The IETF invites any interested party to bring to its attention any 1050 copyrights, patents or patent applications, or other proprietary 1051 rights that may cover technology that may be required to implement 1052 this standard. Please address the information to the IETF at 1053 ietf-ipr@ietf.org.