draft-ietf-tcpm-1323bis-10.txt   draft-ietf-tcpm-1323bis-11.txt 
TCP Maintenance (TCPM) D. Borman TCP Maintenance (TCPM) D. Borman
Internet-Draft Quantum Corporation Internet-Draft Quantum Corporation
Intended status: Standards Track B. Braden Intended status: Standards Track B. Braden
Expires: October 18, 2013 University of Southern Expires: October 24, 2013 University of Southern
California California
V. Jacobson V. Jacobson
Packet Design Packet Design
R. Scheffenegger, Ed. R. Scheffenegger, Ed.
NetApp, Inc. NetApp, Inc.
April 16, 2013 April 22, 2013
TCP Extensions for High Performance TCP Extensions for High Performance
draft-ietf-tcpm-1323bis-10 draft-ietf-tcpm-1323bis-11
Abstract Abstract
This document specifies a set of TCP extensions to improve This document specifies a set of TCP extensions to improve
performance over paths with a large bandwidth * delay product and to performance over paths with a large bandwidth * delay product and to
provide reliable operation over very high-speed paths. It defines provide reliable operation over very high-speed paths. It defines
TCP options for scaled windows and timestamps. The timestamps are TCP options for scaled windows and timestamps. The timestamps are
used for two distinct mechanisms, RTTM (Round Trip Time Measurement) used for two distinct mechanisms, RTTM (Round Trip Time Measurement)
and PAWS (Protection Against Wrapped Sequences). and PAWS (Protection Against Wrapped Sequences).
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 18, 2013. This Internet-Draft will expire on October 24, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 33 skipping to change at page 3, line 33
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 18 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. The PAWS Mechanism . . . . . . . . . . . . . . . . . . . . 18 4.2. The PAWS Mechanism . . . . . . . . . . . . . . . . . . . . 18
4.3. Basic PAWS Algorithm . . . . . . . . . . . . . . . . . . . 20 4.3. Basic PAWS Algorithm . . . . . . . . . . . . . . . . . . . 20
4.4. Timestamp Clock . . . . . . . . . . . . . . . . . . . . . 22 4.4. Timestamp Clock . . . . . . . . . . . . . . . . . . . . . 22
4.5. Outdated Timestamps . . . . . . . . . . . . . . . . . . . 23 4.5. Outdated Timestamps . . . . . . . . . . . . . . . . . . . 23
4.6. Header Prediction . . . . . . . . . . . . . . . . . . . . 24 4.6. Header Prediction . . . . . . . . . . . . . . . . . . . . 24
4.7. IP Fragmentation . . . . . . . . . . . . . . . . . . . . . 25 4.7. IP Fragmentation . . . . . . . . . . . . . . . . . . . . . 25
4.8. Duplicates from Earlier Incarnations of Connection . . . . 25 4.8. Duplicates from Earlier Incarnations of Connection . . . . 25
5. Conclusions and Acknowledgements . . . . . . . . . . . . . . . 26 5. Conclusions and Acknowledgements . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Implementation Suggestions . . . . . . . . . . . . . 30 Appendix A. Implementation Suggestions . . . . . . . . . . . . . 30
Appendix B. Duplicates from Earlier Connection Incarnations . . . 31 Appendix B. Duplicates from Earlier Connection Incarnations . . . 31
B.1. System Crash with Loss of State . . . . . . . . . . . . . 31 B.1. System Crash with Loss of State . . . . . . . . . . . . . 32
B.2. Closing and Reopening a Connection . . . . . . . . . . . . 32 B.2. Closing and Reopening a Connection . . . . . . . . . . . . 32
Appendix C. Summary of Notation . . . . . . . . . . . . . . . . . 33 Appendix C. Summary of Notation . . . . . . . . . . . . . . . . . 34
Appendix D. Event Processing Summary . . . . . . . . . . . . . . 34 Appendix D. Event Processing Summary . . . . . . . . . . . . . . 35
Appendix E. Timestamps Edge Cases . . . . . . . . . . . . . . . . 40 Appendix E. Timestamps Edge Cases . . . . . . . . . . . . . . . . 40
Appendix F. Window Retraction Example . . . . . . . . . . . . . . 40 Appendix F. Window Retraction Example . . . . . . . . . . . . . . 41
Appendix G. Changes from RFC 1323 . . . . . . . . . . . . . . . . 41 Appendix G. Changes from RFC 1323 . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The TCP protocol [RFC0793] was designed to operate reliably over The TCP protocol [RFC0793] was designed to operate reliably over
almost any transmission medium regardless of transmission rate, almost any transmission medium regardless of transmission rate,
delay, corruption, duplication, or reordering of segments. Over the delay, corruption, duplication, or reordering of segments. Over the
years, advances in networking technology has resulted in ever-higher years, advances in networking technology has resulted in ever-higher
transmission speeds, and the fastest paths are well beyond the domain transmission speeds, and the fastest paths are well beyond the domain
skipping to change at page 27, line 12 skipping to change at page 27, line 12
The TCP sequence space is a fixed size, and as the window becomes The TCP sequence space is a fixed size, and as the window becomes
larger it becomes easier for an attacker to generate forged packets larger it becomes easier for an attacker to generate forged packets
that can fall within the TCP window, and be accepted as valid that can fall within the TCP window, and be accepted as valid
segments. While use of timestamps and PAWS can help to mitigate segments. While use of timestamps and PAWS can help to mitigate
this, when using PAWS, if an attacker is able to forge a packet that this, when using PAWS, if an attacker is able to forge a packet that
is acceptable to the TCP connection, a timestamp that is in the is acceptable to the TCP connection, a timestamp that is in the
future would cause valid segments to be dropped due to PAWS checks. future would cause valid segments to be dropped due to PAWS checks.
Hence, implementers should take care to not open the TCP window Hence, implementers should take care to not open the TCP window
drastically beyond the requirements of the connection. drastically beyond the requirements of the connection.
Middle boxes and options: If a middle box removes TCP options from
the <SYN> segment, such as TSopt, a high speed connection that needs
PAWS would not have that protection. In this situation, an
implementer could provide a mechanism for the application to
determine whether or not PAWS is in use on the connection, and chose
to terminate the connection if that protection doesn't exist.
Mechanisms to protect the TCP header from modification should also
protect the TCP options.
A naive implementation that derives the timestamp clock value A naive implementation that derives the timestamp clock value
directly from a system uptime clock may unintentionally leak this directly from a system uptime clock may unintentionally leak this
information to an attacker. This does not directly compromise any of information to an attacker. This does not directly compromise any of
the mechanisms described in this document. However, this may be the mechanisms described in this document. However, this may be
valuable information to a potential attacker. An implementer should valuable information to a potential attacker. An implementer should
evaluate the potential impact and mitigate this accordingly (i.e. by evaluate the potential impact and mitigate this accordingly (i.e. by
using a random offset for the timestamp clock on each connection, or using a random offset for the timestamp clock on each connection, or
using an external, real-time derived timestamp clock source). using an external, real-time derived timestamp clock source).
Expanding the TCP window beyond 64 KiB for IPv6 allows Jumbograms Expanding the TCP window beyond 64 KiB for IPv6 allows Jumbograms
[RFC2675] to be used when the local network supports packets larger [RFC2675] to be used when the local network supports packets larger
than 64 KiB. When larger TCP segments are used, the TCP checksum than 64 KiB. When larger TCP segments are used, the TCP checksum
becomes weaker. becomes weaker.
Mechanisms to protect the TCP header from modification should also
protect the TCP options.
Middleboxes and TCP options:
Some middleboxes have been known to remove the TCP options
described in this document from the <SYN> segment. Middleboxes
should not remove TCP options described in this document from the
<SYN> segment, and must not remove any of these options in a
<SYN,ACK> segment. Examples of issues that can arise when
middleboxes remove these TCP options include:
* If a Window Scale option is removed from a <SYN,ACK> segment,
the end hosts will not negotiate the window scaling factor
correctly. Middleboxes must not remove or modify the Window
Scale option from <SYN,ACK> segments.
* If a stateful firewall uses the window field to detect whether
a received segment is inside the current window, and does not
support the Window Scale option, it will not be able to
correctly determine whether or not a packet is in the window.
These middle boxes must also support the Window Scale option
and apply the scaling when processing segments. If the window
scale cannot be determined, it must not do window based
processing.
* If the Timestamp option is removed from the <SYN> or <SYN,ACK>
segment, high speed connections that need PAWS would not have
that protection. Middleboxes should not remove the Timestamp
option.
Implementations that depend on PAWS could provide a mechanism for the
application to determine whether or not PAWS is in use on the
connection, and chose to terminate the connection if that protection
doesn't exist. This is not just to protect the connection against
middleboxes that might remove the Timestamp option, but also against
remote hosts that do not have Timestamp support.
7. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
 End of changes. 10 change blocks. 
21 lines changed or deleted 49 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/