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

Versions: 00

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]


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