[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01

Network Working Group                                         A. Langley
Internet-Draft                                                Google Inc
Expires: January 16, 2009                                  July 15, 2008

          Faster application handshakes with SYN/ACK payloads

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 16, 2009.

Langley                 Expires January 16, 2009                [Page 1]

Internet-Draft               SYNACK Payloads                   July 2008


   This document describes an extension to TCP [RFC0793] which permits a
   small, mostly constant data payload to be carried in the SYN+ACK
   frame of the 3-way handshake.  This new behaviour is enabled by an
   option in the SYN packet to ensure backwards compatibility.  We
   should how this has latency benefits, specifically for cryptographic

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The SYNACK Payload Permitted Option  . . . . . . . . . . . . .  6
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   5.  Implementation details . . . . . . . . . . . . . . . . . . . .  9
   6.  Comparison to T/TCP  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Middlebox Interactions . . . . . . . . . . . . . . . . . . . . 11
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     10.1.  Normative References  . . . . . . . . . . . . . . . . . . 14
     10.2.  Informative References  . . . . . . . . . . . . . . . . . 14
   Appendix A.  Changes . . . . . . . . . . . . . . . . . . . . . . . 15
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17

Langley                 Expires January 16, 2009                [Page 2]

Internet-Draft               SYNACK Payloads                   July 2008

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Langley                 Expires January 16, 2009                [Page 3]

Internet-Draft               SYNACK Payloads                   July 2008

2.  Introduction

   Consider the following, diagrammatic representation of the beginning
   of an SSH [RFC4253] connection:

      0 SYN     ------------>          0.5
      1         <------------ SYNACK   0.5
      1 Ident   ------------>          1.5
      1 NList   ------------>          1.5
      2         <------------ Ident    1.5
      2         <------------ NList    1.5
      2         <------------ KX       1.5
      2 KX      ------------>          2.5

        Ident: A string which contains the SSH implementation name
        NList: Name list: the list of supported algorithms
        KX: Key exchange data, usually Diffie-Hellman

   Standard SSH protocol

                                 Figure 1

   Here, arrows from the left to the right are frames from client to
   server.  Times on the left are the times that the client either
   transmits or receives a packet (and vice versa).  Times are measured
   in round trip times (RTT), so that it takes 0.5 units for a frame to
   pass between the hosts.

   The above diagram is for a latency tuned implementation of SSH,
   specifically, the client doesn't wait for the server's identity
   string to be received.  And yes, in this ideal scenario, the client
   can only start transmitting useful data after 2 RTT and the server
   can only start transmitting after 2.5 RTT.  As a rule of thumb, the
   RTT from San Francisco to London is 150ms, so this means a 300ms
   latency, at least, when setting up this connection.

   (To keep the discussion simple, we assume there is no packet loss,
   that the path is symmetrical and that the client's ACK of the 3-way
   handshake carries a data payload.)

   Now, let us consider a hypothetical SSH protocol where the server
   could include a short, constant byte-string in the SYNACK packet of
   the TCP exchange.  First we compact the name-list (part of the
   algorithm negotiation) and put it in the SYNACK.

Langley                 Expires January 16, 2009                [Page 4]

Internet-Draft               SYNACK Payloads                   July 2008

      0 SYN     ------------>          0.5
      1         <------------ SA+NList 0.5
      1 NList   ------------>          1.5
      1 KX      ------------>          1.5
      2         <------------ KX       1.5

   SSH protocol with a compact name list carried in the SYN+ACK frame

                                 Figure 2

   In this situation, the client knows the results of the algorithm
   negotiation as soon as the SYNACK comes back and can include the
   correct key exchange with the first ACK packet.  This reduces the
   server's latency by a full RTT since it can transmit as soon as the
   3-way handshake completes.

   As a final optimisation, we could assume either that the server takes
   a successful guess at the key exchange algorithm to use, or that the
   application level protocol specifies a single key exchange algorithm:

      0 SYN     ------------>          0.5
      1         <------------ SA+KX    0.5
      1 KX      ------------>          1.5

   A protocol which includes key exchange information in the SYN+ACK

                                 Figure 3

   Here the client's latency is 1 RTT and the server's is 1.5 RTT, which
   is equal to the minimum required by the 3-way handshake, saving a
   full RTT of latency from the initial diagram.  In order for the
   SYNACK to be sent without application involvement, some cryptographic
   tricks are needed, as detailed below.

   None of the above discussion is specific to SSH.  Many cryptographic
   protocols, such as TLS [RFC4346], involve a similar scheme and could
   benefit from lower latency.  Specifically designed protocols could
   style themselves on the third example and achieve, essentially, no
   latency overhead.  This also allows existing protocols to be extended
   with encryption with no additional round trips and with transparent

Langley                 Expires January 16, 2009                [Page 5]

Internet-Draft               SYNACK Payloads                   July 2008

3.  The SYNACK Payload Permitted Option

   Several commonly used TCP stacks don't support receiving data
   payloads in SYNACK packets.  Thus, SYNACK payloads cannot be enabled
   unless it's known that the remote host can support them.  To that end
   we define an option in the SYN frame:

                        1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2   . . .
   +---------------+---------------+--------------- . . .
   |     Kind =    |  Length = 2+n | Flag bits
   | TDB-IANA-KIND1|               |0 1 2 3 4 5 6 7 . . .
   +---------------+---------------+--------------- . . .

   TCP Flags Option

                                 Figure 4

   The flags option contains a conceptually infinite number of bits
   which are numbered from the MSB of the first byte, upwards.  If not
   specified, bits are assumed to be false.  The flags option MUST be as
   short as possible and yet cover all the true bits that need to be
   specified.  If no bits are true, the flags option MUST NOT be
   included.  The meanings of flag bits are to be assigned by IANA.  For
   this RFC, bit 0 is assumed to be "SYNACK Payload Permitted".

   For example, if no other flag bits are to be set, SYNACK payload
   support would be advertised by a 3-byte option whose first data byte
   is "0x80".

   Hosts MUST NOT set the SYNACK Payload Permitted bit unless an
   application has requested it for the current socket.  If SYNACK
   Payload Permitted is requested for a socket, the host SHOULD include
   the SYNACK Payload Permitted.  For example, it may choose not to in
   the case of having to retransmit the SYN frame as middleware may be
   filtering the extra option.

   Upon receipt of a SYN frame with SYNACK Payload Permitted, a host
   SHOULD include a data payload in any resulting SYNACK frame, if so
   configured.  For a given SYN, if any resulting SYNACK frame has a
   payload then all resulting frames MUST have a payload.  If a host
   chooses to retransmit a SYN frame without a SYNACK Payload Permitted
   bit when previous transmissions included the bit, it MUST reject any
   SYNACK with a payload.  If a SYN frame for a given handshake is ever
   transmitted without a SYNACK Payload Permitted bit, all
   retransmissions MUST NOT include the bit.

   The data payload affects the SEQ/ACK numbers like any other data.

Langley                 Expires January 16, 2009                [Page 6]

Internet-Draft               SYNACK Payloads                   July 2008

   Any ACK frame resulting from such a SYNACK frame MUST acknowledge the
   whole SYNACK frame, including the SYN flag.  If a frame is the final
   ACK in a 3-way handshake, a host MUST reject it unless it
   acknowledges the whole SYNACK frame.

   A host MUST NOT include a data payload in any SYNACK resulting from a
   SYN frame without SYNACK Payload Permitted.

   A host MUST provide a method for applications to set a SYNACK
   payload, to determine if a passive-open connection sent a SYNACK
   payload and to determine if an active open connection received a
   payload in the SYNACK frame.  This is because the SYNACK data appears
   to the application like any other, but its presence may alter the
   application level protocol.

   It's expected that a host will make a best effort to include a SYNACK
   payload when the application has set one.  It may choose not to for a
   number of reasons including: the SYN frame didn't request it, the
   host is under heavy SYN load, is using SYN cookies or that the host
   is having to retransmit the SYNACK.

Langley                 Expires January 16, 2009                [Page 7]

Internet-Draft               SYNACK Payloads                   July 2008

4.  Security Considerations

   Any payload in a SYNACK packet must be as frugal as possible since a
   host will be transmitting it to an unconfirmed address.  If a 40 byte
   frame could elicit a 1500 byte reply to an attacker controlled
   address, this would be readily used to hide and amplify distributed
   denial of service attacks.

   Thus we specify a maximum size of 64 bytes for the payload.  This is
   sufficient to include a strong elliptic curve key (256 bits), a 64-
   bit nonce and a small amount of overhead (12 bytes).

Langley                 Expires January 16, 2009                [Page 8]

Internet-Draft               SYNACK Payloads                   July 2008

5.  Implementation details

   Although the exact implementation details shouldn't be spelled out by
   this document, consideration must be given to it.

   Breaking the very common BSD sockets API by having applications get
   advance notice of connections so that they can specify the SYNACK
   payload (if any) would be painfully incongruent with current
   implementations.  Thus it would be ideal if the SYNACK payload for a
   given, listening socket were constant; a constant value can be
   specified by a "setsockopt".

   However, for the specific motivating case here (cryptography), it's
   very helpful to include an nonce.  One could consider using the SEQ
   and ACK numbers as nonces but the overloading is distasteful and they
   are quite short for secure nonces.  So, at the risk of over
   optimising for a specific case: implementations SHOULD allow
   applications to specify that the first 8 bytes of the SYNACK payload
   be replaced with a cryptographically strong nonce.

   For the case where the key exchange material is carried in the SYN+
   ACK frame, the public key thus has to be constant.  This means that
   certain schemes which provide perfect forward secrecy are
   inapplicable and that implementors should be careful to use key
   exchange algorithms which are still secure under this model.

Langley                 Expires January 16, 2009                [Page 9]

Internet-Draft               SYNACK Payloads                   July 2008

6.  Comparison to T/TCP

   The idea of including data in frames which also carry a SYN flag
   isn't new: it was included in the experimental T/TCP RFCs 1379
   [RFC1379] and 1644 [RFC1644].  T/TCP suffered because it broke the
   assumption that the source address of a new connection from a
   passive-open socket had been verified by a 3-way handshake.  This was
   a critical security issue for applications like RSH which often used
   source address whitelists.

   This draft doesn't break any such assumptions that applications may
   be depending on.  Source addresses for new connections are still
   validated by a 3-way handshake for passive-open sockets.
   Additionally, this draft is dramatically simpler than T/TCP: it
   doesn't introduce any additional TCP states nor does it deal with the
   complexity of including payloads in a SYN frame.  Nor does this draft
   apply to any application which is unaware of it since applications
   are required to explicitly configure SYNACK payloads before they come
   into effect.

Langley                 Expires January 16, 2009               [Page 10]

Internet-Draft               SYNACK Payloads                   July 2008

7.  Middlebox Interactions

   The large number of middleboxes (firewalls, proxies, protocol
   scrubbers, etc) currently present in the Internet pose some
   difficulty for deploying new TCP options.  Some firewalls may block
   segments that carry unknown options.  For instance, if the flags
   option is not understood by a firewall, incoming SYNs advertising
   SYNACK payload support may be dropped, preventing connection
   establishment.  This is similar to the ECN blackhole problem, where
   certain faulty hosts and routers throw away packets with ECN bits set
   [RFC3168].  Some recent results indicate that for new TCP options,
   this may not be a significant threat, with only 0.2% of web requests
   failing when carrying an unknown option [transport-middlebox].

Langley                 Expires January 16, 2009               [Page 11]

Internet-Draft               SYNACK Payloads                   July 2008

8.  IANA Considerations

   This document requires IANA to create a new registry of flag option
   bits, currently containing a single entry: bit 0 is assigned by
   SYNACK Payload Permitted.

   This document requires IANA to update values in its registry of TCP
   options numbers to assign a new entry, referred herein as

Langley                 Expires January 16, 2009               [Page 12]

Internet-Draft               SYNACK Payloads                   July 2008

9.  Acknowledgements

   Wesley Eddy kindly reviewed initial versions of this draft.

Langley                 Expires January 16, 2009               [Page 13]

Internet-Draft               SYNACK Payloads                   July 2008

10.  References

10.1.  Normative References

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

   [RFC4253]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, January 2006.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC1379]  Braden, B., "Extending TCP for Transactions -- Concepts",
              RFC 1379, November 1992.

   [RFC1644]  Braden, B., "T/TCP -- TCP Extensions for Transactions
              Functional Specification", RFC 1644, July 1994.

              Medina, A., Allman, M., and S. Floyd, "Measuring
              Interactions Between Transport Protocols and Middleboxes",
              ACM SIGCOMM/USENIX Internet Measurement Conference,
              October 2004.

Langley                 Expires January 16, 2009               [Page 14]

Internet-Draft               SYNACK Payloads                   July 2008

Appendix A.  Changes

Langley                 Expires January 16, 2009               [Page 15]

Internet-Draft               SYNACK Payloads                   July 2008

Author's Address

   Adam Langley
   Google Inc

   Email: agl@imperialviolet.org

Langley                 Expires January 16, 2009               [Page 16]

Internet-Draft               SYNACK Payloads                   July 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Langley                 Expires January 16, 2009               [Page 17]

Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/