idnits 2.17.1 draft-yourtchenko-tran-announce-dns-01.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 31, 2010) is 5133 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 4871 (Obsoleted by RFC 6376) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-07) exists of draft-tuexen-sctp-udp-encaps-03 == Outdated reference: A later version (-01) exists of draft-wing-http-new-tech-00 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Yourtchenko 3 Internet-Draft D. Wing 4 Intended status: Standards Track cisco 5 Expires: October 2, 2010 March 31, 2010 7 A la carte: Announcing the supported transport protocols via DNS 8 draft-yourtchenko-tran-announce-dns-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 2, 2010. 33 Copyright Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 While TCP has enjoyed many enhancements over the decades, it is 48 useful to allow applications to use new transports, such as SCTP. It 49 is inefficient to naively probe the server using the new transport 50 protocol. This document proposes a new DNS resource record which 51 provides an efficient way to query which protocols are supported by a 52 server. The presence of this record will allow the client to avoid 53 the excessive probing. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 59 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Contents of RR . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Comparison with SRV records . . . . . . . . . . . . . . . . . . 4 62 6. The example of a zone file . . . . . . . . . . . . . . . . . . 5 63 7. Deployment considerations . . . . . . . . . . . . . . . . . . . 5 64 8. Evaluation of existing resource record types . . . . . . . . . 6 65 8.1. TXT RR . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 8.2. WKS RR . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8.3. CNAME RR . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 70 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 12.1. Normative References . . . . . . . . . . . . . . . . . . . 8 73 12.2. Informative References . . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 Many new transport protocols have been developed in recent years DCCP 79 [RFC4340], SCTP [RFC4960], but have seen little deployment on the 80 Internet. There are two reasons for the lack of deployment: IPv4 81 middleboxes (e.g, NAT, firewall) which block the new protocol and 82 lack of application support for the transport protocol. By running 83 the transport protocols over UDP ( DCCPoUDP 84 [I-D.phelan-dccp-natencap] and SCTPoUDP 85 [I-D.tuexen-sctp-udp-encaps]), or utilizing IPv6, hosts can overcome 86 the problems caused by IPv4 middleboxes. But once a client 87 application supports a new transport protocol a new problem arises: 88 the client application has no choice but to probe the server (and the 89 network) with all of the viable transport protocols. For example, an 90 HTTP client that supports both TCP and SCTP would need to send a TCP 91 SYN and an SCTP INIT and SCTP over UDP until the client learns if 92 both the network path and the server support TCP, SCTP, or SCTP over 93 UDP. This is described in detail in I-D.wing-http-new-tech 94 [I-D.wing-http-new-tech] 96 This specification defines a new DNS resource record (RR) which helps 97 optimize the probing. With the new RR, the server can advertise 98 which transport protocols it supports for a specific application. 99 With that information, the client application only needs to probe the 100 network path for those transport protocols. This helps reduce 101 unnecessary network traffic and, more importantly, prevents 102 degradation of the user experience when a new transport protocol is 103 enabled on the client and is being deployed on servers on the 104 Internet. 106 2. Notational Conventions 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. Description 114 This proposal introduces the new resource record type, which we 115 denote "XPORT", that allows to get the answer to the question "For a 116 given application-level protocol APP on the host HOST in the domain 117 DOMAIN, which transport protocol should I choose ?". 119 The client that wants to know the preferred transport, would query 120 for this record on the name _app.hostname.example.com, and parse the 121 received reply in order to get the list of the transports that the 122 server(s) can offer for this application. Each of the returned RRs 123 would contain the transport choice along with the preference value 124 for this choice. The smaller values mean more preferred choices. 125 [LATER: the parameters for the transport may also be specified] 127 Subsequently, the client would use the application name and the 128 resolved transport name to query the SRV records to get the actual 129 hostname and port to connect to. 131 4. Contents of RR 133 The preference is encoded as a single byte value between 48 and 57 - 134 which gives the textual representation in the ASCII format between 135 '0' and '9'. The protocol and its optional parameters are encoded 136 into a comma-separated string. The protocol is the name of the 137 protocol suitable for passing to getprotobyname(), prefixed with "_". 139 +-------+-------+-------+ . . . 140 | pref | proto and parms .... 141 +-------+-------+-------+ . . . 143 The parameters are protocol-specific. When the casing of the 144 parameters is not explicitly specified, they MUST be all-lowercase. 146 The only currently defined parameter is "udp" which means the 147 protocol-specific encapsulation over UDP. 149 The reason for choosing this format is the possibility of easy 150 (ab)use of TXT record in order to hold the same information, in case 151 the new RR is deemed unnecessary. 153 5. Comparison with SRV records 155 The SRV records allow to answer the question: "What is the hostname 156 and port?" - given the known application, transport, and domain name. 158 The XPORT records allow to answer the question: "What is the 159 transport ?" - given the known application and domain name. 161 The client stack MAY use SRV records subsequently in order to 162 determine the ports and the real hosts that will serve this 163 application. 165 The server application SHOULD also listen on the default transports 166 for that application, to avoid the malfunction of the clients that 167 are not upgraded (for example, for HTTP that would be TCP transport). 169 6. The example of a zone file 171 Borrowing the example of the zone file from SRV RR [RFC2782] 172 specification, we show the relevant part of it in order to hint the 173 clients about the various protocols that can be used for accessing 174 "http://www.example.com", and to hint that 175 "http://newhost.example.com/" is only accessible via SCTP. 177 $ORIGIN example.com. 178 @ SOA server.example.com. root.example.com. ( 179 1995032001 3600 3600 604800 86400 ) 180 NS server.example.com. 181 NS ns1.provider.example.net. 182 NS ns2.provider.example.net. 184 ; http transport selection - signal to use SCTP over UDP and SCTP, 185 ; and use tcp as a fallback mechanism for the host 'www' 187 _http.www XPORT 5 _sctp,udp 188 XPORT 5 _sctp 189 XPORT 9 _tcp 191 www A 192.0.2.10 193 ; the newhost's http is only accessible via SCTP, hint about this. 194 ; note that we still need to have the host listening on TCP 195 ; as well to preserve the legacy hosts' operation. 197 _http.newhost XPORT 1 _sctp 199 newhost A 192.0.2.11 201 7. Deployment considerations 203 The DNS was chosen instead of any other mechanism due to its 204 widespread deployment, and the logical positioning of the protocol 205 within the applications. 207 The incremental nature of the change means that only one side would 208 need to be modified initially (content provider). The unmodified 209 applications would work with the default transport assignments for 210 the application protocols. 212 The separate resource record allows for the separation of this 213 mechanism from the existing ones. However, considering the possibly 214 lower entry costs, one could consider using the TXT record for 215 storing the preference information - the encoding is crafted in such 216 a way that using the TXT record is straightforward. (TBD: should we 217 consider a "magic number" to be put in the beginning of the TXT 218 record to ensure we can verify the usage of TXT record, or the exotic 219 name is enough ?) 221 It may be noted that the extra lookup mentioned in this proposal adds 222 to the latency of the initial connection establishment. However, 223 assuming the transports are not going to change, it should be 224 feasible to use longer lifetimes, and cache the results at the local 225 recursive name server. 227 8. Evaluation of existing resource record types 229 Introducing of a new resource record type takes time due to the 230 standards process, the availability of the support for the new 231 resource record type in the nameservers code, problems with the 232 nameservers that fail when queried for the resource record types they 233 do not recognize, and so on. This section evaluates how well 234 existing resource records can provide the functionality similar to 235 XPORT. 237 8.1. TXT RR 239 The authors have considered following the example of RFC4871 240 [RFC4871] to use a subdomain starting with an underscore. This would 241 result in the following zone file examples: 243 _xport._http.www.example.com in txt ("SCTP,SCTPUDP,TCP") 244 _xport._http.server.example.com in txt ("TCP") 246 This could be extended further to provide weights like the XPORT 247 resource record, for example: 249 _xport._http.www.example.com in txt ("SCTP=5,SCTPUDP=5,TCP=9") 251 While this could be quickly deployed, it was felt too cumbersome. 253 8.2. WKS RR 255 The WKS resource record [RFC1035] provides functionality similar to 256 the proposal in this document. However, WKS returns an IPv4 address 257 and a bitmask of ports for the explicit transport protocols (e.g. 258 TCP, SCTP), thus is not suitable for IPv6 nor for protocols which 259 lack an IETF protocol assignment (such as tunneling a transport 260 protocol over UDP [I-D.tuexen-sctp-udp-encaps]). 262 8.3. CNAME RR 264 The authors considered an idea of combining the SRV and defining a 265 "catch-all" transport name, say, "_any", and use the SRV records to 266 help determine the transport(s) offered by the server. The 267 "_appname._any.example.com" record would contain multiple CNAME 268 records, say, "_appname._tcp.example.com" and 269 "_appname._sctp.example.com". The latter names would have the valid 270 SRV records for the respective protocols. Consequently, an SRV 271 lookup of _appname._any.example.com would give a CNAME and the 272 corresponding SRV record - and the contents of the CNAME could be 273 analyzed to extract the protocol to use. 275 However, this would not work, because the section 3.6.2 of [RFC1034] 276 allows only one CNAME. 278 9. Security Considerations 280 This proposal allows to influence the preferred transport for the 281 client by means of DNS. 283 First possibility is attacker preventing the DNS reply from reaching 284 the client. In this case, the client would fallback to the default. 285 However, assuming the attacker can block the message on the way back 286 to the client, it could block the A/AAAA response messages as well, 287 so this path does not add any new attack vectors. 289 Second possibility is for the attacker to spoof the packets in case 290 they are not there. In this case, the attacker could have spoofed 291 the A/AAAA responses as well and direct the client to an address of 292 his choosing. Therefore, this path does not add any new attack 293 vectors either. 295 10. Acknowledgements 297 Thanks to Bryan Ford and Janardhan Iyengar for the discussions that 298 led to this draft. Thanks to Erik Kline for the review and 299 suggestions. 301 11. IANA Considerations 303 This document has no IANA actions. 305 12. References 306 12.1. Normative References 308 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 309 STD 13, RFC 1034, November 1987. 311 [RFC1035] Mockapetris, P., "Domain names - implementation and 312 specification", STD 13, RFC 1035, November 1987. 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, March 1997. 317 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 318 specifying the location of services (DNS SRV)", RFC 2782, 319 February 2000. 321 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 322 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 324 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 325 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 326 Signatures", RFC 4871, May 2007. 328 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 329 RFC 4960, September 2007. 331 12.2. Informative References 333 [I-D.phelan-dccp-natencap] 334 Phelan, T., "Datagram Congestion Control Protocol (DCCP) 335 Encapsulation for NAT Traversal (DCCP-NAT)", 336 draft-phelan-dccp-natencap-03 (work in progress), 337 November 2009. 339 [I-D.tuexen-sctp-udp-encaps] 340 Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP 341 Packets", draft-tuexen-sctp-udp-encaps-03 (work in 342 progress), December 2009. 344 [I-D.wing-http-new-tech] 345 Wing, D., Yourtchenko, A., and P. Natarajan, "Happy 346 Eyeballs: Successful Introduction of New Technology to 347 HTTP", draft-wing-http-new-tech-00 (work in progress), 348 July 2009. 350 Authors' Addresses 352 Andrew Yourtchenko 353 cisco 354 6a de Kleetlaan 355 Diegem 1831 356 BE 358 Phone: +32 2 704 5494 359 Email: ayourtch@cisco.com 361 Dan Wing 362 cisco 363 170 West Tasman Drive 364 San Jose CA 95134 365 USA 367 Email: dwing@cisco.com