Network Working Group A. Langley
Internet-Draft Google Inc
Expires: January 16, 2009 July 15, 2008
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.
Langley Expires January 16, 2009 [Page 1]
Internet-Draft SYNACK Payloads July 2008
Abstract
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
applications.
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
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
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
frame.
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
fallback.
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
"TBD-IANA-KIND1".
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.
[transport-middlebox]
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
"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.
Langley Expires January 16, 2009 [Page 17]