Skip to main content

Intended status: Standards Track A.Eromenko December 2015
draft-eromenko-ipff-tcp64-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Alexey Eromenko
Last updated 2015-12-28
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-eromenko-ipff-tcp64-00
INTERNET-DRAFT
"TCP 64-bit extension: Modern Variation",
Alexey Eromenko, 2015-12-16,
<draft-eromenko-ipff-tcp64-00.txt>
expiration date: 2016-06-16

Intended status: Standards Track
                                                              A.Eromenko
                                                           December 2015

                  TCP 64-bit extension: "Modern Variation"
                ===========================================
                    for Internet Protocol - Five Fields

Abstract

   This document attempts to modernize TCP protocol for new reality,
   faster bandwidth, encryption-optimization and optional checksums,
   which is required for Identity-Locator Network Protocol (ILNP) 
   compatibility.
   This extension is backwards compatible with the original TCP 
   specification during session establishment, but not compatible 
   during the rest of the session nor with deployed middleboxes.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

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

Copyright Notice

   Copyright (c) 2015 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
   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

   Introduction
   1. TCP Header: "Classic variation"
   2. TCP Header: "Modern variation" a.k.a TCP.64
   2.1. TCP Header: "Modern variation without CRC"
   3. Initiating a TCP.64 Session "Modern Variation"
   4. Checksum ignored option
   Authors' Contacts

Introduction

   TCP in IP-FF comes in several variations.
   The questions is:
   Our operating systems and processors are 64-bit.
   Why not make TCP 64-bit also ?
   Well, I decided to define what TCP 64-bit should look like.

   The session beings with the good-old, time-tested "Classic variation",
    which looks familiar.

1. TCP Header: "Classic variation"

    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4|          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  8|                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12|                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 16|  Data |     |N|C|E|U|A|P|R|S|F|                               |
   | Offset|     |S|W|C|R|C|S|S|Y|I|            Window             |
   |       |     | |R|E|G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 20|           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(bytes)

   and only during SYN/ACK, it MAY be moved to a different variation.

2. TCP Header: "Modern variation" a.k.a TCP.64

    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4|          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  8|         Reserved Flags        |            Window             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12|  Data   |   |N|C|E|U|A|P|R|S|F|                               |
   | Offset  |   |S|W|C|R|C|S|S|Y|I|        Urgent Pointer         |
   |         |   | |R|E|G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 16|                                                               |
   +                        Sequence Number                        +
 20|                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 24|                                                               |
   +                    Acknowledgment Number                      +
 28|                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 32|                                                               |
   +                       CRC64c Checksum                         +
 36|                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(bytes)

   Design note: Bloated for a good reason.

   I realize the downside of making TCP bloated by a whopping 
   extra 16 bytes, but I also realize this is a necessary evil at speeds
   over 100 Gigabits-per-Second. 
   If you're on a slow link, just don't advertise that you're TCP 64-bit
   capable, and stay on the "classic variation".

   64-bit Checksums:

   16-bit checksums of "classic variation" may fail badly there.
   Today, only Data-Link layer checksum saves Internet from complete 
   breakdown, as those checksums are fairly strong 32-bit CRCs.

   But strong CRC64c checksums is an adequate protection for future 
   huge amounts of unencrypted data.
   Going encryption of-course renders checksums useless.

   64-bit Sequence numbers and acknowledgements:

   The problem with 32-bit SYN/ACK is TCP Reliability

   Quote from RFC-7323:

   "An especially serious kind of error may result from an accidental
   reuse of TCP sequence numbers in data segments.  TCP reliability
   depends upon the existence of a bound on the lifetime of a segment:
   the "Maximum Segment Lifetime" or MSL.

   Duplication of sequence numbers might happen in either of two ways:

   (1)  Sequence number wrap-around on the current connection

        A TCP sequence number contains 32 bits.  At a high enough
        transfer rate of large volumes of data (at least 4 GiB in the
        same session), the 32-bit sequence space may be "wrapped"
        (cycled) within the time that a segment is delayed in queues.

   (2)  Earlier incarnation of the connection

        Suppose that a connection terminates, either by a proper close
        sequence or due to a host crash, and the same connection (i.e.,
        using the same pair of port numbers) is immediately reopened.  A
        delayed segment from the terminated connection could fall within
        the current window for the new incarnation and be accepted as
        valid.

   Duplicates from earlier incarnations, case (2), are avoided by
   enforcing the current fixed MSL of the TCP specification, as
   explained in Section 5.8 and Appendix B.  In addition, the
   randomizing of ephemeral ports can also help to probabilistically
   reduce the chances of duplicates from earlier connections.  However,
   case (1), avoiding the reuse of sequence numbers within the same
   connection, requires an upper bound on MSL that depends upon the
   transfer rate, and at high enough rates, a dedicated mechanism is
   required.""

   
   On a gigabit link, Sequence numbers are rotated every 17 seconds.
   On a 100-gigabit link, this is well under a second.
   TCP originally was never designed for such speeds.

   This is dangerous, because packets from older rotation might get 
   stuck in queue, then released by a router, get through and corrupt
   user data if sent to destination, or cause a TCP reset, if sent as 
   an ack to the sender. 
   And those old packets do have correct sequence number and correct checksum.

   PAWS, a system designed to prevent such issues by using timers, may
   fail badly and produce bad errors with 32-bit Sequence number,
   due to inaccurate timing issues.

   Data Offset: 5 bits; not including the first 28 bytes.
   (this allows far more options in to be sent in TCP)

   Compatibility Note: 64-bit TCP breaks compatibility with existing
     "middleboxes".

   64-bit Initial sequence number:
   Must be copied from the lower 32-bits to the upper 32-bits,
   if not specified during SYN.

   The actual switching to "Modern variation" happens from SYN/ACK 
   packet (3rd handshake), assuming the "ACK" advertises such 
   capability.

2.1. TCP Header: "Modern variation without CRC" or TCP.64-NOCRC

    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4|          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  8|         Reserved Flags        |            Window             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12|  Data   |   |N|C|E|U|A|P|R|S|F|                               |
   | Offset  |   |S|W|C|R|C|S|S|Y|I|        Urgent Pointer         |
   |         |   | |R|E|G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 16|                                                               |
   +                        Sequence Number                        +
 20|                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 24|                                                               |
   +                    Acknowledgment Number                      +
 28|                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(bytes)

   Same as above, but without the CRC64c checksum. This is useful for
   encryption protocols, such as SSL/TLS, that provide their own 
   checksum or authentication mechanisms.

   Initially the system switches to "Modern variation", on SYN/ACK, 
   and with CRC64 field, but that field gets eliminated after 65535 
   bytes of data, which is where switching to 
   "Modern variation without CRC" occurs.

   (i.e. packets that begin with relative SYN over 65535, are expected
   by the receiver to have no CRC64 field)
   In first 64 KiB, CRC is required to negotiate encryption parameters.

3. Initiating a TCP.64 Session "Modern Variation"

   This is the same signaling as for initiating a normal TCP connection,
   but the SYN, SYN/ACK, and ACK packets also carry the 64BIT_CAPABLE
   option.

      Client                                  Server
      ------                                  ------
      64BIT_CAPABLE            ->
      [SYN flag]
                            <-                64BIT_CAPABLE
                                              [ACK flag]
      64BIT_CAPABLE            ->
      [SYN+ACK flags]

   TCP "Modern Variation" Option:

             +---------+---------+---------+
             | Kind=31 | Length  |Variation|
             |         |         | or ISN  |
             +---------+---------+---------+

     Kind: 31 (To be determined by IANA)

   Length:

     3 = For setting variation

     6 = For upper 32-bits of initial sequence number.

   Variations or codes:

     0 = Checksum ignored (useful for ILNP); 
         Takes effect from 1st packet. (initial SYN)

     1 = Modern Variation (TCP.64-bit capable)

     2 = Modern Variation, without CRC field; (useful for encryption)
         Takes effect after 64 KiB of data.

     If Len=6, this field is used to setup an upper 32-bits of 
     the initial sequence number.

4. Checksum ignored option

   This option lets the receiver to ignore TCP-supplied checksum.
   Affects both classic 16-bit checksum as well as CRC.
   Affects TCP session from the initial SYN packet.

   This allows for Identity-Locator Network Protocol (ILNP) to 
   function with TCP/IP networks.
   In this case ILNP or other protocol should provide their own
   checksums for both TCP and IP.

Acknowledgements:

   Influenced by the hard work of R. Ullmann "TP/IX: The Next Internet"
   [RFC-1475] and by "Identifier-Locator Network Protocol (ILNP)",
   [RFC-6740] written by "Randall J. Atkinson" and "SN Bhatti".

   Thanks to:
   "D. Borman", "B. Braden", "V. Jacobson", "R. Scheffenegger, Ed."
   for [RFC-1323] and [RFC-7323]; "TCP Extensions for High Performance".

   And big thanks to DARPA for the original specification of TCP, as
   defined in [RFC-793] !

Authors' Contacts

   Alexey Eromenko
   Israel

   Skype: Fenix_NBK_
   EMail: al4321@gmail.com
   Facebook: https://www.facebook.com/technologov

INTERNET-DRAFT
Alexey
expiration date: 2016-06-16