idnits 2.17.00 (12 Aug 2021) /tmp/idnits36934/draft-stiemerling-alto-dns-discovery-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 (July 27, 2010) is 4309 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) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 2818 == Outdated reference: draft-ietf-geopriv-lis-discovery has been published as RFC 5986 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO M. Stiemerling 3 Internet-Draft NEC Europe Ltd. 4 Intended status: Standards Track H. Tschofenig 5 Expires: January 28, 2011 Nokia Siemens Networks 6 July 27, 2010 8 A DNS-based ALTO Server Discovery Procedure 9 draft-stiemerling-alto-dns-discovery-00.txt 11 Abstract 13 The Application-Layer Traffic Optimization (ALTO) provides guidance 14 to applications having to select one or several hosts from a set of 15 candidates that are able to provide a desired resource. 17 This document specifies the U-NAPTR based resolution process. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 28, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. U-NAPTR Resolution . . . . . . . . . . . . . . . . . . . . . . 3 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 58 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 61 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 Networking applications today already have access to a great amount 67 of Inter-Provider network topology information. For example, views 68 of the Internet routing table are easily available at looking glass 69 servers and entirely practical to be downloaded by clients. What is 70 missing is knowledge of the underlying network topology from the ISP 71 or Content Provider (henceforth referred as Provider) point of view. 72 In other words, what a Provider prefers in terms of traffic 73 optimization -- and a way to distribute it. 75 The ALTO Service provides information such as preferences of network 76 resources with the goal of modifying network resource consumption 77 patterns while maintaining or improving application performance. 78 This document describes a protocol implementing the ALTO Service. 79 While such service would primarily be provided by the network (i.e., 80 the ISP), content providers and third parties could also operate this 81 service. Applications that could use this service are those that 82 have a choice in connection endpoints. Examples of such applications 83 are peer-to-peer (P2P) and content delivery networks. 85 This document specifies the U-NAPTR based resolution process. To 86 start the U-NAPTR resolution process a domain name needs to be 87 obtained first. One mechanism to obtain such a domain name is via 88 DHCP, as described in [I-D.ietf-geopriv-lis-discovery]. 90 2. Terminology 92 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 93 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 94 and "OPTIONAL" are to be interpreted as described in RFC 2119 95 [RFC2119]. 97 3. U-NAPTR Resolution 99 ALTO servers are identified by U-NAPTR/DDDS (URI-Enabled NAPTR/ 100 Dynamic Delegation Discovery Service) [RFC4848] application unique 101 strings, in the form of a DNS name. An example is 102 'altoserver.example.com'. 104 Clients need to use the U-NAPTR [RFC4848] specification described 105 below to obtain a URI (indicating host and protocol) for the 106 applicable ALTO service. In this document, only the HTTP and HTTPS 107 URL schemes are defined. Note that the HTTP URL can be any valid 108 HTTP URL, including those containing path elements. 110 The following two DNS entries show the U-NAPTR resolution for 111 "example.com" to the HTTPS URL https://altoserver.example.com/secure 112 or the HTTP URL http://altoserver.example.com, with the former being 113 preferred. 115 example.com. 117 IN NAPTR 100 10 "u" "ALTO:https" 118 "!.*!https://altoserver.example.com/secure!" "" 120 IN NAPTR 200 10 "u" "ALTO:http" 121 "!.*!http://altoserver.example.com!" "" 123 End host learn the ALTO's server host name by means beyond the scope 124 of this specification, such as DHCP. 126 4. IANA Considerations 128 This document registers the following U-NAPTR application service 129 tag: 130 Application Service Tag: ALTO 131 Defining Publication: The specification contained within this 132 document. 134 This document registers the following U-NAPTR application protocol 135 tags: 136 o Application Protocol Tag: http 138 Defining Publication: RFC 2616 [RFC2616] 139 o Application Protocol Tag: https 141 Defining Publication: RFC 2818 [RFC2818] 143 5. Security Considerations 145 The address of a ALTO is usually well-known within an access network; 146 therefore, interception of messages does not introduce any specific 147 concerns. 149 The primary attack against the methods described in this document is 150 one that would lead to impersonation of a ALTO server since a device 151 does not necessarily have a prior relationship with a ALTO server. 153 An attacker could attempt to compromise ALTO discovery at any of 154 three stages: 156 1. 1. providing a falsified domain name to be used as input to 157 U-NAPTR 158 2. 2. altering the DNS records used in U-NAPTR resolution 159 3. 3. impersonation of the ALTO 161 This document focuses on the U-NAPTR resolution process and hence 162 this section discusses the security considerations related to the DNS 163 handling. The security aspects of obtaining the domain name that is 164 used for input to the U-NAPTR process is described in respective 165 documents, such as [I-D.ietf-geopriv-lis-discovery]. 167 The domain name that is used to authenticated the ALTO server is the 168 domain name in the URI that is the result of the U-NAPTR resolution. 169 Therefore, if an attacker were able to modify or spoof any of the DNS 170 records used in the DDDS resolution, this URI could be replaced by an 171 invalid URI. The application of DNS security (DNSSEC) [RFC4033] 172 provides a means to limit attacks that rely on modification of the 173 DNS records used in U-NAPTR resolution. Security considerations 174 specific to U-NAPTR are described in more detail in [RFC4848]. 176 An "https:" URI is authenticated using the method described in 177 Section 3.1 of [RFC2818]. The domain name used for this 178 authentication is the domain name in the URI resulting from U-NAPTR 179 resolution, not the input domain name as in [RFC3958]. Using the 180 domain name in the URI is more compatible with existing HTTP client 181 software, which authenticate servers based on the domain name in the 182 URI. 184 An ALTO server that is identified by an "http:" URI cannot be 185 authenticated. If an "http:" URI is the product of the ALTO 186 discovery, this leaves devices vulnerable to several attacks. Lower 187 layer protections, such as layer 2 traffic separation might be used 188 to provide some guarantees. 190 6. Acknowledgements 192 The authors would like to thank Martin Thomson for his feedback on 193 this document. We would like to thank the ALTO working group for 194 their prior discussions on discovery. 196 7. References 198 7.1. Normative References 200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 201 Requirement Levels", RFC 2119, BCP 14, March 1997. 203 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 204 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 205 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 207 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 209 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 210 Service Location Using SRV RRs and the Dynamic Delegation 211 Discovery Service (DDDS)", RFC 3958, January 2005. 213 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 214 Rose, "DNS Security Introduction and Requirements", 215 RFC 4033, March 2005. 217 7.2. Informative References 219 [I-D.ietf-geopriv-lis-discovery] 220 Thomson, M. and J. Winterbottom, "Discovering the Local 221 Location Information Server (LIS)", 222 draft-ietf-geopriv-lis-discovery-15 (work in progress), 223 March 2010. 225 [RFC4848] Daigle, L., "Domain-Based Application Service Location 226 Using URIs and the Dynamic Delegation Discovery Service 227 (DDDS)", RFC 4848, April 2007. 229 Authors' Addresses 231 Martin Stiemerling 232 NEC Laboratories Europe/University of Goettingen 233 Kurfuerstenanlage 36 234 Heidelberg 69115 235 Germany 237 Phone: +49 6221 4342 113 238 Fax: +49 6221 4342 155 239 Email: martin.stiemerling@neclab.eu 240 URI: http://ietf.stiemerling.org 241 Hannes Tschofenig 242 Nokia Siemens Networks 243 Linnoitustie 6 244 Espoo 02600 245 Finland 247 Phone: +358 (50) 4871445 248 Email: Hannes.Tschofenig@gmx.net 249 URI: http://www.tschofenig.priv.at