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 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. TCP-ENO probing protocol
• 3. Configuration
• 4. Security considerations
• 5. References
• 5.1. Normative References
• 5.2. Informative References
• Authors' Addresses

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.

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

5.2. Informative References

Authors' Addresses