| Network Working Group | Y. Nishida |
| Internet-Draft | GE Global Research |
| Intended status: Experimental | June 10, 2014 |
| Expires: December 12, 2014 |
A-PAWS: Alternative Approach for PAWS
draft-nishida-tcpm-apaws-01
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.
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 December 12, 2014.
Copyright (c) 2014 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.
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 to attain the same protection against old all duplicate segments as PAWS while reducing the use of TS options in segments. 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 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.
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].
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.
A-PAWS requires a signaling mechanism to enable this feature as it employs different logics from [RFC2119] to process TS options. A-PAWS presumes the use of PAWS. Hence, if TS option is not negotiated during SYN exchanges, A-PAWS MUST NOT be activated. An important point for A-PAWS is that it does not require synchronized signaling between senders and receivers. In Table 1 illustrates possible combinations for PAWS and A-PAWS. It should be noted that when receiver employs A-PAWS, it does not matter if sender uses PAWS or A-PAWS (case 2 and case 4). This allows us to use less synchronized signaling mechanisms described in the following sections. However, we must avoid the situation where the sender activates A-PAWS while the receiver uses PAWS (case 3).
| case # | Sender | Receiver | |
|---|---|---|---|
| 1 | PAWS | PAWS | Work |
| 2 | PAWS | A-PAWS | Work |
| 3 | A-PAWS | PAWS | Doesn't work |
| 4 | A-PAWS | A-PAWS | Work |
Based on these requirements, the followings are possible approach for A-PAWS signaling.
As explained in Section 3.1, A-PAWS will explore a signaling method that utilizes non-SYN segments. If robust and reliable signaling mechanisms are necessary, we will probably need to invent another three-way handshake like mechanisms that use non-SYN segments. This will require drastic changes in the current TCP semantics. Instead, in case of A-PAWS, we can use a relatively simple and easy mechanism for feature negotiation. One important characteristic for A-PAWS is the signaling mechanism does not require tight synchronization between endpoints. This is because A-PAWS receivers can interact with both A-PAWS senders and PAWS senders. Hence, we can use a less reliable method for A-PAWS signaling. For example, when an endpoint sends A-PAWS option and the other endpoint does not send back A-PAWS option, we are not very sure if the other endpoint disabled the feature or a middlebox in the forward or the return path removed the option. However, A-PAWS endpoints are not confused in these cases by using the following two rules. Table 1 even if some signaling has been lost.
By having these rules, A-PAWS sender logic will not be activated without explicit signaling from its peer, which allows us to avoid the case 3 in
Another discussion point for this signaling method is when to set A-PAWS option in segments. As A-PAWS employs asynchronous signaling, both endpoints basically can set A-PAWS option in segments anytime they want. However, we recommend using the following rules for setting options.
These rules allow endpoints to have loose synchronized signaling so that they can at least solicit responses from their peers. Of course, even an endpoint solicit a response by setting A-PAWS option in a data segment, it might not receive A-PAWS option in the ACK segment. This can be caused by the lost of the ACK segment or middleboxes that remove unknown options. In order to address these cases, the following rules can be used.
This rule can address the cases where A-PAWS options has been removed by middleboxes or segments with A-PAWS options has been lost.
A-PAWS enabled TCP transmits segments, it needs to follow the rules below.
A-PAWS enabled TCP receives segments, it needs to follow the rules below.
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.
As A-PAWS is an experimental logic, the following points need to be considered and discussed.
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.
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.
A-PAWS is designed to be robust against middleboxes. This means that 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. Activating A-PAWS receiving logic for PAWS sender might be redundant as it requires additional overheads. 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.
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.
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.
This document may request new TCP option codepoint or other resources.
| [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. |