idnits 2.17.1 draft-carpenter-grobj-reqts-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (January 20, 2010) is 5203 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-boucadair-softwire-cgn-bypass-00 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GROBJ BOF B. Carpenter, Ed. 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational January 20, 2010 5 Expires: July 24, 2010 7 Problem Statement and Requirements for Generic Referrals 8 draft-carpenter-grobj-reqts-00 10 Abstract 12 The purpose of a referral is to enable a given entity in a multiparty 13 Internet application to pass information to another party. This memo 14 discusses the problems involved and describes requirements for a 15 generic referral mechanism. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on July 24, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the BSD License. 55 Table of Contents 57 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 59 2. The additional problem of scope . . . . . . . . . . . . . . . 7 60 3. The additional problem of path selection . . . . . . . . . . . 10 61 4. Summary of Requirements . . . . . . . . . . . . . . . . . . . 10 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 64 7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 13 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 66 9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 69 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 1. Introduction and Problem Statement 74 A frequently occurring situation is that one entity A connected to 75 the Internet (or to some private network using the Internet protocol 76 suite) needs to inform another entity B how to reach either A itself 77 or some third-party entity C. This is known as a referral. 79 In the original design of the Internet, IP addresses were global, 80 unique, and quasi-permanent. Also any differentiation beyond that 81 provided by an IP address was done by protocol and port numbers. 82 Referrals were therefore performed simply by passing an IP address 83 and possibly protocol and port numbers. In fact simple referrals 84 (the first case above, sometimes called first-party referrals) were 85 never needed since B could simply use A's address. Third-party 86 referrals were trivial: A would tell B about C's address. Thus, it 87 became common practice to pass raw addresses between entities. A 88 classical example is the FTP PORT command [RFC0959]. 90 Unfortunately, this simple approach to referrals often fails in 91 today's Internet. As has been known for some time [RFC2101], 92 addresses no longer all have global scope, often have limited 93 reachability, and may have limited lifetime. It is no longer 94 reasonable to assume that a host with a fixed location has a fixed 95 address, or even a stable address. 97 We also encounter multi-interfaced hosts whose reachability is bound 98 to a particular (logical/physical) interface. Furthermore, in the 99 context of IPv4 address exhaustion, several solutions have emerged to 100 share a single public IPv4 address between several customers 101 simultaneously. Consequently, an IPv4 address often no longer 102 identifies a single customer/user/host. Other information (e.g., 103 port range) is required to identify unambiguously a given customer/ 104 user/host. 106 Both addresses and port numbers may be different on either side of a 107 NAT or some other middlebox [RFC3234], and firewalls may block them. 108 It is no longer reasonable to assume that an address for host H, 109 which allows a given peer to reach that host in one location, also 110 works from a different location - even if H is reachable from the 111 second location. Also, the Internet now has two co-existing address 112 formats for IPv4 and IPv6. Having the address of the source and 113 destination in the same IP version does not necessarily mean that the 114 path will be using that IP version. Simple approaches may cause 115 unnecessary double translation [I-D.boucadair-softwire-cgn-bypass]. 116 Some addresses may even be the result of translation between IPv4 and 117 IPv6, with severe limitations on their scope and lifetime. Sending 118 an out-of-scope or expired address, or one of the wrong format, as a 119 referral will fail. 121 IP addresses today may have an implied "context" (VPN, VoIP VC, IP 122 TV, etc.): the reachability of such an address depends on that 123 context. 125 In some cases, this problem may be readily solved by passing a Fully 126 Qualified Domain Name (FQDN) instead of an IP address. Indeed, that 127 is an architecturally preferred solution [RFC1958]. However, it is 128 not sufficient in many cases of dynamic referrals. Experience shows 129 that an application cannot use a domain name in order to reliably 130 find useable address(es) of an arbitrary peer. Domain names work 131 fairly well to find the addresses of public servers, as in web 132 servers or SMTP servers, because operators of such servers take pains 133 to make sure that their domain names work. But DNS records are not 134 as reliably maintained for arbitrary hosts such as might need to be 135 contacted in peer-to-peer applications, or for servers within 136 corporate networks. Many small networks do not even maintain DNS 137 entries for their hosts, and for some networks that do list local 138 hosts in DNS, the listings may well be unusable from a remote 139 location, because of two-faced DNS, or because the A record contains 140 a private address. These cases may even be intentional as part of a 141 security ring-fence, where w3.example.com only resolves within the 142 corporate boundary, and/or resolves to IP addresses which are only 143 reachable within the corporate administrative boundaries. In such 144 contexts, incoming connections are usually filtered by the corporate 145 firewall. 147 An additional issue with FQDNs is the very common situation where 148 multiple hosts are hidden behind a NAT, but they share one FQDN which 149 is in fact a dummy name, created automatically by the ISP so that 150 reverse DNS lookup will succeed for the NAT's public IPv4 address. 151 Such FQDNs are useless for identifying specific hosts. 153 Furthermore, an FQDN may not be sufficient to establish successful 154 communications involving heterogeneous peers (i.e., IPv4 and IPv6) 155 since A and AAAA records may not be consistently provisioned. There 156 are known cases where a server has one name that produces an A record 157 (e.g., www.example.com) and another name that produces an AAAA record 158 (e.g., ipv6.example.com). An additional complication is that some 159 answers from DNS may be synthetic IP addresses, e.g., AAAA records 160 sent by DNS64. The host may have no means to detect that such an 161 address represents an IPv4 host. These addresses should not be 162 interpreted as native IPv6 address. 164 In such cases, an IP address either cannot be derived from an FQDN, 165 or if so derived, cannot be accessed from an arbitrary location in 166 the Internet. 168 A related problem is that an application does not have a reliable way 169 of knowing its own domain name - or to be more precise, a way of 170 knowing a domain name that will allow the application to be reached 171 from another location. 173 There are wider systemic problems with the DNS as a reliable way to 174 find a useable address, which are somewhat out of scope here, but can 175 be summarised: 176 o In large networks, it is now quite common that the DNS 177 administrator is out of touch with the applications user or 178 administrator, and as a result, that the DNS is out of sync with 179 reality. 180 o DNS was never designed to accommodate mobile or roaming hosts, 181 whose locator may change rapidly. 182 o DNS has never been satisfactorily adapted to isolated, 183 transiently-connected, or ad hoc networks. 184 o It is no longer reasonable to assume that all addresses associated 185 with a DNS name are bound to a single host. One result is that 186 the DNS name might suffice for an initial connection, but a 187 specific address is needed to rebind to the same peer, say, to 188 recover from a broken connection. 189 o It is no longer reasonable to assume that a DNS query will return 190 all usable addresses for a host. 191 o Hosts may be identified by a different URI per service: no unique 192 URI scheme, meaning no single FQDN, will apply. 194 For all the above reasons, the problem of address referrals cannot be 195 solved simply by recommending the use of FQDNs instead. The 196 guideline in [RFC1958] is in fact too simple for today's network. 197 Something more elaborate than an IP address or an FQDN appears to be 198 needed in the general case of application referrals. 200 The first problem motivating this draft is the observation that 201 unless the parties involved have reached an understanding about the 202 scope, lifetime, and format of the elements in a referral through 203 some other means, that information must be passed with the referral. 204 This is required so that the receiving entity can determine whether 205 or not the referral is useful. The referral therefore needs to 206 consist of a fully-fledged data structure, or to be made using a 207 mutually agreed referral protocol. 209 When a referral fails, good design suggests that the receiving entity 210 should attempt to correct the situation. For example, if 211 communication fails to be established using an IP address, it would 212 often be appropriate to attempt a DNS lookup, despite the 213 difficulties mentioned above. The second motivating problem is that 214 it may be helpful to the entity receiving a referral to also receive 215 information about the source of the referral, such as an FQDN, if 216 that is known to the sender of the referral. The receiving entity 217 can then attempt to recover a valid address (and possibly port 218 number) for the referred entity. 220 The third motivating problem is to allow a referral to contain 221 alternatives to an IP address or an FQDN, when any such alternatives 222 exist. 224 Additional arguments for a generic referral mechanism include: 225 1. Allow for general mechanisms that can be used by any application 226 to handle referrals and understand the meaning of referral 227 information, such as IP address, possibly protocol and port 228 numbers. However, there is an open question whether this 229 standard referral design should be used for new applications 230 only, or extended to existing applications. 231 2. Simplify ALG design during middlebox traversal. There are 232 middleboxes, like firewalls and translators, especially in the 233 mobile network, which require application layer gateways ALG. 234 The cost of ALG functions is huge for the mobile operator in 235 terms of implementation, performance. Standard referrals could 236 simplify ALG implementation during middlebox traversal in the 237 mobile network. 238 3. Simplify packet inspection. Operators sometimes need to inspect 239 information or details during communication for administration 240 reasons. If referral mechanism is standardized, it is easier for 241 an operator to capture and investigate the required information. 243 We observe that we have identified two general requirements: the need 244 to define address scope more precisely, and the need to communicate 245 referrals in a generic way. 247 It should be noted that partial or application-specific solutions to 248 these problems abound, because any multi-party distributed 249 application must solve them. The best documented example is ICE 250 [I-D.ietf-mmusic-ice], which is an active protocol specific to 251 applications mediated by SDP [RFC4566]. ICE "works by including a 252 multiplicity of IP addresses and ports in SDP offers and answers, 253 which are then tested for connectivity by peer-to-peer connectivity 254 checks." The question raised here is whether we can define 255 requirements for a generic solution that can be used by future 256 applications, and possibly be retro-fitted to existing applications. 258 One approach could be a "SuperICE" designed to be completely general 259 and not tied to the SDP model. Another approach, considered here, is 260 the idea of a generic referral object, defined below. Such an object 261 could be passed between the entities of a multi-party application, 262 but without defining a specific protocol for that purpose. Some 263 applications might choose to send it in-band as a raw binary object, 264 others might use a simple ASCII encoding, and still others might 265 prefer to encode it in XML, for example. Finally, it might also be 266 used as part of SuperICE. 268 1.1. Terminology 270 This document makes use of the following terms: 271 o "Entity": we use this rather than "application" to describe any 272 software component embedded in an Internet host, not just a 273 specific application, that sends, receives or makes use of 274 referrals. Also, in case of dynamic load sharing or failover, an 275 entity might even migrate between hosts. 276 o "Referral": the act of one entity informing another entity how to 277 contact a specific entity. 278 o "Generic Referral Object (GRO)": a data object expressed in an 279 application-independent format that can be passed between entities 280 to communicate referrals. 281 o "Reference": the actual data (name, address, identitifier, 282 locator, pointer, etc.) that is the basis of a referral. The 283 reference(s) contained in a GRO provide an entity with sufficient 284 information to utilise one or more methods to attempt to reach 285 another entity. 286 o "Qualifier": a data item that gives additional information about a 287 Reference, such as lifetime, port numbers, etc. 288 o "Referring entity": the entity that sends a referral. 289 o "Receiving entity": the entity that receives a referral. 290 o "Referenced entity": the entity described in a GRO; the target of 291 a reference. 292 o "Scope": the region or regions of the Internet within which a 293 given reference is applicable to reach the referenced entity. See 294 further discussion in the next section. 295 o "Scope Identifier" (ScopeID): an identifier in an unambiguous 296 namespace for the scope of a reference. Used as a Qualifier. 297 o "Limited Scope": whatever set of referring and receiving entities 298 have been configured (statically or dynamically) to accept a given 299 Scope Identifier. 301 2. The additional problem of scope 303 The principal purpose of a referral is to enable one entity in a 304 multi-party application to pass information to another party involved 305 in the same application. This document makes no assumptions about 306 whether the entities are acting as clients, servers, peers, super- 307 nodes, relays, proxies, etc., as far as the application is concerned. 308 Neither does it take a position as to how the various entities become 309 aware of the need to send a referral; this depends entirely on the 310 structure of the application. 312 Since the most fundamental quantity likely to be conveyed in a GRO is 313 an IP address, (and possibly a port number) its scope is a key 314 question. Address scope is not a simple concept, as shown by the 315 discussion in [RFC4007] and the practical difficulties caused by 316 [RFC3484]. Even the concept of link-local scope is complicated by 317 the existence of multi-link subnets [RFC4903]. For the purpose of 318 referrals, it seems that previous formalisations of the concept of 319 scope are inadequate. Assuming that a GRO is trustworthy, one 320 question that a receiving entity must answer is: "can the address in 321 this GRO be reached from here?" That question is not answered by 322 knowing only the scope (in the sense of [RFC4007]) as defined at the 323 location of the referring entity. For that reason, scope needs to be 324 represented in a new way in GROs. Firstly, the effective scope (to 325 the best of the referring entity's knowledge) could be any of the 326 following: 327 o Null. The address is known not to be applicable outside the 328 referring host (e.g., a loopback address). This option is 329 mentioned mainly for completeness; it has no value in a GRO, and 330 for privacy reasons it should not be communicated anyway. 331 o Link. Apart from the standard Ethernet-like view of link 332 locality, this scope would also apply to point-to-point links and 333 to fragments of a multi-link subnet. Although on-link referrals 334 should be trivial, this case is included to allow for uniform 335 design of applications utilising GROs, so that link-local does not 336 become a special case. 337 o Limited. The address has applicability beyond the link, but it is 338 known not to have global applicability. Examples include IPv4 339 private addresses [RFC1918] and IPv6 Unique Local Addresses 340 (ULAs)[RFC4193]. Other cases include addresses on subnets which 341 the referring entity knows to be obstructed by firewalls, network 342 address translators, or other barriers to transparency [RFC2775]. 343 A typical case is the set of subnets sharing a single set of 344 border routers connecting them to the Internet. 345 o Global. The address has applicability beyond the link, and is 346 believed to have global applicability within its address family. 348 However, particularly in the case of limited scope, this is 349 insufficient for the receiving entity to decide whether the address 350 is applicable in the receiving entity's context. The scopes above 351 are described as if they were a set of concentric circles, but 352 reality is more complex, and limited scopes might overlap each other 353 in an arbitrary way, for example when multiple VPNs are formed. A 354 case in point is a VPN constructed between two independent sites, 355 over which only those two sites' ULAs are routed. This would allow a 356 complex pattern of overlapping scopes. For example, hosts in site A 357 might potentially have addresses in three different scopes (global, 358 Site_A_only, ULA_A+B). Similarly, site B might also recognize three 359 scopes (global, Site_B_only, ULA_A+B). Which hosts can send packets 360 to each other will depend on the combination of addresses and scopes 361 available. For example, a host which only has an address in scope 362 Site_A_only cannot send a packet to a host which only has an address 363 in scope ULA_A+B. Hosts in scope ULA_A+B can send packets between 364 sites A and B over the VPN. This can readily be encoded in routing 365 configurations, but application software is generally unaware of it. 367 Thus, a referring entity may or may not be aware that the receiving 368 entity and the referenced entity are within a link scope or limited 369 scope that does not contain the referring entity. 371 The delimiter of a limited scope will in many cases be the device 372 (firewall or NAT) that obstructs transparency. A tempting solution 373 would be to use some unique identifier of that device as the unique 374 ScopeID. Unfortunately, this cannot be an IP address of the device, 375 since in the case of nested NATs, all its addresses may be ambiguous. 376 Neither can we rely on such a device having its own FQDN, or on that 377 FQDN being known to all entities within the scope concerned. 378 Finally, some limited scopes may not be hidden behind a single such 379 device; for example, a limited scope might consist of a company's 380 network and selected VPN connections to subsets of several business 381 partners' networks. Alternatively, multiple limited scopes might be 382 hidden behind the same device. Device addresses are therefore not 383 suitable as ScopeIDs. 385 Methods for configuring, advertising and discovering ScopeIDs are not 386 discussed in this document. However, in their absence, it is 387 extremely hard for receiving entities to interpret and use 388 information about limited scopes. To the extent possible, all 389 entities involved in referrals should determine what scope is shared 390 between the referred entity and the receiving entity, by any means. 391 Those means are not covered in this document, but may include use of 392 external services, agreement on scope identifiers, or direct 393 negotiation. 395 In general, the referring entity cannot know the scope in which the 396 GRO will be interpreted. For example, the initial receiving entity 397 may itself be behind a NAT, unknown to the referring entity, or the 398 receiving entity may send the GRO onwards to another host in yet 399 another scope. In practice, we have to leave the receiver to decide 400 whether certain information is useful or not. In the case of a 401 ScopeID in particular, the referring entity is not able to know which 402 ScopeIDs apply to the receiving entity. 404 Discovery or negotiation of ScopeIDs between referring, referenced 405 and receiving entities is certainly a possibility, but may be 406 expensive, and is not assumed by this document. 408 A referring entity may obtain the address and port number for the 409 referenced entity in various ways, and knowledge about this may help 410 the receiving entity when combined with scope information. For 411 example, if the receiving entity is aware that the address has been 412 translated, and that it has global scope, it may choose to use it 413 without further checks. If it is not marked as translated, and has 414 limited scope, the receiving entity may then verify whether it has a 415 suitable ScopeID. 417 To enable such logic, a GRO may describe the source of an address or 418 port number. How knowledge of this source is obtained is outside the 419 scope of the present document, but ICE [I-D.ietf-mmusic-ice] is an 420 example method. It is also out of scope here to describe exactly how 421 the receiving entity uses the information; for example GRO semantics 422 do not include or imply preferences or priorities when multiple 423 addresses are provided. The receiving entity may choose to use a 424 predefined policy, apply general logic as sketched in the previous 425 paragraph, or follow application-specific logic, all based on the 426 data provided in a GRO. 428 Finally we note that theoretical scope does not guarantee actual 429 reachability. A receiving entity should always be prepared for 430 reachability failures and associated retry and failover mechanisms. 432 3. The additional problem of path selection 434 We note that theoretical scope does not guarantee actual 435 reachability. A receiving entity should always be prepared for 436 reachability failures and associated retry and failover mechanisms. 438 A GRO might carry multiple references for the same target. These may 439 lead to multiple paths from the receiving entity to the referenced 440 entity. The referring entity is not likely to know which path is 441 best. The receiving entity will need to make a choice, possibly by 442 policy (e.g. [RFC3484]) or possibly by trial and error (e.g. 443 [RFC4038], [RFC5534]). Even if a reference is in scope, and within 444 its defined lifetime, it may have become unreachable since it was 445 sent. The whole problem of path selection is quite complex in 446 itself, and is not discussed further in this document. 448 4. Summary of Requirements 450 R1: A GRO should contain all available information that the referring 451 entity can provide (subject to security policy) about the scope, 452 lifetime, format and source of the referral. It is the 453 responsibility of the referring entity to construct a GRO on the 454 basis of information in its possession. 456 [[ Discussion invited: Another view is that a GRO should contain the 457 minimum information required to establish connectivity. The problem 458 is that the referring entity may not know enough about the context of 459 the receiving entity to determine what that minimum is. ]] 461 R2: It is the responsibility of the receiving entity to interpret and 462 check this information by testing reachability. Due to the barriers 463 to connectivity in today's Internet, the referring entity cannot 464 guarantee that the referenced entity can be reached by any specific 465 reference. This can only be checked by the receiving entity. In the 466 event of a reachability problem, the alternative information in the 467 GRO may assist the receiving entity to find a working path. 469 R3: A GRO must contain at least one Reference. One option would be 470 to make the presence of at least one IP address mandatory. However, 471 there are alternatives, the most obvious one being an FQDN. Any form 472 of identifier-locator separation, with HIP [RFC5201] as an example, 473 may also offer an alternative. Therefore, we do not require a GRO to 474 include an IP address, even though its inclusion is a very likely 475 case. 477 R4: A GRO should be self-contained in a context-independent format. 478 Even if it is forwarded several times across the network, the 479 ultimate receiving entity should be able to extract and interpret all 480 the information inserted by the original referring entity. 482 R5: A GRO should be compact and designed for efficient processing. 484 R6: The GRO format must not be specific to a given IP version. 486 R7: The GRO format should be extensible with well-defined backwards 487 compatibility. 489 R8: A GRO must be able to contain any reasonable number of References 490 of mixed types. 492 R9: Each Reference may carry any reasonable number of Qualifiers. 494 R10: To maintain efficiency, intrinsic error detection or correction 495 for GROs should not be mandatory. Therefore, GROs should be sent 496 over a channel supporting error detection or correction. 498 R11: To maintain efficiency, intrinsic cryptographic authentication 499 of GROs should not be mandatory. The use of an authenticated channel 500 to transmit GROs is recommended. 502 R12: To maintain efficiency, intrinsic encryption of GROs should not 503 be mandatory. The use of an encrypted channel to transmit GROs is 504 recommended. 506 R13: A GRO must be able to include a lifetime as a Qualifier for each 507 Reference. 509 R14: A GRO must be able to include a scope identifier (ScopeID) as a 510 Qualifier for each Reference. 512 R15: There needs to be a high level of assurance that ScopeIDs are 513 unique, or at least that a GRO will never be forwarded outside a 514 region in which ScopeIDs are unique. 516 R16: All referring and receiving entities need to be aware of the 517 ScopeID(s) that apply to them. However, it is clearly undesirable to 518 create a new global registration scheme for ScopeIDs. 520 R17: If shared scope (or set of scopes) is determined between the 521 referring and receiving entities, a referral should ideally only 522 include information useful in that scope or set of scopes. If shared 523 scope is uncertain, a referral should include all information that 524 might be useful, taking privacy considerations into account. 526 [[ Discussion invited: Should we also require optional preference 527 information for each reference in a GRO, or alternatively require 528 that references be listed in order of preference? Here is some 529 tentative text. ]] 531 Rxx: A preference order (or reachability trust level?) may be 532 associated with references. 534 Ryy: The receiving entity will interpret the preferences in 535 accordance with local policies (sometimes on per interface basis). 537 5. Security Considerations 539 It should be noted that GROs cannot function as a way to nullify the 540 effect of a firewall or any other security mechanism. If the 541 receiving entity chooses a particular reference in the GRO and 542 attempts to send packets to the corresponding IP address, whether 543 they are delivered or not will depend on the existing security 544 mechanisms, whatever they may be. 546 Nevertheless, if a site security policy requires it, certain 547 references may be excluded from GROs sent to certain destinations. 548 This would require a security policy mechanism to be added to the 549 process of generating GROs. 551 Forged or intercepted GROs would enable a wide variety of attacks. 552 Although not fundamentally different from attacks based on forged or 553 observed IP addresses or FQDNs, no doubt GROs would allow such 554 attacks to be more ingenious, simply because they provide more 555 information than an address or FQDN alone. As noted in Section 4, 556 GROs should be transmitted through authenticated and encrypted 557 channels. Since this is a requirement of the channel and not of the 558 GRO, and the channel used depends on a specific use case, it is not 559 further elaborated here. 561 Conceivably, an extension to the GRO format could be defined which 562 would allow it to carry security information (for example, some sort 563 of handle or nonce to authorise firewall penetration). Any such 564 extension must be adequately encrypted, in such a way that only a 565 receiving entity in possession of a given key can decrypt it. This 566 is necessary even if the GRO is transmitted through a secure channel. 568 GROs raise potential privacy issues, which are not explored in this 569 document. For example, in the SIP context, mechanisms such as 570 [RFC3323] and [I-D.ietf-sip-ua-privacy] are available to hide 571 information that might identify end-points. Usage scenarios for GROs 572 must ensure that they do not unintentionally defeat privacy 573 solutions. 575 6. IANA Considerations 577 This document requests no action by IANA. 579 7. Contributing authors 581 At the moment, one editor is shown for this document. Authors of two 582 preceding drafts whose text has been used were: Mohamed Boucadair, 583 Joel Halpern, Sheng Jiang, Keith Moore and Bo Zhou. 585 8. Acknowledgements 587 This document was requested by the GROBJ BOF at IETF76. Valuable 588 comments and contributions were made by Scott Brim, Alan Ford, Simon 589 Perreault, Andrew Sullivan, Dan Wing, and others. 591 This document was produced using the xml2rfc tool [RFC2629]. 593 9. Change log 595 draft-carpenter-grobj-reqts-00: original version, 2010-01-20 597 10. References 599 10.1. Normative References 601 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 602 Addresses", RFC 4193, October 2005. 604 10.2. Informative References 606 [I-D.boucadair-softwire-cgn-bypass] 607 Boucadair, M., "Procedure to bypass DS-lite AFTR", 608 draft-boucadair-softwire-cgn-bypass-00 (work in progress), 609 December 2009. 611 [I-D.ietf-mmusic-ice] 612 Rosenberg, J., "Interactive Connectivity Establishment 613 (ICE): A Protocol for Network Address Translator (NAT) 614 Traversal for Offer/Answer Protocols", 615 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 617 [I-D.ietf-sip-ua-privacy] 618 Munakata, M., Schubert, S., and T. Ohba, "UA-Driven 619 Privacy Mechanism for SIP", draft-ietf-sip-ua-privacy-08 620 (work in progress), May 2009. 622 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 623 STD 9, RFC 959, October 1985. 625 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 626 E. Lear, "Address Allocation for Private Internets", 627 BCP 5, RFC 1918, February 1996. 629 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 630 RFC 1958, June 1996. 632 [RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 633 Address Behaviour Today", RFC 2101, February 1997. 635 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 636 June 1999. 638 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 639 February 2000. 641 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 642 Issues", RFC 3234, February 2002. 644 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 645 Initiation Protocol (SIP)", RFC 3323, November 2002. 647 [RFC3484] Draves, R., "Default Address Selection for Internet 648 Protocol version 6 (IPv6)", RFC 3484, February 2003. 650 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 651 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 652 March 2005. 654 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 655 Castro, "Application Aspects of IPv6 Transition", 656 RFC 4038, March 2005. 658 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 659 Description Protocol", RFC 4566, July 2006. 661 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 662 June 2007. 664 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 665 "Host Identity Protocol", RFC 5201, April 2008. 667 [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and 668 Locator Pair Exploration Protocol for IPv6 Multihoming", 669 RFC 5534, June 2009. 671 Author's Address 673 Brian Carpenter (editor) 674 Department of Computer Science 675 University of Auckland 676 PB 92019 677 Auckland, 1142 678 New Zealand 680 Email: brian.e.carpenter@gmail.com