idnits 2.17.1 draft-ietf-mipshop-mstp-solution-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: According to[IEEE80221] when MIH message is sent using an L3 or higher layer transport, L3 takes care of any fragmentation issue and the MIH protocol does not handle fragmentation in such cases. Thus, MIH layer fragmentation MUST NOT be used together with IP layer framentation and MUST not be used when MIH packets are carried over TCP. -- 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 (January 28, 2009) is 5564 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-10 == Outdated reference: A later version (-07) exists of draft-ietf-mipshop-mos-dns-discovery-04 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) -- 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 2988 (Obsoleted by RFC 6298) -- 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) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 10 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: August 1, 2009 Nokia 6 S. Das 7 Telcordia Technologies Inc. 8 N. Golmie 9 NIST 10 JC. Zuniga 11 InterDigital Communications, LLC 12 January 28, 2009 14 IEEE 802.21 Mobility Services Framework Design (MSFD) 15 draft-ietf-mipshop-mstp-solution-12 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 1, 2009. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. 52 Abstract 54 This document describes a mobility services framework design (MSFD) 55 for the IEEE 802.21 Media Independent Handover (MIH) protocol that 56 addresses identified issues associated with the transport of MIH 57 messages. The document also describes mechanisms for mobility 58 service (MoS) discovery and transport layer mechanisms for the 59 reliable delivery of MIH messages. This document does not provide 60 mechanisms for securing the communication between a mobile node (MN) 61 and the mobility service (MoS). Instead, it is assumed that either 62 lower layer (e.g., link layer) security mechanisms, or overall 63 system-specific proprietary security solutions, are used. 65 Requirements Language 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [RFC2119]. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 7 76 3.1. Scenario S1: Home Network MoS . . . . . . . . . . . . . . 7 77 3.2. Scenario S2: Visited Network MoS . . . . . . . . . . . . . 8 78 3.3. Scenario S3: Third party MoS . . . . . . . . . . . . . . . 8 79 3.4. Scenario S4: Roaming MoS . . . . . . . . . . . . . . . . . 9 80 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 10 81 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 11 82 4.2. MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . . . . 12 83 5. MoS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 12 84 5.1. MoS Discovery when MN and MoSh are in the home network 85 (Scenario S1) . . . . . . . . . . . . . . . . . . . . . . 13 86 5.2. MoS Discovery when MN and MoSv both are in visited 87 network (Scenario S2) . . . . . . . . . . . . . . . . . . 14 88 5.3. MoS Discovery when MIH services are in a 3rd party 89 remote network (Scenario S3) . . . . . . . . . . . . . . . 14 90 5.4. MoS Discovery when the MN is in a visited Network and 91 Services are at the Home network . . . . . . . . . . . . . 15 92 6. MIH Transport Options . . . . . . . . . . . . . . . . . . . . 15 93 6.1. MIH Message size . . . . . . . . . . . . . . . . . . . . . 16 94 6.2. MIH Message rate . . . . . . . . . . . . . . . . . . . . . 17 95 6.3. Retransmission . . . . . . . . . . . . . . . . . . . . . . 17 96 6.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 18 97 6.5. General guidelines . . . . . . . . . . . . . . . . . . . . 18 98 7. Operation Flows . . . . . . . . . . . . . . . . . . . . . . . 18 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 100 8.1. Security Considerations for MoS Discovery . . . . . . . . 21 101 8.2. Security Considerations for MIH Transport . . . . . . . . 21 102 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 103 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 105 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 106 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 109 1. Introduction 111 This document proposes a solution to the issues identified in the 112 problem statement document [RFC5164] for the layer 3 transport of 113 IEEE 802.21 MIH protocols. 115 The MIH Layer 3 transport problem is divided into two main parts: the 116 discovery of a node that supports specific Mobility Services (MoS) 117 and the transport of the information between a mobile node (MN) and 118 the discovered node. The discovery process is required for the MN to 119 obtain the information needed for MIH protocol communication with a 120 peer node. The information includes the transport address (e.g., the 121 IP address) of the peer node and the types of MoS provided by the 122 peer node. 124 This document lists the major MoS deployment scenarios. It describes 125 the solution architecture, including the MSFD reference model and 126 MIHF identifiers. MoS discovery procedures explain how the MN 127 discovers MoS in its home network, in a visited network or in a third 128 party network. The remainder of this document describes the MIH 129 transport architecture, example message flows for several signaling 130 scenarios, and security issues. 132 This document does not provide mechanisms for securing the 133 communication between a mobile node and the mobility service. 134 Instead, it is assumed that either lower layer (e.g., link layer) 135 security mechanisms, or overall system-specific proprietary security 136 solutions, are used. The details of such lower layer and/or 137 proprietary mechanisms are beyond the scope of this document. It is 138 RECOMMENDED against using this protocol without careful analysis that 139 these mechanisms meet the desired requirements, and encourages future 140 standardization work in this area. The IEEE 802.21a Task Group has 141 recently started work on MIH security issues that may provide some 142 solution in this area. For further information, please refer to 143 Section 8. 145 2. Terminology 147 The following acronyms and terminology are used in this document: 149 MIH Media Independent Handover: the handover support architecture 150 defined by the IEEE 802.21 working group that consists of the MIH 151 Function (MIHF), MIH Network Entities and MIH protocol messages. 153 MIHF Media Independent Handover Function: a switching function that 154 provides handover services including the Event Service (ES), 155 Information Service (IS), and Command Service (CS), through 156 service access points (SAPs) defined by the IEEE 802.21 working 157 group [IEEE80221]. 159 MIHF User An entity that uses the MIH SAPs to access MIHF services, 160 and which is responsible for initiating and terminating MIH 161 signaling. 163 MIHFID Media Independent Handover Function Identifier: an identifier 164 required to uniquely identify the MIHF endpoints for delivering 165 mobility services (MoS); it is implemented as either a FQDN or 166 NAI. 168 MoS Mobility Services: those services, as defined in the MIH problem 169 statement document [RFC5164] , which includes the MIH IS, CS, and 170 ES services defined by the IEEE 802.21 standard. 172 MoSh: Mobility Services assigned in the mobile node's Home Network. 174 MoSv: Mobility Services assigned in the Visited Network. 176 MoS3: Mobility Services assigned in a 3rd Party Network, which is a 177 network that is neither the Home Network nor the current Visited 178 Network. 180 MN Mobile Node: an Internet device whose location changes, along with 181 its point of connection to the network. 183 MSTP Mobility Services Transport Protocol: a protocol that is used 184 to deliver MIH protocol messages from an MIHF to other MIH-aware 185 nodes in a network. 187 IS Information Service: a MoS that originates at the lower or upper 188 layers of the protocol stack and sends information to the local or 189 remote upper or lower layers of the protocol stack. The purpose 190 of IS is to exchange information elements (IEs) relating to 191 various neighboring network information. 193 ES Event Service: a MoS that originates at a remote MIHF or the lower 194 layers of the local protocol stack and sends information to the 195 local MIHF or local higher layers. The purpose of the ES is to 196 report changes in link status (e.g., Link Going Down messages) and 197 various lower layer events. 199 CS Command Service: MoS that sends commands from the remote MIHF or 200 local upper layers to the remote or local lower layers of the 201 protocol stack to switch links or to get link status. 203 FQDN: Fully-Qualified Domain Name: a complete domain name for a host 204 on the Internet, showing (in reverse order) the full delegation 205 path from the DNS root and top level domain down to the host name 206 (e.g. myexample.example.org). 208 NAI Network Access Identifier: the user ID that a user submits 209 during network access authentication [RFC4282]. For mobile users, 210 the NAI identifies the user and helps to route the authentication 211 request message. 213 NAT Network Address Translator: A device that implements the Network 214 Address Translation function described in [RFC3022], in which 215 local or private network layer addresses are mapped to routable 216 (outside the NAT domain) network addresses and port numbers. 218 DHCP Dynamic Host Configuration Protocol: protocols described in 219 [RFC2131] and [RFC3315] that allow Internet devices to obtain 220 respectively IPv4 and IPv6 addresses, subnet masks, default 221 gateway addresses, and other IP configuration information from 222 DHCP servers. 224 DNS Domain Name System: a protocol described in [RFC1035] that 225 translates domain names to IP addresses. 227 AAA Authentication, Authorization and Accounting: a set of network 228 management services that respectively determine the validity of a 229 user's ID, determine whether a user is allowed to use network 230 resources, and track users' use of network resources. 232 Home AAA AAAh: an AAA server located on the MN's home network. 234 Visited AAA AAAv: an AAA server located in a visited network that is 235 not the MN's home network. 237 MIH ACK MIH Acknowledgement Message: a MIH signaling message that a 238 MIHF sends in response to an MIH message from a sending MIHF, when 239 UDP is used as the MSTP. 241 PoS Point of Service: a network-side MIHF instance that exchanges 242 MIH messages with a MN-based MIHF. 244 NAS Network Access Server: a server to which a MN initially connects 245 when it is trying to gain a connection to a network and which 246 determines whether the MN is allowed to connect to the NAS's 247 network. 249 UDP User Datagram Protocol: a connectionless transport layer 250 protocol used to send datagrams between a source and a destination 251 at a given port, defined in RFC 768. 253 TCP Transmission Control Protocol: a stream-oriented transport layer 254 protocol that provides a reliable delivery service with congestion 255 control, defined in RFC 793. 257 RTT Round-Trip Time: an estimation of the time required for a 258 segment to travel from a source to a destination and an 259 acknowledgement to return to the source that is used by TCP in 260 connection with timer expirations to determine when a segment is 261 considered lost and should be resent. 263 MTU Maximum Transmission Unit: the largest size of an IP packet that 264 can be sent on a network segment without requiring fragmentation 265 [RFC1191]. 267 PMTU Path MTU: the largest size of an IP packet that can be sent on 268 an end-to-end network path without requiring IP fragmentation. 270 TLS Transport Layer Security Protocol: an application layer protocol 271 that primarily assures privacy and data integrity between two 272 communicating network entities [RFC5246]. 274 SMSS Sender Maximum Segment Size: size of the largest segment that 275 the sender can transmit as per [RFC2581]. 277 3. Deployment Scenarios 279 This section describes the various possible deployment scenarios for 280 the MN and the MoS. The relative positioning of MN and MoS affects 281 MoS discovery as well as the performance of the MIH signaling 282 service. This document addresses the scenarios listed in [RFC5164] 283 and specifies transport options to carry the MIH protocol over IP. 285 3.1. Scenario S1: Home Network MoS 287 In this scenario, the MN and the services are located in the home 288 network. We refer to this set of services as MoSh as in Figure 1. 289 The MoSh can be located at the access network the MN uses to connect 290 to the home network, or it can be located elsewhere. 292 +--------------+ +====+ 293 | HOME NETWORK | |MoSh| 294 +--------------+ +====+ 295 /\ 296 || 297 \/ 298 +--------+ 299 | MN | 300 +--------+ 302 Figure 1: MoS in the home network 304 3.2. Scenario S2: Visited Network MoS 306 In this scenario, the MN is in the visited network and mobility 307 services are provided by the visited network. We refer to this as 308 MoSv as shown in Figure 2. 310 +--------------+ 311 | HOME NETWORK | 312 +--------------+ 313 /\ 314 || 315 \/ 316 +====+ +-----------------+ 317 |MoSv| | VISITED NETWORK | 318 +====+ +-----------------+ 319 /\ 320 || 321 \/ 322 +--------+ 323 | MN | 324 +--------+ 326 Figure 2: MoSv in the visited network 328 3.3. Scenario S3: Third party MoS 330 In this scenario, the MN is in its home network or in a visited 331 network and services are provided by a 3rd party network. We refer 332 to this situation as MoS3 as shown in Figure 3. (Note that MoS can 333 exist both in home and in visited networks). 335 +--------------+ 336 | HOME NETWORK | 337 +====+ +--------------+ +--------------+ 338 |MoS3| | THIRD PARTY | <===> /\ 339 +====+ +--------------+ || 340 \/ 341 +-----------------+ 342 | VISITED NETWORK | 343 +-----------------+ 344 /\ 345 || 346 \/ 347 +--------+ 348 | MN | 349 +--------+ 351 Figure 3: MoS from a third party 353 3.4. Scenario S4: Roaming MoS 355 In this scenario, the MN is located in the visited network and all 356 MIH services are provided by the home network, as shown in Figure 4. 358 +====+ +--------------+ 359 |MoSh| | HOME NETWORK | 360 +====+ +--------------+ 361 /\ 362 || 363 \/ 364 +-----------------+ 365 | VISITED NETWORK | 366 +-----------------+ 367 /\ 368 || 369 \/ 370 +--------+ 371 | MN | 372 +--------+ 374 Figure 4: MoS provided by the home while in visited 376 Different types of MoS can be provided independently of other types 377 and there is no strict relationship between ES, CS and IS, nor is 378 there a requirement that the entities that provide these services 379 should be co-located. However, while IS tends to involve a large 380 amount of static information, ES and CS are dynamic services and some 381 relationships between them can be expected, e.g., a handover command 382 (CS) could be issued upon reception of a link event (ES). This 383 document does not make any assumption on the location of the MoS 384 (although there might be some preferred configurations), and aims at 385 flexible MSFD to discover different services in different locations 386 to optimize handover performance. MoS discovery is discussed in more 387 detail in Section 5. 389 4. Solution Overview 391 As mentioned in Section 1, the solution space is being divided into 392 two functional domains: discovery and transport. The following 393 assumptions have been made: 395 o The solution is primarily aimed at supporting IEEE 802.21 MIH 396 services, namely Information Service (IS), Event Service (ES), and 397 Command Service (CS). 399 o If the MIHFID is available, FQDN or NAI's realm is used for 400 mobility service discovery. 402 o The solutions are chosen to cover all possible deployment 403 scenarios as described in Section 3. 405 o MoS discovery can be performed during initial network attachment 406 or at any time thereafter. 408 The MN may know the realm of the MoS to be discovered. The MN may 409 also be pre-configured with the address of the MoS to be used. In 410 case the MN does not know what realm/MoS to query, dynamic assignment 411 methods are described in Section 5. 413 The discovery of the MoS (and the related configuration at MIHF 414 level) is required to bind two MIHF peers (e.g. MN and MoS) with 415 their respective IP addresses. Discovery MUST be executed in the 416 following conditions: 418 o Bootstrapping: upon successful layer 2 network attachment the MN 419 MAY be required to use DHCP for address configuration. These 420 procedures can carry the required information for MoS 421 configuration in specific DHCP options. 423 o If the MN does not receive MoS information during network 424 attachment and the MN does not have a pre-configured MoS, it MUST 425 run a discovery procedure upon initial IP address configuration. 427 o If the MN changes its IP address (e.g. upon handover) it MUST 428 refresh MIHF peer bindings (i.e., MIHF registration process). In 429 case the MoS used is not suitable anymore (e.g. too large RTT 430 experienced) the MN MAY need to perform a new discovery procedure. 432 o If the MN is a multi-homed device and it communicates with the 433 same MoS via different IP addresses it MAY run discovery 434 procedures if one of the IP addresses changes. 436 Once the MIHF peer has been discovered, MIH information can be 437 exchanged between MIH peers over a transport protocol such as UDP or 438 TCP. The usage of transport protocols is described in Section 6 and 439 packing of the MIH messages does not require extra framing since the 440 MIH protocol defined in [IEEE80221] already contains a length field. 442 4.1. Architecture 444 Figure 5 depicts the MSFD reference model and its components within a 445 node. The topmost layer is the MIHF user. This set of applications 446 consists of one or more MIH clients that are responsible for 447 operations such as generating query and response, processing Layer 2 448 triggers as part of the ES, and initiating and carrying out handover 449 operations as part of the CS. Beneath the MIHF user is the MIHF 450 itself. This function is responsible for MoS discovery, as well as 451 creating, maintaining, modifying, and destroying MIH signaling 452 associations with other MIHFs located in MIH peer nodes. Below the 453 MIHF are various transport layer protocols as well as address 454 discovery functions. 456 +--------------------------+ 457 | MIHF User | 458 +--------------------------+ 459 || 460 +--------------------------+ 461 | MIHF | 462 +--------------------------+ 463 || || || 464 || +------+ +-----+ 465 || | DHCP | | DNS | 466 || +------+ +-----+ 467 || || || 468 +--------------------------+ 469 | TCP/UDP | 470 +--------------------------+ 472 Figure 5: MN stack 474 The MIHF relies on the services provided by TCP and UDP for 475 transporting MIH messages, and relies on DHCP and DNS for peer 476 discovery. In cases where the peer MIHF IP address is not pre- 477 configured, the source MIHF needs to discover it either via DHCP or 478 DNS as described in Section 5. Once the peer MIHF is discovered, the 479 MIHF must exchange messages with its peer over either UDP or TCP. 480 Specific recommendations regarding the choice of transport protocols 481 are provided in Section 6. 483 There are no security features currently defined as part of the MIH 484 protocol level. However, security can be provided either at the 485 transport or IP layer where it is necessary. Section 8 provides 486 guidelines and recommendations for security. 488 4.2. MIHF Identifiers (FQDN, NAI) 490 MIHFID is an identifier required to uniquely identify the MIHF end 491 points for delivering the mobility services (MoS). Thus an MIHF 492 identifier needs to be unique within a domain where mobility services 493 are provided and independent of the configured IP addresse(s). An 494 MIHFID MUST be represented either in the form of an FQDN [RFC2181] or 495 NAI [RFC4282]. An MIHFID can be pre-configured or discovered through 496 the discovery methods described in Section 5. 498 5. MoS Discovery 500 The MoS discovery method depends on whether the MN attempts to 501 discover an MoS in the home network, in the visited network, or in a 502 3rd party remote network that is neither the home network nor the 503 visited network. In the case the MN has already a MoS address pre- 504 configured it is not necessary to run the discovery procedure. If 505 the MN does not have pre-configured MoS the following procedure 506 applies. 508 In the case where MoS is provided locally (scenarios S1 and S2) , the 509 discovery techniques described in [I-D.ietf-mipshop-mos-dhcp-options] 510 and [I-D.ietf-mipshop-mos-dns-discovery] are both applicable as 511 described in Section 5.1 and Section 5.2. 513 In the case where MoS is provided in the home network while the MN is 514 in the visited network (scenario S4), the DNS based discovery 515 described in [I-D.ietf-mipshop-mos-dns-discovery] is applicable. 517 In the case where MoS is provided by a third party network which is 518 different from the current visited network (scenario S3), only the 519 DNS based discovery method described in 520 [I-D.ietf-mipshop-mos-dns-discovery] is applicable. 522 It should be noted that authorization of a MN to use a specific MoS 523 server is neither in scope of this document nor is currently 524 specified in IEEE80221. We further assume all devices can access 525 discovered MoS. In case future deployments will implement 526 authorization policies the mobile nodes should fall back to other 527 learned MoS if authorization is denied. 529 5.1. MoS Discovery when MN and MoSh are in the home network (Scenario 530 S1) 532 To discover an MoS in the home network, the MN SHOULD use the DNS 533 based MoS discovery method described in 534 [I-D.ietf-mipshop-mos-dns-discovery]. In order to use that 535 mechanism, the MN MUST have its home domain pre-configured (i.e., 536 subscription is tied to a network). The DNS query option is shown in 537 Figure 6a. Alternatively, the MN MAY use the DHCP options for MoS 538 discovery [I-D.ietf-mipshop-mos-dhcp-options] as shown in Figure 6b 539 (in some deployments, a DHCP relay may not be present). 541 (a) +-------+ 542 +----+ |Domain | 543 | MN |-------->|Name | 544 +----+ |Server | 545 MN@example.org +-------+ 547 (b) 548 +-----+ +------+ 549 +----+ | | |DHCP | 550 | MN |<----->| DHCP|<---->|Server| 551 +----+ |Relay| | | 552 +-----+ +------+ 554 Figure 6: MOS Discovery (a) using DNS query, (b) using DHCP option 556 5.2. MoS Discovery when MN and MoSv both are in visited network 557 (Scenario S2) 559 To discover an MoS in the visited network, the MN SHOULD attempt to 560 use the DHCP options for MoS discovery 561 [I-D.ietf-mipshop-mos-dhcp-options] as shown in Figure 7. 563 +-----+ +------+ 564 +----+ | | |DHCP | 565 | MN |<----->| DHCP|<---->|Server| 566 +----+ |Relay| | | 567 +-----+ +------+ 569 Figure 7: MoS Discovery using DHCP options 571 5.3. MoS Discovery when MIH services are in a 3rd party remote network 572 (Scenario S3) 574 To discover an MoS in a remote network other than home network, the 575 MN MUST use the DNS based MoS discovery method described in 576 [I-D.ietf-mipshop-mos-dns-discovery]. The MN MUST first learn the 577 domain name of the network containing the MoS it is searching for. 578 The MN can query its current MoS to find out the domain name of a 579 specific network or the domain name of a network at a specific 580 location (as in Figure 8a, IEEE 802.21 defines information elements 581 such as OPERATOR ID and SERVICE PROVIDER ID which can be a domain 582 name. An IS query can provide this information, see [IEEE80221]). 584 Alternatively, the MN MAY query a MoS previously known to learn the 585 domain name of the desired network . Finally, the MN MUST use DNS 586 based discovery mechanisms to find MoS in the remote network as in 587 Figure 8b. It should be noted that step b can only be performed upon 588 obtaining the domain name of the remote network. 590 (a) 591 +------------+ 592 +----+ | | 593 | | |Information | 594 | MN |-------->| Server | 595 | | |(previously | 596 +----+ |discovered) | 597 +------------+ 599 (b) 600 +-------+ 601 +----+ |Domain | 602 | MN |-------->|Name | 603 +----+ |Server | 604 MN@example.org +-------+ 606 Figure 8: MOS Discovery using (a) IS Query to a known IS Server, (b) 607 DNS Query 609 5.4. MoS Discovery when the MN is in a visited Network and Services are 610 at the Home network 612 To discover an MoS in the visited network when MIH services are 613 provided by the home network, the DNS based discovery method 614 described in [I-D.ietf-mipshop-mos-dns-discovery] is applicable. To 615 discover the MoS at home while in a visited network using DNS, the MN 616 SHOULD use the procedures described in Section 5.1. 618 6. MIH Transport Options 620 Once the Mobility Services have been discovered, MIH peers run a 621 capability discovery and subscription procedure as specified in 622 [IEEE80221]. MIH peers MAY exchange information over TCP, UDP or any 623 other transport supported by both the server and the client. The 624 client MAY use the DNS discovery mechanism to discover which 625 transport protocols are supported by the server in addition to TCP 626 and UDP that are recommended in this document. While either protocol 627 can provide the basic transport functionality required, there are 628 performance trade-offs and unique characteristics associated with 629 each that need to be considered in the context of the MIH services 630 for different network loss and congestion conditions. The objectives 631 of this section are to discuss these trade-offs for different MIH 632 settings such as the MIH message size and rate, and the 633 retransmission parameters. In addition, factors such as NAT 634 traversal are also discussed. Given the reliability requirements for 635 the MIH transport, it is assumed in this discussion that the MIH ACK 636 mechanism is to be used in conjunction with UDP, while it MUST NOT be 637 used with TCP since TCP includes acknowledgement and retransmission 638 functionality. 640 6.1. MIH Message size 642 Although the MIH message size varies widely from about 30 bytes (for 643 a capability discovery request) to around 65000 bytes (for an IS 644 MIH_Get_Information response primitive), a typical MIH message size 645 for the ES/CS service ranges between 50 to 100 bytes [IEEE80221]. 646 Thus, considering the effects of the MIH message size on the 647 performance of the transport protocol brings us to discussing two 648 main issues, related to fragmentation of long messages in the context 649 of UDP and the concatenation of short messages in the context of TCP. 651 Since transporting long MIH messages may require fragmentation that 652 is not available in UDP, if MIH is using UDP a limit MUST be set on 653 the size of the MIH message based on the path MTU to destination (or 654 the Minimum MTU where PMTU is not implemented). The Minimum MTU 655 depends on the IP version used for transmission, and is the lesser of 656 the first hop MTU, and 576 or 1280 bytes for IPv4 [RFC1122] or for 657 IPv6 [RFC2460], respectively, although applications may reduce these 658 values to guard against the presence of tunnels. 660 According to[IEEE80221] when MIH message is sent using an L3 or 661 higher layer transport, L3 takes care of any fragmentation issue and 662 the MIH protocol does not handle fragmentation in such cases. Thus, 663 MIH layer fragmentation MUST NOT be used together with IP layer 664 framentation and MUST not be used when MIH packets are carried over 665 TCP. 667 The loss of an IP fragment leads to the retransmission of an entire 668 MIH message, which in turn leads to poor end-to-end delay performance 669 in addition to wasted bandwidth. Additional recommendations in 670 [RFC5405] apply for limiting the size of the MIH message when using 671 UDP and assuming IP layer fragmentation. In terms of dealing with 672 short messages, TCP has the capability to concatenate very short 673 messages in order to reduce the overall bandwidth overhead. However, 674 this reduced overhead comes at the cost of additional delay to 675 complete an MIH transaction, which may not be acceptable for CS and 676 ES services. Note also that TCP is a stream oriented protocol and 677 measures data flow in terms of bytes, not messages. Thus it is 678 possible to split messages across multiple TCP segments if they are 679 long enough. Even short messages can be split across two segments. 680 This can also cause unacceptable delays, especially if the link 681 quality is severely degraded as is likely to happen when the MN is 682 exiting a wireless access coverage area. The use of the TCP_NODELAY 683 option can alleviate this problem by triggering transmission of a 684 segment less than the SMSS. (It should be noted that [RFC4960] 685 addresses both of these problems, but discussion of SCTP is omitted 686 here, as it is generally not used for the mobility services discussed 687 in this document.). 689 6.2. MIH Message rate 691 The frequency of MIH messages varies according to the MIH service 692 type. It is expected that CS/ES message arrive at a rate of one in 693 hundreds of milliseconds in order to capture quick changes in the 694 environment and/ or process handover commands. On the other hand, IS 695 messages are exchanged mainly every time a new network is visited 696 which may be in order of hours or days. Therefore a burst of either 697 short CS/ES messages or long IS message exchanges (in the case where 698 multiple MIH nodes request information) may lead to network 699 congestion. While the built-in rate-limiting controls available in 700 TCP may be well suited for dealing with these congestion conditions, 701 this may result in large transmission delays that may be unacceptable 702 for the timely delivery of ES/CS messages. On the other hand, if UDP 703 is used, a rate-limiting effect similar to the one obtained with TCP 704 SHOULD be obtained by adequately adjusting the parameters of a token 705 bucket regulator as defined in the MIH specifications [IEEE80221]. 706 Recommendations for token bucket parameter settings are as follow: 708 o If the MIHF knows the RTT (e.g., based on the request/response MIH 709 protocol exchange between two MIH peers), the rate can be based 710 upon this as specified in [IEEE80221]. 712 o If not, then on average it SHOULD NOT send more than one UDP 713 message every 3 seconds. 715 6.3. Retransmission 717 For TCP, the retransmission timeout is adjusted according to the 718 measured RTT. However due to the exponential backoff mechanism, the 719 delay associated with retransmission timeouts may increase 720 significantly with increased packet loss. 722 If UDP is being used to carry MIH messages, MIH MUST use MIH ACKs. 723 An MIH message is retransmitted if its corresponding MIH ACK is not 724 received by the generating node within a timeout interval set by the 725 MIHF. The maximum number of retransmissions is configurable and the 726 value of the retransmission timer is computed according to the 727 algorithm defined in [RFC2988]. The default maximum number of 728 retransmissions is set to 2 and the initial retransmission timer 729 (TMO) is set to 3s when RTT is not known. The maximum TMO is set to 730 30s. 732 6.4. NAT Traversal 734 There are no known issues for NAT traversal when using TCP. The 735 default connection timeout of 2 hours 4 minutes [RFC5382] (assuming a 736 2 hours TCP keep-alive) is considered adequate for MIH transport 737 purposes. However, issues with NAT traversal using UDP are 738 documented in [RFC5405]. Communication failures are experienced when 739 middleboxes destroy the per-flow state associated with an application 740 session during periods when the application does not exchange any UDP 741 traffic. Hence, communication between the MN and the MoS SHOULD be 742 able to gracefully handle such failures and implement mechanisms to 743 re-establish their UDP sessions. In addition and in order to avoid 744 such failures, MIH messages MAY be sent periodically, similarly to 745 keep-alive messages, in an attempt to refresh middlebox state. As 746 [RFC4787] requires a minimum state timeout of two minutes or more, 747 MIH messages using UDP as transport SHOULD be sent once every two 748 minutes. Re-registration or Event indication messages as defined in 749 [IEEE80221] MAY be used for this purpose. 751 6.5. General guidelines 753 Since ES and CS messages are small in nature and have tight latency 754 requirements, UDP in combination with MIH acknowledgement SHOULD be 755 used for transporting ES and CS messages. On the other hand, IS 756 messages are more resilient in terms of latency constraints and some 757 long IS messages could exceed the MTU of the path to the destination. 758 TCP SHOULD be used to transport IS messages. 760 For both UDP and TCP cases, if a port number is not explicitly 761 assigned (e.g. by the DNS SRV), MIH messages sent over UDP, TCP or 762 other supported transport MUST use the default port number defined in 763 Section 9 for that particular transport. 765 A MoS server MUST support both UDP and TCP for MIH transport and the 766 MN MUST support TCP. Additionally, the server and MN MAY support 767 additional transport mechanisms. The MN MAY use the procedures 768 defined in [I-D.ietf-mipshop-mos-dns-discovery] to discover 769 additional transport protocols supported by the server (e.g. SCTP). 771 7. Operation Flows 773 Figure 9 gives an example operation flow between MIHF peers when a 774 MIH user requests an IS service and both the MN and the MoS are in 775 the MN's home network. DHCP is used for MoS discovery and TCP is 776 used for establishing a transport connection to carry the IS 777 messages. When MoS is not pre-configured, the MIH user needs to 778 discover the IP address of MoS to communicate with the remote MIHF. 780 Therefore the MIH user sends a discovery request message to the local 781 MIHF as defined in [IEEE80221]. 783 In this example (one could draw similar mechanisms with DHCPv6), we 784 assume that MoS discovery is performed before a transport connection 785 is established with the remote MIHF, and the DHCP client process is 786 invoked via some internal APIs. The DHCP Client sends a DHCP INFORM 787 message according to standard DHCP and with the MoS option as defined 788 in [I-D.ietf-mipshop-mos-dhcp-options]. The DHCP server replies via 789 a DHCP ACK message with the IP address of the MoS. The MoS address 790 is then passed to the MIHF locally via some internal APIs. The MIHF 791 generates the discovery response message and passes it on to the 792 corresponding MIH user. The MIH user generates an IS query addressed 793 to the remote MoS. The MIHF invokes the underlying TCP client which 794 establishes a transport connection with the remote peer. Once the 795 transport connection is established, the MIHF sends the IS query via 796 a MIH protocol REQUEST message. The message and query arrive at the 797 destination MIHF and MIH user respectively. The MoS MIH user 798 responds to the corresponding IS query and the MoS MIHF sends the IS 799 response via a MIH protocol RESPONSE message. The message arrives at 800 the source MIHF which passes the IS response on to the corresponding 801 MIH user. 803 MN MoS 804 |===================================| |======| |===================| 805 + ---------+ + ---------+ 806 | MIH USER | +------+ +------+ +------+ +------+ | MIH USER | 807 | +------+ | | TCP | |DHCP | |DHCP | | TCP | | +------+ | 808 | | MIHF | | |Client| |Client| |Server| |Server| | | MIHF | | 809 +----------+ +------+ +------+ +------+ +------+ +----------+ 810 | | | | | | 811 MIH Discovery | | | | | 812 Request | | | | | 813 | | | | | | 814 |Invoke DHCP Client | | | | 815 |(Internal process with MoS)|DHCP INFORM| | | 816 |==========================>|==========>| | | 817 | | | | | | 818 | | | DHCP ACK | | | 819 | | |<==========| | | 820 | Inform MoS address | | | | 821 |<==========================| | | | 822 | (internal process) | | | | 823 | | | | | | 824 MIH Discovery | | | | | 825 Response | | | | | 826 | | | | | | 827 IS Query | | | | | 828 MIH User-> MIHF | | | | | 829 | | | | | | 830 |Invoke TCP Client| | | | | 831 |================>| | | | | 832 Internal process | | | | | 833 | | TCP connection established | | 834 | |<=============================>| | 835 | | | | | | 836 | IS QUERY REQUEST (via MIH protocol) | 837 |===========================================================>| 838 | | | | | | 839 | | | | | IS QUERY| 840 | | | | | REQUEST| 841 | | | | MIHF-> MIH User | 842 | | | | | | 843 | | | | | QUERY| 844 | | | | | RESPONSE| 845 | | | | MIHF <-MIH User | 846 | | | | | | 847 | | IS QUERY RESPONSE (via MIH protocol) | 848 |<===========================================================| 849 | | | | | | 850 IS RESPONSE | | | | | 851 MIH User <-MIHF | | | | | 852 | | | | | | 854 Figure 9: Example Flow of Operation Involving MIH User 856 8. Security Considerations 858 There are two components to the security considerations: MoS 859 Discovery and MIH Transport. For MoS Discovery, DHCP and DNS 860 recommendations are hereby provided per IETF guidelines. For MIH 861 Transport, we describe the security threats and expect that the 862 system deployment will have means to mitigate such threats when 863 sensitive information is being exchanged between the mobile node and 864 MoS. Since IEEE 802.21 base specification does not provide MIH 865 protocol level security, it is assumed that either lower layer 866 security (e.g., link layer), or overall system specific (e.g. 867 proprietary) security solutions are available. The present document 868 does not provide any guidelines in this regard. It is should be 869 stressed that the IEEE 802.21a Task Group has recently started work 870 on MIH security issues that may provide some solution in this area. 871 Finally authorization of a MN to use a specific MoS, as stated in 872 Section 5, is neither in scope of this document nor is currently 873 specified in [IEEE80221]. 875 8.1. Security Considerations for MoS Discovery 877 There are a number of security issues that need to be taken into 878 account during node discovery. In the case where DHCP is used for 879 node discovery and authentication of the source and content of DHCP 880 messages is required, network administrators SHOULD use the DHCP 881 authentication option described in [RFC3118], where available, or 882 rely upon link layer security. [RFC3118] provides mechanisms for 883 both entity authentication and message authentication. In case where 884 the DHCP authentication mechanism is not available administrators may 885 need to rely upon the underlying link layer security. In such cases 886 the link between DHCP client and layer-2 termination point may be 887 protected but the DHCP message source and its messages can not be 888 authenticated or the integrity of the latter checked unless there 889 exits a security binding between link layer and DHCP layer. 891 In the case where DNS is used for discovering MoS, fake DNS requests 892 and responses may cause DoS and the inability of the MN to perform a 893 proper handover, respectively. Where networks are exposed to such 894 DoS, it is RECOMMENDED that DNS service providers use the Domain Name 895 System Security Extensions (DNSSEC) as described in [RFC4033]. 896 Readers may also refer to [RFC4641] to consider the aspects of DNSSEC 897 Operational Practices. 899 8.2. Security Considerations for MIH Transport 901 The communication between an MN and an MoS is exposed to a number of 902 security threads: 904 o MoS Identity spoofing. A fake MoS could provide the MNs with 905 bogus data and force them to select the wrong network or to make a 906 wrong handover decision. 908 o Tampering. Tampering with the information provided by an MoS may 909 result in the MN making wrong network selection or handover 910 decisions 912 o Replay attack. Since MoSs as defined in [IEEE80221] support a 913 'PUSH model', they can send bulk of data to the MNs whenever the 914 MoSs think that the data is relevant for the MN. An attacker may 915 intercept the data sent my the MoSs to the MNs and replay it at a 916 later time, causing the MNs to make network selection or handover 917 decisions which are not valid at that point in time. 919 o Eavesdropping. By snooping the communication between an MN and an 920 MoS, an attacker may be able to trace a user's movement between 921 networks or cells, or predict future movements, by inspecting 922 handover service messages. 924 There are many deployment specific system security solutions 925 available and can be used to countermeasure the above mentioned 926 threats. For example, for the MoSh and MoSv scenarios (including 927 roaming scenarios), link layer security may be sufficient to protect 928 the communication between MN and MoS. This is a typical mobile 929 operator environment where link layer security provides 930 authentication, data confidentiality and integrity. In other 931 scenarios, such as the third party MoS, link layer security solutions 932 may not be sufficient to protect the communication path between the 933 MN and the MoS. The communication channel between MN and MoS needs 934 to be secured by other means. 936 The present document does not provide any specific guidelines about 937 the way these security solutions should be deployed. However, if in 938 future the IEEE 802.21 Working Group amends the specification with 939 MIH protocol level security or recommends the deployment scenarios, 940 IETF may revisit the security considerations and recommend specific 941 transport layer security as appropriate. 943 9. IANA Considerations 945 This document registers the following TCP and UDP port(s) with IANA: 947 Keyword Decimal Description 948 -------- --------------- ------------ 949 ieee-mih TBD_BY_IANA/tcp MIH Services 950 ieee-mih TBD_BY_IANA/udp MIH Services 952 10. Acknowledgements 954 The authors would like to thank Yoshihiro Ohba, David Griffith, Kevin 955 Noll, Vijay Devarapalli, Patrick Stupar and Sam Xia for their 956 valuable comments, reviews and fruitful discussions. 958 11. References 960 11.1. Normative References 962 [I-D.ietf-mipshop-mos-dhcp-options] 963 Bajko, G. and S. Das, "Dynamic Host Configuration Protocol 964 (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility 965 Server (MoS) discovery", 966 draft-ietf-mipshop-mos-dhcp-options-10 (work in progress), 967 January 2009. 969 [I-D.ietf-mipshop-mos-dns-discovery] 970 Bajko, G., "Locating IEEE 802.21 Mobility Servers using 971 DNS", draft-ietf-mipshop-mos-dns-discovery-04 (work in 972 progress), October 2008. 974 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 975 Requirement Levels", BCP 14, RFC 2119, March 1997. 977 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 978 Specification", RFC 2181, July 1997. 980 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 981 Messages", RFC 3118, June 2001. 983 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 984 and M. Carney, "Dynamic Host Configuration Protocol for 985 IPv6 (DHCPv6)", RFC 3315, July 2003. 987 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 988 Rose, "DNS Security Introduction and Requirements", 989 RFC 4033, March 2005. 991 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 992 Network Access Identifier", RFC 4282, December 2005. 994 11.2. Informative References 996 [IEEE80221] 997 "Draft IEEE Standard for Local and Metropolitan Area 998 Networks: Media Independent Handover Services", IEEE LAN/ 999 MAN Draft IEEE P802.21/D13.00, August 2008. 1001 [RFC1035] Mockapetris, P., "Domain names - implementation and 1002 specification", STD 13, RFC 1035, November 1987. 1004 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1005 Communication Layers", STD 3, RFC 1122, October 1989. 1007 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1008 November 1990. 1010 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1011 RFC 2131, March 1997. 1013 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1014 (IPv6) Specification", RFC 2460, December 1998. 1016 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 1017 Control", RFC 2581, April 1999. 1019 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 1020 Timer", RFC 2988, November 2000. 1022 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1023 Address Translator (Traditional NAT)", RFC 3022, 1024 January 2001. 1026 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 1027 RFC 4641, September 2006. 1029 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1030 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1031 RFC 4787, January 2007. 1033 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1034 RFC 4960, September 2007. 1036 [RFC5164] Melia, T., "Mobility Services Transport: Problem 1037 Statement", RFC 5164, March 2008. 1039 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1040 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1042 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1043 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1044 RFC 5382, October 2008. 1046 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1047 for Application Designers", BCP 145, RFC 5405, 1048 November 2008. 1050 Authors' Addresses 1052 Telemaco Melia (editor) 1053 Alcatel-Lucent 1054 Route de Villejust 1055 Nozay 91620 1056 France 1058 Email: telemaco.melia@alcatel-lucent.com 1059 Gabor Bajko 1060 Nokia 1062 Email: Gabor.Bajko@nokia.com 1064 Subir Das 1065 Telcordia Technologies Inc. 1067 Email: subir@research.telcordia.com 1069 Nada Golmie 1070 NIST 1072 Email: nada.golmie@nist.gov 1074 Juan Carlos Zuniga 1075 InterDigital Communications, LLC 1077 Email: j.c.zuniga@ieee.org