Internet DRAFT - draft-arkko-strint-networking-functions


Network Working Group                                           J. Arkko
Internet-Draft                                                  Ericsson
Intended status: Informational                             March 6, 2014
Expires: September 7, 2014

                    Privacy and Networking Functions


   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

   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
   ( 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

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.


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


   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, 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.


   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.


   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.


   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.


   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.

              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
   Jorvas  02420


Arkko                   Expires September 7, 2014               [Page 7]