Network Working Group J. Arkko Internet-Draft Ericsson Intended status: Informational March 6, 2014 Expires: September 7, 2014 Privacy and Networking Functions draft-arkko-strint-networking-functions-00 Abstract This paper discusses the inherent tussle between network functions and some aspects of privacy. There is clearly room for a much improved privacy in Internet communications, but there are also interesting interactions with network functions, e.g., what information networks need to provide a service. Exploring these limits is useful to better understand potential improvements. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 7, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Arkko Expires September 7, 2014 [Page 1] Internet-Draft Networking and Privacy March 2014 1. Introduction This paper discusses the inherent tussle between network functions and some aspects of privacy. There is clearly room for a much improved privacy in Internet communications, but there are also interesting interactions with network functions, e.g., what information networks need to provide a service. Exploring these limits is useful to better understand potential improvements. This draft has been inspired by the discussions during last call of [I-D.farrell-perpass-attack]. These discussions touched on some of issues listed in this draft. Section 2 presents some examples of these interactions. Section 3 discusses some principles that may help us deal with the issues. The goal is to design protocols so that the information leakage from network functions is appropriately balanced by the benefits. 2. Examples 2.1. Example 1: Forwarding To start with a very basic observation, destination addresses need to be visible to routers that forward packets. In practice the same holds also for source addresses. While forged source addresses are common, in practice most protocols that IP can carry require bidirectional communication by sending packets back to the source address. As a result, the communicating parties are identified to network nodes along the path. There are ways to hide this information, of course. For instance, encrypted tunnels transport information from one gateway to another and hide the actual packets, including their source and destination addresses. However, the gateway nodes and the part of path where the packets are not carried in the tunnel still see the addresses. A more extreme form of address hiding can be provided by purpose- built privacy routing solutions such as Tor [TOR]. Here the goal is to hide address information from as many nodes as possible, down to perhaps only the communicating client knowing who it is and who it is going to send a packet to, at least within the Tor network itself. Still, the routing network as a whole may have enough information to uncover the communicating parties. Clearly, subverting multiple nodes is more difficult than an individual node, but software attacks and other issues may make such attacks also possible. Of course, privacy routing and anonymization solutions usually incur some cost, such as extra delay due to going through additional nodes. Arkko Expires September 7, 2014 [Page 2] Internet-Draft Networking and Privacy March 2014 Even more extreme but impractical forms of address hiding can be imagined, such as delivering all traffic to all destinations. 2.2. Example 2: Equal Cost Multipath When several network paths between the same two nodes are known by the routing system, it may be desirable to share traffic among them [RFC6438]. One such techniques is known as Equal Cost Multipath (ECMP) routing. While performing ECMP, it is desirable to maintain roughly equal share of traffic on each path, as well as to minimize packet reordering in individual traffic flows. Packets are commonly distributed to these paths by hashing source and destination addresses. This technique works well, and exposes no more information than the routing system would already have anyway. However, some alternate systems use the IPv6 flow identifier or the 5-tuple (source, destination, protocol, source port, destination port) as an input to the hash function. These techniques may work better in situations when the number of hosts communicating through the ECMP network is small. As a result, at least some ECMP implementations benefit from the ability to see information from the packet beyond the addresses. 2.3. Example 3: Caching and Distribution Caching is a commonly used technique to store frequently needed information closer to the user, potentially helping reduce network load at the original source and delivering the content to the end user faster. Similarly, distributing content close to the user in a large number of content delivery nodes or local servers is commonly used for largely the same reasons. However, these techniques can also make the user's traffic or other information more widely available. Caching requires content (or at least encrypted content) to be visible to a network node. Distribution implies that information relating to the user may exist in a large number of nodes in the world, e.g., due to copying it to multiple content nodes that the user might access. 2.4. Example 4: Packet inspection Firewalls and other packet inspection mechanisms look at packets in the network at least at the level of the 5-tuple and possibly further into them. Reasons for deploying these mechanisms vary from protecting a network to traffic prioritization and enforcing policy. Arkko Expires September 7, 2014 [Page 3] Internet-Draft Networking and Privacy March 2014 Application-Layer Gateways (ALGs) not only inspect traffic but also commonly modify it. Another class of devices looking and modifying traffic are Network Address Translators (NATs). For the purposes of sharing an address, packets are inspected, modified, and re-sent in a different form. It is interesting to observe that these functions were not originally envisioned, but grew out of necessity and opportunity. The opportunity was the uniform nature of Internet traffic and the lack of cryptographic confidentiality protection, which made it possible to inspect the packets beyond addresses. (As a side note, the functions have also had an effect on what traffic can be carried in the networks, when, for instance, NATs only supported UDP and TCP traffic.) 2.5. Example 5: Network management Networks are usually carefully engineered and monitored to ensure correctness and performance. However, some of these activities require information about the traffic transported by the network. For instance, debugging tools can reveal information about the network itself, traffic statistics (including applications and destinations) can be tracked to improve efficiency, and so on. 2.6. Example 6: Additional Parties Communication systems often involve parties that are not directly interested in the communication itself, but are there to assist others in making that communication possible. For instance, certificate authorities help secure communications. And many applications have nodes that act as rendezvous points where communication is possible even with some of the parties not always present. E-mail servers or social media systems, for instance. While these parties are helpful or even essential, they also pose problems. Infrastructure systems are a vulnerable point for attacks as well as pervasive surveillance activities. 3. Principles It is important to understand that the examples in the previous section are just that - examples. There are many functions where the user benefits from a network function that requires some information to be disclosed. The crux is how to design protocols such that the information leakage is appropriately balanced by the benefits. In the following I propose some guidelines for this. REQUIRED INFORMATION Arkko Expires September 7, 2014 [Page 4] Internet-Draft Networking and Privacy March 2014 There are some functions that are absolutely required for the network to operate: routing and management, for instance. The information that these functions must have needs to be made available to the network. NEED TO KNOW But information should not be unnecessarily distributed to everyone without a reason. This is the basis in many of the current efforts in making a bigger part of Internet traffic encrypted [RFC1984]. Encrypting information makes it invisible to others than the intended recipients. As a side effect, it also ensures that protected information is not over time used for some new network functionality along the path. But encryption is just one form of reducing information distribution. Good design leads to clear responsibilities for different network nodes. For instance, in a hierarchical naming system such as the DNS, the root does not need to know that a search is being made for host1.departmenta.example.com, or what request is going to be sent to that node. In good design, each node or layer is given the information that it requires to do its task, not more. Another example is onion routing, where the necessary routing information is not given to all nodes, but rather just a subset. Traffic flow confidentiality - such as padding tunneled packets to all be of same length, or filling a link with traffic regardless of whether there are real packets, helps conceal that communication is taking place. However, if these practices are implemented without the knowledge of the network management and monitoring systems, it can confuse the observed state of the network. For instance, a network can appear to carry more traffic than it really is. Finally, it is necessary to minimise the amount of information that can be collected in any protocol. This minimisation applies both to the information that is being sent, as well as information that might be collected through correlating several pieces of information. For instance, stable identifiers should only be used between sessions if they provide a necessary function in the application; otherwise they are just unnecessary baggage that can be used to track the node or user in question. LIMITING THE ROLE OF ADDITIONAL PARTIES As noted earlier, additional parties are often essential for applications. It makes sense to benefit from rendezvous points, Arkko Expires September 7, 2014 [Page 5] Internet-Draft Networking and Privacy March 2014 storage and computation facilities, central points of authority for certificates, and many other things. Obviously, the number of additional parties should still be minimised. But perhaps more importantly, they need to have very clear and limited roles. For instance, while a node may be needed to perform a task, it does not follow that it should necessarily have access to all information or be able to make all kinds of decisions. One example of this what was said above about DNS root and the information it gets to see. Other examples include storing cleartext vs. encrypted information on network storage, using specific cryptographic authorization (for a purpose by someone in a context, not by someone for anything), and caching encrypted rather than cleartext content. USER CHOICE Where there is a reasonable argument that different deployments, organisations, or users prefer different choices, protocols should leave these choices to them. A good protocol can run in many different environments and for different purposes. As an example, Mobile IPv6 route optimization reduces the latency of communicating with peers, but can cause problems for location privacy [RFC4882]. Tunneling all traffic via the home network changes the situation, but also removes the benefit. However, as mobile nodes can choose which method to apply, this is ultimately a user choice. VISIBILITY And users should be aware of what goes on in the network, and what information is exposed to whom. The classic example of this is the browser key icon that shows whether a secure connection (HTTPS) is being used. In particular, exposing user-level information (such as content) to third parties is something that needs to be clearly flagged, if it is necessary at all. EASE OF USE While having choice and ability to configure highly secure networking services is good, the usability of these services is a common problem. The classic example of this problem is end-to-end e-mail encryption, which works well in limited domains, but has been difficult to use and turn on in the global Internet. Arkko Expires September 7, 2014 [Page 6] Internet-Draft Networking and Privacy March 2014 4. Informative References [RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG Statement on Cryptographic Technology and the Internet", RFC 1984, August 1996. [RFC4882] Koodli, R., "IP Address Location Privacy and Mobile IPv6: Problem Statement", RFC 4882, May 2007. [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, November 2011. [I-D.farrell-perpass-attack] Farrell, S. and H. Tschofenig, "Pervasive Monitoring is an Attack", draft-farrell-perpass-attack-06 (work in progress), February 2014. [TOR] TOR, "The TOR Project", . Appendix A. Acknowledgments The author would like to thank Benoit Claise, Dave Crocker, Bengt Sahlin, Adrian Farrell, Stewart Bryant, Salvatore Loreto, Stephen Farrell, Mats Naslund, Sean Turner, Russ Housley, Randy Bush, Steven Bellovin, Mohit Sethi, John Mattsson, and many others for lively discussions of this problem space. Author's Address Jari Arkko Ericsson Jorvas 02420 Finland Email: jari.arkko@piuha.net Arkko Expires September 7, 2014 [Page 7]