idnits 2.17.1 draft-arkko-strint-networking-functions-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 a Security Considerations section. ** 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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 191: '... REQUIRED INFORMATION...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2014) is 3676 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational March 6, 2014 5 Expires: September 7, 2014 7 Privacy and Networking Functions 8 draft-arkko-strint-networking-functions-00 10 Abstract 12 This paper discusses the inherent tussle between network functions 13 and some aspects of privacy. There is clearly room for a much 14 improved privacy in Internet communications, but there are also 15 interesting interactions with network functions, e.g., what 16 information networks need to provide a service. Exploring these 17 limits is useful to better understand potential improvements. 19 Status of This Memo 21 This Internet-Draft is submitted to IETF 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 September 7, 2014. 36 Copyright Notice 38 Copyright (c) 2014 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. 48 1. Introduction 50 This paper discusses the inherent tussle between network functions 51 and some aspects of privacy. There is clearly room for a much 52 improved privacy in Internet communications, but there are also 53 interesting interactions with network functions, e.g., what 54 information networks need to provide a service. Exploring these 55 limits is useful to better understand potential improvements. 57 This draft has been inspired by the discussions during last call of 58 [I-D.farrell-perpass-attack]. These discussions touched on some of 59 issues listed in this draft. 61 Section 2 presents some examples of these interactions. Section 3 62 discusses some principles that may help us deal with the issues. The 63 goal is to design protocols so that the information leakage from 64 network functions is appropriately balanced by the benefits. 66 2. Examples 68 2.1. Example 1: Forwarding 70 To start with a very basic observation, destination addresses need to 71 be visible to routers that forward packets. In practice the same 72 holds also for source addresses. While forged source addresses are 73 common, in practice most protocols that IP can carry require 74 bidirectional communication by sending packets back to the source 75 address. As a result, the communicating parties are identified to 76 network nodes along the path. 78 There are ways to hide this information, of course. For instance, 79 encrypted tunnels transport information from one gateway to another 80 and hide the actual packets, including their source and destination 81 addresses. However, the gateway nodes and the part of path where the 82 packets are not carried in the tunnel still see the addresses. 84 A more extreme form of address hiding can be provided by purpose- 85 built privacy routing solutions such as Tor [TOR]. Here the goal is 86 to hide address information from as many nodes as possible, down to 87 perhaps only the communicating client knowing who it is and who it is 88 going to send a packet to, at least within the Tor network itself. 89 Still, the routing network as a whole may have enough information to 90 uncover the communicating parties. Clearly, subverting multiple 91 nodes is more difficult than an individual node, but software attacks 92 and other issues may make such attacks also possible. 94 Of course, privacy routing and anonymization solutions usually incur 95 some cost, such as extra delay due to going through additional nodes. 97 Even more extreme but impractical forms of address hiding can be 98 imagined, such as delivering all traffic to all destinations. 100 2.2. Example 2: Equal Cost Multipath 102 When several network paths between the same two nodes are known by 103 the routing system, it may be desirable to share traffic among them 104 [RFC6438]. One such techniques is known as Equal Cost Multipath 105 (ECMP) routing. While performing ECMP, it is desirable to maintain 106 roughly equal share of traffic on each path, as well as to minimize 107 packet reordering in individual traffic flows. 109 Packets are commonly distributed to these paths by hashing source and 110 destination addresses. This technique works well, and exposes no 111 more information than the routing system would already have anyway. 112 However, some alternate systems use the IPv6 flow identifier or the 113 5-tuple (source, destination, protocol, source port, destination 114 port) as an input to the hash function. These techniques may work 115 better in situations when the number of hosts communicating through 116 the ECMP network is small. 118 As a result, at least some ECMP implementations benefit from the 119 ability to see information from the packet beyond the addresses. 121 2.3. Example 3: Caching and Distribution 123 Caching is a commonly used technique to store frequently needed 124 information closer to the user, potentially helping reduce network 125 load at the original source and delivering the content to the end 126 user faster. Similarly, distributing content close to the user in a 127 large number of content delivery nodes or local servers is commonly 128 used for largely the same reasons. 130 However, these techniques can also make the user's traffic or other 131 information more widely available. Caching requires content (or at 132 least encrypted content) to be visible to a network node. 133 Distribution implies that information relating to the user may exist 134 in a large number of nodes in the world, e.g., due to copying it to 135 multiple content nodes that the user might access. 137 2.4. Example 4: Packet inspection 139 Firewalls and other packet inspection mechanisms look at packets in 140 the network at least at the level of the 5-tuple and possibly further 141 into them. Reasons for deploying these mechanisms vary from 142 protecting a network to traffic prioritization and enforcing policy. 144 Application-Layer Gateways (ALGs) not only inspect traffic but also 145 commonly modify it. Another class of devices looking and modifying 146 traffic are Network Address Translators (NATs). For the purposes of 147 sharing an address, packets are inspected, modified, and re-sent in a 148 different form. 150 It is interesting to observe that these functions were not originally 151 envisioned, but grew out of necessity and opportunity. The 152 opportunity was the uniform nature of Internet traffic and the lack 153 of cryptographic confidentiality protection, which made it possible 154 to inspect the packets beyond addresses. (As a side note, the 155 functions have also had an effect on what traffic can be carried in 156 the networks, when, for instance, NATs only supported UDP and TCP 157 traffic.) 159 2.5. Example 5: Network management 161 Networks are usually carefully engineered and monitored to ensure 162 correctness and performance. However, some of these activities 163 require information about the traffic transported by the network. 164 For instance, debugging tools can reveal information about the 165 network itself, traffic statistics (including applications and 166 destinations) can be tracked to improve efficiency, and so on. 168 2.6. Example 6: Additional Parties 170 Communication systems often involve parties that are not directly 171 interested in the communication itself, but are there to assist 172 others in making that communication possible. For instance, 173 certificate authorities help secure communications. And many 174 applications have nodes that act as rendezvous points where 175 communication is possible even with some of the parties not always 176 present. E-mail servers or social media systems, for instance. 178 While these parties are helpful or even essential, they also pose 179 problems. Infrastructure systems are a vulnerable point for attacks 180 as well as pervasive surveillance activities. 182 3. Principles 184 It is important to understand that the examples in the previous 185 section are just that - examples. There are many functions where the 186 user benefits from a network function that requires some information 187 to be disclosed. The crux is how to design protocols such that the 188 information leakage is appropriately balanced by the benefits. In 189 the following I propose some guidelines for this. 191 REQUIRED INFORMATION 192 There are some functions that are absolutely required for the network 193 to operate: routing and management, for instance. The information 194 that these functions must have needs to be made available to the 195 network. 197 NEED TO KNOW 199 But information should not be unnecessarily distributed to everyone 200 without a reason. 202 This is the basis in many of the current efforts in making a bigger 203 part of Internet traffic encrypted [RFC1984]. Encrypting information 204 makes it invisible to others than the intended recipients. As a side 205 effect, it also ensures that protected information is not over time 206 used for some new network functionality along the path. 208 But encryption is just one form of reducing information distribution. 209 Good design leads to clear responsibilities for different network 210 nodes. For instance, in a hierarchical naming system such as the 211 DNS, the root does not need to know that a search is being made for 212 host1.departmenta.example.com, or what request is going to be sent to 213 that node. In good design, each node or layer is given the 214 information that it requires to do its task, not more. 216 Another example is onion routing, where the necessary routing 217 information is not given to all nodes, but rather just a subset. 219 Traffic flow confidentiality - such as padding tunneled packets to 220 all be of same length, or filling a link with traffic regardless of 221 whether there are real packets, helps conceal that communication is 222 taking place. However, if these practices are implemented without 223 the knowledge of the network management and monitoring systems, it 224 can confuse the observed state of the network. For instance, a 225 network can appear to carry more traffic than it really is. 227 Finally, it is necessary to minimise the amount of information that 228 can be collected in any protocol. This minimisation applies both to 229 the information that is being sent, as well as information that might 230 be collected through correlating several pieces of information. For 231 instance, stable identifiers should only be used between sessions if 232 they provide a necessary function in the application; otherwise they 233 are just unnecessary baggage that can be used to track the node or 234 user in question. 236 LIMITING THE ROLE OF ADDITIONAL PARTIES 238 As noted earlier, additional parties are often essential for 239 applications. It makes sense to benefit from rendezvous points, 240 storage and computation facilities, central points of authority for 241 certificates, and many other things. 243 Obviously, the number of additional parties should still be 244 minimised. But perhaps more importantly, they need to have very 245 clear and limited roles. For instance, while a node may be needed to 246 perform a task, it does not follow that it should necessarily have 247 access to all information or be able to make all kinds of decisions. 249 One example of this what was said above about DNS root and the 250 information it gets to see. Other examples include storing cleartext 251 vs. encrypted information on network storage, using specific 252 cryptographic authorization (for a purpose by someone in a context, 253 not by someone for anything), and caching encrypted rather than 254 cleartext content. 256 USER CHOICE 258 Where there is a reasonable argument that different deployments, 259 organisations, or users prefer different choices, protocols should 260 leave these choices to them. A good protocol can run in many 261 different environments and for different purposes. 263 As an example, Mobile IPv6 route optimization reduces the latency of 264 communicating with peers, but can cause problems for location privacy 265 [RFC4882]. Tunneling all traffic via the home network changes the 266 situation, but also removes the benefit. However, as mobile nodes 267 can choose which method to apply, this is ultimately a user choice. 269 VISIBILITY 271 And users should be aware of what goes on in the network, and what 272 information is exposed to whom. The classic example of this is the 273 browser key icon that shows whether a secure connection (HTTPS) is 274 being used. 276 In particular, exposing user-level information (such as content) to 277 third parties is something that needs to be clearly flagged, if it is 278 necessary at all. 280 EASE OF USE 282 While having choice and ability to configure highly secure networking 283 services is good, the usability of these services is a common 284 problem. The classic example of this problem is end-to-end e-mail 285 encryption, which works well in limited domains, but has been 286 difficult to use and turn on in the global Internet. 288 4. Informative References 290 [RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG 291 Statement on Cryptographic Technology and the Internet", 292 RFC 1984, August 1996. 294 [RFC4882] Koodli, R., "IP Address Location Privacy and Mobile IPv6: 295 Problem Statement", RFC 4882, May 2007. 297 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 298 for Equal Cost Multipath Routing and Link Aggregation in 299 Tunnels", RFC 6438, November 2011. 301 [I-D.farrell-perpass-attack] 302 Farrell, S. and H. Tschofenig, "Pervasive Monitoring is an 303 Attack", draft-farrell-perpass-attack-06 (work in 304 progress), February 2014. 306 [TOR] TOR, "The TOR Project", . 308 Appendix A. Acknowledgments 310 The author would like to thank Benoit Claise, Dave Crocker, Bengt 311 Sahlin, Adrian Farrell, Stewart Bryant, Salvatore Loreto, Stephen 312 Farrell, Mats Naslund, Sean Turner, Russ Housley, Randy Bush, Steven 313 Bellovin, Mohit Sethi, John Mattsson, and many others for lively 314 discussions of this problem space. 316 Author's Address 318 Jari Arkko 319 Ericsson 320 Jorvas 02420 321 Finland 323 Email: jari.arkko@piuha.net