Faster application handshakes with SYN/ACK payloads
draft-agl-tcpm-sadata-00

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

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 http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

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

Abstract

This document describes an extension to TCP (Postel, J., “Transmission Control Protocol,” September 1981.) [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 applications.

Table of Contents

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

1.  Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  Introduction

Consider the following, diagrammatic representation of the beginning of an SSH (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Transport Layer Protocol,” January 2006.) [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

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

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.

   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

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

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 (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1,” April 2006.) [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 fallback.

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

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

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

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.

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 (Braden, B., “Extending TCP for Transactions -- Concepts,” November 1992.) [RFC1379] and 1644 (Braden, B., “T/TCP -- TCP Extensions for Transactions Functional Specification,” July 1994.) [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.

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] (Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP,” September 2001.). 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] (Medina, A., Allman, M., and S. Floyd, “Measuring Interactions Between Transport Protocols and Middleboxes,” ACM SIGCOMM/USENIX Internet Measurement Conference, October 2004.).

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 TBD-IANA-KIND1.

9.  Acknowledgements

Wesley Eddy kindly reviewed initial versions of this draft.

10.  References

10.1. Normative References

10.2. Informative References

Appendix A.  Changes

Author's Address

Full Copyright Statement

Copyright © 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 “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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 http://www.ietf.org/ipr.

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 ietf-ipr@ietf.org.