idnits 2.17.1 draft-nottingham-gin-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 04, 2014) is 3556 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft 4 Intended status: Informational July 04, 2014 5 Expires: January 05, 2015 7 Granular Information about Networks 8 draft-nottingham-gin-00 10 Abstract 12 Protocol endpoints often want to adapt their behavior based upon the 13 current properties of the network path, but have limited information 14 available to aid these decisions. This document motivates discussion 15 of protocol work to make this information available. 17 Status of This Memo 19 This Internet-Draft is submitted 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). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 05, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 53 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Granular Information about Networks: Straw-Men . . . . . . . 4 55 3.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.2. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.4. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 62 5.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 Protocol endpoints often want to adapt their behavior based upon the 68 current properties of the network path. 70 For example, it has become common practice for HTTP [RFC7230] servers 71 to adapt the responses they give based upon the IP address of the 72 client, client "fingerprinting" (e.g., using the User-Agent request 73 header field), and other properties. 75 Likewise, client using HTTP sometimes adapt their behavior in a 76 similar fashion; for example, a mobile client on a 3G network might 77 download a different video file then if it were on a wifi network. 78 Often, the goal of these adaptations is to improve user experience by 79 making content more suitable for the properties of the network it is 80 traversing, whilst utilizing the network resources more optimally. 82 There are currently a number of sources of information to inform 83 these decisions, but they share a few limitations. For example, it 84 is possible to measure delay to a given server using ICMP, but the 85 results are ephemeral, and may change if a different server has 86 changed. 88 There have also been attempts to provide relevant information in 89 APIs; for example, [netinfo]. Doing so has proven to be difficult, 90 because of the limited information available to the client. 92 To address these issues, network operators have been deploying 93 infrastructure that uses the information available to them to modify 94 content; e.g., [bytemobile], [verizon], [syniverse], [flashnet]. 96 However, at the same time, encryption has become more prevalent on 97 the Internet, with many prominent (and heavily traffic'd) Web sites 98 going HTTPS-only. This frustrates attempts to adapt content in the 99 network. 101 This document proposes an alternative approach. By making the 102 information that the network operators have available to the 103 endpoints, it allows them to make more informed choices about 104 content, thereby allowing the user experience to be improved and the 105 network to be used more optimally without requiring that the end-to- 106 end nature of encryption (e.g., in HTTPS) to be compromised. 108 1.1. Notational Conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 2. Requirements 116 To be useful to endpoints, the information a network exposes needs to 117 be: 119 o Specific to the client - General information about network 120 properties is often an improvement over current practice, but to 121 be truly useful, it should be able to be tailored to a specific 122 client IP address. 124 o Reasonably current - Information from fifteen minutes ago is often 125 useless; when necessary, an endpoint ought to be able to get 126 information that is fresh (on the granularity of a few seconds). 128 o Scalable - The overhead of conveying information to clients ought 129 to be minimal, and it needs to be usable on the scale of a large 130 Web site. 132 o Private - The protocol ought not expose details of private 133 networks, or any personally identifying information beyond that 134 already available. 136 A protocol for exposing this information necessarily must choose the 137 scope of its applicability. Due to the nature of the Internet, it is 138 not practical to meet the goals above for the end-to-end path(s) 139 between any given pair of IP addresses; the permutations are 140 impractical, and discovering meaningful information on this scale is 141 likewise unlikely. 143 However, it is comparatively easy for a network operator to expose 144 what it considers to be the "last mile" properties of an IP address. 145 For example, an ISP providing ADSL access to its subscribers could 146 advertise the properties of those end links, whereas a mobile 147 operator could use the information available to advertise the 148 properties of individual subscriber handset IP addresses (whether 149 they be globally routable, or behind NAT). 151 This partial information is not a complete picture, of course, but it 152 is information that's difficul to aquire now, and often has a 153 disproprionate impact upon the delivery of content. 155 A protocol for such information ought to expose a minimum of: 157 o Bandwidth - an approximation of the bandwidth currently unused on 158 the "last mile" connection, in bits per second. 160 o Delay - an approximation of delay seen on the "last mile" 161 connection, in milliseconds. 163 o Packet Loss - the current packet loss seen on "last mile" 164 connections from the client, expressed as a percentage. 166 Additional metrics (including some that are operator-specific) might 167 also be useful, and ought to be accommodated. 169 This information, in turn, could be used by Web servers, browsers and 170 other tools to optimize both the responses and requests made. For 171 example, MPEG-DASH clients could use the information about their own 172 address to better choose an encoding; servers could re-encode images 173 and HTML to account for slow networks, based upon the requesting 174 client's IP address. 176 3. Granular Information about Networks: Straw-Men 178 NOTE: the technical mechanisms discussed are straw-men, and might not 179 be the "real" approach. Readers are encouraged to consider and 180 discuss the overall viability of the idea expressed above before 181 focusing too much upon the details below. 183 3.1. DNS 185 One approach would be to using DNS [RFC1035] to convey this 186 information. This has several advantages: 188 o DNS works at the granularity of an IP address 189 o Reverse DNS for a public IP address is often administered by the 190 access network that provisions it 192 o DNS is lightweight and has a built-in caching mechanism 194 Potential disadvantages include: 196 o Servers receiving requests from clients that are unknown (or where 197 there is only stale information available) will need to either 198 wait for the lookup, or act without information for such requests 200 o Additional load on DNS infrastructure may be considerable 202 This would require a new RRTYPE to be defined to carry the 203 information outlined above. 205 3.2. HTTP 207 It might be possible to provide such information with a lightweight 208 HTTP [RFC7230] service exposed by the network operator. However, 209 discovery of that service would still need to be established; this 210 might be possible through DNS. 212 This approach's advantages include: 214 o Built-in caching and scaling mechanisms 216 o Rich extensibility 218 o Familiarity for developers and ops 220 Potential disadvantages include: 222 o Servers receiving requests from clients that are unknown (or where 223 there is only stale information available) will need to either 224 wait for the lookup, or act without information for such requests 226 o Comparatively high overhead 228 3.3. TLS 230 Another approach would be to add another channel in TLS [RFC5246] 231 that does not form part of teh encrypted session, to allow the 232 network to annotate connections directly. 234 This has a few advantages: 236 o Immediate availability of network information in-channel 237 o Direct binding to a single connection 239 o Annotations could be added on subsequent hops 241 However: 243 o Doing so is likely to be technically invasive, my have interop 244 problems with deployed infrastructure 246 o May be seen as a layering violation / security issue 248 3.4. TCP 250 Yet another approach would be to define simliar side-channel 251 mechanisms in TCP [RFC0793]. 253 The advantages and disadvantages of this approach are similar to 254 those around TLS; however, there is an additional disadvantage, in 255 that TCP extensibility is even more constrained than TLS'. 257 4. Security Considerations 259 This document is only exploratory now, but there are already clearly 260 evident security and privacy implications, including: 262 o Whether the information exposed can be used to identify a user 264 o Whether denial of service attacks are possible using this 265 mechanism 267 5. References 269 5.1. Normative References 271 [RFC1035] Mockapetris, P., "Domain names - implementation and 272 specification", STD 13, RFC 1035, November 1987. 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, March 1997. 277 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 278 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 279 2014. 281 5.2. Informative References 283 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 284 793, September 1981. 286 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 287 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 289 [bytemobile] 290 Citrix, "ByteMobile Adaptive Traffic Management", 2014, 291 . 294 [flashnet] 295 Flash Networks, "Optimization Overview", 2014, 296 . 298 [netinfo] W3C, "The Network Information API", 2014, 299 . 301 [syniverse] 302 Syniverse, "Hosted Data Optimization", 2014, . 306 [verizon] Verizon, "VERIZON WIRELESS OPTIMIZED VIEW FOR MOBILE WEB", 307 2014, . 311 Author's Address 313 Mark Nottingham 315 Email: mnot@mnot.net 316 URI: http://www.mnot.net/