Network Working Group Y. Nishida
Internet-Draft GE Global Research
Intended status: Experimental July 28, 2013
Expires: January 29, 2014
A-PAWS: Alternative Approach for PAWS
draft-nishida-tcpm-apaws-00
Abstract
This documents describe a technique called A-PAWS which can provide
protection against old duplicates segments like PAWS. While PAWS
requires TCP to set timestamp options in all segments in a TCP
connection, A-PAWS supports the same feature without using
timestamps. A-PAWS is designed to be used complementary with PAWS.
TCP needs to use PAWS when it is necessary and activates A-PAWS only
when it is safe to use. Without impairing the reliability and the
robustness of TCP, A-PAWS can provide more option space to other TCP
extensions.
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."
This Internet-Draft will expire on January 29, 2014.
Copyright Notice
Copyright (c) 2013 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
Nishida Expires January 29, 2014 [Page 1]
Internet-Draft Alternative PAWS July 2013
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. The A-PAWS Design . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Signaling Method . . . . . . . . . . . . . . . . . . . . . 6
3.2. Sending Behavior . . . . . . . . . . . . . . . . . . . . . 7
3.3. Receiving Behavior . . . . . . . . . . . . . . . . . . . . 7
4. When To Use A-PAWS . . . . . . . . . . . . . . . . . . . . . . 8
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Protection Against Early Incarnations . . . . . . . . . . 9
5.2. Protection Against Security Threats . . . . . . . . . . . 9
5.3. Middlebox Considerations . . . . . . . . . . . . . . . . . 9
5.4. Aggressive Mode in A-PAWS . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Nishida Expires January 29, 2014 [Page 2]
Internet-Draft Alternative PAWS July 2013
1. Introduction
PAWS (Protect Against Wrapped Sequences) defined in [RFC1323] is a
technique that can identify old duplicate segments in a TCP
connection. An old duplicate segment can be generated when it has
been delayed by queueing, etc. If such a segment has the sequence
number which falls within the receiver's current window, the receiver
will accept it without any warning or error. However, this segment
can be a segment created by an old connection that has the same port
and address pair, or a segments sent 2**32 bytes earlier on the same
connection. Although this situation rarely happens, it impairs the
reliability of TCP.
PAWS utilizes timestamp option in [RFC1323] to provide protection
against this. It is assumed that every received TCP segment contains
a timestamp. PAWS can identify old duplicate segments by comparing
the timestamp in the received segments and the timestamps from other
segments received recently. If both TCP endpoints agree to use PAWS,
all segments belong to this connection should have timestamp. Since
PAWS is the only standardized protection against old duplicate
segments, it has been implemented and used in most TCP
implementations. However, as some TCP extensions such as [RFC2018],
[RFC5925] and [RFC6824] also requires a certain amount of option
space in non-SYN segments, using 10-12 bytes length in option space
for timestamp in all segments tends to be considered expensive in
recent discussions.
In addition, although PAWS is necessary for connections which
transmit more than 2**32 bytes, it is not very important for other
connections since [RFC0793] already has protection against segments
from old connections by using timers. Moreover, some research
results indicates that most of TCP flows tend to transmit small
amount of data, which means only small fraction of TCP connections
really need PAWS [QIAN11]. Timestamp option is also used for RTTM
(Round Trip Time Measurement) in [RFC1323]. Gathering many RTT
samples from the timestamp in every TCP segment looks useful approach
to improve RTO estimation. However, some research results shows the
number of samples per RTT does not affect the effectiveness of the
RTO [MALLMAN99]. Hence, we can think if PAWS is not used, sending a
few timestamps per RTT will be sufficient.
Based on these observations, we propose a new technique called A-PAWS
which can archive similar protection against old duplicates segments.
The basic idea of A-PAWS is not using option in non-SYN segments,
while it can attain the same protection against old all duplicate
segments as PAWS. A-PAWS is designed to be used complementary with
PAWS. This means an implementation that supports A-PAWS is still
required to supports PAWS. A-PAWS is activated only when it is safe
Nishida Expires January 29, 2014 [Page 3]
Internet-Draft Alternative PAWS July 2013
to use. This sounds the applicability of A-PAWS is limited, however,
we believe TCP will have a lot of chances to save the option space if
it uses A-PAWS.
There are some discussions that PAWS can also be used to enhance
security, however, we still believe that A-PAWS can maintain the same
level of security as PAWS. Detailed discussions on this point are
provided in Section 5. A-PAWS is an experimental idea yet, but we
hope it will contribute to facilitating the use of TCP option space.
Nishida Expires January 29, 2014 [Page 4]
Internet-Draft Alternative PAWS July 2013
2. Conventions and Terminology
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 [RFC2119].
Nishida Expires January 29, 2014 [Page 5]
Internet-Draft Alternative PAWS July 2013
3. The A-PAWS Design
A-PAWS assumes PAWS as it is designed to be used complementary with
PAWS. Hence, a node which supports A-PAWS MUST support PAWS. The
following mechanisms are required in TCP in order to perform A-PAWS.
3.1. Signaling Method
A-PAWS requires a signaling mechanism to enable this fature. This is
because A-PAWS presumes the use of timestamp, while it allows TCP to
transmit segments without timestamp. In [RFC1323], once timestamp
option has been negotiated to be used in the connection, TCP stacks
are required to set timestamp options in all TCP segments. If TCP
receives segments without TS option after timestamp negotiation, the
segments will be discarded. Hence, if one endpoint uses A-PAWS and
the other endpoint uses PAWS, the segments from the A-PAWS endpoint
will be discarded. The signaling mechanism for A-PAWS should address
this point. The followings are possible approach.
1) Synchronous Option Exchange
This method requires using new codepoints for TCP option and
exchange them during SYN negotiation. The use of
[I-D.ietf-tcpm-experimental-options] is recommended. Since
A-PAWS negotiation is 1 bit information (on or off), new option
does not need to have any content. Hence, if 16-bit EXID is
used, the option size for A-PAWS can be kept in 4 bytes length.
We currently recommend the use of different codepoints for SYN
and SYN-ACK. This is because it is known that some TCP
implementations blindly echo-back their unknown options in SYN
segments. Also, it is recommended to set the option in the third
ACK: ACK for SYN-ACK for robust signaling in case of the lost of
the option in SYN-ACK.
2) Asynchronous Option Exchange
This method also uses new codepoints for TCP option and exchange
them during SYN negotiation. However, the signaling of this
method is treated as unidirectional. This means when TCP set
A-PAWS option, it indicates that this endpoint is willing to
accept segments without timestamps by A-PAWS logic. However, it
does not indicate this endpoint will transmit segments without
timestamp. TCP is allowed to transmit segments with A-PAWS logic
only when it receives the segments with A-PAWS option.
3) Option Exchange in non-SYN Segments
This method is similar to the synchronous or asynchronous option
exchange in SYN segments, however, it uses A-PAWS option in non-
SYN segments for signaling. This approach does not need to
utilize option space in SYN segments which is highly competitive
Nishida Expires January 29, 2014 [Page 6]
Internet-Draft Alternative PAWS July 2013
resource.
4) Timestamp Field Negotiation
This method is based on timestamp field negotiation proposed in
[I-D.scheffenegger-tcpm-timestamp-negotiation]. The draft
proposes to utilize timestamp values in SYN segments in order to
negotiate additional capabilities for timestamps. Although the
detailed mechanisms are still under discussion, it does not
require option space.
3.2. Sending Behavior
A-PAWS enabled TCP transmits segments, it needs to follow the rules
below.
1. TCP needs to check how many bytes has been transmitted in a
connection. If the transmitted bytes exceeds 2**32 -
'Sender.Offset', TCP migrates PAWS mode and MUST set timestamp
option in all segments to be transmitted. The value for
'Sender.Offset' is discussed in Section 5.
2. If the number of bytes transmitted in a TCP connection does not
exceeds 2**32 - 'Sender.Offset', TCP MAY omit timestamp option in
segments as long as it does not affect RTTM. This draft does not
define how much TCP can omit timestamps because it should be
determined by RTTM.
3.3. Receiving Behavior
A-PAWS enabled TCP receives segments, it needs to follow the rules
below.
1. TCP needs to check how many bytes has been received in a TCP
connection. If it exceeds 2**32 bytes, A-PAWS nodes SHOULD
discard the received segments which does not have timestamp
option. TCP MUST perform PAWS check when received bytes exceeds
2**32 bytes.
2. If the number of bytes received in a TCP connection does not
exceeds 2**32 bytes, A-PAWS nodes SHOULD accept the segments even
if it does not have timestamp option. A-PAWS nodes MAY skip PAWS
check until the received bytes exceeds 2**32 bytes.
Nishida Expires January 29, 2014 [Page 7]
Internet-Draft Alternative PAWS July 2013
4. When To Use A-PAWS
In basic principal, A-PAWS capable nodes can always use A-PAWS as
long as the peers agree with them. However, the following cases
require special considerations to enable A-PAWS.
1. As "When To Keep Quiet" section in [RFC0793] suggests, it is
recommended that TCP keeps quiet for a MSL upon starting up or
recovering from a crash where memory of sequence numbers has been
lost. However, if timestamps are being used and if the timestamp
clock can be guaranteed to be increased monotonically, this quiet
time may be unnecessary. Because TCP can identify the segments
from old connections by checking the timestamp. We think some
TCP implementations may disable the quiet time because of using
timestamps from this reason. However, since A-PAWS nodes does
not set timestamp options in all segments, TCP cannot rely on
this approach. To avoid decreasing the robustness of TCP
connection, TCP MUST NOT use A-PAWS for a MSL upon starting up or
recovering from a crash.
2. Various TCP implementations provide APIs such as setsockopt()
that can set SO_REUSEADDR flag on TCP connections. If this flag
is set, the TCP connection allows to reuse the same local port
without waiting for 2 MSL period. While this option is useful
when users want to relaunch applications immediately, it makes
the TCP connection a little vulnerable as TCP stack might receive
duplicate segments from earlier incarnations. It has been said
that PAWS can contribute to mitigate this risk by checking the
timestamps in segments. In order to keep the same level of
protection, TCP SHOULD NOT enable A-PAWS when SO_REUSEADDR flag
is set.
Nishida Expires January 29, 2014 [Page 8]
Internet-Draft Alternative PAWS July 2013
5. Discussion
As A-PAWS is an experimental logic, the following points need to be
considered and discussed.
5.1. Protection Against Early Incarnations
There are some discussions that timestamp can enhance the robustness
against early incarnations. Since A-PAWS does not set timestamps in
all segments, some may say that it degrades the robustness of TCP.
We believe that the degradation caused by A-PAWS on this point is
negligible. As long as TCP limits the usage of A-PAWS as described
in Section 4, duplicate segments from early incarnations should not
be received by TCP.
5.2. Protection Against Security Threats
A TCP connection can be identified by a 5-tuple: source address,
destination address, source port number, destination port number and
protocol. Crackers need to guess all these parameters when they try
malicious attacks on the connection. PAWS can enhance the protection
for this as it additionally requires timestamp checking. However, we
think the effect of PAWS against malicious attacks is limited due to
the simplicity of PAWS check. In PAWS, a segment can be considered
as an old duplicate if the timestamp in the segment less than some
timestamps recently received on the connection. The "less than" in
this context is determined by processing timestamp values as 32 bit
unsigned integers in a modular 32-bit space. For example, if t1 and
t2 are timestamp values, t1 < t2 is verified when 0 < (t2 - t1) <
2**31 computed in unsigned 32-bit arithmetic. Hence, if crackers set
a random value in the timestamp option, there will be 50% chance for
them to trick PAWS check. Moreover, there will be more chances if
they send multiple segments with different timestamps, which will not
be difficult to perform.
In addition, we think there might be a case where using PAWS
increases security risks. PAWS recommends to increase timestamp over
a system when TCP waives the "quiet time" described in [RFC0793].
However, if timestamps are generated from a global counter, it may
leak some information such as system uptime as discussed in
[SILBERSACK05]. A-PAWS might be able to allows TCP to use random
timestamp values per connections.
5.3. Middlebox Considerations
There might be a case where the signaling for A-PAWS is confused by
middleboxes. For example, in case of synchronous option exchange, if
the option for A-PAWS is removed from SYN-ACK, we will have a
Nishida Expires January 29, 2014 [Page 9]
Internet-Draft Alternative PAWS July 2013
situation where one node enables A-PAWS and the other node disables
A-PAWS. When an A-PAWS endpoint sends segments without timestamp and
a PAWS endpoint receives them, the segments will be discarded.
Hence, if synchronous option exchange is used, we recommend to set
A-PAWS option in the third ACK for robust signaling. If the third
ACK does not contain A-PAWS option, the receiver should disable
A-PAWS.
In case of asynchronous option exchange signaling, endpoints will not
be messed up even if middleboxes discard A-PAWS option. This is
because A-PAWS sender logic is activated only when TCP receives a
segment with A-PAWS options. A-PAWS receiver logic does not need to
know whether the sender is using PAWS or A-PAWS. On the other hand,
as an A-PAWS endpoint always needs to activate A-PAWS receiver logic
even if the peer uses PAWS, it will require extra overhead compared
to the synchronous signaling. However, we believe the overhead will
be acceptable in most cases because of the simplicity of A-PAWS
logic.
Another concern on middleboxes is that they can insert or delete some
bytes in TCP connections. If a middlebox inserts extra bytes into a
TCP connections, there might be a situation where an A-PAWS sender
can transmit segments without timestamp, while an A-PAWS receiver
perform PAWS check on them as it already has received 2**32 bytes.
In order to avoid discarding segments unnecessarily, we recommend
that A-PAWS sender should have a certain amount of offset bytes in
order to migrate PAWS mode before the receiver receives 2**32 bytes.
We call this protocol parameter 'Sender.Offset'. The proper value
for 'Sender.Offset' needs to be discussed.
5.4. Aggressive Mode in A-PAWS
The current A-PAWS requires TCP to migrate PAWS mode after sending/
receiving 2**32 bytes. However, if both nodes check if 2 MSL has
already passed during sending/receiving 2**32 bytes, they might be
able to continue using A-PAWS. We call this "Aggressive mode". We
currently do not recommend this mode as it requires additional
complexities in A-PAWS.
Nishida Expires January 29, 2014 [Page 10]
Internet-Draft Alternative PAWS July 2013
6. Security Considerations
We believe A-PAWS can maintain the same level of security as PAWS
does, but further discussions will be needed. Some security aspects
of A-PAWS are discussed in Section 5.
Nishida Expires January 29, 2014 [Page 11]
Internet-Draft Alternative PAWS July 2013
7. IANA Considerations
This document may request new TCP option codepoints or other
resources.
Nishida Expires January 29, 2014 [Page 12]
Internet-Draft Alternative PAWS July 2013
8. References
8.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.ietf-tcpm-experimental-options]
Touch, J., "Shared Use of Experimental TCP Options",
draft-ietf-tcpm-experimental-options-06 (work in
progress), June 2013.
[I-D.scheffenegger-tcpm-timestamp-negotiation]
Scheffenegger, R., Kuehlewind, M., and B. Trammell,
"Additional negotiation in the TCP Timestamp Option field
during the TCP handshake",
draft-scheffenegger-tcpm-timestamp-negotiation-05 (work in
progress), October 2012.
[MALLMAN99]
Allman, M. and V. Paxson, "On Estimating End-to-End
Network Path Properties", Proceedings of the ACM SIGCOMM ,
September 1999.
[QIAN11] Qian, L. and B. Carpenter, "A Flow-Based Performance
Analysis of TCP and TCP Applications", 3rd International
Conference on Computer and Network Technology (ICCNT
2011) .
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013.
[SILBERSACK05]
Nishida Expires January 29, 2014 [Page 13]
Internet-Draft Alternative PAWS July 2013
Silbersack, M., "Improving TCP/IP security through
randomization without sacrificing interoperability.",
EuroBSDCon 2005 , November 2005.
Nishida Expires January 29, 2014 [Page 14]
Internet-Draft Alternative PAWS July 2013
Author's Address
Yoshifumi Nishida
GE Global Research
2623 Camino Ramon
San Ramon, CA 94583
USA
Email: nishida@wide.ad.jp
Nishida Expires January 29, 2014 [Page 15]