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]