TCP Maintenance and Minor F. Gont
Extensions (tcpm) UK CPNI
Internet-Draft A. Oppermann
Intended status: BCP FreeBSD
Expires: December 24, 2010 June 22, 2010
On the generation of TCP timestamps
draft-gont-timestamps-generation-00.txt
Abstract
This document discusses the generation of TCP timestamps. In
particular, it discusses a number of algorithms for producing
monotonically-increasing timestamps such that timestamps can be used
to reduce the TIME-WAIT state, and an algorithm for generating
timestamps that allows for extended SYN-cookies.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
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 December 24, 2010.
Copyright Notice
Copyright (c) 2010 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
Gont & Oppermann Expires December 24, 2010 [Page 1]
Internet-Draft Generation of TCP timestamps June 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Timestamps generation for TCPs that perform the active open . . 3
3. Timestamps generation for TCPs that perform the passive
open . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Extended SYN cookies . . . . . . . . . . . . . . . . . . . 4
3.2. Potential problems with SYN-cookies . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Gont & Oppermann Expires December 24, 2010 [Page 2]
Internet-Draft Generation of TCP timestamps June 2010
1. Introduction
The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP
to include a timestamp value in its segments, that can be used used
to perform two functions: Round-Trip Time Measurement (RTTM), and
Protection Against Wrapped Sequences (PAWS).
For the purpose of PAWS, the timestamps sent on a connection are
required to be monotonically increasing. RFC 1323 does not include
any further requirements for the TCP timestamps (such as the initial
timestamp value or the relationship between timestamps that
correspond to different connections).
[I-D.gont-tcpm-tcp-timestamps] discusses an algorithm that employs
TCP timestamps to reduce the TIME-WAIT state. The aforementioned
algorithm benefits from timestamps that are monotonically-increasing
across connections.
Some TCP implementations have employed TCP timestamps to implement
extended SYN-Cookies [RFC4987]. These implementations encode part of
the information received in an incomming SYN segment in the TCP
timestamps sent in the SYN/ACK.
It should be noted that a TCP implementation could benefit from the
benefits of both timestamps generation approaches. Monotonically-
increasing timestamps could be generated for TCPs that perform the
active open, while timestamps for TCPs that perform the passive open
could be generated according to [Opperman].
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].
2. Timestamps generation for TCPs that perform the active open
While there is no requirement that timestamps are monotonically
increasing across TCP connections, the generation of timestamps such
that they are monotonically increasing across connections between the
same two endpoints allows the use of timestamps for improving the
handling of SYN segments that are received while the corresponding
four-tuple is in the TIME-WAIT state. That is, the timestamp option
could be used to perform heuristics to determine whether to allow the
creation of a new incarnation of a connection that is in the TIME-
WAIT state.
It is RECOMMENDED that timestamps are generated with a similar
algorithm to that introduced by RFC 1948 [RFC1948] for the generation
Gont & Oppermann Expires December 24, 2010 [Page 3]
Internet-Draft Generation of TCP timestamps June 2010
of Initial Sequence Numbers (ISNs). That is,
timestamp = T() + F(localhost, localport, remotehost, remoteport,
secret_key)
where the result of T() is a global system clock that complies with
the requirements of Section 4.2.2 of RFC 1323 [RFC1323], and F() is a
function that should not be computable from the outside without
knowledge of the secret key (secret_key). Therefore, we suggest F()
to be a cryptographic hash function of the connection-id and some
secret data (which could be chosen randomly).
F() provides an offset that will be the same for all incarnations of
a connection between the same two endpoints, while T() provides the
monotonically increasing values that are needed for PAWS.
3. Timestamps generation for TCPs that perform the passive open
3.1. Extended SYN cookies
The purpose of SYN cookies is to avoid keeping track of all SYN's we
receive and to be able to handle SYN floods from bogus source
addresses (where we will never receive any reply). SYN floods try to
exhaust all our memory and available slots in the SYN cache table to
cause a denial of service to legitimate users of the local host.
The idea of SYN cookies is to encode and include all necessary
information about the connection setup state within the SYN-ACK we
send back and thus to get along without keeping any local state until
the ACK to the SYN-ACK arrives (if ever). Everything we need to know
should be available from the information we encoded in the SYN-ACK.
This implementation extends the orginal idea and first implementation
of FreeBSD by using not only the initial sequence number field to
store information but also the timestamp field if present. This way
we can keep track of the entire state we need to know to recreate the
session in its original form. Almost all TCP speakers implement
RFC1323 timestamps these days. For those that do not we still have
to live with the known shortcomings of the ISN-only SYN cookies.
Initial Sequence Number (ISN) we send:
Gont & Oppermann Expires December 24, 2010 [Page 4]
Internet-Draft Generation of TCP timestamps June 2010
31|................................|0
DDDDDDDDDDDDDDDDDDDDDDDDDMMMRRRP
D = MD5 Digest (first dword)
M = MSS index
R = Rotation of secret
P = Odd or Even secret
Figure 1
The MD5 Digest is computed with over following parameters:
o randomly rotated secret
o struct in_conninfo containing the remote/local ip/port (IPv4&IPv6)
o the received initial sequence number from remote host
o the rotation offset and odd/even bit
Timestamp we send:
31|................................|0
DDDDDDDDDDDDDDDDDDDDDDSSSSRRRRA5
D = MD5 Digest (third dword) (only as filler)
S = Requested send window scale
R = Requested receive window scale
A = SACK allowed
5 = TCP-MD5 enabled (not implemented yet)
XORed with MD5 Digest (forth dword)
Figure 2
The timestamp isn't cryptographically secure and doesn't need to be.
The double use of the MD5 digest dwords ties it to a specific remote/
local host/port, remote initial sequence number and our local time
limited secret. A received timestamp is reverted (XORed) and then
the contained MD5 dword is compared to the computed one to ensure the
timestamp belongs to the SYN-ACK we sent. The other parameters may
have been tampered with but this isn't different from supplying bogus
values in the SYN in the first place.
3.2. Potential problems with SYN-cookies
Some of the problems of ISN-only SYN cookies remain, nevertheless.
Consider the problem of a recreated (and retransmitted) cookie. If
Gont & Oppermann Expires December 24, 2010 [Page 5]
Internet-Draft Generation of TCP timestamps June 2010
the original SYN was accepted, the connection is established. The
second SYN is inflight, and if it arrives with an ISN that falls
within the receive window, the connection is killed.
A heuristic to determine when to accept syn cookies is not necessary.
An ACK flood would cause the syncookie verification to be attempted,
but a SYN flood causes syncookies to be generated. Both are of equal
cost, so there's no point in trying to optimize the ACK flood case.
Also, if you don't process certain ACKs for some reason, then all
someone would have to do is launch a SYN and ACK flood at the same
time, which would stop cookie verification and defeat the entire
purpose of syncookies.
4. Security Considerations
This document describes a number of algorithms for generating TCP
timestamps.
[CPNI-TCP] provides a thorough discussion of the security
implications of TCP timestamps.
5. IANA Considerations
This document has no actions for IANA.
6. Acknowledgements
Fernando Gont would like to thank the United Kingdom's Centre for the
Protection of National Infrastructure (UK CPNI) for their continued
support.
7. References
7.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
Gont & Oppermann Expires December 24, 2010 [Page 6]
Internet-Draft Generation of TCP timestamps June 2010
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP",
RFC 1337, May 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[CPNI-TCP]
CPNI, "Security Assessment of the Transmission Control
Protocol (TCP)", http://www.cpni.gov.uk/Docs/
tn-03-09-security-assessment-TCP.pdf, 2009.
[FreeBSD-impl]
FreeBSD, "FreeBSD", http://www.freebsd.org/cgi/
cvsweb.cgi/src/sys/netinet/
tcp_syncache.c?rev=1.99&content-type=text/x-cvsweb-markup,
2008.
[I-D.gont-tcpm-tcp-timestamps]
Gont, F., "Reducing the TIME-WAIT state using TCP
timestamps", draft-gont-tcpm-tcp-timestamps-04 (work in
progress), March 2010.
[Linux] The Linux Project, "http://www.kernel.org".
[Linux-impl]
Westphal, F., "Add support for TCP-options via
timestamps", http://lwn.net/Articles/277219/, 2008.
[Opperman]
Oppermann, A., "FYI: Extended TCP syncookies in FreeBSD-
current", Post to the tcpm mailing-list. Available at: ht
tp://www.ietf.org/mail-archive/web/tcpm/current/
msg02251.html, 2006.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, August 2007.
Gont & Oppermann Expires December 24, 2010 [Page 7]
Internet-Draft Generation of TCP timestamps June 2010
Authors' Addresses
Fernando Gont
UK Centre for the Protection of National Infrastructure
Email: fernando@gont.com.ar
URI: http://www.cpni.gov.uk
Andre Oppermann
FreeBSD
Email: andre@freebsd.org
Gont & Oppermann Expires December 24, 2010 [Page 8]