idnits 2.17.1 draft-faccin-mih-infoserv-02.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 on line 931. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 908. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 915. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 921. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 6 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (March 06, 2006) is 6625 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) == Unused Reference: '17' is defined on line 809, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 829, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 836, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 843, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 847, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-02) exists of draft-hepworth-mipshop-mih-problem-statement-01 -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '3') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2001 (ref. '4') (Obsoleted by RFC 2581) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '6') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. '7') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '8') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '9') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '10') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2581 (ref. '11') (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 2582 (ref. '12') (Obsoleted by RFC 3782) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '16') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. '17') (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3377 (ref. '18') (Obsoleted by RFC 4510) -- Obsolete informational reference (is this intentional?): RFC 3736 (ref. '19') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '20') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4068 (ref. '22') (Obsoleted by RFC 5268) == Outdated reference: A later version (-06) exists of draft-ietf-dna-link-information-02 == Outdated reference: A later version (-08) exists of draft-ietf-mobike-design-01 == Outdated reference: A later version (-05) exists of draft-rescorla-dtls-02 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Sreemanthula (Ed.) 3 Internet-Draft Nokia 4 Expires: September 7, 2006 G. Daley 5 Panasonic 6 S. Faccin 7 Nokia 8 E. Hepworth 9 Siemens/Roke Manor Research 10 S. Das 11 Telcordia 12 March 06, 2006 14 Requirements for a Handover Information Service 15 draft-faccin-mih-infoserv-02.txt 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 September 7, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 Handover Information Services may be used to assist handovers between 49 one network to another network or within a network, based on stored 50 network knowledge. Information Services can be used to provide 51 essential network related information e.g. topology and channel 52 information which may allow a moving host to select an appropriate 53 link-layer connection to make, amongst available networks, whether 54 using the same technology or heterogeneous technologies. 56 This document is an effort to describe use cases and transport 57 requirements for handover information services, when they are 58 transported over IP networks. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Information Services . . . . . . . . . . . . . . . . . . . 3 64 1.2. Scope of work on information services . . . . . . . . . . 3 65 2. 802.21 Media Independent Information Services . . . . . . . . 4 66 3. Information Service Reference Model . . . . . . . . . . . . . 4 67 4. Scenarios for IS Transported over IP . . . . . . . . . . . . . 5 68 5. Protocol Development Scope . . . . . . . . . . . . . . . . . . 8 69 5.1. Information Service Interfaces . . . . . . . . . . . . . . 9 70 5.2. Message Exchanges . . . . . . . . . . . . . . . . . . . . 10 71 5.3. Information Service Discovery . . . . . . . . . . . . . . 11 72 5.4. Transport-Layer Issues . . . . . . . . . . . . . . . . . . 12 73 5.5. Security Association Negotiation . . . . . . . . . . . . . 13 74 6. Requirements for Transport over IP . . . . . . . . . . . . . . 13 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 7.1. Attacks against service entities . . . . . . . . . . . . . 15 77 7.2. Attacks against information . . . . . . . . . . . . . . . 16 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 83 Intellectual Property and Copyright Statements . . . . . . . . . . 22 85 1. Introduction 87 Handover services are a class of network services, which aim to 88 assist the quality of handovers available to wireless devices. In 89 order to support more intelligent handover services it is often 90 necessary to be able to exchange information between mobile and fixed 91 nodes within the network. A comprehensive description of the problem 92 related to this aspect can be found in [2]. 94 Information Services (IS) are one part of handover services used to 95 provide network related information about the current or neighboring 96 networks with same or different access link technology. This allows 97 the network or host to make informed decisions of which network to 98 handover to or handover operations to undertake either in response to 99 certain events, or when planning controlled or commanded handovers. 100 The Information Services work complementary to the mobility 101 management protocols in the capacity that they are utilized before 102 making decisions for handovers. 104 While the IETF is primarily interested in how handover services can 105 be used to assist mobility signaling protocols, and interactions 106 between handover services and network/transport layers, other groups 107 have been taking a more generally applicable view (see Section 2). 109 1.1. Information Services 111 Information Services are considered to be an important component of 112 handover services, for providing local network information to 113 wireless devices in a non-real-time fashion [1]. 115 Information services provide additional information about the 116 environment a mobile device is operating in. These services 117 typically require one or more servers within a set of access 118 networks, which distribute knowledge that can assist hosts performing 119 handovers between cells. 121 Information provided varies dependent on the purpose and operation of 122 the information service, but may consist of: wireless channel state, 123 adjacent base-station channel occupation, neighboring network 124 information or upper-layer mobility service information. While each 125 of these is possible, it is important to note that information 126 services described in this document have a restricted scope described 127 below in Section 1.2. This scope is limited in order to achieve 128 timely outcomes for document development and standardization. 130 1.2. Scope of work on information services 132 The development of information services covered in this document 133 assume a set of models compatible with IEEE 802.21's descriptions of 134 a Handover Information Service,as described in Section 2. In this 135 context, a system would need to provide discovery, security 136 association bootstrap and transport of information services over IP, 137 in a variety of deployment scenarios. These scenarios are described 138 in Section 4. The extent of protocol development work to be 139 undertaken is elaborated on in Section 5. 141 Initial specification of use cases will focus on delivery services 142 required by the existing client (802.21), in the hope that the scheme 143 is general enough to be of use in the other cases [1]. 145 2. 802.21 Media Independent Information Services 147 IEEE is currently working on Information Services as part of 802.21 148 Media Independent Handover Services (MIHS). 150 Amongst media independent handover services, information services are 151 most readily deployed over IP [1]. In the 802.21 case, link-layer 152 oriented information would then be distributed over IP and upper- 153 layer protocols. 155 For these information services, it is possible that network 156 information may be either centrally stored on a server or distributed 157 in each individual access network. Presumably, an L2 or L3 based 158 mechanism to identify or discover a valid information server would be 159 required. Such scenarios are described in more detail in Section 4. 161 In order to accomplish this, it will be necessary to describe IS 162 discovery and specify transport services over IP. Interactions with 163 IP in delivering handover services over IP therefore need 164 consideration in the IETF, both for use with 802.21 and for other 165 instances of handover services [22]. 167 3. Information Service Reference Model 169 Entities involved with handover information services perform the 170 roles of an Information Services client (IS client), Information 171 Services Proxy and an Information Services server (IS-Server). 172 Relative positions of client and server, and the interfaces between 173 them may produce different requirements, depending on the type of 174 communication. Essentially, they fall under the category of i) user 175 to network communications (UNC) or ii) network to network 176 communications (NNC). 178 Figure 1 presents a reference model for both for single and mutihop 179 communication of Information Services. The reference model shows 180 both client-server, client-proxy-server and client-server-server 181 models. The IS-Proxy role is to forward or route the IS 182 communications to the intended destination IS-Server. IS-Server 183 terminated IS communications, however it may initiate a new IS 184 communications with another IS-Server. It is possible that IS-Proxy 185 may present server-server communication path. The IS-Proxy and the 186 IS-Server may reside either within its administrative domain, or in 187 another domain. 189 ------------ ----------- 190 | IS-client|<-------|------>|IS-Server| 191 ------------ UNC ----------- 193 ------------ ----------- ----------- 194 | IS-Client|<-------|------>|IS-Proxy | <-----|------> | IS-Server| 195 ------------ UNC ----------- NNC ----------- 197 ------------ ----------- ----------- 198 | IS-Client|<-------|------>|IS-Server| <-----|------> | IS-Server| 199 ------------ UNC ----------- NNC ----------- 201 Figure 1: Information Services Reference Model and Interfaces 203 In order to support the above models, an Information Service system 204 would need to provide more services than just a transport functions 205 such as, discovery of proxy and Information servers, security 206 association between client-server, client-proxy-server, proxy-server 207 and server-server in a variety of deployment scenarios. 209 4. Scenarios for IS Transported over IP 211 In the general case, Information Services delivery over IP may be 212 applicable to more than just media independent handovers. What is 213 likely to be held in common are deployment scenarios, which detail 214 particular challenges dealt with by the information service, and the 215 consequent requirements from these services. 217 The models described above for information services allow deployment 218 of IS Information Servers anywhere within the visited network domain. 219 In this section example scenarios are described indicating where 220 information services are likely to be deployed. Descriptions of 221 particular characteristics of these deployments are made, especially 222 where the deployments place requirements on any information service 223 transportation deployed over IP. 225 In each of the diagrams (Figure 2 and Figure 3) below, a mobile 226 device is currently connected to a particular wireless cell, serviced 227 by an Access Point. In order to gain information about other 228 wireless cells in the vicinity, it contacts an information server 229 within the fixed network. 231 If IP is used for information services transport, for example, in 232 (Figure 2), the server is co-located in the router. There the router 233 has access to the upper layer information required to assist 234 handovers [1][22]. 236 While information services delivery in this scenario is partly 237 addressed by experimental information services in CARD and FMIPv6, 238 the authors consider a fresh look at these issues are warranted, 239 particularly to establish the applicability of security association 240 establishment mechanisms in these and other environments [21][22]. 242 /--------\ 243 I / \ 244 ----- -------- -------- /----/ \----\ 245 |[ ]| | |--+--| ---- |---/ \ 246 |ooo|<----------------------->|IS| | / \ 247 |ooo| | | | | ---- | \ / 248 ----- -------- | -------- \ / 249 Host Access | Router \----\ /----/ 250 Point | \ / 251 | -------- / \--------/ 252 +--| ---- | / Distribution 253 | |IS| |-------/ Network 254 | ---- | 255 -------- 256 Router 258 Figure 2: IS-Server on Subnet Router 260 Information service servers deployed outside the mobile node's subnet 261 present both advantages and challenges. As illustrated in Figure 3, 262 an IS-Server outside a subnet doesn't require explicit support from 263 devices the mobile's link. Therefore the server is able to be 264 deployed in networks which are not able to be modified easily. 265 Additionally, the server is in a position to serve many access 266 subnets simultaneously, which reduces administrative overheads. 268 Conversely, network support for discovering the IS-Server becomes 269 critically important. Since a mobile device may roam within a domain 270 though, it may not be necessary to discover the server each time it 271 changes subnet, so long as the mobile remains in the set of networks 272 covered by the server. Discovery mechanisms are covered in more 273 detail in Section 5.3. 275 Additionally, the location of information services addressable 276 outside the subnet has security implications which are described in 277 Section 7. 279 /--------\ 280 I / \ 281 ----- -------- -------- /----/ -------- \----\ 282 |[ ]| | |-----| |---/ | ---- | \ 283 |ooo|<----------------------------------------->| |IS| | \ 284 |ooo| | | | | \ | ---- | / 285 ----- -------- -------- \ -------- / 286 Host Access Router \----\ Information/----/ 287 Point \ Server / 288 -------- -------- / \--------/ 289 | |-----| | / Distribution 290 | | | |-------/ Network 291 | | | | 292 -------- -------- 293 Access Router 294 Point 296 Figure 3: Standalone IS-Server 298 As described in [1], information services may potentially retrieve 299 different types of data from different sources. Where this data is 300 also used for different purposes within the recipient host, it may be 301 useful to segregate the discovery and operation of information 302 services for different classes of data onto separate servers. 304 At discovery time, the discovery operation could then respond with 305 service advertisements describing which services are provided on 306 which servers, potentially indicating that one information class is 307 available on one server and one on another. 309 While this scenario is not explicitly supported in 802.21, where 310 service discovery is provided over IP networks, it is feasible to 311 request/identify if an information server has a particular service. 312 The scenario is illustrated below: 314 /--------\ 315 I -------- / -------- \ 316 ----- | | /----/ | ---- | \----\ 317 |[ ]|<------------------------------------------->|IS| | \ 318 |ooo| | ---- | / | ---- | \ 319 |ooo|<----------------------|>|IS| |--\ | | / 320 ----- | ---- | \ -------- / 321 Host -------- \----\ Network /----/ 322 Router \ Server / 323 / \--------/ 324 -------- / Distribution 325 | | / Network 326 |Router|------/ 327 | | 328 -------- 330 Figure 4: Separation of Information Content Option 332 In Figure 4, separate information classes are shown on the different 333 servers. Discovery of services may indicate that a current SA and 334 communication channel to the IS may be reused (for example to the 335 central server), while link or access-specific information services 336 would be accessed for local information services. 338 This is to be contrasted with the previous unified information 339 services deployment model from deploying the information server at 340 one of the particular locations in or Figure 3. If information 341 services are deployed in multiple servers, it may require additional 342 operations to discover all required services. Also, it could lead to 343 additional signalling and computation expenses in bootstrapping 344 security associations for each communication. 346 As development of information services over IP proceeds, it may be 347 valuable to deploy the same discovery and security association 348 bootstrap mechanisms for subsequent non-link-layer oriented services. 349 In this case, the discovery mechanism would need to be flexible 350 enough to accommodate additional information services, or 351 combinations of services. 353 5. Protocol Development Scope 355 This section describes the areas requiring investigation or 356 standardization to provide transport of information services over IP. 358 5.1. Information Service Interfaces 360 Entities involved with handover information services perform the 361 roles of an Information Services client (IS client) or an Information 362 Services server (IS-Server). Relative positions of client and 363 server, and the interfaces between them produce different 364 requirements, depending on the type of communication. 366 Illustrated in Figure 5, are a number of devices participating in 367 information services exchanges. On the left-hand side of the figure, 368 a mobile IS client contacts an IS-Server in a network device. If 369 this server requires additional information, it may contact another 370 IS-Server by becoming a client itself. This new IS-Server may reside 371 either within its administrative domain, or in another domain. 373 --------- ----------- ----------- 374 | | |IS-Proxy/| | | 375 |mobile |-------->|IS-Server|-------->|IS-Server| 376 --------- ----------- ----------- 377 | 378 domain A | 379 - - - - - - - - - - - -|- - - - - - - - - - - - - 380 domain B | 381 V 382 ----------- ----------- 383 |IS-Proxy/| | | 384 |IS-Server|-------->|IS-Server| 385 ----------- ----------- 387 Figure 5: Relationships between Information Service entities 389 The mobile to IS-Proxy/IS-Server (UNI) interface is the primary 390 interface requiring standardization by IETF. Initially, an 391 information server must be discovered, as the mobile device will not 392 be preconfigured with the server identity. Subsequently, secured 393 communications are established. This security association may allow 394 the mobile to be anonymous, but in some environments, mobile device 395 authentication may be used to prevent resource exhaustion attacks. 396 In any case, message authentication needs to be provided. 398 To ensure the validity of data, the IS-Server itself needs to 399 authenticate itself to the mobile. This proves that it is the origin 400 of the messages, and prevents man-in-the-middle attacks. 402 After security association establishment, information requests and 403 responses are exchanged. 405 The IS-Proxy to IS-Server or the IS-Server to IS-Server (NNI) 406 interface is required if information servers need to retrieve 407 additional information from each other. For this interface, message 408 formats are the same as the UNI interface. The lifetime of the 409 security association may change though, especially in environments 410 where servers each act as a requester and a responder. If this is 411 the case, mutual authentication is required between the servers. 412 Discovery is considered to be out-of-scope, as in many networks, this 413 will be under the control of other network management systems. 415 5.2. Message Exchanges 417 On the mobile/IS-Server interface a series of steps are required 418 before information is able to be delivered back to the mobile node. 419 In Figure 6, the steps are illustrated. The mobile device is 420 involved in all exchanges, although dependent on the discovery scheme 421 developed for Information Services, it may contact a separate 422 directory service in order to locate the IS-Server's address. The 423 figure is shown only as an illustration and not all steps may be 424 required for handover information queries. 426 / \ ----------- 427 | 1) IS-Server Discovery | |Directory| 428 | ----------------------> \ | or | 429 | 2) IS-Server Address / | Group | 430 | <---------------------- | ----------- 431 -------------- | / 432 | Mobile | | 433 |Information | / 434 | Service | \ 3) IS-Server Contact \ 435 | Client | | ----------------------------> | 436 -------------- | 4) Build Security Associations | ------------- 437 | <============================> \ |Information| 438 | 5) Information Request / | Service | 439 | -----------------------------> | | Server | 440 | 6) Information Response | ------------- 441 \ <----------------------------- / 443 Figure 6: Message exchanges required for Information Service 444 Operation 446 1. IS-Server Discovery - A message from the mobile to either a 447 multicast/anycast group, or a directory service which can be used 448 to find an IS-Server. 450 2. IS-Server Address - The response from either a member of a 451 multicast/anycast group or the directory server, indicating the 452 address of the IS-Server. 454 3. IS-Server Contact - The initial contact operation where the 455 mobile tests if the IS-Server is reachable. This may occur 456 within the first message used for Security Association (SA) 457 bootstrap. 459 4. Optionally, build Security Associations - Messages exchanged to 460 bootstrap SAs with which to protect the data exchange. 462 5. Information Request - The data query packets typically sent from 463 the mobile to the IS-Server, protected by the SAs. 465 6. Information Response - A responding set of response packets sent 466 from the IS-Server to the requester. This message is protected 467 by the SAs already negotiated. Where the direct requester was an 468 IS-Server, the response goes back to the requester rather than a 469 mobile. 471 Discovery exchanges (1 and 2) rely upon the underlying discovery 472 protocol, as described in Section 5.3. 474 Subsequently, secure communications are established (steps 3/4). 475 This should make use of an existing applicable, dependent on the 476 transport required for information request and responses (steps 5 and 477 6). 479 Transport layer requirements for information exchanges are described 480 in Section 5.4, and additional considerations for security 481 association negotiation are provided in Section 5.5. 483 5.3. Information Service Discovery 485 Discovery by the mobile device of the IS-Server either requires 486 Information Server participation in a discovery protocol, network 487 entity discovery support or use of a directory service. The 488 directory service can then refer mobiles to an appropriate server for 489 their location. 491 Discovery mechanisms need to provide IP layer contact information for 492 the IS-Server. Such a discovery system should provide protection 493 against spoofing, to prevent attackers substituting bogus information 494 servers. 496 In IP networks, numerous directory and configuration services already 497 exist. Use of these services either requires support from locally 498 discoverable resources within the same IP hop [5][16][19], or rely on 499 prior configuration of the unicast address of the directory service 500 [13][14][18]. Prior configuration itself may be performed 501 dynamically, along with other host services [5][16]. 503 Network entity discovery, such as Router Discovery [10] could allow 504 discovery of an IS server during routing configuration operations. 505 If server discovery can be achieved through existing configuration 506 discovery procedures, no additional packet exchanges would be 507 required to perform discovery. Strict procedures for modifying 508 packet formats with these primitive discovery mechanisms may limit 509 the applicability of these techniques though. 511 Other non-directory discovery methods require participation by the 512 IS-Server in multicast or anycast communication [13]. In this case, 513 the access network needs to support this form of routing, although it 514 is not aware of the content. Multicast routing itself requires 515 additional routing protocols. These protocols, while simple to 516 operate in constrained domains such as this, are not yet deployed on 517 all access routers. Where the IS server is not on the first IP, this 518 prevents discovery protocol operation. 520 5.4. Transport-Layer Issues 522 The existing ready use of IETF developed transport layer protocols is 523 a compelling reason to develop information services transported over 524 IP. Particularly, it is valuable to determine if IS requirements 525 match existing transport models and protocols. 527 While information services are non-real time, in some scenarios (IS- 528 Server within a subnet), the lifetimes of communications with a 529 particular server are short. As such, the sequenced delivery of 530 packets using TCP may be too complicated for this application heavy 531 handed [3]. TCP fast recovery relies upon delivery of additional 532 packets to stimulate additional transmissions of acknowledgements 533 from a receiver back to a transmitter. Where packet exchanges are 534 short and sporadic, loss of a packet may not be detected except using 535 long retransmission timeouts [4][11][12][15]. 537 Where existing transport protocols do not incorporate their own 538 congestion control and rate limitation, basic mechanisms for network 539 protection and congestion recovery may need to be added to IS 540 application protocols. 542 Additionally, the rich development of security mechanisms which work 543 with TCP and other stream oriented communications, encourage its use 544 [6]. Recent developments allowing similar session oriented security 545 services for datagrams may allow either stream oriented services or 546 datagram oriented services to be used or the mobile node's preference 547 [26]. 549 5.5. Security Association Negotiation 551 Security is important in IP networks, since there is a danger that 552 attacking devices can attempt to adopt roles as information service 553 devices. Such bogus devices could cause service degradation through 554 spurious message exchanges, or by providing false information to 555 mobile devices. 557 IS-Servers need both to protect themselves from attack, and to 558 provide mobile clients provable trust, in order that they can make 559 handover decisions without fear of malicious inaccuracies or 560 mischief. 562 Therefore, before exchanging information requests with a new 563 information server, a set of Security Associations (SAs) are 564 established. Each SA must to provide message authentication, and 565 should provide encryption, for the purposes of mobile device 566 anonymity from eavesdroppers. 568 The exact SA negotiation mechanism described depends on the transport 569 layer used, and security services required. For example, TLS may be 570 applicable if upper layer protocols use TCP, while ESP using IPSec/ 571 IKE will work in most situations, regardless of the upper layer 572 protocol, so long as the IS protocol identifiers are handled by IKE 573 [6][7][8]. Other considerations related to flexibility and ease of 574 use at the application layer may also play a role in the choice. 576 While a mobile device moves within an area serviced by the same IS- 577 Server, it can continue to use the same security association, so long 578 as the clients IP address doesn't change. Where the IS-Server is not 579 on the same LAN as the mobile, the mobile may move between IP 580 networks covered by the same server. In this case, the IP address of 581 the mobile changes. 583 If the mobile's address changes, it may be possible to reuse an 584 existing SA by updating the addresses to use for communication 585 endpoint addresses using Mobile IPv6 Route Optimization, or IKEv2 586 session mobility [20][24]. If address update services are not 587 available, then it will be necessary to reestablish the security 588 association each time the mobile device's address changes. 590 6. Requirements for Transport over IP 591 o Provide an information service transport mechanism which works 592 whether IS-Server is on the same subnet, or deep in the network 593 belonging to same or different administrative domain. 595 o Provide an information service transport mechanism which works 596 with both IPv6 and IPv4. 598 o Distinguish between the packet source and query source (allow 599 proxies). 601 o Provide transport of information services through NAT for IPv4. 603 o Provide transport of information services through firewall for 604 IPv4. 606 o Provide transport of information services through firewall for 607 IPv6. 609 o Optionally allow for multiple queries per transport session. 611 o Optionally ensure compatibility between the information services 612 transport, and those required for Event and Command Services. 614 o Describe an information service discovery mechanism for IPv6 615 hosts. 617 o Describe an information service discovery mechanism for IPv4 618 hosts. 620 o Provide a common discovery method regardless of whether the IS- 621 Server is on the same subnet, or deep within the network. 623 o Information services discovery should be protected from discovery 624 service impersonation and exchange modification attacks. 626 o Optionally ensure compatibility between the information services 627 discovery mechanisms, and those required for Event and Command 628 Services over IP. 630 o Allow for distinct classes Information Servers to be discovered. 632 o Allow for more than one Information Server to be discovered at a 633 time. 635 o Allow for context sensitive IS server discovery (per visited 636 Subnet, per Mobile). 638 o Optionally allow discovery messages being transported through NAT. 639 In this case, support for requester specific knowledge needs to 640 use both the NAT source address and the query original address. 642 o Provide a common SA negotiation method regardless of whether the 643 IS-Server is on the same subnet, or deep within the network. 645 o Protect against IS-Server and wireless device impersonation (with 646 authentication). 648 o Protect against data insertion and modification (provide message 649 authentication). 651 o Protect against replay attacks. 653 o Provide confidentiality of query and response contents. 655 o Protect the identity of a querier against eavesdroppers. 657 o Protect IS-Server and discovery resources against denial of 658 service. 660 o Minimize computational and transmission resources for mobile 661 clients. 663 o Provide compatibility with Address or Security Association 664 Mobility management, to allow use of an IS server after host 665 movements without renegotiating an SA. 667 o Allow for security services to be disabled. 669 o Changes to the IS payload should not affect the security 670 mechanisms defined in the underlying transport mechanism to ensure 671 protocol modifications and evolutions defined in payload. 673 o Enable fast SA setup to handle address mobility. 675 7. Security Considerations 677 Exchange of Link-layer and handover related information over upper- 678 layer protocols such as IP has the potential effect of widening the 679 scope of attacks against both the information service's interfaces 680 within the network, and the information itself. 682 7.1. Attacks against service entities 684 Attacks upon information services may prevent one or more devices 685 being able to receive handover related information. As such this may 686 cause degradation in handover performance. 688 New attacks against information services become possible where link- 689 layer information which would otherwise be limited to only one medium 690 or bridge span, is subsequently available through an arbitrarily 691 large IP subnet. 693 Additionally, where information service packets may be requested or 694 supplied from beyond the boundaries of a single routed hop, the 695 potential scope for attack upon either of the (client or server) IS 696 entities is Internet-wide. 698 Discovery of the information server is implied as a requirement in 699 providing information services transported over IP. Where the server 700 is indicated through link-layer signaling, the robustness of the 701 discovery mechanism is largely based on the security of the existing 702 link-layer signaling mechanisms. Where the server discovery is 703 performed over IP, special care needs to be taken to ensure that 704 discovery may not be hijacked, especially since the underlying 705 wireless medium may in some cases be considered vulnerable to such 706 attack. 708 Link-local scope signaling for either discovery, or both discovery 709 and client-server communications reduce the origin of attacks to 710 those who are on-link [9]. This may provide a mechanism which 711 mitigates the effect of external attacks, but will require service 712 entities to exist on every subnet. 714 7.2. Attacks against information 716 Attacks against the information exchanged between the information 717 server and the information client may potentially modify the behavior 718 and trust of the client protocol stack. 720 Where the integrity and origin of the information delivered to the 721 client is not verifiable, the value of the information is degraded, 722 as hosts are less able to rely upon the data received. 724 Where the client's request is spoofed or modified, additional 725 information may be sent to the IS client. As the mobile node is 726 typically upon a lower bandwidth medium than the server, there exists 727 potential to deny service to devices on that medium. Additionally, 728 spoofed responses may be acted upon instead of legitimate 729 information. This may lead to handover toward undesirable networks, 730 or erratic connectivity. 732 Systems which ensure data origin authentication and message integrity 733 may be able to remove or mitigate some of these effects, by ensuring 734 that data arrives as intended back to the client. It may be 735 difficult, though, to bootstrap some types of security association 736 considering a potential lack of keying material, computation and 737 network bandwidth resources from mobile devices. Any specified 738 integrity protection mechanism therefore needs to be deployable on 739 low-powered battery-operated devices which are commonly deployed in 740 wireless environments. 742 8. Acknowledgements 744 Many thanks to Qiaobing Xie for participating in early discussions, 745 James Kempf and Jari Arkko for an informed and thorough review of 746 this document and IEEE 802.21 WG for providing MIIS transport 747 requirements to IETF. 749 9. References 751 9.1. Normative References 753 [1] "Draft IEEE Standard for Local and Metropolitan Area Networks: 754 Media Independent Handover Services", IEEE LAN/MAN Draft IEEE 755 P802.21/D00.05, January 2006. 757 9.2. Informative References 759 [2] Hepworth, E., "Media Independent Handovers: Problem Statement", 760 draft-hepworth-mipshop-mih-problem-statement-01 (work in 761 progress), March 2006. 763 [3] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 764 September 1981. 766 [4] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast 767 Retransmit, and Fast Recovery Algorithms", RFC 2001, 768 January 1997. 770 [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 771 March 1997. 773 [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 774 RFC 2246, January 1999. 776 [7] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 777 (ESP)", RFC 2406, November 1998. 779 [8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 780 RFC 2409, November 1998. 782 [9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 783 Specification", RFC 2460, December 1998. 785 [10] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 786 for IP Version 6 (IPv6)", RFC 2461, December 1998. 788 [11] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 789 Control", RFC 2581, April 1999. 791 [12] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's 792 Fast Recovery Algorithm", RFC 2582, April 1999. 794 [13] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service 795 Location Protocol, Version 2", RFC 2608, June 1999. 797 [14] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 798 specifying the location of services (DNS SRV)", RFC 2782, 799 February 2000. 801 [15] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An 802 Extension to the Selective Acknowledgement (SACK) Option for 803 TCP", RFC 2883, July 2000. 805 [16] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 806 Carney, "Dynamic Host Configuration Protocol for IPv6 807 (DHCPv6)", RFC 3315, July 2003. 809 [17] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 810 August 2002. 812 [18] Hodges, J. and R. Morgan, "Lightweight Directory Access 813 Protocol (v3): Technical Specification", RFC 3377, 814 September 2002. 816 [19] Droms, R., "Stateless Dynamic Host Configuration Protocol 817 (DHCP) Service for IPv6", RFC 3736, April 2004. 819 [20] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 820 IPv6", RFC 3775, June 2004. 822 [21] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, 823 "Candidate Access Router Discovery (CARD)", RFC 4066, 824 July 2005. 826 [22] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 827 July 2005. 829 [23] Yegin, A., "Link-layer Event Notifications for Detecting 830 Network Attachments", draft-ietf-dna-link-information-02 (work 831 in progress), July 2005. 833 [24] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol", 834 draft-ietf-mobike-design-01 (work in progress), January 2005. 836 [25] Williams, M., "Directions in Media Independent Handover", IEICE 837 Transactions on Fundamentals Special Section on Multi- 838 dimensional Mobile Information Networks, July 2005. 840 [26] Rescorla, E., "Datagram Transport Layer Security", 841 draft-rescorla-dtls-02 (work in progress), December 2004. 843 [27] Brickley, D. and R. Guha, "RDF Vocabulary Description Language 844 1.0: RDF Schema", W3C 845 Recommendation http://www.w3.org/TR/rdf-schema, February 2004. 847 [28] Prudhommeaux, E. and A. Seaborne, "SPARQL Query Language for 848 RDF", W3C Working 849 Draft http://www.w3.org/TR/2004/WD-rdf-sparql-query-20041012, 850 October 2004. 852 Authors' Addresses 854 Srinivas Sreemanthula 855 Nokia 856 6000 Connection Dr. 857 Irving, Texas 75039 858 USA 860 Phone: +1 972 894 4356 861 Email: Srinivas.Sreemanthula@nokia.com 863 Greg Daley 864 Panasonic Digital Networking Laboratory 865 2 Research Way 866 Princeton, New Jersey 08540 867 USA 869 Phone: +1 609 734 7334 870 Email: greg.daley@research.panasonic.com 872 Stefano Faccin 873 Nokia 874 6000 Connection Dr 875 Irving, TX 75229 876 USA 878 Phone: +1 973 894 5000 879 Email: stefano.faccin@nokia.com 881 Eleanor Hepworth 882 Siemens/Roke Manor Research 883 Roke Manor 884 Romsey SO51 0ZN 885 UK 887 Phone: 888 Email: eleanor.hepworth@roke.co.uk 889 Subir Das 890 Telcordia 891 RRC 1B 229 892 One Telcordia Drive 893 Piscataway, NJ 08854 894 US 896 Phone: +1-732-699-2483 897 Email: subir@research.telcordia.com 899 Intellectual Property Statement 901 The IETF takes no position regarding the validity or scope of any 902 Intellectual Property Rights or other rights that might be claimed to 903 pertain to the implementation or use of the technology described in 904 this document or the extent to which any license under such rights 905 might or might not be available; nor does it represent that it has 906 made any independent effort to identify any such rights. Information 907 on the procedures with respect to rights in RFC documents can be 908 found in BCP 78 and BCP 79. 910 Copies of IPR disclosures made to the IETF Secretariat and any 911 assurances of licenses to be made available, or the result of an 912 attempt made to obtain a general license or permission for the use of 913 such proprietary rights by implementers or users of this 914 specification can be obtained from the IETF on-line IPR repository at 915 http://www.ietf.org/ipr. 917 The IETF invites any interested party to bring to its attention any 918 copyrights, patents or patent applications, or other proprietary 919 rights that may cover technology that may be required to implement 920 this standard. Please address the information to the IETF at 921 ietf-ipr@ietf.org. 923 Disclaimer of Validity 925 This document and the information contained herein are provided on an 926 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 927 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 928 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 929 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 930 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 931 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 933 Copyright Statement 935 Copyright (C) The Internet Society (2006). This document is subject 936 to the rights, licenses and restrictions contained in BCP 78, and 937 except as set forth therein, the authors retain all their rights. 939 Acknowledgment 941 Funding for the RFC Editor function is currently provided by the 942 Internet Society.