draft-ietf-tcpm-1323bis-19.txt   draft-ietf-tcpm-1323bis-20.txt 
TCP Maintenance (TCPM) D. Borman TCP Maintenance (TCPM) D. Borman
Internet-Draft Quantum Corporation Internet-Draft Quantum Corporation
Obsoletes: 1323 (if approved) B. Braden Obsoletes: 1323 (if approved) B. Braden
Intended status: Standards Track University of Southern Intended status: Standards Track University of Southern
Expires: July 28, 2014 California Expires: September 5, 2014 California
V. Jacobson V. Jacobson
Google, Inc. Google, Inc.
R. Scheffenegger, Ed. R. Scheffenegger, Ed.
NetApp, Inc. NetApp, Inc.
January 24, 2014 March 4, 2014
TCP Extensions for High Performance TCP Extensions for High Performance
draft-ietf-tcpm-1323bis-19 draft-ietf-tcpm-1323bis-20
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
the TCP Window Scale (WS) option and the TCP Timestamps (TS) option the TCP Window Scale (WS) option and the TCP Timestamps (TS) option
and their semantics. The Window Scale option is used to support and their semantics. The Window Scale option is used to support
larger receive windows, while the Timestamps option can be used for larger receive windows, while the Timestamps option can be used for
at least two distinct mechanisms, PAWS (Protection Against Wrapped at least two distinct mechanisms, PAWS (Protection Against Wrapped
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 July 28, 2014. This Internet-Draft will expire on September 5, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 3, line 48 skipping to change at page 3, line 48
9.1. Normative References . . . . . . . . . . . . . . . . . . . 30 9.1. Normative References . . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . . 31 9.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Implementation Suggestions . . . . . . . . . . . . . 34 Appendix A. Implementation Suggestions . . . . . . . . . . . . . 34
Appendix B. Duplicates from Earlier Connection Incarnations . . . 35 Appendix B. Duplicates from Earlier Connection Incarnations . . . 35
B.1. System Crash with Loss of State . . . . . . . . . . . . . 35 B.1. System Crash with Loss of State . . . . . . . . . . . . . 35
B.2. Closing and Reopening a Connection . . . . . . . . . . . . 35 B.2. Closing and Reopening a Connection . . . . . . . . . . . . 35
Appendix C. Summary of Notation . . . . . . . . . . . . . . . . . 37 Appendix C. Summary of Notation . . . . . . . . . . . . . . . . . 37
Appendix D. Event Processing Summary . . . . . . . . . . . . . . 38 Appendix D. Event Processing Summary . . . . . . . . . . . . . . 38
Appendix E. Timestamps Edge Cases . . . . . . . . . . . . . . . . 43 Appendix E. Timestamps Edge Cases . . . . . . . . . . . . . . . . 43
Appendix F. Window Retraction Example . . . . . . . . . . . . . . 44 Appendix F. Window Retraction Example . . . . . . . . . . . . . . 44
Appendix G. RTO calculation modification . . . . . . . . . . . . 44 Appendix G. RTO calculation modification . . . . . . . . . . . . 45
Appendix H. Changes from RFC 1323 . . . . . . . . . . . . . . . . 45 Appendix H. Changes from RFC 1323 . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
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 have resulted in ever-higher years, advances in networking technology have 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 28, line 47 skipping to change at page 28, line 47
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.
See [RFC5961] for mitigation strategies to blind in-window attacks.
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. It is therefore
evaluate the potential impact and mitigate this accordingly (i.e. by RECOMMENDED to generate a random, per-connection offset to be used
using a random offset for the timestamp clock on each connection, or with the clock source when generating the Timestamps option value
using an external, real-time derived timestamp clock source). (see Section 5.4).
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 Mechanisms to protect the TCP header from modification should also
protect the TCP options. protect the TCP options.
Middleboxes and TCP options: Middleboxes and TCP options:
skipping to change at page 33, line 36 skipping to change at page 33, line 36
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, March 2007.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963, July 2007. Errors at High Data Rates", RFC 4963, July 2007.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009. Control", RFC 5681, September 2009.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961,
August 2010.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, "Computing TCP's Retransmission Timer", RFC 6298,
June 2011. June 2011.
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
Number Attacks", RFC 6528, February 2012. Number Attacks", RFC 6528, February 2012.
[RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M.,
and Y. Nishida, "A Conservative Loss Recovery Algorithm and Y. Nishida, "A Conservative Loss Recovery Algorithm
Based on Selective Acknowledgment (SACK) for TCP", Based on Selective Acknowledgment (SACK) for TCP",
 End of changes. 8 change blocks. 
9 lines changed or deleted 15 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/