draft-ietf-tcpm-1323bis-20.txt   draft-ietf-tcpm-1323bis-21.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: September 5, 2014 California Expires: October 13, 2014 California
V. Jacobson V. Jacobson
Google, Inc. Google, Inc.
R. Scheffenegger, Ed. R. Scheffenegger, Ed.
NetApp, Inc. NetApp, Inc.
March 4, 2014 April 11, 2014
TCP Extensions for High Performance TCP Extensions for High Performance
draft-ietf-tcpm-1323bis-20 draft-ietf-tcpm-1323bis-21
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 September 5, 2014. This Internet-Draft will expire on October 13, 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 43 skipping to change at page 3, line 43
6. Conclusions and Acknowledgments . . . . . . . . . . . . . . . 28 6. Conclusions and Acknowledgments . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 30 7.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
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 . . . . . . . . . . . . 36
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 . . . . . . . . . . . . 45 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
skipping to change at page 25, line 8 skipping to change at page 25, line 8
o The timestamp clock may be derived from a system clock that is o The timestamp clock may be derived from a system clock that is
subject to being abruptly changed, by adding a variable offset subject to being abruptly changed, by adding a variable offset
value. This offset is initialized to zero. When a new timestamp value. This offset is initialized to zero. When a new timestamp
clock value is needed, the offset can be adjusted as necessary to clock value is needed, the offset can be adjusted as necessary to
make the new value equal to or larger than the previous value make the new value equal to or larger than the previous value
(which was saved for this purpose). (which was saved for this purpose).
o A random offset may be added to the timestamp clock on a per o A random offset may be added to the timestamp clock on a per
connection basis. See [RFC6528], section 3, on randomizing the connection basis. See [RFC6528], section 3, on randomizing the
initial sequence number (ISN). The same function with a different initial sequence number (ISN). The same function with a different
secret key can be use to generate the per connection timestamp secret key can be used to generate the per connection timestamp
offset. offset.
5.5. Outdated Timestamps 5.5. Outdated Timestamps
If a connection remains idle long enough for the timestamp clock of If a connection remains idle long enough for the timestamp clock of
the other TCP to wrap its sign bit, then the value saved in TS.Recent the other TCP to wrap its sign bit, then the value saved in TS.Recent
will become too old; as a result, the PAWS mechanism will cause all will become too old; as a result, the PAWS mechanism will cause all
subsequent segments to be rejected, freezing the connection (until subsequent segments to be rejected, freezing the connection (until
the timestamp clock wraps its sign bit again). the timestamp clock wraps its sign bit again).
skipping to change at page 29, line 8 skipping to change at page 29, line 8
See [RFC5961] for mitigation strategies to blind in-window attacks. 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. It is therefore valuable information to a potential attacker. It is therefore
RECOMMENDED to generate a random, per-connection offset to be used RECOMMENDED to generate a random, per-connection offset to be used
with the clock source when generating the Timestamps option value with the clock source when generating the Timestamps option value
(see Section 5.4). (see Section 5.4). By carefully choosing this random offset, further
improvements as described in [RFC6191] are possible.
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 40 skipping to change at page 33, line 40
[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 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961, Robustness to Blind In-Window Attacks", RFC 5961,
August 2010. August 2010.
[RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP
Timestamps", BCP 159, RFC 6191, April 2011.
[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. 
7 lines changed or deleted 11 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/