idnits 2.17.1 draft-ietf-mipshop-mstp-solution-07.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 1021. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1032. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1039. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1045. 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 24, 2008) is 5692 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-05 == Outdated reference: A later version (-07) exists of draft-ietf-mipshop-mos-dns-discovery-02 ** 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 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 13 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 28, 2009 Nokia 6 S. Das 7 Telcordia Technologies Inc. 8 N. Golmie 9 NIST 10 JC. Zuniga 11 InterDigital Communications, LLC 12 September 24, 2008 14 Mobility Services Framework Design (MSFD) 15 draft-ietf-mipshop-mstp-solution-07 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 28, 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 . . . . . . . . . . . . . 7 64 3.3. Scenario S3: Third party MoS . . . . . . . . . . . . . . . 7 65 3.4. Scenario S4: Roaming MoS . . . . . . . . . . . . . . . . . 8 66 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 9 67 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 10 68 4.2. MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . . . . 11 69 5. MoS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 11 70 5.1. MoS Discovery when MN and MoSh are in the home network 71 (Scenario S1) . . . . . . . . . . . . . . . . . . . . . . 12 72 5.2. MoS Discovery when MN and MoSv both are in visited 73 network (Scenario S2) . . . . . . . . . . . . . . . . . . 13 74 5.3. MoS Discovery when MIH services are in a 3rd party 75 remote network (scenario S3) . . . . . . . . . . . . . . . 13 76 5.4. MoS Discovery when the MN is in a visited Network and 77 Services are at the Home network . . . . . . . . . . . . . 14 78 6. MIH Transport Options . . . . . . . . . . . . . . . . . . . . 14 79 6.1. MIH Message size . . . . . . . . . . . . . . . . . . . . . 15 80 6.2. MIH Message rate . . . . . . . . . . . . . . . . . . . . . 16 81 6.3. Retransmission . . . . . . . . . . . . . . . . . . . . . . 16 82 6.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 17 83 6.5. General guidelines . . . . . . . . . . . . . . . . . . . . 17 84 7. Operation Flows . . . . . . . . . . . . . . . . . . . . . . . 17 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 92 Intellectual Property and Copyright Statements . . . . . . . . . . 24 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 into 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 local protocol stack and sends information to the local 168 MIHF 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, showing (in reverse order) the full delegation 178 path from the DNS root and top level domain down to the host name 179 (e.g. myexample.example.org). 181 NAI Network Access Identifier: the user ID that a user submits 182 during network access authentication[RFC4282]. For mobile users, 183 the NAI identifies the user and helps to route the authentication 184 request message. 186 NAT Network Address Translator: A device that implements the Network 187 Address Translation function described in [RFC3022], in which 188 local or private network layer addresses are mapped to routable 189 (outside the NAT domain) network addresses and port numbers. 191 DHCP Dynamic Host Configuration Protocol: protocols described in 192 [RFC2131] and [RFC3315] that allow Internet devices to obtain 193 respectively IPv4 and IPv6 addresses, subnet masks, default 194 gateway addresses, and other IP configuration information from 195 DHCP servers. 197 DNS Domain Name System: a protocol described in [RFC1035] that 198 translates domain names to IP addresses. 200 AAA Authentication, Authorization and Accounting: a set of network 201 management services that respectively determine the validity of a 202 user's ID, determine whether a user is allowed to use network 203 resources, and track users' use of network resources. 205 Home AAA AAAh: an AAA server located on the MN's home network. 207 Visited AAA AAAv: an AAA server located in a visited network that is 208 not the MN's home network. 210 MIH ACK MIH Acknowledgement Message: a MIH signaling message that a 211 MIHF sends in response to an MIH message from a sending MIHF, when 212 UDP is used as the MSTP. 214 PoS Point of Service: a network-side MIHF instance that exchanges 215 MIH messages with a MN-based MIHF. 217 NAS Network Access Server: a server to which a MN initially connects 218 when it is trying to gain a connection to a network and which 219 determines whether the MN is allowed to connect to the NAS's 220 network. 222 UDP User Datagram Protocol: a connectionless transport layer 223 protocol used to send datagrams between a source and a destination 224 at a given port, defined in RFC 768. 226 TCP Transmission Control Protocol: a stream-oriented transport layer 227 protocol that provides a reliable delivery service with congestion 228 control, defined in RFC 793. 230 RTT Round-Trip Time: an estimation of the time required for a 231 segment to travel from a source to a destination and an 232 acknowledgement to return to the source that is used by TCP in 233 connection with timer expirations to determine when a segment is 234 considered lost and should be resent. 236 MTU Maximum Transmission Unit: the largest size of an IP packet that 237 can be sent on a network segment without requiring fragmentation 238 [RFC1191]. 240 PMTU Path MTU: the largest size of an IP packet that can be sent on 241 an end-to-end network path without requiring IP fragmentation. 243 TLS Transport Layer Security Protocol: an application layer protocol 244 that primarily assures privacy and data integrity between two 245 communicating network entities [RFC5246]. 247 SMSS Sender Maximum Segment Size: size of the largest segment that 248 the sender can transmit as per [RFC2581]. 250 3. Deployment Scenarios 252 This section describes the various possible deployment scenarios for 253 the MN and the MoS. The relative positioning of MN and MoS affects 254 MoS discovery as well as the performance of the MIH signaling 255 service. This document addresses the scenarios listed in [RFC5164] 256 and specifies transport options to carry the MIH protocol over IP. 258 3.1. Scenario S1: Home Network MoS 260 In this scenario, the MN and the services are located in the home 261 network. We refer to this set of services as MoSh as in Figure 1. 262 The MoSh can be located at the access network the MN uses to connect 263 to the home network, or it can be located elsewhere. 265 +--------------+ +====+ 266 | HOME NETWORK | |MoSh| 267 +--------------+ +====+ 268 /\ 269 || 270 \/ 271 +--------+ 272 | MN | 273 +--------+ 275 Figure 1: MoS in the home network 277 3.2. Scenario S2: Visited Network MoS 279 In this scenario, the MN is in the visited network and mobility 280 services are provided by the visited network. We refer to this as 281 MoSv as shown in Figure 2. 283 +--------------+ 284 | HOME NETWORK | 285 +--------------+ 286 /\ 287 || 288 \/ 289 +====+ +-----------------+ 290 |MoSv| | VISITED NETWORK | 291 +====+ +-----------------+ 292 /\ 293 || 294 \/ 295 +--------+ 296 | MN | 297 +--------+ 299 Figure 2: MoSV in the visited network 301 3.3. Scenario S3: Third party MoS 303 In this scenario, the MN is in its home network or in a visited 304 network and services are provided by a 3rd party network. We refer 305 to this situation as MoS3 as shown in Figure 3. (Note that MoS can 306 exist both in home and in visited networks). 308 +--------------+ 309 | HOME NETWORK | 310 +====+ +--------------+ +--------------+ 311 |MoS3| | THIRD PARTY | <===> /\ 312 +====+ +--------------+ || 313 \/ 314 +-----------------+ 315 | VISITED NETWORK | 316 +-----------------+ 317 /\ 318 || 319 \/ 320 +--------+ 321 | MN | 322 +--------+ 324 Figure 3: MoS from a third party 326 3.4. Scenario S4: Roaming MoS 328 In this scenario, the MN is located in the visited network and all 329 MIH services are provided by the home network, as shown in Figure 4. 331 +====+ +--------------+ 332 |MoSh| | HOME NETWORK | 333 +====+ +--------------+ 334 /\ 335 || 336 \/ 337 +-----------------+ 338 | VISITED NETWORK | 339 +-----------------+ 340 /\ 341 || 342 \/ 343 +--------+ 344 | MN | 345 +--------+ 347 Figure 4: MoS provided by the home while in visited 349 Different types of MoS can be provided independently of other types 350 and there is no strict relationship between ES, CS and IS, nor is 351 there a requirement that the entities that provide these services 352 should be co-located. However, while IS tends to involve a large 353 amount of static information, ES and CS are dynamic services and some 354 relationships between them can be expected, e.g., a handover command 355 (CS) could be issued upon reception of a link event (ES). This 356 document does not make any assumption on the location of the MoS 357 (although there might be some preferred configurations), and aims at 358 flexible MSFD to discover different services in different locations 359 to optimize handover performance. MoS discovery is discussed in more 360 detail in Section 5. 362 4. Solution Overview 364 As mentioned in Section 1, the solution space is being divided into 365 two functional domains: discovery and transport. The following 366 assumptions have been made: 368 o The solution is primarily aimed at supporting IEEE 802.21 MIH 369 services, namely Information Service (IS), Event Service (ES), and 370 Command Service (CS). 372 o If the MIHFID is available, FQDN or NAI's realm is used for 373 mobility service discovery. 375 o The solutions are chosen to cover all possible deployment 376 scenarios as described in Section 3. 378 o MoS discovery can be performed during initial network attachment 379 or at any time thereafter. 381 The MN may know the realm of the MoS to be discovered. The MN may 382 also be pre-configured with the address of the MoS to be used. In 383 case the MN does not know what realm/MoS to query, dynamic assignment 384 methods are described in Section 5. 386 The discovery of the MoS (and the related configuration at MIHF 387 level) is required to bind two MIHF peers (e.g. MN and MoS) with 388 their respective IP addresses. Discovery MUST be executed in the 389 following conditions: 391 o Bootstrapping: upon successful layer 2 network attachment the MN 392 MAY be required to use DHCP for address configuration. These 393 procedures can carry the required information for MoS 394 configuration in specific DHCP options. 396 o If the MN does not receive MoS information during network 397 attachment and the MN does not have a pre-configured MoS, it MUST 398 run a discovery procedure upon initial IP address configuration. 400 o If the MN changes its IP address (e.g. upon handover) it MUST 401 refresh MIHF peer bindings (i.e., MIHF registration process). In 402 case the MoS used is not suitable anymore (e.g. too large RTT 403 experienced) the MN MAY need to perform a new discovery procedure. 405 o if the MN is a multi-homed device and it communicates with the 406 same MoS via different IP addresses it MAY run discovery 407 procedures if one of the IP addresses changes. 409 Once the MIHF peer has been discovered, MIH information can be 410 exchanged between MIH peers over a transport protocol such as UDP or 411 TCP. The usage of transport protocols is described in Section 6 and 412 packing of the MIH messages does not require extra framing since the 413 MIH protocol defined in [IEEE80221] already contains a length field. 415 4.1. Architecture 417 Figure 5 depicts the MSFD reference model and its components within a 418 node. The topmost layer is the MIHF user. This set of applications 419 consists of one or more MIH clients that are responsible for 420 operations such as generating query and response, processing Layer 2 421 triggers as part of the ES, and initiating and carrying out handover 422 operations as part of the CS. Beneath the MIHF user is the MIHF 423 itself. This function is responsible for MoS discovery, as well as 424 creating, maintaining, modifying, and destroying MIH signaling 425 associations with other MIHFs located in MIH peer nodes. Below the 426 MIHF are various transport layer protocols as well as address 427 discovery functions. 429 +--------------------------+ 430 | MIHF User | 431 +--------------------------+ 432 || 433 +--------------------------+ 434 | MIHF | 435 +--------------------------+ 436 || || || 437 || +------+ +-----+ 438 || | DHCP | | DNS | 439 || +------+ +-----+ 440 || || || 441 +--------------------------+ 442 | TCP/UDP | 443 +--------------------------+ 445 Figure 5: MN stack 447 The MIHF relies on the services provided by TCP and UDP for 448 transporting MIH messages, and relies on DHCP and DNS for peer 449 discovery. In cases where the peer MIHF IP address is not pre- 450 configured, the source MIHF needs to discover it either via DHCP or 451 DNS as described in Section 5. Once the peer MIHF is discovered, the 452 MIHF must exchange messages with its peer over either UDP or TCP. 453 Specific recommendations regarding the choice of transport protocols 454 are provided in Section 6. 456 There are no security features currently defined as part of the MIH 457 protocol level. However, security can be provided either at the 458 transport or IP layer where it is necessary. Section 8 provides 459 guidelines and recommendations for security. 461 4.2. MIHF Identifiers (FQDN, NAI) 463 MIHFID is an identifier required to uniquely identify the MIHF end 464 points for delivering the mobility services (MoS). Thus an MIHF 465 identifier needs to be unique within a domain where mobility services 466 are provided and independent of the configured IP addresse(s). An 467 MIHFID MUST be represented either in the form of an FQDN [RFC2181] or 468 NAI [RFC4282]. An MIHFID can be pre-configured or discovered through 469 the discovery methods described in Section 5. 471 5. MoS Discovery 473 The MoS discovery method depends on whether the MN attempts to 474 discover an MoS in the home network, in the visited network, or in a 475 3rd party remote network that is neither the home network nor the 476 visited network. In the case the MN has already a MoS address pre- 477 configured it is not necessary to run the discovery procedure. If 478 the MN does not have pre-configured MoS the following procedure 479 applies. 481 In the case where MoS is provided locally (scenarios S1 and S2) , the 482 discovery techniques described in [I-D.ietf-mipshop-mos-dhcp-options] 483 and [I-D.ietf-mipshop-mos-dns-discovery] are both applicable as 484 described in Section 5.1 and Section 5.2. 486 In the case where MoS is provided in the home network while the MN is 487 in the visited network (scenario S4), the DNS based discovery 488 described in [I-D.ietf-mipshop-mos-dns-discovery] is applicable. 490 In the case where MoS is provided by a third party network which is 491 different from the current visited network (scenario S3), only the 492 DNS based discovery method described in 493 [I-D.ietf-mipshop-mos-dns-discovery] is applicable. 495 It should be noted that authorization of a MN to use a specific MoS 496 server is neither in scope of this document nor is currently 497 specified in [IEEE80221]. We further assume all devices can access 498 discovered MoS. In case future deployments will implement 499 authorization policies the mobile nodes should fall back to other 500 learned MoS if authorization is denied. 502 5.1. MoS Discovery when MN and MoSh are in the home network (Scenario 503 S1) 505 To discover an MoS in the home network, the MN SHOULD use the DNS 506 based MoS discovery method described in 507 [I-D.ietf-mipshop-mos-dns-discovery]. In order to use that 508 mechanism, the MN MUST have its home domain pre-configured (i.e., 509 subscription is tied to a network). The DNS query option is shown in 510 Figure 6a. Alternatively, the MN MAY use the DHCP options for MoS 511 discovery[I-D.ietf-mipshop-mos-dhcp-options] as shown inFigure 6b (in 512 some deployments, a DHCP relay may not be present). 514 (a) +-------+ 515 +----+ |Domain | 516 | MN |-------->|Name | 517 +----+ |Server | 518 MN@xyz.com +-------+ 520 (b) 521 +-----+ +------+ 522 +----+ | | |DHCP | 523 | MN |<----->| DHCP|<---->|Server| 524 +----+ |Relay| | | 525 +-----+ +------+ 527 Figure 6: MOS Discovery (a) using DNS query, (b) using DHCP option 529 5.2. MoS Discovery when MN and MoSv both are in visited network 530 (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 Figure 7: MoS Discovery using DHCP options 544 5.3. MoS Discovery when MIH services are in a 3rd party remote network 545 (scenario S3) 547 To discover an MoS in a remote network other than home network, the 548 MN MUST use the DNS based MoS discovery method described in 549 [I-D.ietf-mipshop-mos-dns-discovery]. The MN MUST first learn the 550 domain name of the network containing the MoS it is searching for. 551 The MN can query its current MoS to find out the domain name of a 552 specific network or the domain name of a network at a specific 553 location (as in Figure 8a, IEEE 802.21 defines information elements 554 such as OPERATOR ID and SERVICE PROVIDER ID which can be a domain 555 name. An IS query can provide this information, see [IEEE80221]). 557 Alternatively, the MN MAY query a MoS previously known to learn the 558 domain name of the desired network . Finally, the MN MUST use DNS 559 based discovery mechanisms to find MoS in the remote network as 560 inFigure 8b. It should be noted that step b can only be performed 561 upon obtaining the domain name of the remote network. 563 (a) 564 +------------+ 565 +----+ | | 566 | | |Information | 567 | MN |-------->| Server | 568 | | |(previously | 569 +----+ |discovered) | 570 +------------+ 572 (b) 573 +-------+ 574 +----+ |Domain | 575 | MN |-------->|Name | 576 +----+ |Server | 577 MN@xyz.com +-------+ 579 Figure 8: MOS Discovery using (a) IS Query to a known IS Server, (b) 580 DNS Query 582 5.4. MoS Discovery when the MN is in a visited Network and Services are 583 at the Home network 585 To discover an MoS in the visited network when MIH services are 586 provided by the home network, the DNS based discovery method 587 described in [I-D.ietf-mipshop-mos-dns-discovery] is applicable. To 588 discover the MoS at home while in a visited network using DNS, the MN 589 SHOULD use the procedures described in Section 5.1. 591 6. MIH Transport Options 593 Once the Mobility Services have been discovered, MIH peers run a 594 capability discovery and subscription procedure as specified in 595 [IEEE80221]. MIH peers MAY exchange information over TCP, UDP or any 596 other transport supported by both the server and the client. The 597 client MAY use the DNS discovery mechanism to discover which 598 transport protocols are supported by the server in addition to TCP 599 and UDP that are recommended in this document. While either protocol 600 can provide the basic transport functionality required, there are 601 performance trade-offs and unique characteristics associated with 602 each that need to be considered in the context of the MIH services 603 for different network loss and congestion conditions. The objectives 604 of this section are to discuss these trade-offs for different MIH 605 settings such as the MIH message size and rate, and the 606 retransmission parameters. In addition, factors such as NAT 607 traversal are also discussed. Given the reliability requirements for 608 the MIH transport, it is assumed in this discussion that the MIH ACK 609 mechanism is to be used in conjunction with UDP, while it is 610 preferred to avoid using MIH ACKs with TCP since TCP includes 611 acknowledgement and retransmission functionality. 613 6.1. MIH Message size 615 Although the MIH message size varies widely from about 30 bytes (for 616 a capability discovery request) to around 65000 bytes (for an IS 617 MIH_Get_Information response primitive), a typical MIH message size 618 for the ES/CS service ranges between 50 to 100 bytes [IEEE80221]. 619 Thus, considering the effects of the MIH message size on the 620 performance of the transport protocol brings us to discussing two 621 main issues, related to fragmentation of long messages in the context 622 of UDP and the concatenation of short messages in the context of TCP. 624 Since transporting long MIH messages may require fragmentation that 625 is not available in UDP, if MIH is using UDP a limit MUST be set on 626 the size of the MIH message based on the path MTU to destination (or 627 the Minimum MTU where PMTU is not implemented). The minimum MTU 628 depends on the IP version used for transmission, and is the lesser of 629 576 bytes for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC2460], 630 although applications may reduce these values to guard against the 631 presence of tunnels. 633 It should be noted that MIH layer fragmentation MUST NOT be used 634 together with IP layer fragmentation as specified in [IEEE80221]. 636 The loss of an IP fragment leads to the retransmission of an entire 637 MIH message, which in turn leads to poor end-to-end delay performance 638 in addition to wasted bandwidth. Additional recommendations in 639 [I-D.ietf-tsvwg-udp-guidelines] apply for limiting the size of the 640 MIH message when using UDP and assuming IP layer fragmentation. In 641 terms of dealing with short messages, TCP has the capability to 642 concatenate very short messages in order to reduce the overall 643 bandwidth overhead. However, this reduced overhead comes at the cost 644 of additional delay to complete an MIH transaction, which may not be 645 acceptable for CS and ES services. Note also that TCP is a stream 646 oriented protocol and measures data flow in terms of bytes, not 647 messages. Thus it is possible to split messages across multiple TCP 648 segments if they are long enough. Even short messages can be split 649 across two segments. This can also cause unacceptable delays, 650 especially if the link quality is severely degraded as is likely to 651 happen when the MN is exiting a wireless access coverage area. The 652 use of the TCP_NODELAY option can alleviate this problem by 653 triggering transmission of a segment less than the SMSS. (It should 654 be noted that [RFC4960] addresses both of these problems, it is 655 howerver omitted due to absence of running code) 657 6.2. MIH Message rate 659 The frequency of MIH messages varies according to the MIH service 660 type. It is expected that CS/ES message arrive at a rate of one in 661 hundreds of milliseconds in order to capture quick changes in the 662 environment and/ or process handover commands. On the other hand, IS 663 messages are exchanged mainly every time a new network is visited 664 which may be in order of hours or days. Therefore a burst of either 665 short CS/ES messages or long IS message exchanges (in the case where 666 multiple MIH nodes request information) may lead to network 667 congestion. While the built-in rate-limiting controls available in 668 TCP may be well suited for dealing with these congestion conditions, 669 this may result in large transmission delays that may be unacceptable 670 for the timely delivery of ES/CS messages. On the other hand, if UDP 671 is used, a rate-limiting effect similar to the one obtained with TCP 672 SHOULD be obtained by adequately adjusting the parameters of a token 673 bucket regulator as defined in the MIH specifications [IEEE80221]. 674 Recommendations for token bucket parameter settings are as follow: 676 o If MIHF knows the RTT (e.g., based on the request/response MIH 677 protocol exchange between two MIH peers), the rate can be based 678 upon this as specified in [IEEE80221] 680 o If not, then on average it SHOULD NOT send more than one UDP 681 message every 3 seconds. 683 6.3. Retransmission 685 For TCP, the retransmission timeout is adjusted according to the 686 measured RTT. However due to the exponential backoff mechanism, the 687 delay associated with retransmission timeouts may increase 688 significantly with increased packet loss. 690 If UDP is being used to carry MIH messages, MIH MUST use MIH ACKs. 691 An MIH message is retransmitted if its corresponding MIH ACK is not 692 received by the generating node within a timeout interval set by the 693 MIHF. This approach does not include an exponential backoff and 694 therefore tends to degrade more gracefully than TCP when the packet 695 loss rate becomes large, in the sense that the expected delay does 696 not increase exponentially. The number of retransmissions is 697 limited, which reduces head-of-line blocking of other MIH messages, 698 but this can cause important ES/CS messages to be lost. The default 699 number of retransmissions is set to 2 and retransmissions are 700 controlled by a timer with a default value of 10s. No backoff 701 mechanism is specified. 703 6.4. NAT Traversal 705 There are no known issues for NAT traversal when using TCP. The 706 default connection timeout of 24 hours is considered adequate for MIH 707 transport purposes. However, issues with NAT traversal using UDP are 708 documented in [I-D.ietf-tsvwg-udp-guidelines]. Communication 709 failures are experienced when middleboxes destroy the per-flow state 710 associated with an application session during periods when the 711 application does not exchange any UDP traffic. Hence, communication 712 between the MN and the MoS SHOULD be able to gracefully handle such 713 failures and implement mechanisms to re-establish their UDP sessions. 714 In addition and in order to avoid such failures, MIH messages MAY be 715 sent periodically, similarly to keep-alive messages, in an attempt to 716 refresh middlebox state. As [RFC4787] requires a minimum state 717 timeout of two minutes or more, MIH messages using UDP as transport 718 SHOULD be sent once every two minutes. Re-registration or Event 719 indication messages as defined in [IEEE80221] MAY be used for this 720 purpose. 722 6.5. General guidelines 724 Since ES and CS messages are small in nature and have tight latency 725 requirements, UDP in combination with MIH acknowledgement MAY be used 726 for transporting ES and CS messages. On the other hand, IS messages 727 are more resilient in terms of latency constraints and some long IS 728 messages could exceed the MTU of the path to the destination. For 729 both UDP and TCP cases, if a port number is not explicitly assigned 730 (e.g. by the DNS SRV), MIH messages sent over UDP, TCP or other 731 supported transport MUST use the default port number defined in 732 Section 9 for that particular transport. 734 A MoS server MUST support both UDP and TCP for MIH transport and the 735 MN MUST support TCP. Additionally, the server and MN MAY support 736 additional transport mechanisms. The MN MAY use the procedures 737 defined in [I-D.ietf-mipshop-mos-dns-discovery] to discover 738 additional transport protocols supported by the server. 740 7. Operation Flows 742 Figure 9 gives an example operation flow between MIHF peers when a 743 MIH user requests an IS service and both the MN and the MoS are in 744 the MN's home network. DHCP is used for MoS discovery and TCP is 745 used for establishing a transport connection to carry the IS 746 messages. When MoS is not pre-configured, the MIH user needs to 747 discover the IP address of MoS to communicate with the remote MIHF. 748 Therefore the MIH user sends a discovery request message to the local 749 MIHF as defined in [IEEE80221]. 751 In this example (one could draw similar mechanisms with DHCPv6), we 752 assume that MoS discovery is performed before a transport connection 753 is established with the remote MIHF, and the DHCP client process is 754 invoked via some internal APIs. The DHCP Client sends DHCP INFORM 755 message according to standard DHCP and with the MoS option as defined 756 in [I-D.ietf-mipshop-mos-dhcp-options]. The DHCP server replies via 757 a DHCP ACK message with the IP address of the MoS. The MoS address 758 is then passed to the MIHF locally via some internal APIs. The MIHF 759 generates the discovery response message and passes it on to the 760 corresponding MIH user. The MIH user generates an IS query addressed 761 to the remote MoS. The MIHF invokes the underlying TCP client which 762 establishes a transport connection with the remote peer. Once the 763 transport connection is established, the MIHF sends the IS query via 764 MIH protocol REQUEST message. The message and query arrive at the 765 destination MIHF and MIH user respectively. The MoS MIH user 766 responds to the corresponding IS query and the MoS MIHF sends the IS 767 response via a MIH protocol RESPONSE message. The message arrives at 768 the source MIHF which passes the IS response on to the corresponding 769 MIH user. 771 MN MoS 772 |===================================| |======| |===================| 773 + ---------+ + ---------+ 774 | MIH USER | +------+ +------+ +------+ +------+ | MIH USER | 775 | +------+ | | TCP | |DHCP | |DHCP | | TCP | | +------+ | 776 | | MIHF | | |Client| |Client| |Server| |Server| | | MIHF | | 777 +----------+ +------+ +------+ +------+ +------+ +----------+ 778 | | | | | | 779 MIH Discovery | | | | | 780 Request | | | | | 781 | | | | | | 782 |Invoke DHCP Client | | | | 783 |(Internal process with MoS)|DHCP INFORM| | | 784 |==========================>|==========>| | | 785 | | | | | | 786 | | | DHCP ACK | | | 787 | | |<==========| | | 788 | Inform MoS address | | | | 789 |<==========================| | | | 790 | (internal process) | | | | 791 | | | | | | 792 MIH Discovery | | | | | 793 Response | | | | | 794 | | | | | | 795 IS Query | | | | | 796 MIH User-> MIHF | | | | | 797 | | | | | | 798 |Invoke TCP Client| | | | | 799 |================>| | | | | 800 Internal process | | | | | 801 | | TCP connection established | | 802 | |<=============================>| | 803 | | | | | | 804 | IS QUERY REQUEST (via MIH protocol) | 805 |===========================================================>| 806 | | | | | | 807 | | | | | IS QUERY| 808 | | | | | REQUEST| 809 | | | | MIHF-> MIH User | 810 | | | | | | 811 | | | | | QUERY| 812 | | | | | RESPONSE| 813 | | | | MIHF <-MIH User | 814 | | | | | | 815 | | IS QUERY RESPONSE (via MIH protocol) | 816 |<===========================================================| 817 | | | | | | 818 IS RESPONSE | | | | | 819 MIH User <-MIHF | | | | | 820 | | | | | | 822 Figure 9: Example Flow of Operation Involving MIH User 824 8. Security Considerations 826 There are a number of security issues that need to be taken into 827 account during node discovery and information exchange via a 828 transport connection [RFC5164]. 830 In the case where DHCP is used for node discovery and authentication 831 of the source and content of DHCP messages is required, network 832 administrators SHOULD use DHCP authentication option described in 833 [RFC3118], where available, or rely upon link layer security. 834 [RFC3118] provides mechanisms for both entity authentication and 835 message authentication. In case where DHCP authentication mechanism 836 is not available administrators may need to rely upon underlying link 837 layer security. In such cases the link between DHCP client and 838 layer-2 termination point may be protected but the DHCP message 839 source and its messages can not be authenticated or the integrity of 840 the latter checked unless there exits a security binding between link 841 layer and DHCP layer. 843 In the case where DNS is used for discovering MoS, fake DNS requests 844 and responses may cause DoS and the inability of the MN to perform a 845 proper handover, respectively. Where networks are exposed to such 846 DoS, it is RECOMMENDED that DNS service providers use the Domain Name 847 System Security Extensions (DNSSEC) as described in [RFC4033]. 848 Readers may also refer to [RFC4641] to consider the aspects of DNSSEC 849 Operational Practices. 851 In the case where a reliable transport protocol such as TCP is used 852 for the transport connection between two MIHF peers, TLS [RFC5246] 853 with server-side certificates SHOULD be used for server only 854 authentication, message confidentiality and data integrity. Certain 855 subscriptions may include client certificates, and in those cases 856 servers MAY require the clients to authenticate themselves using 857 client-side certificates. Readers should also follow the 858 recommendations in [RFC5246] that provides generic extension 859 mechanisms for the TLS protocol suitable for wireless environments. 861 In the case where an unreliable transport protocol such as UDP is 862 used for the transport connection between two MIHF peers, DTLS 863 [RFC4347] SHOULD be used for message confidentiality and data 864 integrity. The DTLS protocol is based on the Transport Layer 865 Security (TLS) protocol and provides equivalent security guarantees. 867 Finally, as mentioned in section Section 5, it should be noted that 868 authorization of a MN to use a specific MoS server is neither in 869 scope of this document nor is currently specified in [IEEE80221]. We 870 further assume all devices can access discovered MoS. In case future 871 deployments will implement authorization policies the mobile nodes 872 should fall back to other learned MoS if authorization is denied. 874 9. IANA Considerations 876 This document registers the following TCP and UDP port(s) with IANA: 878 Keyword Decimal Description 879 -------- --------------- ------------ 880 ieee-mih TBD_BY_IANA/tcp MIH Services 881 ieee-mih TBD_BY_IANA/udp MIH Services 883 10. Acknowledgements 885 The authors would like to thank Yoshihiro Ohba, David Griffith, Kevin 886 Noll, Vijay Devarapalli, Patrick Stupar and Sam Xia for their 887 valuable comments, reviews and fruitful discussions. 889 11. References 890 11.1. Normative References 892 [I-D.ietf-mipshop-mos-dhcp-options] 893 Bajko, G. and S. Das, "Dynamic Host Configuration Protocol 894 (DHCPv4 and DHCPv6) Options for Mobility Server (MoS) 895 discovery", draft-ietf-mipshop-mos-dhcp-options-05 (work 896 in progress), September 2008. 898 [I-D.ietf-mipshop-mos-dns-discovery] 899 Bajko, G., "Locating Mobility Servers using DNS", 900 draft-ietf-mipshop-mos-dns-discovery-02 (work in 901 progress), September 2008. 903 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 904 Requirement Levels", BCP 14, RFC 2119, March 1997. 906 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 907 Specification", RFC 2181, July 1997. 909 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 910 Messages", RFC 3118, June 2001. 912 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 913 and M. Carney, "Dynamic Host Configuration Protocol for 914 IPv6 (DHCPv6)", RFC 3315, July 2003. 916 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 917 Rose, "DNS Security Introduction and Requirements", 918 RFC 4033, March 2005. 920 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 921 Network Access Identifier", RFC 4282, December 2005. 923 11.2. Informative References 925 [I-D.ietf-tsvwg-udp-guidelines] 926 Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 927 for Application Designers", 928 draft-ietf-tsvwg-udp-guidelines-10 (work in progress), 929 August 2008. 931 [IEEE80221] 932 "Draft IEEE Standard for Local and Metropolitan Area 933 Networks: Media Independent Handover Services", IEEE LAN/ 934 MAN Draft IEEE P802.21/D13.00, August 2008. 936 [RFC1035] Mockapetris, P., "Domain names - implementation and 937 specification", STD 13, RFC 1035, November 1987. 939 [RFC1122] Braden, R., "Requirements for Internet Hosts - 940 Communication Layers", STD 3, RFC 1122, October 1989. 942 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 943 November 1990. 945 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 946 RFC 2131, March 1997. 948 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 949 (IPv6) Specification", RFC 2460, December 1998. 951 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 952 Control", RFC 2581, April 1999. 954 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 955 Address Translator (Traditional NAT)", RFC 3022, 956 January 2001. 958 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 959 Security", RFC 4347, April 2006. 961 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 962 RFC 4641, September 2006. 964 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 965 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 966 RFC 4787, January 2007. 968 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 969 RFC 4960, September 2007. 971 [RFC5164] Melia, T., "Mobility Services Transport: Problem 972 Statement", RFC 5164, March 2008. 974 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 975 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 977 Authors' Addresses 979 Telemaco Melia (editor) 980 Alcatel-Lucent 981 Route de Villejust 982 Nozay 91620 983 France 985 Email: telemaco.melia@alcatel-lucent.com 987 Gabor Bajko 988 Nokia 990 Email: Gabor.Bajko@nokia.com 992 Subir Das 993 Telcordia Technologies Inc. 995 Email: subir@research.telcordia.com 997 Nada Golmie 998 NIST 1000 Email: nada.golmie@nist.gov 1002 Juan Carlos Zuniga 1003 InterDigital Communications, LLC 1005 Email: j.c.zuniga@ieee.org 1007 Full Copyright Statement 1009 Copyright (C) The IETF Trust (2008). 1011 This document is subject to the rights, licenses and restrictions 1012 contained in BCP 78, and except as set forth therein, the authors 1013 retain all their rights. 1015 This document and the information contained herein are provided on an 1016 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1017 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1018 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1019 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1020 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1021 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1023 Intellectual Property 1025 The IETF takes no position regarding the validity or scope of any 1026 Intellectual Property Rights or other rights that might be claimed to 1027 pertain to the implementation or use of the technology described in 1028 this document or the extent to which any license under such rights 1029 might or might not be available; nor does it represent that it has 1030 made any independent effort to identify any such rights. Information 1031 on the procedures with respect to rights in RFC documents can be 1032 found in BCP 78 and BCP 79. 1034 Copies of IPR disclosures made to the IETF Secretariat and any 1035 assurances of licenses to be made available, or the result of an 1036 attempt made to obtain a general license or permission for the use of 1037 such proprietary rights by implementers or users of this 1038 specification can be obtained from the IETF on-line IPR repository at 1039 http://www.ietf.org/ipr. 1041 The IETF invites any interested party to bring to its attention any 1042 copyrights, patents or patent applications, or other proprietary 1043 rights that may cover technology that may be required to implement 1044 this standard. Please address the information to the IETF at 1045 ietf-ipr@ietf.org.