Internet DRAFT - draft-arkko-strint-networking-functions
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
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", <https://www.torproject.org/>.
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]