Internet DRAFT - draft-bittau-tcpinc-bcp
draft-bittau-tcpinc-bcp
Network Working Group A. Bittau
Internet-Draft D. Giffin
Intended status: Informational D. Mazieres
Expires: September 3, 2016 Stanford University
March 2, 2016
Best current practices for TCP-ENO configuration
draft-bittau-tcpinc-bcp-00
Abstract
TCP-ENO negotiates encryption of TCP connections, protecting legacy
applications and protocols from passive eavesdropping. TCP-ENO
generally falls back to unencrypted TCP when not supported by both
endpoints or the network. Nonetheless, certain middlebox behavior
could cause TCP connections to fail entirely in conjunction with TCP-
ENO. This document specifies conventions for servers against which
TCP-ENO machines can test network paths for TCP-ENO compatibility,
and describes the best current practice for enabling TCP-ENO only
when it is unlikely to cause connection failure.
Status of This Memo
This Internet-Draft is submitted 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 3, 2016.
Copyright Notice
Copyright (c) 2016 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
Bittau, et al. Expires September 3, 2016 [Page 1]
Internet-Draft tcpinc-api March 2016
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. TCP-ENO probing protocol . . . . . . . . . . . . . . . . . . 3
3. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Security considerations . . . . . . . . . . . . . . . . . . . 3
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Normative References . . . . . . . . . . . . . . . . . . 4
5.2. Informative References . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction
The TCP Encryption Negotiation Option (TCP-ENO)
[I-D.ietf-tcpinc-tcpeno] permits hosts to negotiate encryption of a
TCP connection. TCP-ENO is designed to fail by reverting to
unencrypted TCP. Such behavior is necessary for incremental
deployment, and is no worse than the status quo in which there is no
TCP-layer encryption. However, one outcome worse than the status quo
would be for TCP-ENO connections to fail completely where unencrypted
connections would work. Fortunately, if TCP-ENO is not supported by
both endpoints, or if middleboxes strip the ENO option from packets,
then implementations simply revert to unencrypted TCP upon receiving
a SYN or initial ACK segment without an ENO option. This fallback
approach also applies to interception proxies [RFC3040], which
typically terminate TCP connections and hence will not include ENO in
their SYN segments if they do not know about it.
However, given that the goal of TCP-ENO is to encrypt previously
plaintext traffic, there is always the possibility that a middlebox
performing deep packet inspection could shut down connections when
the ciphertext does not resemble an expected higher-level application
protocol such as HTTP. Such middleboxes would cause TCP-ENO
connections to fail. This document describes a technique for probing
the network so as to enable TCP-ENO only in places where middleboxes
do not induce such failures. TCP-ENO configuration
[I-D.bittau-tcpinc-api] can then be used to avoid such failures.
Bittau, et al. Expires September 3, 2016 [Page 2]
Internet-Draft tcpinc-api March 2016
2. TCP-ENO probing protocol
Hosts can determine whether or not a network path breaks TCP-ENO with
the help of an external server. A precedent for probing middlebox
behavior is the STUN protocol [RFC5389], which applications use to
characterize NAT. STUN relies on having a known, publicly-accessible
server beyond any locally administered middleboxes.
Like STUN, TCP-ENO probing requires a known external server running
an agreed upon protocol. This should be done using HTTP as the
protocol, and responding to the path "/tcp-eno/session-id" with a
response of type "text/plain". Upon successful TCP-ENO negotiation,
servers should reply with the string "encrypted " followed by a
lower-case hexadecimal encoding of the tcpcrypt session ID followed
by a newline. For connections on which TCP-ENO fails, the same path
should return the string "unencrypted\n" (with no session ID).
3. Configuration
STUN is typically invoked by applications that require peer-to-peer
communication to decide whether they can accept incoming connections.
For TCP-ENO, which affects all TCP connections, it makes more sense
to probe for network compatibility at the time network interfaces are
configured by DHCP [RFC2131], stateless address autoconfiguration
[RFC4862], or other mechanisms. Many DHCP implementation already
provide hooks through which such probes can be configured.
Upon interface configuration, a host should probe a known external
server to request "/tcp-enno/session-id". If the request works with
TCP-ENO disabled but hangs or resets with TCP-ENO enabled, then TCP-
ENO should be disabled for the host. Otherwise, if the probe
succeeds, then even if it returns "unencrypted", TCP-ENO should be
enabled (for the possible benefit of local connections), as
middleboxes may simply be stripping off the option.
Hosts should perform the above probe twice, using both port 80 and a
different port, we suggest 8080, on the same server. Given the
prevalence of interception proxies on port 80, port 80 may experience
entirely different failure modes from other ports. If the port 80
probe fails, TCP-ENO should be disabled for port 80. If the other
probe fails, TCP-ENO should be disabled entirely.
4. Security considerations
The proposed mechanism allows an attacker to convince hosts to
disable TCP-ENO, which makes subsequent eavesdropping easier.
However, this is but one of several ways attackers have to downgrade
TCP-ENO connections. Until TCP-level encryption has been more widely
Bittau, et al. Expires September 3, 2016 [Page 3]
Internet-Draft tcpinc-api March 2016
deployed and applications authenticate the session ID, TCP-ENO's
protection will primarily be against passive eavesdroppers anyway.
Servers providing ENO path testing will have knowledge of where
machines are using TCP-ENO, which has potential privacy implications.
5. References
5.1. Normative References
[I-D.bittau-tcpinc-api]
Bittau, A., Boneh, D., Giffin, D., Handley, M., Mazieres,
D., and E. Smith, "Interface Extensions for TCP-ENO",
draft-bittau-tcpinc-api-01 (work in progress), March 2016.
[I-D.ietf-tcpinc-tcpeno]
Bittau, A., Boneh, D., Giffin, D., Handley, M., Mazieres,
D., and E. Smith, "TCP-ENO: Encryption Negotiation
Option", draft-ietf-tcpinc-tcpeno-01 (work in progress),
February 2016.
5.2. Informative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>.
[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040,
DOI 10.17487/RFC3040, January 2001,
<http://www.rfc-editor.org/info/rfc3040>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008,
<http://www.rfc-editor.org/info/rfc5389>.
Authors' Addresses
Bittau, et al. Expires September 3, 2016 [Page 4]
Internet-Draft tcpinc-api March 2016
Andrea Bittau
Stanford University
353 Serra Mall, Room 288
Stanford, CA 94305
US
Email: bittau@cs.stanford.edu
Daniel B. Giffin
Stanford University
353 Serra Mall, Room 288
Stanford, CA 94305
US
Email: dbg@scs.stanford.edu
David Mazieres
Stanford University
353 Serra Mall, Room 290
Stanford, CA 94305
US
Email: dm@uun.org
Bittau, et al. Expires September 3, 2016 [Page 5]
