idnits 2.17.1 draft-carpenter-referral-ps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 21, 2010) is 5057 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational S. Jiang 5 Expires: December 23, 2010 Huawei Technologies Co., Ltd 6 B. Zhou 7 ChinaMobile 8 June 21, 2010 10 Problem Statement for Referral 11 draft-carpenter-referral-ps-00 13 Abstract 15 The purpose of a referral is to enable a given entity in a multiparty 16 Internet application to pass information to another party. It 17 enables a communication initiator to be aware of relevant information 18 of its destination entity before launching the communication. This 19 memo discusses the problems involved in referral scenarios. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 23, 2010. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Goals of Referral . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Reachability . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Path Selection . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2.1. An Example: Triangle Path Optimization . . . . . . . . 4 61 3.3. Interface Selection . . . . . . . . . . . . . . . . . . . 5 62 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. IP Addresses are not sufficient . . . . . . . . . . . . . 6 64 4.2. FQDNs are not sufficient . . . . . . . . . . . . . . . . . 7 65 4.3. Additional Information . . . . . . . . . . . . . . . . . . 8 66 4.4. A Generic Referral Mechanism is needed . . . . . . . . . . 9 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 A frequently occurring situation is that one entity A connected to 79 the Internet (or to some private network using the Internet protocol 80 suite) needs to be aware of the information of another entity B in 81 order to reach it. The information can be obtained from B itself or 82 some third-party entity C. This is known as a referral. 84 Referral is the act whereby one entity informs another entity how to 85 contact a specific entity. It enables a communication initiator to 86 be aware of relevant information of its destination entity in order 87 to launch a communication channel. This referral information can be 88 obtained through an existing communication channel between these two 89 entities or from thrid-party entities. 91 In the original design of the Internet, IP addresses were global, 92 unique, and quasi-permanent. Also any differentiation beyond that 93 provided by an IP address was done by protocol and port numbers. 94 Referrals were therefore performed simply by passing an IP address 95 and possibly protocol and port numbers. In fact simple referrals 96 (the first case above, sometimes called first-party referrals) were 97 never needed since A could simply use B's address. Third-party 98 referrals were trivial: C would tell A about B's address. Thus, it 99 became common practice to pass raw addresses between entities. A 100 classical example is the FTP PORT command [RFC0959]. 102 2. Terminology 104 This document makes use of the following terms: 105 o "Entity": we use this rather than "application" to describe any 106 software component embedded in an Internet host, not just a 107 specific application, that sends, receives or makes use of 108 referrals. Also, in case of dynamic load sharing or failover, an 109 entity might even migrate between hosts. 110 o "Referral": the act of one entity informing another entity how to 111 contact a specific entity. 112 o "Reference": the actual data (name, address, identitifier, 113 locator, pointer, etc.) that is the basis of a referral. 114 o "Referring entity": the entity that sends a referral. 115 o "Receiving entity": the entity that receives a referral. 116 o "Referenced entity": the target entity of a reference. 117 o "Scope": the region or regions of the Internet within which a 118 given reference is applicable to reach the referenced entity. 120 3. Goals of Referral 122 The principal purpose of referral is to enable one entity in a multi- 123 party application to pass information to another party involved in 124 the same application. This document makes no assumptions about 125 whether the entities are acting as clients, servers, peers, super- 126 nodes, relays, proxies, etc., as far as the application is concerned. 127 Neither does it take a position as to how the various entities become 128 aware of the need to send a referral; this depends entirely on the 129 structure of the application. 131 3.1. Reachability 133 The primary goals of referral is to enable a communication initiator 134 to reach its destination entity. Referral is a best effort 135 mechanism. It does not guarantee actual reachability, since the 136 referring entity has no general way of knowing which paths exist 137 between the receiving entity and the referenced entity. Even if a 138 reference is theoretically in scope, and within its defined lifetime, 139 it may have become unreachable since it was sent. A receiving entity 140 should always be prepared for reachability failures and associated 141 retry and failover mechanisms, which are out of scope for the 142 referral mechanism itself. 144 3.2. Path Selection 146 A reference might carry multiple references for the same target. 147 These may lead to multiple possible paths from the receiving entity 148 to the referenced entity. This scenario is particularly generic when 149 the destination or/and source entity has multiple interfaces or is 150 multi-homed. 152 The referring entity is not likely to know which path is best. The 153 receiving entity will need to make a choice, possibly by local policy 154 (e.g. [RFC3484]) or possibly by trial and error (e.g. [RFC4038], 155 [RFC5534]). This choice is also out of scope for the referral 156 mechanism itself. 158 3.2.1. An Example: Triangle Path Optimization 160 In application scenarios, the triangular path shown below is common. 161 Both Host A and Host B connect to an application server and the 162 application server forwards traffic as a relay agent. A slightly 163 more complicated scenario is when the two hosts connect to different 164 application servers individually and application servers talk to each 165 other's relay agents. In SIP, this is often called the "SIP 166 trapezoid". 168 +------------------------------+ 169 | application server | 170 +--+------------------------+--+ 171 / \ 172 | | 173 | referral information | 174 | | 175 | | 176 +-+-+ +-+-+ 177 | A +----------------------+ B | 178 +---+ direct communication +---+ 180 By passing A's reference to B, B can try to communicate directly with 181 A, using the communication line at the bottom. If the direct 182 communication is established successfully, the triangle path gets 183 optimized. Both the application server and network bandwidth can be 184 benefit from this operation. 186 3.3. Interface Selection 188 We also encounter multi-interfaced hosts whose reachability is bound 189 to a particular (logical/physical) interface. More information is 190 required to indicate which interface may be used under different 191 circumstances. Multi-interface is defined and studied by IETF MIF 192 WG. Here referral can provide the host A's multi-interface 193 information to host B, accordingly, host B can select one of the 194 interface to establish the connection. 196 +------------+ Path 1 +------------+ 197 |Interface A1+----------------+Interface B1| 198 | Host A | | Host B | 199 |Interface A2|----------------+Interface B2| 200 +------------+ Path 2 +-----------+ 202 For example, as shown in the above figure, Host A has connected to 203 Host B through Path 1. They can exchange references through Path 1. 204 They may find out Path 2 using different interfaces is better than 205 Path 1, maybe cheaper, faster or more stable. Then, they can switch 206 to Path 2. Host A has interface A1 as broadband access, almost free; 207 and interface A2 is 3G access, which costs 0.1 $ per MB. Both of 208 them are avaible for incoming connection. If these information is 209 passed to host B, through referral, then host B should choose A1 210 interface to reach host A. This kind of information is useful to 211 express the source's status or preference. 213 In order to choose between different interfaces, not only the 214 connectivity information of these interfaces, but also some additonal 215 information may be helpful, such as bandwidth, finance cost, latency, 216 etc. These additional information may also be provided through 217 referral. However, this additional information, even if known by the 218 referring entity, may be invalid at the location of the receiving 219 entity. 221 4. Problem Statement 223 Unfortunately, the simple approach to referrals, passing an IP 224 address, often fails in today's Internet. As has been known for some 225 time [RFC2101], hosts' IP addresses no longer all have global scope. 226 They often have limited reachability, and may have limited lifetime. 227 They are not sufficient to establish communication in many cases of 228 dynamic referrals, for a variety of reasons. FQDN may be used 229 instead in some scenarios. However, FQDN also has its own limitation 230 and may fail in some scenarios. 232 4.1. IP Addresses are not sufficient 234 It is no longer reasonable to assume that a host with a fixed 235 location has a fixed IP address, or even a stable IP address. 237 Furthermore, in the context of IPv4 address exhaustion, several 238 solutions have emerged to share a single public IPv4 address between 239 several customers simultaneously. Consequently, a public IPv4 240 address often no longer identifies a single customer/user/host while 241 a private IPv4 address is meaningless out of the private network 242 scope. Other information (e.g., port range) is required to identify 243 unambiguously a given customer/user/host. Both IP addresses and port 244 numbers may be different on either side of a NAT or some other 245 middlebox [RFC3234], and firewalls may block them. It is no longer 246 reasonable to assume that an IP address for a host, which allows a 247 given peer to reach that host in one location, also works from a 248 different location - even if that host is reachable from the second 249 location. 251 Also, the Internet now has two co-existing address formats for IPv4 252 and IPv6. Direct communication can only be established when both 253 peers use the same IP version. Having the address of the source and 254 destination in the same IP version does not necessarily mean that the 255 path will be using that IP version. Simple approaches may cause 256 unnecessary double translation [I-D.boucadair-softwire-cgn-bypass]. 257 Some addresses may even be the result of translation between IPv4 and 258 IPv6, with severe limitations on their scope and lifetime. Sending 259 an out-of-scope or expired address, or one of the wrong format, as a 260 referral will fail. 262 IP addresses today may have an implied "context" (VPN, VoIP VC, IP 263 TV, etc.): the reachability of such an address depends on that 264 context. 266 An implication of these issues is that there is no clean definition 267 of the scope of an address (especially an IPv4 address, due to the 268 prevalence of NAT). It is impossible to determine algorithmically, 269 by inspecting the bits of an address, what its scope of reachability 270 is. Resolving this problem would greatly clarify the general problem 271 of referrals. 273 4.2. FQDNs are not sufficient 275 In some cases, this problem may be readily solved by passing a Fully 276 Qualified Domain Name (FQDN) instead of an IP address. Indeed, that 277 is an architecturally preferred solution [RFC1958]. However, it is 278 not sufficient in many cases of dynamic referrals. Experience shows 279 that an application cannot use a domain name in order to reliably 280 find usable address(es) of an arbitrary peer. Domain names work 281 fairly well to find the addresses of public servers, as in web 282 servers or SMTP servers, because operators of such servers take pains 283 to make sure that their domain names work. But DNS records are not 284 as reliably maintained for arbitrary hosts such as might need to be 285 contacted in peer-to-peer applications, or for servers within 286 corporate networks. Many small networks do not even maintain DNS 287 entries for their hosts, and for some networks that do list local 288 hosts in DNS, the listings may well be unusable from a remote 289 location, because of two-faced DNS, or because the A record contains 290 a private address. These cases may even be intentional as part of a 291 security ring-fence, where w3.example.com only resolves within the 292 corporate boundary, and/or resolves to IP addresses which are only 293 reachable within the corporate administrative boundaries. In such 294 contexts, incoming connections are usually filtered by the corporate 295 firewall. 297 An additional issue with FQDNs is the very common situation where 298 multiple hosts are hidden behind a NAT, but they share one FQDN which 299 is in fact a dummy name, created automatically by the ISP so that 300 reverse DNS lookup will succeed for the NAT's public IPv4 address. 301 Such FQDNs are useless for identifying specific hosts. 303 Furthermore, an FQDN may not be sufficient to establish successful 304 communications involving heterogeneous peers (i.e., IPv4 and IPv6) 305 since A and AAAA records may not be consistently provisioned. There 306 are known cases where a server has one name that produces an A record 307 (e.g., www.example.com) and another name that produces an AAAA record 308 (e.g., ipv6.example.com). An additional complication is that some 309 answers from DNS may be synthetic IP addresses, e.g., AAAA records 310 sent by DNS64. The host may have no means to detect that such an 311 address represents an IPv4 host. These addresses should not be 312 interpreted as native IPv6 address. 314 In such cases, an IP address either cannot be derived from an FQDN, 315 or if so derived, cannot be accessed from an arbitrary location in 316 the Internet. 318 A related problem is that an application does not have a reliable way 319 of knowing its own domain name - or to be more precise, a way of 320 knowing a domain name that will allow the application to be reached 321 from another location. 323 There are wider systemic problems with the DNS as a reliable way to 324 find a usable address, which are somewhat out of scope here, but can 325 be summarised: 326 o In large networks, it is now quite common that the DNS 327 administrator is out of touch with the applications user or 328 administrator, and as a result, that the DNS is out of sync with 329 reality. 330 o DNS was never designed to accommodate mobile or roaming hosts, 331 whose locator may change rapidly. 332 o DNS has never been satisfactorily adapted to isolated, 333 transiently-connected, or ad hoc networks. 334 o It is no longer reasonable to assume that all addresses associated 335 with a DNS name are bound to a single host. One result is that 336 the DNS name might suffice for an initial connection, but a 337 specific address is needed to rebind to the same peer, say, to 338 recover from a broken connection. 339 o It is no longer reasonable to assume that a DNS query will return 340 all usable addresses for a host. 341 o Hosts may be identified by a different URI per service: no unique 342 URI scheme, meaning no single FQDN, will apply. 344 For all the above reasons, the problem of address referrals cannot be 345 solved simply by recommending the use of FQDNs instead. The 346 guideline in [RFC1958] is in fact too simple for today's network. 347 Something more elaborate than an IP address or an FQDN appears to be 348 needed in the general case of application referrals. 350 4.3. Additional Information 352 Neither an IP address nor an FQDN gives complete information about 353 the referenced entity. For example, IP addresses normally have 354 associated lifetimes (derived from DHCP, SLAAC or the relevant DNS 355 TTL), so they should be treated as invalid after their lifetimes 356 expire. A referral that does not convey the lifetime associated with 357 an address is problematic. Also, some mechanisms entering use today 358 (e.g., HIP, LISP, SHIM6) may break the implicit linkage between 359 location and identity provided by an IP addresses. As mentioned 360 above, the scope of a reference also affects its usefulness. These 361 are examples of additional information that is necessary to correctly 362 interpret a referral; therefore part of the problem is conveying such 363 information along with the reference. 365 4.4. A Generic Referral Mechanism is needed 367 The first motivation is the observation that unless the parties 368 involved have reached an understanding about the scope, lifetime, and 369 format of the elements in a referral through some other means, that 370 information must be passed with the referral. This is required so 371 that the receiving entity can determine whether or not the referral 372 is useful. The referral therefore needs to consist of a fully- 373 fledged data structure, or to be made using a mutually agreed 374 referral protocol. 376 When an attempt to establish a communication channel based on certain 377 referral information fails, good design suggests that the receiving 378 entity should attempt to correct the situation. For example, if 379 communication fails to be established using an IP address, it would 380 often be appropriate to attempt a DNS lookup, despite the 381 difficulties mentioned above. The second motivating problem is that 382 it may be helpful to the entity receiving a reference to also receive 383 information about the source of the reference, such as an FQDN, if 384 that is known to the sender of the reference. The receiving entity 385 can then attempt to recover a valid address (and possibly port 386 number) for the referred entity. 388 The third motivating problem is to allow a reference to contain 389 alternatives to an IP address or an FQDN, when any such alternatives 390 exist. 392 Additional arguments for a generic referral mechanism include: 393 1. Allow for general mechanisms that can be used by any application 394 to handle references and understand the meaning of referral 395 information, such as IP address, possibly protocol and port 396 numbers. However, there is an open question whether this 397 standard referral design should be used for new applications 398 only, or extended to existing applications. 399 2. Simplify ALG design during middlebox traversal. There are 400 middleboxes, like firewalls and translators, especially in the 401 mobile network, which require application layer gateways ALG. 402 The cost of ALG functions is huge for the mobile operator in 403 terms of implementation, performance. Standard references could 404 simplify ALG implementation during middlebox traversal in the 405 mobile network. 407 3. Simplify packet inspection. Operators sometimes need to inspect 408 information or details during communication for administration 409 reasons. If referral mechanism is standardized, it is easier for 410 an operator to capture and investigate the required information. 412 We observe that we have identified two general requirements: the need 413 to define address scope more precisely, and the need to communicate 414 references in a generic way. 416 It should be noted that partial or application-specific solutions to 417 these problems abound, because any multi-party distributed 418 application must solve them. The best documented example is ICE 419 [RFC5245], which is an active protocol specific to applications 420 mediated by SDP [RFC4566]. ICE "works by including a multiplicity of 421 IP addresses and ports in SDP offers and answers, which are then 422 tested for connectivity by peer-to-peer connectivity checks." The 423 question raised here is whether we can define requirements for a 424 generic solution that can be used by future applications, and 425 possibly be retro-fitted to existing applications. 427 One approach could be a "SuperICE" designed to be completely general 428 and not tied to the SDP model. Another approach is the idea of a 429 generic referral object. Such an object could be passed between the 430 entities of a multi-party application, but without defining a 431 specific protocol for that purpose. Some applications might choose 432 to send it in-band as a raw binary object, others might use a simple 433 ASCII encoding, and still others might prefer to encode it in XML, 434 for example. Finally, it might also be used as part of SuperICE. 436 5. Security Considerations 438 It should be noted that referral should not function as a way to 439 nullify the effect of a firewall or any other security mechanism. If 440 the receiving entity chooses a particular reference and attempts to 441 send packets to the corresponding IP address, whether they are 442 delivered or not will depend on the existing security mechanisms, 443 whatever they may be. 445 Nevertheless, if a site security policy requires it, certain 446 references may be excluded from referral information sent to certain 447 destinations. This would require a security policy mechanism to be 448 added to the process of generating referral information. 450 Forged or intercepted referral information would enable a wide 451 variety of attacks. Although not fundamentally different from 452 attacks based on forged or observed IP addresses or FQDNs, no doubt 453 referral would allow such attacks to be more ingenious, simply 454 because they provide more information than an address or FQDN alone. 455 Referral information should be transmitted through authenticated and 456 encrypted channels. It is not further elaborated here. 458 Referral may raise potential privacy issues, which are not explored 459 in this document. For example, in the SIP context, mechanisms such 460 as [RFC3323] and [RFC5767] are available to hide information that 461 might identify end-points. Referral usage scenarios must ensure that 462 they do not unintentionally defeat privacy solutions. 464 6. IANA Considerations 466 This document requests no action by IANA. 468 7. Acknowledgements 470 This document was requested by the REFER BOF at IETF78. Valuable 471 comments and contributions were made by Mohamed Boucadair, Dan Wing, 472 Keith Moore and others. 474 This document was produced using the xml2rfc tool [RFC2629]. 476 8. Change log 478 draft-carpenter-referral-ps-00: original version, 2010-06-21. 480 9. References 482 9.1. Normative References 484 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 485 STD 9, RFC 959, October 1985. 487 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 488 Initiation Protocol (SIP)", RFC 3323, November 2002. 490 [RFC3484] Draves, R., "Default Address Selection for Internet 491 Protocol version 6 (IPv6)", RFC 3484, February 2003. 493 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 494 Description Protocol", RFC 4566, July 2006. 496 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 497 (ICE): A Protocol for Network Address Translator (NAT) 498 Traversal for Offer/Answer Protocols", RFC 5245, 499 April 2010. 501 [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and 502 Locator Pair Exploration Protocol for IPv6 Multihoming", 503 RFC 5534, June 2009. 505 9.2. Informative References 507 [I-D.boucadair-softwire-cgn-bypass] 508 Boucadair, M., "Procedure to bypass DS-lite AFTR (work in 509 progress)", December 2009. 511 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 512 RFC 1958, June 1996. 514 [RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 515 Address Behaviour Today", RFC 2101, February 1997. 517 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 518 June 1999. 520 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 521 Issues", RFC 3234, February 2002. 523 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 524 Castro, "Application Aspects of IPv6 Transition", 525 RFC 4038, March 2005. 527 [RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent- 528 Driven Privacy Mechanism for SIP", RFC 5767, April 2010. 530 Authors' Addresses 532 Brian Carpenter 533 Department of Computer Science 534 University of Auckland 535 PB 92019 536 Auckland, 1142 537 New Zealand 539 Email: brian.e.carpenter@gmail.com 540 Sheng Jiang 541 Huawei Technologies Co., Ltd 542 Huawei Building, No.3 Xinxi Rd., 543 Shang-Di Information Industry Base, Hai-Dian District, Beijing 544 P.R. China 546 Email: shengjiang@huawei.com 548 Bo Zhou 549 China Mobile 550 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 551 Beijing, 100053 552 P.R. China 554 Email: zhouboyj@gmail.com