idnits 2.17.1 draft-ietf-mipshop-mstp-solution-09.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 1071. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1082. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1089. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1095. 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 (November 3, 2008) is 5625 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-07 == 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 2459 (Obsoleted by RFC 3280) -- 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 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 (~~), 3 warnings (==), 15 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: May 7, 2009 Nokia 6 S. Das 7 Telcordia Technologies Inc. 8 N. Golmie 9 NIST 10 JC. Zuniga 11 InterDigital Communications, LLC 12 November 3, 2008 14 IEEE 802.21 Mobility Services Framework Design (MSFD) 15 draft-ietf-mipshop-mstp-solution-09 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 May 7, 2009. 42 Abstract 44 This document describes a mobility services framework design (MSFD) 45 for the IEEE 802.21 Media Independent Handover (MIH) protocol that 46 addresses identified issues associated with the transport of MIH 47 messages. The document also describes mechanisms for mobility 48 service (MoS) discovery and transport layer mechanisms for the 49 reliable delivery of MIH messages. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [RFC2119]. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Scenario S1: Home Network MoS . . . . . . . . . . . . . . 6 63 3.2. Scenario S2: Visited Network MoS . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 21 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 22 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 92 Intellectual Property and Copyright Statements . . . . . . . . . . 25 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. 148 MoS3: Mobility Services assigned in a 3rd Party Network, which is a 149 network that is neither the Home Network nor the current Visited 150 Network. 152 MN Mobile Node: an Internet device whose location changes, along with 153 its point of connection to the network. 155 MSTP Mobility Services Transport Protocol: a protocol that is used 156 to deliver MIH protocol messages from an MIHF to other MIH-aware 157 nodes in a network. 159 IS Information Service: a MoS that originates at the lower or upper 160 layers of the protocol stack and sends information to the local or 161 remote upper or lower layers of the protocol stack. The purpose 162 of IS is to exchange information elements (IEs) relating to 163 various neighboring network information. 165 ES Event Service: a MoS that originates at a remote MIHF or the lower 166 layers of the local protocol stack and sends information to the 167 local MIHF or local higher layers. The purpose of the ES is to 168 report changes in link status (e.g., Link Going Down messages) and 169 various lower layer events. 171 CS Command Service: MoS that sends commands from the remote MIHF or 172 local upper layers to the remote or local lower layers of the 173 protocol stack to switch links or to get link status. 175 FQDN: Fully-Qualified Domain Name: a complete domain name for a host 176 on the Internet, showing (in reverse order) the full delegation 177 path from the DNS root and top level domain down to the host name 178 (e.g. myexample.example.org). 180 NAI Network Access Identifier: the user ID that a user submits 181 during network access authentication [RFC4282]. For mobile users, 182 the NAI identifies the user and helps to route the authentication 183 request message. 185 NAT Network Address Translator: A device that implements the Network 186 Address Translation function described in [RFC3022], in which 187 local or private network layer addresses are mapped to routable 188 (outside the NAT domain) network addresses and port numbers. 190 DHCP Dynamic Host Configuration Protocol: protocols described in 191 [RFC2131] and [RFC3315] that allow Internet devices to obtain 192 respectively IPv4 and IPv6 addresses, subnet masks, default 193 gateway addresses, and other IP configuration information from 194 DHCP servers. 196 DNS Domain Name System: a protocol described in [RFC1035] that 197 translates domain names to IP addresses. 199 AAA Authentication, Authorization and Accounting: a set of network 200 management services that respectively determine the validity of a 201 user's ID, determine whether a user is allowed to use network 202 resources, and track users' use of network resources. 204 Home AAA AAAh: an AAA server located on the MN's home network. 206 Visited AAA AAAv: an AAA server located in a visited network that is 207 not the MN's home network. 209 MIH ACK MIH Acknowledgement Message: a MIH signaling message that a 210 MIHF sends in response to an MIH message from a sending MIHF, when 211 UDP is used as the MSTP. 213 PoS Point of Service: a network-side MIHF instance that exchanges 214 MIH messages with a MN-based MIHF. 216 NAS Network Access Server: a server to which a MN initially connects 217 when it is trying to gain a connection to a network and which 218 determines whether the MN is allowed to connect to the NAS's 219 network. 221 UDP User Datagram Protocol: a connectionless transport layer 222 protocol used to send datagrams between a source and a destination 223 at a given port, defined in RFC 768. 225 TCP Transmission Control Protocol: a stream-oriented transport layer 226 protocol that provides a reliable delivery service with congestion 227 control, defined in RFC 793. 229 RTT Round-Trip Time: an estimation of the time required for a 230 segment to travel from a source to a destination and an 231 acknowledgement to return to the source that is used by TCP in 232 connection with timer expirations to determine when a segment is 233 considered lost and should be resent. 235 MTU Maximum Transmission Unit: the largest size of an IP packet that 236 can be sent on a network segment without requiring fragmentation 237 [RFC1191]. 239 PMTU Path MTU: the largest size of an IP packet that can be sent on 240 an end-to-end network path without requiring IP fragmentation. 242 TLS Transport Layer Security Protocol: an application layer protocol 243 that primarily assures privacy and data integrity between two 244 communicating network entities [RFC5246]. 246 SMSS Sender Maximum Segment Size: size of the largest segment that 247 the sender can transmit as per [RFC2581]. 249 3. Deployment Scenarios 251 This section describes the various possible deployment scenarios for 252 the MN and the MoS. The relative positioning of MN and MoS affects 253 MoS discovery as well as the performance of the MIH signaling 254 service. This document addresses the scenarios listed in [RFC5164] 255 and specifies transport options to carry the MIH protocol over IP. 257 3.1. Scenario S1: Home Network MoS 259 In this scenario, the MN and the services are located in the home 260 network. We refer to this set of services as MoSh as in Figure 1. 261 The MoSh can be located at the access network the MN uses to connect 262 to the home network, or it can be located elsewhere. 264 +--------------+ +====+ 265 | HOME NETWORK | |MoSh| 266 +--------------+ +====+ 267 /\ 268 || 269 \/ 270 +--------+ 271 | MN | 272 +--------+ 274 Figure 1: MoS in the home network 276 3.2. Scenario S2: Visited Network MoS 278 In this scenario, the MN is in the visited network and mobility 279 services are provided by the visited network. We refer to this as 280 MoSv as shown in Figure 2. 282 +--------------+ 283 | HOME NETWORK | 284 +--------------+ 285 /\ 286 || 287 \/ 288 +====+ +-----------------+ 289 |MoSv| | VISITED NETWORK | 290 +====+ +-----------------+ 291 /\ 292 || 293 \/ 294 +--------+ 295 | MN | 296 +--------+ 298 Figure 2: MoSv in the visited network 300 3.3. Scenario S3: Third party MoS 302 In this scenario, the MN is in its home network or in a visited 303 network and services are provided by a 3rd party network. We refer 304 to this situation as MoS3 as shown in Figure 3. (Note that MoS can 305 exist both in home and in visited networks). 307 +--------------+ 308 | HOME NETWORK | 309 +====+ +--------------+ +--------------+ 310 |MoS3| | THIRD PARTY | <===> /\ 311 +====+ +--------------+ || 312 \/ 313 +-----------------+ 314 | VISITED NETWORK | 315 +-----------------+ 316 /\ 317 || 318 \/ 319 +--------+ 320 | MN | 321 +--------+ 323 Figure 3: MoS from a third party 325 3.4. Scenario S4: Roaming MoS 327 In this scenario, the MN is located in the visited network and all 328 MIH services are provided by the home network, as shown in Figure 4. 330 +====+ +--------------+ 331 |MoSh| | HOME NETWORK | 332 +====+ +--------------+ 333 /\ 334 || 335 \/ 336 +-----------------+ 337 | VISITED NETWORK | 338 +-----------------+ 339 /\ 340 || 341 \/ 342 +--------+ 343 | MN | 344 +--------+ 346 Figure 4: MoS provided by the home while in visited 348 Different types of MoS can be provided independently of other types 349 and there is no strict relationship between ES, CS and IS, nor is 350 there a requirement that the entities that provide these services 351 should be co-located. However, while IS tends to involve a large 352 amount of static information, ES and CS are dynamic services and some 353 relationships between them can be expected, e.g., a handover command 354 (CS) could be issued upon reception of a link event (ES). This 355 document does not make any assumption on the location of the MoS 356 (although there might be some preferred configurations), and aims at 357 flexible MSFD to discover different services in different locations 358 to optimize handover performance. MoS discovery is discussed in more 359 detail in Section 5. 361 4. Solution Overview 363 As mentioned in Section 1, the solution space is being divided into 364 two functional domains: discovery and transport. The following 365 assumptions have been made: 367 o The solution is primarily aimed at supporting IEEE 802.21 MIH 368 services, namely Information Service (IS), Event Service (ES), and 369 Command Service (CS). 371 o If the MIHFID is available, FQDN or NAI's realm is used for 372 mobility service discovery. 374 o The solutions are chosen to cover all possible deployment 375 scenarios as described in Section 3. 377 o MoS discovery can be performed during initial network attachment 378 or at any time thereafter. 380 The MN may know the realm of the MoS to be discovered. The MN may 381 also be pre-configured with the address of the MoS to be used. In 382 case the MN does not know what realm/MoS to query, dynamic assignment 383 methods are described in Section 5. 385 The discovery of the MoS (and the related configuration at MIHF 386 level) is required to bind two MIHF peers (e.g. MN and MoS) with 387 their respective IP addresses. Discovery MUST be executed in the 388 following conditions: 390 o Bootstrapping: upon successful layer 2 network attachment the MN 391 MAY be required to use DHCP for address configuration. These 392 procedures can carry the required information for MoS 393 configuration in specific DHCP options. 395 o If the MN does not receive MoS information during network 396 attachment and the MN does not have a pre-configured MoS, it MUST 397 run a discovery procedure upon initial IP address configuration. 399 o If the MN changes its IP address (e.g. upon handover) it MUST 400 refresh MIHF peer bindings (i.e., MIHF registration process). In 401 case the MoS used is not suitable anymore (e.g. too large RTT 402 experienced) the MN MAY need to perform a new discovery procedure. 404 o If the MN is a multi-homed device and it communicates with the 405 same MoS via different IP addresses it MAY run discovery 406 procedures if one of the IP addresses changes. 408 Once the MIHF peer has been discovered, MIH information can be 409 exchanged between MIH peers over a transport protocol such as UDP or 410 TCP. The usage of transport protocols is described in Section 6 and 411 packing of the MIH messages does not require extra framing since the 412 MIH protocol defined in [IEEE80221] already contains a length field. 414 4.1. Architecture 416 Figure 5 depicts the MSFD reference model and its components within a 417 node. The topmost layer is the MIHF user. This set of applications 418 consists of one or more MIH clients that are responsible for 419 operations such as generating query and response, processing Layer 2 420 triggers as part of the ES, and initiating and carrying out handover 421 operations as part of the CS. Beneath the MIHF user is the MIHF 422 itself. This function is responsible for MoS discovery, as well as 423 creating, maintaining, modifying, and destroying MIH signaling 424 associations with other MIHFs located in MIH peer nodes. Below the 425 MIHF are various transport layer protocols as well as address 426 discovery functions. 428 +--------------------------+ 429 | MIHF User | 430 +--------------------------+ 431 || 432 +--------------------------+ 433 | MIHF | 434 +--------------------------+ 435 || || || 436 || +------+ +-----+ 437 || | DHCP | | DNS | 438 || +------+ +-----+ 439 || || || 440 +--------------------------+ 441 | TCP/UDP | 442 +--------------------------+ 444 Figure 5: MN stack 446 The MIHF relies on the services provided by TCP and UDP for 447 transporting MIH messages, and relies on DHCP and DNS for peer 448 discovery. In cases where the peer MIHF IP address is not pre- 449 configured, the source MIHF needs to discover it either via DHCP or 450 DNS as described in Section 5. Once the peer MIHF is discovered, the 451 MIHF must exchange messages with its peer over either UDP or TCP. 452 Specific recommendations regarding the choice of transport protocols 453 are provided in Section 6. 455 There are no security features currently defined as part of the MIH 456 protocol level. However, security can be provided either at the 457 transport or IP layer where it is necessary. Section 8 provides 458 guidelines and recommendations for security. 460 4.2. MIHF Identifiers (FQDN, NAI) 462 MIHFID is an identifier required to uniquely identify the MIHF end 463 points for delivering the mobility services (MoS). Thus an MIHF 464 identifier needs to be unique within a domain where mobility services 465 are provided and independent of the configured IP addresse(s). An 466 MIHFID MUST be represented either in the form of an FQDN [RFC2181] or 467 NAI [RFC4282]. An MIHFID can be pre-configured or discovered through 468 the discovery methods described in Section 5. 470 5. MoS Discovery 472 The MoS discovery method depends on whether the MN attempts to 473 discover an MoS in the home network, in the visited network, or in a 474 3rd party remote network that is neither the home network nor the 475 visited network. In the case the MN has already a MoS address pre- 476 configured it is not necessary to run the discovery procedure. If 477 the MN does not have pre-configured MoS the following procedure 478 applies. 480 In the case where MoS is provided locally (scenarios S1 and S2) , the 481 discovery techniques described in [I-D.ietf-mipshop-mos-dhcp-options] 482 and [I-D.ietf-mipshop-mos-dns-discovery] are both applicable as 483 described in Section 5.1 and Section 5.2. 485 In the case where MoS is provided in the home network while the MN is 486 in the visited network (scenario S4), the DNS based discovery 487 described in [I-D.ietf-mipshop-mos-dns-discovery] is applicable. 489 In the case where MoS is provided by a third party network which is 490 different from the current visited network (scenario S3), only the 491 DNS based discovery method described in 492 [I-D.ietf-mipshop-mos-dns-discovery] is applicable. 494 It should be noted that authorization of a MN to use a specific MoS 495 server is neither in scope of this document nor is currently 496 specified in [IEEE80221]. We further assume all devices can access 497 discovered MoS. In case future deployments will implement 498 authorization policies the mobile nodes should fall back to other 499 learned MoS if authorization is denied. 501 5.1. MoS Discovery when MN and MoSh are in the home network (Scenario 502 S1) 504 To discover an MoS in the home network, the MN SHOULD use the DNS 505 based MoS discovery method described in 506 [I-D.ietf-mipshop-mos-dns-discovery]. In order to use that 507 mechanism, the MN MUST have its home domain pre-configured (i.e., 508 subscription is tied to a network). The DNS query option is shown in 509 Figure 6a. Alternatively, the MN MAY use the DHCP options for MoS 510 discovery [I-D.ietf-mipshop-mos-dhcp-options] as shown in Figure 6b 511 (in some deployments, a DHCP relay may not be present). 513 (a) +-------+ 514 +----+ |Domain | 515 | MN |-------->|Name | 516 +----+ |Server | 517 MN@example.org +-------+ 519 (b) 520 +-----+ +------+ 521 +----+ | | |DHCP | 522 | MN |<----->| DHCP|<---->|Server| 523 +----+ |Relay| | | 524 +-----+ +------+ 526 Figure 6: MOS Discovery (a) using DNS query, (b) using DHCP option 528 5.2. MoS Discovery when MN and MoSv both are in visited network 529 (Scenario S2) 531 To discover an MoS in the visited network, the MN SHOULD attempt to 532 use the DHCP options for MoS discovery 533 [I-D.ietf-mipshop-mos-dhcp-options] as shown in Figure 7. 535 +-----+ +------+ 536 +----+ | | |DHCP | 537 | MN |<----->| DHCP|<---->|Server| 538 +----+ |Relay| | | 539 +-----+ +------+ 541 Figure 7: MoS Discovery using DHCP options 543 5.3. MoS Discovery when MIH services are in a 3rd party remote network 544 (Scenario S3) 546 To discover an MoS in a remote network other than home network, the 547 MN MUST use the DNS based MoS discovery method described in 548 [I-D.ietf-mipshop-mos-dns-discovery]. The MN MUST first learn the 549 domain name of the network containing the MoS it is searching for. 550 The MN can query its current MoS to find out the domain name of a 551 specific network or the domain name of a network at a specific 552 location (as in Figure 8a, IEEE 802.21 defines information elements 553 such as OPERATOR ID and SERVICE PROVIDER ID which can be a domain 554 name. An IS query can provide this information, see [IEEE80221]). 556 Alternatively, the MN MAY query a MoS previously known to learn the 557 domain name of the desired network . Finally, the MN MUST use DNS 558 based discovery mechanisms to find MoS in the remote network as in 559 Figure 8b. It should be noted that step b can only be performed upon 560 obtaining the domain name of the remote network. 562 (a) 563 +------------+ 564 +----+ | | 565 | | |Information | 566 | MN |-------->| Server | 567 | | |(previously | 568 +----+ |discovered) | 569 +------------+ 571 (b) 572 +-------+ 573 +----+ |Domain | 574 | MN |-------->|Name | 575 +----+ |Server | 576 MN@example.org +-------+ 578 Figure 8: MOS Discovery using (a) IS Query to a known IS Server, (b) 579 DNS Query 581 5.4. MoS Discovery when the MN is in a visited Network and Services are 582 at the Home network 584 To discover an MoS in the visited network when MIH services are 585 provided by the home network, the DNS based discovery method 586 described in [I-D.ietf-mipshop-mos-dns-discovery] is applicable. To 587 discover the MoS at home while in a visited network using DNS, the MN 588 SHOULD use the procedures described in Section 5.1. 590 6. MIH Transport Options 592 Once the Mobility Services have been discovered, MIH peers run a 593 capability discovery and subscription procedure as specified in 594 [IEEE80221]. MIH peers MAY exchange information over TCP, UDP or any 595 other transport supported by both the server and the client. The 596 client MAY use the DNS discovery mechanism to discover which 597 transport protocols are supported by the server in addition to TCP 598 and UDP that are recommended in this document. While either protocol 599 can provide the basic transport functionality required, there are 600 performance trade-offs and unique characteristics associated with 601 each that need to be considered in the context of the MIH services 602 for different network loss and congestion conditions. The objectives 603 of this section are to discuss these trade-offs for different MIH 604 settings such as the MIH message size and rate, and the 605 retransmission parameters. In addition, factors such as NAT 606 traversal are also discussed. Given the reliability requirements for 607 the MIH transport, it is assumed in this discussion that the MIH ACK 608 mechanism is to be used in conjunction with UDP, while it MUST NOT be 609 used with TCP since TCP includes acknowledgement and retransmission 610 functionality. 612 6.1. MIH Message size 614 Although the MIH message size varies widely from about 30 bytes (for 615 a capability discovery request) to around 65000 bytes (for an IS 616 MIH_Get_Information response primitive), a typical MIH message size 617 for the ES/CS service ranges between 50 to 100 bytes [IEEE80221]. 618 Thus, considering the effects of the MIH message size on the 619 performance of the transport protocol brings us to discussing two 620 main issues, related to fragmentation of long messages in the context 621 of UDP and the concatenation of short messages in the context of TCP. 623 Since transporting long MIH messages may require fragmentation that 624 is not available in UDP, if MIH is using UDP a limit MUST be set on 625 the size of the MIH message based on the path MTU to destination (or 626 the Minimum MTU where PMTU is not implemented). The Minimum MTU 627 depends on the IP version used for transmission, and is the lesser of 628 the first hop MTU, and 576 or 1280 bytes for IPv4 [RFC1122] or for 629 IPv6 [RFC2460], respectively, although applications may reduce these 630 values to guard against the presence of tunnels. 632 According to[IEEE80221] when MIH message is sent using an L3 or 633 higher layer transport, L3 takes care of any fragmentation issue and 634 the MIH protocol does not handle fragmentation in such cases. Thus, 635 MIH layer fragmentation MUST NOT be used together with IP layer 636 framentation. 638 The loss of an IP fragment leads to the retransmission of an entire 639 MIH message, which in turn leads to poor end-to-end delay performance 640 in addition to wasted bandwidth. Additional recommendations in 641 [I-D.ietf-tsvwg-udp-guidelines] apply for limiting the size of the 642 MIH message when using UDP and assuming IP layer fragmentation. In 643 terms of dealing with short messages, TCP has the capability to 644 concatenate very short messages in order to reduce the overall 645 bandwidth overhead. However, this reduced overhead comes at the cost 646 of additional delay to complete an MIH transaction, which may not be 647 acceptable for CS and ES services. Note also that TCP is a stream 648 oriented protocol and measures data flow in terms of bytes, not 649 messages. Thus it is possible to split messages across multiple TCP 650 segments if they are long enough. Even short messages can be split 651 across two segments. This can also cause unacceptable delays, 652 especially if the link quality is severely degraded as is likely to 653 happen when the MN is exiting a wireless access coverage area. The 654 use of the TCP_NODELAY option can alleviate this problem by 655 triggering transmission of a segment less than the SMSS. (It should 656 be noted that [RFC4960] addresses both of these problems, but 657 discussion of it is omitted here due to the lack of running code). 659 6.2. MIH Message rate 661 The frequency of MIH messages varies according to the MIH service 662 type. It is expected that CS/ES message arrive at a rate of one in 663 hundreds of milliseconds in order to capture quick changes in the 664 environment and/ or process handover commands. On the other hand, IS 665 messages are exchanged mainly every time a new network is visited 666 which may be in order of hours or days. Therefore a burst of either 667 short CS/ES messages or long IS message exchanges (in the case where 668 multiple MIH nodes request information) may lead to network 669 congestion. While the built-in rate-limiting controls available in 670 TCP may be well suited for dealing with these congestion conditions, 671 this may result in large transmission delays that may be unacceptable 672 for the timely delivery of ES/CS messages. On the other hand, if UDP 673 is used, a rate-limiting effect similar to the one obtained with TCP 674 SHOULD be obtained by adequately adjusting the parameters of a token 675 bucket regulator as defined in the MIH specifications [IEEE80221]. 676 Recommendations for token bucket parameter settings are as follow: 678 o If the MIHF knows the RTT (e.g., based on the request/response MIH 679 protocol exchange between two MIH peers), the rate can be based 680 upon this as specified in [IEEE80221]. 682 o If not, then on average it SHOULD NOT send more than one UDP 683 message every 3 seconds. 685 6.3. Retransmission 687 For TCP, the retransmission timeout is adjusted according to the 688 measured RTT. However due to the exponential backoff mechanism, the 689 delay associated with retransmission timeouts may increase 690 significantly with increased packet loss. 692 If UDP is being used to carry MIH messages, MIH MUST use MIH ACKs. 693 An MIH message is retransmitted if its corresponding MIH ACK is not 694 received by the generating node within a timeout interval set by the 695 MIHF. The maximum number of retransmissions is configurable and the 696 value of the retransmission timer is computed according to the 697 algorithm defined in [RFC2988]. The default maximum number of 698 retransmissions is set to 2 and the initial retransmission timer 699 (TMO) is set to 3s when RTT is not known. The maximum TMO is set to 700 30s. 702 6.4. NAT Traversal 704 There are no known issues for NAT traversal when using TCP. The 705 default connection timeout of 2 hours 4 minutes [RFC5382] (assuming a 706 2 hours TCP keep-alive) is considered adequate for MIH transport 707 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 SHOULD be 726 used for transporting ES and CS messages. On the other hand, IS 727 messages are more resilient in terms of latency constraints and some 728 long IS messages could exceed the MTU of the path to the destination. 729 TCP SHOULD be used to transport IS messages. 731 For both UDP and TCP cases, if a port number is not explicitly 732 assigned (e.g. by the DNS SRV), MIH messages sent over UDP, TCP or 733 other supported transport MUST use the default port number defined in 734 Section 9 for that particular transport. 736 A MoS server MUST support both UDP and TCP for MIH transport and the 737 MN MUST support TCP. Additionally, the server and MN MAY support 738 additional transport mechanisms. The MN MAY use the procedures 739 defined in [I-D.ietf-mipshop-mos-dns-discovery] to discover 740 additional transport protocols supported by the server (e.g. SCTP). 742 7. Operation Flows 744 Figure 9 gives an example operation flow between MIHF peers when a 745 MIH user requests an IS service and both the MN and the MoS are in 746 the MN's home network. DHCP is used for MoS discovery and TCP is 747 used for establishing a transport connection to carry the IS 748 messages. When MoS is not pre-configured, the MIH user needs to 749 discover the IP address of MoS to communicate with the remote MIHF. 750 Therefore the MIH user sends a discovery request message to the local 751 MIHF as defined in [IEEE80221]. 753 In this example (one could draw similar mechanisms with DHCPv6), we 754 assume that MoS discovery is performed before a transport connection 755 is established with the remote MIHF, and the DHCP client process is 756 invoked via some internal APIs. The DHCP Client sends a DHCP INFORM 757 message according to standard DHCP and with the MoS option as defined 758 in [I-D.ietf-mipshop-mos-dhcp-options]. The DHCP server replies via 759 a DHCP ACK message with the IP address of the MoS. The MoS address 760 is then passed to the MIHF locally via some internal APIs. The MIHF 761 generates the discovery response message and passes it on to the 762 corresponding MIH user. The MIH user generates an IS query addressed 763 to the remote MoS. The MIHF invokes the underlying TCP client which 764 establishes a transport connection with the remote peer. Once the 765 transport connection is established, the MIHF sends the IS query via 766 a MIH protocol REQUEST message. The message and query arrive at the 767 destination MIHF and MIH user respectively. The MoS MIH user 768 responds to the corresponding IS query and the MoS MIHF sends the IS 769 response via a MIH protocol RESPONSE message. The message arrives at 770 the source MIHF which passes the IS response on to the corresponding 771 MIH user. 773 MN MoS 774 |===================================| |======| |===================| 775 + ---------+ + ---------+ 776 | MIH USER | +------+ +------+ +------+ +------+ | MIH USER | 777 | +------+ | | TCP | |DHCP | |DHCP | | TCP | | +------+ | 778 | | MIHF | | |Client| |Client| |Server| |Server| | | MIHF | | 779 +----------+ +------+ +------+ +------+ +------+ +----------+ 780 | | | | | | 781 MIH Discovery | | | | | 782 Request | | | | | 783 | | | | | | 784 |Invoke DHCP Client | | | | 785 |(Internal process with MoS)|DHCP INFORM| | | 786 |==========================>|==========>| | | 787 | | | | | | 788 | | | DHCP ACK | | | 789 | | |<==========| | | 790 | Inform MoS address | | | | 791 |<==========================| | | | 792 | (internal process) | | | | 793 | | | | | | 794 MIH Discovery | | | | | 795 Response | | | | | 796 | | | | | | 798 IS Query | | | | | 799 MIH User-> MIHF | | | | | 800 | | | | | | 801 |Invoke TCP Client| | | | | 802 |================>| | | | | 803 Internal process | | | | | 804 | | TCP connection established | | 805 | |<=============================>| | 806 | | | | | | 807 | IS QUERY REQUEST (via MIH protocol) | 808 |===========================================================>| 809 | | | | | | 810 | | | | | IS QUERY| 811 | | | | | REQUEST| 812 | | | | MIHF-> MIH User | 813 | | | | | | 814 | | | | | QUERY| 815 | | | | | RESPONSE| 816 | | | | MIHF <-MIH User | 817 | | | | | | 818 | | IS QUERY RESPONSE (via MIH protocol) | 819 |<===========================================================| 820 | | | | | | 821 IS RESPONSE | | | | | 822 MIH User <-MIHF | | | | | 823 | | | | | | 825 Figure 9: Example Flow of Operation Involving MIH User 827 8. Security Considerations 829 There are a number of security issues that need to be taken into 830 account during node discovery and information exchange via a 831 transport connection [RFC5164]. 833 In the case where DHCP is used for node discovery and authentication 834 of the source and content of DHCP messages is required, network 835 administrators SHOULD use the DHCP authentication option described in 836 [RFC3118], where available, or rely upon link layer security. 837 [RFC3118] provides mechanisms for both entity authentication and 838 message authentication. In case where the DHCP authentication 839 mechanism is not available administrators may need to rely upon the 840 underlying link layer security. In such cases the link between DHCP 841 client and layer-2 termination point may be protected but the DHCP 842 message source and its messages can not be authenticated or the 843 integrity of the latter checked unless there exits a security binding 844 between link layer and DHCP layer. 846 In the case where DNS is used for discovering MoS, fake DNS requests 847 and responses may cause DoS and the inability of the MN to perform a 848 proper handover, respectively. Where networks are exposed to such 849 DoS, it is RECOMMENDED that DNS service providers use the Domain Name 850 System Security Extensions (DNSSEC) as described in [RFC4033]. 851 Readers may also refer to [RFC4641] to consider the aspects of DNSSEC 852 Operational Practices. 854 The communication between an MN and an MoS is exposed to a number of 855 security threads: 857 o MoS Identity spoofing. A fake MoS could provide the MNs with 858 bogus data and force them to select the wrong network or to make a 859 wrong handover decision. 861 o Tampering. Tampering with the information provided by an MoS may 862 result in the MN making wrong network selection or handover 863 decisions 865 o Replay attack. Since MoSs as defined in [IEEE80221] support a 866 'PUSH model', they can send bulk of data to the MNs whenever the 867 MoSs think that the data is relevant for the MN. An attacker may 868 intercept the data sent my the MoSs to the MNs and replay it at a 869 later time, causing the MNs to make network selection or handover 870 decisions which are not valid at that point in time. 872 o Eavesdropping. By snooping the communication between an MN and an 873 MoS, an attacker may be able to trace a user's movement between 874 networks or cells, or predict future movements, by inspecting 875 handover service messages. 877 To protect against these attacks, MNs SHOULD use some form of end-to- 878 end authentication to ensure that the correct destination has been 879 reached. Since MIH protocol does not have such a feature, transport 880 layer security (TLS [RFC5246] or DTLS [RFC4347]) with the "server- 881 name" extension SHOULD be used. The basic mechanism works as 882 follows: 884 1. The server sends to the client a credential with the appropriate 885 name as server's identity. For X.509 certificates, the name 886 would be in either the subjectDN or the subjectAltName field. 887 For Kerberos, the name would be a service principle name. 889 2. If the hostname is available (e.g., discovered via DNS or DHCP), 890 the client MUST compare it against the server's identity 891 presented in the server's credential. Matching is performed 892 using the matching rules specified by [RFC2459]. 894 3. If the names match and the credentials have integrity, there is 895 reasonable assurance that the correct end point has been reached. 897 Note that this document does not define either the handshake 898 mechanism, nor the specific credential naming fields. 900 In some scenarios, the MoS may require authentication of the MN to 901 provide access to certain sensitive MIH information. How the server 902 authenticates the client in such an environment is not specified in 903 this document. 905 [I-D.ietf-mipshop-mos-dns-discovery] allows an MN to discover whether 906 MoS supports TLS/DTLS. In cases when the MN is not able to discover 907 if the MoS supports TLS/DTLS, the MN MAY attempt to use the default 908 port numbers defined in Section 9. 910 9. IANA Considerations 912 This document registers the following TCP and UDP port(s) with IANA: 914 Keyword Decimal Description 915 -------- --------------- ------------ 916 ieee-mih TBD_BY_IANA/tcp MIH Services 917 ieee-mih TBD_BY_IANA/udp MIH Services 918 ieee-mih TBD_BY_IANA/TLS over tcp MIH Services 919 ieee-mih TBD_BY_IANA/DTLS over udp MIH Services 921 10. Acknowledgements 923 The authors would like to thank Yoshihiro Ohba, David Griffith, Kevin 924 Noll, Vijay Devarapalli, Patrick Stupar and Sam Xia for their 925 valuable comments, reviews and fruitful discussions. 927 11. References 929 11.1. Normative References 931 [I-D.ietf-mipshop-mos-dhcp-options] 932 Bajko, G. and S. Das, "Dynamic Host Configuration Protocol 933 (DHCPv4 and DHCPv6) Options for Mobility Server (MoS) 934 discovery", draft-ietf-mipshop-mos-dhcp-options-07 (work 935 in progress), October 2008. 937 [I-D.ietf-mipshop-mos-dns-discovery] 938 Bajko, G., "Locating IEEE 802.21 Mobility Servers using 939 DNS", draft-ietf-mipshop-mos-dns-discovery-04 (work in 940 progress), October 2008. 942 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 943 Requirement Levels", BCP 14, RFC 2119, March 1997. 945 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 946 Specification", RFC 2181, July 1997. 948 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 949 Messages", RFC 3118, June 2001. 951 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 952 and M. Carney, "Dynamic Host Configuration Protocol for 953 IPv6 (DHCPv6)", RFC 3315, July 2003. 955 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 956 Rose, "DNS Security Introduction and Requirements", 957 RFC 4033, March 2005. 959 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 960 Network Access Identifier", RFC 4282, December 2005. 962 11.2. Informative References 964 [I-D.ietf-tsvwg-udp-guidelines] 965 Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 966 for Application Designers", 967 draft-ietf-tsvwg-udp-guidelines-11 (work in progress), 968 October 2008. 970 [IEEE80221] 971 "Draft IEEE Standard for Local and Metropolitan Area 972 Networks: Media Independent Handover Services", IEEE LAN/ 973 MAN Draft IEEE P802.21/D13.00, August 2008. 975 [RFC1035] Mockapetris, P., "Domain names - implementation and 976 specification", STD 13, RFC 1035, November 1987. 978 [RFC1122] Braden, R., "Requirements for Internet Hosts - 979 Communication Layers", STD 3, RFC 1122, October 1989. 981 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 982 November 1990. 984 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 985 RFC 2131, March 1997. 987 [RFC2459] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet 988 X.509 Public Key Infrastructure Certificate and CRL 989 Profile", RFC 2459, January 1999. 991 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 992 (IPv6) Specification", RFC 2460, December 1998. 994 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 995 Control", RFC 2581, April 1999. 997 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 998 Timer", RFC 2988, November 2000. 1000 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1001 Address Translator (Traditional NAT)", RFC 3022, 1002 January 2001. 1004 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1005 Security", RFC 4347, April 2006. 1007 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 1008 RFC 4641, September 2006. 1010 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1011 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1012 RFC 4787, January 2007. 1014 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1015 RFC 4960, September 2007. 1017 [RFC5164] Melia, T., "Mobility Services Transport: Problem 1018 Statement", RFC 5164, March 2008. 1020 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1021 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1023 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1024 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1025 RFC 5382, October 2008. 1027 Authors' Addresses 1029 Telemaco Melia (editor) 1030 Alcatel-Lucent 1031 Route de Villejust 1032 Nozay 91620 1033 France 1035 Email: telemaco.melia@alcatel-lucent.com 1037 Gabor Bajko 1038 Nokia 1040 Email: Gabor.Bajko@nokia.com 1042 Subir Das 1043 Telcordia Technologies Inc. 1045 Email: subir@research.telcordia.com 1047 Nada Golmie 1048 NIST 1050 Email: nada.golmie@nist.gov 1052 Juan Carlos Zuniga 1053 InterDigital Communications, LLC 1055 Email: j.c.zuniga@ieee.org 1057 Full Copyright Statement 1059 Copyright (C) The IETF Trust (2008). 1061 This document is subject to the rights, licenses and restrictions 1062 contained in BCP 78, and except as set forth therein, the authors 1063 retain all their rights. 1065 This document and the information contained herein are provided on an 1066 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1067 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1068 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1069 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1070 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1071 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1073 Intellectual Property 1075 The IETF takes no position regarding the validity or scope of any 1076 Intellectual Property Rights or other rights that might be claimed to 1077 pertain to the implementation or use of the technology described in 1078 this document or the extent to which any license under such rights 1079 might or might not be available; nor does it represent that it has 1080 made any independent effort to identify any such rights. Information 1081 on the procedures with respect to rights in RFC documents can be 1082 found in BCP 78 and BCP 79. 1084 Copies of IPR disclosures made to the IETF Secretariat and any 1085 assurances of licenses to be made available, or the result of an 1086 attempt made to obtain a general license or permission for the use of 1087 such proprietary rights by implementers or users of this 1088 specification can be obtained from the IETF on-line IPR repository at 1089 http://www.ietf.org/ipr. 1091 The IETF invites any interested party to bring to its attention any 1092 copyrights, patents or patent applications, or other proprietary 1093 rights that may cover technology that may be required to implement 1094 this standard. Please address the information to the IETF at 1095 ietf-ipr@ietf.org.