idnits 2.17.1 draft-ietf-mipshop-mis-ps-05.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 28. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 806. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 812. 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 doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- 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 12, 2007) is 6008 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-udp-guidelines-03 -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. '5') (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '6') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4423 (ref. '7') (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 4068 (ref. '9') (Obsoleted by RFC 5268) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPSHOP T. Melia 3 Internet-Draft NEC 4 Intended status: Informational E. Hepworth 5 Expires: May 15, 2008 Siemens Roke Manor Research 6 S. Sreemanthula 7 Nokia Research Center 8 Y. Ohba 9 Toshiba 10 G. Vivek 11 Intel 12 J. Korhonen 13 TeliaSonera 14 R. Aguiar 15 IT 16 S. Xia 17 HUAWEI 18 November 12, 2007 20 Mobility Services Transport: Problem Statement 21 draft-ietf-mipshop-mis-ps-05 23 Status of this Memo 25 By submitting this Internet-Draft, each author represents that any 26 applicable patent or other IPR claims of which he or she is aware 27 have been or will be disclosed, and any of which he or she becomes 28 aware will be disclosed, in accordance with Section 6 of BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on May 15, 2008. 48 Copyright Notice 49 Copyright (C) The IETF Trust (2007). 51 Abstract 53 There are on-going activities in the networking community to develop 54 solutions that aid in IP handover mechanisms between heterogeneous 55 wired and wireless access systems including, but not limited to, IEEE 56 802.21. Intelligent access selection, taking into account link layer 57 attributes, requires the delivery of a variety of different 58 information types to the terminal from different sources within the 59 network and vice-versa. The protocol requirements for this 60 signalling have both transport and security issues that must be 61 considered. The signalling must not be constrained to specific link 62 types, so there is at least a common component to the signalling 63 problem which is within the scope of the IETF. This draft presents a 64 problem statement for this core problem. 66 Requirements Language 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in RFC 2119 [2] 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. Definition of Mobility Services . . . . . . . . . . . . . . . 5 77 4. Deployment Scenarios for MoS . . . . . . . . . . . . . . . . . 5 78 4.1. End-to-End Signalling and Transport over IP . . . . . . . 6 79 4.2. End-to-End Signalling and Partial Transport over IP . . . 6 80 4.3. End-to-End Network-to-Network Signalling . . . . . . . . . 7 81 5. MoS Transport Protocol Splitting . . . . . . . . . . . . . . . 7 82 5.1. Payload Formats and Extensibility Considerations . . . . . 8 83 5.2. Requirements on the Mobility Service Transport Layer . . . 9 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 88 10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 10.1. General requirements . . . . . . . . . . . . . . . . . . . 14 90 10.2. IETF transport protocol requirements . . . . . . . . . . . 15 91 10.3. IETF discovery protocol requirements . . . . . . . . . . . 15 92 10.4. IETF security requirements . . . . . . . . . . . . . . . . 16 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 95 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 97 Intellectual Property and Copyright Statements . . . . . . . . . . 20 99 1. Introduction 101 This Internet Draft provides a problem statement for the exchange of 102 information to support handover in heterogeneous link environments 103 [1] . This mobility support service allows more sophisticated 104 handover operations by making available information about network 105 characteristics, neighboring networks and associated characteristics, 106 indications that a handover should take place, and suggestions for 107 suitable target networks to which to handover. The mobility support 108 services are complementary to IP mobility mechanisms [4], [5], [6], 109 [7], [8], [9] to enhance the overall performance and usability 110 perception. 112 There are two key attributes to the handover support service problem 113 for inter-technology handovers: 115 1. The Information: the information elements being exchanged. The 116 messages could be of different nature, such as information, 117 commands to perform an action, or events informing of a change, 118 potentially being defined following a common structure. 120 2. The Underlying Transport: the transport mechanism to support 121 exchange of the information elements mentioned above. This 122 transport mechanism includes information transport, discovery of 123 peers, and the securing of this information over the network. 125 The initial requirement for this protocol comes from the need to 126 provide a transport for the Media Independent Handover (MIH) protocol 127 being defined by IEEE 802.21[1] which is not bound to any specific 128 link layer and can operate over more that one network-layer hop. The 129 solution should be flexible to accommodate evolution in the MIH 130 standard, and should also be applicable for other new mobility 131 signalling protocols which have similar message patterns and 132 discovery and transport requirements. 134 The structure of this document is as follows. Section 3 defines 135 mobility services. Section 4 provides a simple model for the 136 protocol entities involved in the signalling and their possible 137 relationships. Section 5 describes a decomposition of the signalling 138 problem into service specific parts and a generic transport part. 139 Section 5.2 describes more detailed requirements for the transport 140 component. Section 7 provides security considerations, and Section 8 141 summarizes the conclusions and open issues. 143 2. Terminology 145 The following abbreviations are used in the document: 147 MIH: media independent handover 149 MN: mobile node 151 NN: network node, intended to represent some device in the network 152 (the location of the node e.g. in the access network, home network 153 is not specified, and for the moment it is assumed that they can 154 reside anywhere). 156 EP: endpoint, intended to represent the terminating endpoints of 157 the transport protocol used to support the signalling exchanges 158 between nodes. 160 3. Definition of Mobility Services 162 As mentioned in the introduction mobility (handover) support in 163 heterogeneous wireless environments requires functional components 164 located either in the mobile terminal or in the network to exchange 165 information and eventually to take decisions upon this information 166 exchange. For instance traditional host-based handover solutions 167 could be complemented with more sophisticated network-centric 168 solutions. Also, neighborhood discovery, potentially a complex 169 operation in heterogeneous wireless scenarios, can result in a 170 simpler step if implemented with an unified interface towards the 171 access network. 173 In this document the different supporting functions for media 174 independent handover (MIH) management are generally referred as 175 Mobility Services (MoS) having different requirements for the 176 transport protocol. These requirements and associated 177 functionalities are the focus of this document. Speaking 802.21 178 terminology MoS can be regarded as Infomation Services (IS), Event 179 Services (ES), Command Service (CS). 181 4. Deployment Scenarios for MoS 183 The deployment scenarios are outlined in the following sections. 184 Note: while MN-to-MN signalling exchanges are theoretically possible, 185 these are not currently being considered. 187 The following scenarios are discussed for understanding the overall 188 problem of transporting MIH protocol. Although these are all 189 possible scenarios and MIH services can be delivered through link- 190 layer specific solutions and/or through a "layer 3 or above" 191 protocol, this problem statement focuses on the delivery of 192 information for mobility services for the latter case only. 194 4.1. End-to-End Signalling and Transport over IP 196 In this case, the end-to-end signalling used to exchange the handover 197 information elements (the Information Exchange) runs end-to-end 198 between MN and NN. The underlying transport is also end-to-end 200 +------+ +------+ 201 | MN | | NN | 202 | (EP) | | (EP) | 203 +------+ +------+ 204 Information Exchange 205 <------------------------------------> 207 /------------------------------------\ 208 < Transport over IP > 209 \------------------------------------/ 211 Figure 1: End-to-end Signalling and Transport 213 4.2. End-to-End Signalling and Partial Transport over IP 215 As before, the Information Exchange runs end-to-end between the MN 216 and the second NN. However, in this scenario, some other transport 217 means than IP is used from the MN to the first NN, and the transport 218 over IP is used only between NNs. This is analogous to the use of 219 EAP end-to-end between Supplicant and Authentication Server, with an 220 upper-layer multihop protocol such as RADIUS used as a backhaul 221 transport protocol between an Access Point and the Authentication 222 Server. 224 +------+ +------+ +------+ 225 | MN | | NN | | NN | 226 | | | (EP) | | (EP) | 227 +------+ +------+ +------+ 228 Information Exchange 229 <------------------------------------> 231 (Transport over /------------------\ 232 <--------------->< Transport over IP > 233 e.g. L2) \------------------/ 235 Figure 2: Partial Transport 237 4.3. End-to-End Network-to-Network Signalling 239 In this case NN to NN signalling is envisioned. Such model should 240 allow different network components to gather information from each 241 other. This is useful for instance in conditions where network 242 components need to take decisions and instruct mobile terminals of 243 operation to be executed. 245 +------+ +------+ 246 | NN | | NN | 247 | (EP) | | (EP) | 248 +------+ +------+ 249 Information Exchange 250 -------------------> 251 <------------------- 253 /----------------\ 254 < Transport > 255 \----------------/ 257 Figure 3: Information Exchange between different NN 259 Network nodes exchange information about connected terminals status. 261 5. MoS Transport Protocol Splitting 263 Figure 4 shows a model where the Information Exchanges are 264 implemented by a signalling protocol specific to a particular 265 mobility service, and these are relayed over a generic transport 266 layer (the Mobility Service Transport Layer). 268 +----------------+ ^ 269 |Mobility Support| | 270 | Service 2 | | 271 +----------------+ | | | Mobility Service 272 |Mobility Support| +----------------+ | Signaling 273 | Service 1 | +----------------+ | Layer 274 | | |Mobility Support| | 275 +----------------+ | Service 3 | | 276 | | | 277 +----------------+ V 278 ================================================ 279 +---------------------------------------+ ^ Mobility Service 280 | Mobility Service Transport Protocol | | Transport 281 +---------------------------------------+ V Layer 282 ================================================ 283 +---------------------------------------+ 284 | IP | 285 +---------------------------------------+ 287 Figure 4: Handover Services over IP 289 The Mobility Service Transport Layer provides certain functionality 290 (outlined in Section 5.2) to the higher layer mobility support 291 services in order to support the exchange of information between 292 communicating mobility service functions. The transport layer 293 effectively provides a container capability to mobility support 294 services, as well as any required transport and security operations 295 required to provide communication without regard to the protocol 296 semantics and data carried in the specific mobility services. 298 The Mobility Support Services themselves may also define certain 299 protocol exchanges to support the exchange of service specific 300 Information Elements. It is likely that the responsibility for 301 defining the contents and significance of the Information Elements is 302 the responsibility of other standards bodies other than the IETF. 303 Example mobility services include the Information Services, Event and 304 Command services. 306 5.1. Payload Formats and Extensibility Considerations 307 The format of the Mobility Service Transport Protocol (MSTP) is as 308 follows: 310 +----------------+----------------------------------------+ 311 |Mobility Service| Opaque Payload | 312 |Transport Header| (Mobility Support Service) | 313 +----------------+----------------------------------------+ 314 This figure shows the case for a MIH message smaller than the MTU of 315 the path to the destination. A larger payload may require the 316 transport protocol to transparently fragment and reassemble the MIH 317 message. 319 Figure 5: Protocol Structure 321 The opaque payload encompasses the Mobility Support Service (MSTP) 322 information that is to be transported. The definition of the 323 Mobility Service Transport Header is something that is best addressed 324 within the IETF. MSTP does not inspect the payload and any required 325 information will be provided by the MSTP users. 327 5.2. Requirements on the Mobility Service Transport Layer 329 The following section outlines some of the general transport 330 requirements that should be supported by the Mobility Service 331 Transport Protocol. Analysis has suggested that at least the 332 following need to be taken into account: 334 Discovery: MNs need the ability to either discover nodes that 335 support certain services, or discover services provided by a 336 certain node. The service discovery can be dealt with messages as 337 defined in [1]. This section refers to node-discovery in either 338 scenario. There are no assumptions about the location of these 339 mobility services node within the network, therefore the discovery 340 mechanism needs to operate across administrative boundaries. 341 Issues such as speed of discovery, protection against spoofing, 342 when discovery needs to take place, and the length of time over 343 which the discovery information may remain valid all need to be 344 considered. Approaches include: 346 * Hard coding information into the MN, indicating either the IP 347 address of the NN, or information about the NN that can be 348 resolved onto an IP address. The configuration information 349 could be managed dynamically, but assumes that the NN is 350 independent of the access network to which the MN is currently 351 attached. 353 * Pushing information to the MN, where the information is 354 delivered to the MN as part of other configuration operations, 355 for example, via DHCP or Router Discovery exchange. The 356 benefit of this approach is that no additional exchanges with 357 the network would be required, but the limitations associated 358 with modifying these protocols may limit applicability of the 359 solution. 361 * MN dynamically requesting information about a node, which may 362 require both MN and NN support for a particular service 363 discovery mechanism. This may require additional support by 364 the access network (e.g. multicast or anycast) even when it may 365 not be supporting the service directly itself. 367 Numerous directory and configuration services already exist, and 368 reuse of these mechanisms may be appropriate. There is an open 369 question about whether multiple methods of discovery would be 370 needed, and whether NNs would also need to discover other NNs. 371 The definition of a service also needs to be determined, including 372 the granularity of the description. For example IEEE 802.21 373 specifies three different type of Mobility services (Information 374 Services, Command Services and Event Services) that can be located 375 in different portion of the network. A MN could therefore run a 376 discovery procedure of any service running in the (home or 377 visited) network or could run a discovery procedure for a specific 378 service. 380 Information from a trusted source: The MN uses the Mobility Service 381 information to make decisions about what steps to take next. It 382 is essential that there is some way to ensure that the information 383 received is from a trustworthy source. This requirement should 384 reuse trust relationships that have already been established in 385 the network, for example, on the relationships established by the 386 AAA infrastructure after a mutual authentication, or on the 387 certificate infrastructure required to support SEND [10]. 388 Section 7 provides a more complete analysis. 390 Security association management: A common security association 391 negotiation method, independent of any specific MSTP user, should 392 be implemented. The solution must also work in case on MN 393 mobility. 395 Secure delivery: The Mobility Service information must be delivered 396 securely (integrity and confidentiality) between trusted peers, 397 where the transport may pass though untrusted intermediate nodes 398 and networks. The Mobility Service information should also be 399 protected against replay attacks and denial of service attacks. 401 Low latency: Some of the Mobility Services generate time sensitive 402 information. Therefore, there is a need to deliver the 403 information over quite short timescales, and the required lifetime 404 of a connection might be quite short lived. (As an example, the 405 frequency of messages defined in [1] varies according to the MIH 406 service type. It is expected that Events and Commands messages 407 arrive at a rate of hundreds of milliseconds in order to capture 408 quick changes in the environment and/ or process handover 409 commands. On the other hand, Information service messages are 410 mainly exchanged each time a new network is visited which may be 411 in the order of hours or days). For reliable delivery, short- 412 lived connections could be set up as and when needed, although 413 there is a connection setup latency associated with this approach. 414 Alternatively, a long-lived connection could be used, but this 415 requires advanced warning of being needed and some way to maintain 416 the state associated with the connection. It also assumes that 417 the relationships between devices supporting the mobility service 418 are fairly stable. Another alternative is connectionless 419 operation, but this has interactions with other requirements such 420 as reliable delivery. 422 Reliability: Reliable delivery for some of the mobility services may 423 be essential, but it is difficult to trade this off against the 424 low latency requirement. It is also quite difficult to design a 425 robust, high performance mechanism that can operate in 426 heterogeneous environments, especially one where the link 427 characteristics can vary quite dramatically. There are two main 428 approaches that could be adopted: 430 1. Assume the transport cannot be guaranteed to support reliable 431 delivery. In this case, the Mobility Support Service itself 432 will have to provide a reliability mechanism (at MIH level) to 433 allow communicating endpoints to acknowledge receipt of 434 information. 436 2. Assume the underlying transport will provide reliable 437 delivery. There is no need in this case to provide 438 reliability at MIH level. 440 Guidelines provided in [3] are being considered while writing this 441 document. 443 Congestion Control: A Mobility Service may wish to transfer small or 444 large amounts of data, placing different requirements for 445 congestion control in the transport. (As an example, MIH message 446 [1] size varies widely from about 30 bytes (for a broadcast 447 capability discovery request) to around 65000 bytes (for an IS 448 MIH_Get_Information response primitive). A typical MIH message 449 size for the Events and Commands services service ranges between 450 50 to 100 bytes). The solution should consider different 451 congestion control mechanisms depending on the amount of data 452 generated by the application (MIH) as suggested in [3]. 454 Fragmentation and reassembly: ES and CS messages are small in 455 nature, are sent frequently, and may wish trade reliability in 456 order to satisfy the tight latency requirements. On the other 457 hand, IS messages are more resilient in terms of latency 458 constraints and some long IS messages could exceed the MTU of the 459 path to the destination. Depending on the choice of the transport 460 protocol different fragmentation and reassembly strategies are 461 required. 463 Multihoming: For some information services exchanged with the MN, 464 there is a possibility that the request and response messages can 465 be carried over two different links e.g. a handover command 466 request is on the current link while the response could be 467 delivered on the new link. It is expected that the transport 468 protocol is capable of receiving information via multiple links 469 and the MSTP user to combine information belonging to the same 470 session/transaction. When mobility is applied the undelaying IP 471 mobility mechanism should provide session continuty when required. 473 IPv4 and IPv6 support: The MSTP must support both IPv4 and IPv6 474 including NAT traversal for IPv4 networks and firewall pass- 475 through for IPv4 and IPv6 networks. 477 6. IANA Considerations 479 This document makes no request of IANA. 481 7. Security Considerations 483 Network supported mobility services aim at improving decision making 484 and management of dynamically connected hosts. 486 Information Services may not require authorization of the client, but 487 both event and command services may authenticate message sources, 488 particularly if they are mobile. Network side service entities will 489 typically need to provide proof of authority to serve visiting 490 devices. Where signalling or radio operations can result from 491 received messages, significant disruption may result from processing 492 bogus or modified messages. The effect of processing bogus messages 493 depends largely upon the content of the message payload, which is 494 handled by the handover services application. Regardless of the 495 variation in effect, message delivery mechanisms need to provide 496 protection against tampering, spoofing, replay attacks (see 497 (Section 10)). 499 Sensitive and identifying information about a mobile device may be 500 exchanged during handover service message exchange. Since handover 501 decisions are to be made based upon message exchanges, it may be 502 possible to trace an user's movement between cells, or predict future 503 movements, by inspecting handover service messages. In order to 504 prevent such tracking, message confidentiality and message integrity 505 should be available. This is particularly important since many 506 mobile devices are associated with only one user, since divulging of 507 such information may violate the user's privacy. Additionally, 508 identifying information may be exchanged during security association 509 construction. As this information may be used to trace users across 510 cell boundaries, identity protection should be available if possible, 511 when establishing SAs. 513 In addition, the user should not have to disclose its identity to the 514 network (any more than it needed to during authentication) in order 515 to access the Mobility Support Services. For example, if the local 516 network is just aware that an anonymous user with a subscription to 517 "example.com" is accessing the network, the user should not have to 518 divulge their true identity in order to access the Mobility Support 519 Services available locally. 521 Finally, the network nodes themselves will potentially be subject to 522 denial of service attacks from MNs and these problems will be 523 exacerbated if operation of the mobility service protocols imposes a 524 heavy computational load on the NNs. The overall design has to 525 consider at what stage (e.g. discovery, transport layer 526 establishment, service specific protocol exchange) denial of service 527 prevention or mitigation should be built in. 529 8. Conclusions 531 This Internet draft outlined a broad problem statement for the 532 signalling of information elements across a network to support 533 mobility services. In order to enable this type of signalling 534 service, a need for a generic transport solution with certain 535 transport and security properties were outlined. Whilst the 536 motivation for considering this problem has come from work within 537 IEEE 802.21, a desirable goal is to ensure that solutions to this 538 problem are applicable to a wider range of mobility services. 540 It would be valuable to establish realistic performance goals for the 541 solution to this common problem (i.e. transport and security aspects) 542 using experience from previous IETF work in this area and knowledge 543 about feasible deployment scenarios. This information could then be 544 used as an input to other standards bodies in assisting them to 545 design mobility services with feasible performance requirements. 547 Much of the functionality required for this problem is available from 548 existing IETF protocols or combination thereof. This document takes 549 no position on whether an existing protocol can be adapted for the 550 solution or whether new protocol development is required. In either 551 case, we believe that the appropriate skills for development of 552 protocols in this area lie in the IETF. 554 9. Acknowledgements 556 Thanks to Subir Das, Juan Carlos Zuniga, Robert Hancock and Yoshihiro 557 Ohba for their inputs. Thanks to the IEEE 802.21 chair Vivek Gupta 558 for coordinating the work and supporting the IETF liaison. Thanks to 559 all IEEE 802.21 WG folks who indirectly contributed to this document. 561 10. Appendix 563 The following list of requirements is an informative section of the 564 IEEE 802.21 draft standard [1] "Requirements to support 802.21 by L3 565 and above transport". 567 10.1. General requirements 569 The following set of requirements is applicable generically to any L3 570 or above transport protocol: 572 o GR1.The transport mechanism shall provide means for communications 573 between a sending MIH Protocol Entity and a receiving MIH Protocol 574 Entity regardless of their network location, e.g., on the same 575 subnet, or deep in the network belonging to the same or a 576 different network administrative domain. 578 o GR2.The transport mechanism shall be capable of delivering time- 579 sensitive information. 581 o GR3.The transport mechanism shall allow the use of effective 582 security for MIH Protocol exchanges, including: 584 * mutual authentication between the communicating nodes; 586 * message authentication; 587 * message integrity; 589 * message confidentiality 591 o GR4.The transport mechanism framework shall allow the use of 592 discovery protocols as part of the L3 and above solution. 594 10.2. IETF transport protocol requirements 596 The following set of requirements is applicable specifically to IETF 597 transport protocol: 599 o TR1.The transport protocol shall work regardless of the network 600 location of the MIH Protocol Entity e.g. on the same subnet, or 601 deep in the network belonging to same or different IP 602 administrative domain. 604 o TR2.The transport protocol shall be capable to support both IPv4 605 and IPv6 versions. 607 o TR3.The transport protocol shall be capable of delivering time- 608 sensitive MIH information. 610 o TR4.The transport protocol shall enable Network address 611 Translation (NAT) traversal for IPv4 networks. 613 o TR5.The transport protocol shall enable firewall pass-through for 614 IPv4 and IPv6 networks. 616 10.3. IETF discovery protocol requirements 618 The following set of requirements is applicable specifically to IETF 619 discovery protocol: 621 o DR1.The discovery protocol shall work regardless of the network 622 location of the MIH Protocol Entity e.g. on the same subnet, or 623 deep in the network belonging to same or different IP 624 administrative domain. 626 o DR2.The discovery protocol shall work for IPv4 and IPv6 hosts. 628 o DR3.The discovery protocol shall allow for more than one MIH 629 Protocol Entity to be discovered at a time. 631 o DR4.The discovery protocol shall enable Network Address Translator 632 (NAT) traversal for IPv4 networks. 634 o DR5.The discovery protocol shall enable Firewall pass-through for 635 IPv4 and IPv6 networks. 637 10.4. IETF security requirements 639 o SR1.The security mechanism shall provide a common security 640 association (SA) negotiation method regardless of the network 641 location of the MIH Protocol Entity e.g. on the same subnet, or 642 deep within the network. 644 o SR2.The security mechanism shall provide mutual authentication of 645 MIH end nodes. 647 o SR3.The security mechanism may provide one way authentication of 648 either of MIH end nodes. 650 o SR4.The security mechanism shall provide integrity protection for 651 MIH Protocol exchanges. 653 o SR5.The security mechanism may provide confidentiality for the MIH 654 Protocol exchanges. 656 o SR6.The security mechanism shall protect against replay attacks. 658 o SR7.The security mechanism may protect MIH service entities and 659 discovery resources against denial of service attacks. 661 o SR8.The security mechanism shall not be dependent on the MIH 662 protocol. 664 o SR9.The security mechanism may provide means to reuse or fast 665 reestablishment the SA due to host mobility. 667 11. References 669 11.1. Normative References 671 [1] "Draft IEEE Standard for Local and Metropolitan Area Networks: 672 Media Independent Handover Services", IEEE LAN/MAN Draft IEEE 673 P802.21/D07.00, July 2007. 675 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 676 Levels", RFC 2119, March 2007. 678 11.2. Informative References 680 [3] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for 681 Application Designers", draft-ietf-tsvwg-udp-guidelines-03 682 (work in progress), September 2007. 684 [4] 3GPP, "3GPP system architecture evolution (SAE): Report on 685 technical options and conclusions", 3GPP TR 23.882 0.10.1, 686 February 2006. 688 [5] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 689 August 2002. 691 [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 692 IPv6", RFC 3775, June 2004. 694 [7] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) 695 Architecture", RFC 4423, May 2006. 697 [8] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", 698 RFC 4555, June 2006. 700 [9] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 701 July 2005. 703 [10] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 704 Neighbor Discovery (SEND)", RFC 3971, March 2005. 706 Authors' Addresses 708 Telemaco Melia 709 NEC Europe Network Laboratories 710 Kufuerstenanlage 36 711 Heidelberg 69115 712 Germany 714 Phone: +49 6221 90511 42 715 Email: telemaco.melia@netlab.nec.de 716 Eleanor Hepworth 717 Siemens Roke Manor Research 718 Roke Manor 719 Romsey, SO51 5RE 720 UK 722 Email: eleanor.hepworth@roke.co.uk 724 Srivinas Sreemanthula 725 Nokia Research Center 726 6000 Connection Dr. 727 Irving, TX 75028 728 USA 730 Email: srinivas.sreemanthula@nokia.com 732 Yoshihiro Ohba 733 Toshiba America Research, Inc. 734 1 Telcordia Drive 735 Piscateway NJ 08854 736 USA 738 Email: yohba@tari.toshiba.com 740 Vivek Gupta 741 Intel Corporation 742 2111 NE 25th Avenue 743 Hillsboro, OR 97124 744 USA 746 Phone: +1 503 712 1754 747 Email: vivek.g.gupta@intel.com 749 Jouni Korhonen 750 TeliaSonera Corporation. 751 P.O.Box 970 752 FIN-00051 Sonera 753 FINLAND 755 Phone: +358 40 534 4455 756 Email: jouni.korhonen@teliasonera.com 757 Rui L.A. Aguiar 758 Instituto de Telecomunicacoes Universidade de Aveiro 759 Aveiro 3810 760 Portugal 762 Phone: +351 234 377900 763 Email: ruilaa@det.ua.pt 765 Sam(Zhongqi) Xia 766 Huawei Technologies Co.,Ltd 767 HuaWei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base 768 100085 769 Hai-Dian District Beijing, P.R. China 771 Phone: +86-10-82836136 772 Email: xiazhongqi@huawei.com 774 Full Copyright Statement 776 Copyright (C) The IETF Trust (2007). 778 This document is subject to the rights, licenses and restrictions 779 contained in BCP 78, and except as set forth therein, the authors 780 retain all their rights. 782 This document and the information contained herein are provided on an 783 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 784 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 785 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 786 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 787 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 788 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 790 Intellectual Property 792 The IETF takes no position regarding the validity or scope of any 793 Intellectual Property Rights or other rights that might be claimed to 794 pertain to the implementation or use of the technology described in 795 this document or the extent to which any license under such rights 796 might or might not be available; nor does it represent that it has 797 made any independent effort to identify any such rights. Information 798 on the procedures with respect to rights in RFC documents can be 799 found in BCP 78 and BCP 79. 801 Copies of IPR disclosures made to the IETF Secretariat and any 802 assurances of licenses to be made available, or the result of an 803 attempt made to obtain a general license or permission for the use of 804 such proprietary rights by implementers or users of this 805 specification can be obtained from the IETF on-line IPR repository at 806 http://www.ietf.org/ipr. 808 The IETF invites any interested party to bring to its attention any 809 copyrights, patents or patent applications, or other proprietary 810 rights that may cover technology that may be required to implement 811 this standard. Please address the information to the IETF at 812 ietf-ipr@ietf.org. 814 Acknowledgment 816 Funding for the RFC Editor function is provided by the IETF 817 Administrative Support Activity (IASA).