Network Working Group K. Poon
Internet-Draft Sun
Expires: April 24, 2005 N. Demizu
NICT
October 24, 2004
Use of TCP timestamp option to defend against blind spoofing attack
draft-poon-tcp-tstamp-mod-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
The US-CERT alert (TA04-111A) shows that the well-known weakness in
TCP's segment acceptance test is easier to exploit than previously
thought. While there are already mechanisms, such as RFC 2385 for
BGP and IPSEC, to defend against this kind of attack, we propose a
light weight method making use of TCP timestamp (RFC 1323) option as
an alternative.
Poon & Demizu Expires April 24, 2005 [Page 1]
Internet-Draft Timestamp against spoofing October 2004
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Tracking the TSecr range . . . . . . . . . . . . . . . . . 7
4.2 Narrowing Down the Valid TSecr Range . . . . . . . . . . . 8
4.3 Unpredictable Timestamp . . . . . . . . . . . . . . . . . 9
4.4 TSval to use after the connection is idle . . . . . . . . 10
4.5 RST Handling . . . . . . . . . . . . . . . . . . . . . . . 11
4.6 Level of Protection . . . . . . . . . . . . . . . . . . . 11
5. Modified Timestamp Option Handling . . . . . . . . . . . . . . 13
5.1 Segment Sending . . . . . . . . . . . . . . . . . . . . . 13
5.2 Segment Receiving . . . . . . . . . . . . . . . . . . . . 13
5.2.1 LISTEN, and SYN-SENT States . . . . . . . . . . . . . 13
5.2.2 Other States . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
A. Timestamp Specification Inconsistency . . . . . . . . . . . . 18
B. PASA Issues with Different TS.Recent Update Methods . . . . . 19
C. New Condition for Updating TS.Recent . . . . . . . . . . . . . 21
D. TCP PASA-OK Option . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 23
Poon & Demizu Expires April 24, 2005 [Page 2]
Internet-Draft Timestamp against spoofing October 2004
1. Requirements notation
The keywords "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].
Poon & Demizu Expires April 24, 2005 [Page 3]
Internet-Draft Timestamp against spoofing October 2004
2. Introduction
As specified in [RFC793], TCP's segment acceptance test in
ESTABLISHED state is based on the current expected receive sequence
number RCV.NXT, the receive window RCV.WND, the received segment
sequence number SEG.SEQ, and length SEG.LEN. For example, suppose
TCP receives a spoofed RST (SEG.LEN is equal to 0), and the targeted
connection's RCV.WND is 32K. As long as the SEG.SEQ of the RST is in
[RCV.NXT, RCV.NXT + 32K), the received RST is considered acceptable.
In this case, the TCP connection will be aborted. The probability of
an attacker guessing the correct sequence number is thus RCV.WND /
2^32.
An attacker can also inject spoofed data to a TCP connection using a
similar idea. In addition to causing data corruption, spoofed data
injection may also lead to an ACK storm if the SEG.SEQ of the spoofed
segment is of a proper value. As stated on Page 72 of RFC 793, if an
ACK acknowledges some data never sent, TCP should send back an ACK
and drop the ACK. For example, if the SEG.SEQ of the spoofed segment
is RCV.NXT for receiver A, A will send back an ACK acknowledging that
segment. A's peer B will send back an ACK, per Page 72 of RFC 793.
But this ACK has SEG.SEQ equals to A's original RCV.NXT, which is not
acceptable. A will then send back an ACK, per RFC 793. This will
lead to an ACK storm.
As RCV.NXT of a connection is constantly changing, and RCV.WND for
most TCP connections is small comparing to the entire sequence number
space, it has been thought that as long as the initial sequence
number is generated in a proper way, as described in [RFC1948], blind
spoofing attack on this mechanism is not considered a serious threat.
An example of a blind spoofing attack is to send a large number of
RSTs with different sequence numbers spread over the sequence number
space to a known TCP end point. If one RST is acceptable, the
connection will be aborted resulting in a denial of service. This
attack can also take advantage of the fact that some protocols use
well known ports so that the attacker does not need to also search
the port number space for the attack to be successful. A recent
study described in NISCC Vulnerability Advisory 236929 [NISCC] has
shown that this kind of attack is very easy to exploit in some type
of TCP connection, such as the persistent connection used in routers
supporting BGP [RFC1771]. The number of segments needed to have a
successful attack is far less than previously thought. And as the
receive window used in TCP connection is getting larger as network
speed is getting faster, this TCP weakness also becomes easier to
exploit.
[RFC2385] describes a method of using a TCP MD5 signature option to
strength the segment acceptance test. The option contains a MD5
Poon & Demizu Expires April 24, 2005 [Page 4]
Internet-Draft Timestamp against spoofing October 2004
digest of the segment and a key known only to the two end points of a
TCP connection. The receiver can then use this option to verify the
segment's acceptability. This method not only can defend against
blind spoofing attack, it can also defend against attacker who can
obtain segments exchanged in a connection. IPSEC [RFC2401] is
another obvious choice to use for authentication. It not only
protects TCP, but other protocols over IP as well.
In this document, we propose a light weight alternative to the above
methods by making use of the TCP timestamp option [RFC1323]. The
timestamp option already provides PAWS (Protect Against Wrapped
Sequence numbers) and RTTM (Round Trip Time Measurement). It can
also be used to strengthen the TCP segment acceptance test if the
handling is modified a little.
Poon & Demizu Expires April 24, 2005 [Page 5]
Internet-Draft Timestamp against spoofing October 2004
3. Motivation
With the current TCP segment acceptance test, the probability of a
successful blind spoofing attack is proportional to the receive
window used. This assumes that an attacker can find out the ports
and IP addresses being used in a connection. The obvious solution is
to use cryptographic method to authenticate all TCP segments, as
suggested in the other methods mentioned in the Introduction.
Another possible solution to address this weakness is to put a
"cookie" in every TCP segments. If the cookie is only known to the
end points of a connection, it allows the receiver to verify that a
segment indeed belongs to the connection by checking the segment's
cookie. This is similar to the verification tag (vtag) in SCTP
[RFC2960]. Note that the SCTP vtag is the same in every packets and
its use is for verifying an incoming packet indeed belongs to the
intended SCTP association. An attacker needs to find out the vtag of
an association to spoof any packet. The issue with the cookie
mechanism is that it does not protect against a man in the middle
attack. Cryptographic methods, such as the TCP MD5 option, do not
have this problem.
A cookie requires a new TCP option to hold the value. As the option
space in a TCP header is limited, we look at the existing timestamp
option to see if it can be used instead.
Poon & Demizu Expires April 24, 2005 [Page 6]
Internet-Draft Timestamp against spoofing October 2004
4. Basic Idea
As specified in RFC 1323, the TCP timestamp option contains two
values, the sender's timestamp (TSval) and the echo reply (TSecr) of
the timestamp received from its peer end point. From a receiver's
view, the value of TSval in each incoming segment (SEG.TSval) is set
in a monotonically increasing manner by the peer. Each value of
SEG.TSval is thus greater than or equal to the value of the previous
received segment unless reordering occurs or the TCP connection is
idle for a significant amount of time (e.g., more than 24.8 days)
such that the value wraps around. TSval is used for PAWS checking.
The check is in section 4.2.1 of RFC 1323
If SEG.TSval < TS.Recent and TS.Recent is valid, the
segment is rejected.
The probability of guessing a valid SEG.TSval that passes the PAWS
test is 1 in 2. Also see Appendix A about a specification
inconsistency in [1323bis].
The value of TSecr in each incoming segment (SEG.TSecr) is the value
of TSval in the last segment received by the peer that advances its
RCV.NXT. The possible range of SEG.TSecr would vary from a few RTTs
to a few seconds. Hence, the probability of guessing a SEG.TSecr
that falls within this range would vary from 1 in 2^32 during idle
time in a lossless network to around 1 in 2^20 when an ACK segment is
lost, where RTO is 3 seconds and the timestamp clock frequency is 1
ms. The value of SEG.TSecr is not checked as specified in RFC 1323.
TCP only uses SEG.TSecr to do RTTM.
While the TSval can be considered as an "extension" to the sequence
number space, the TSecr may be considered as a "pseudo cookie." The
reason is that a TCP end point should know exactly what TSval values
it has used to send segments to its peer, and the TSecr in every
incoming segments should only contain those values. This means that
a TCP end point should be able to verify that a TSecr value is one of
those TSval it has used. As noted above, the probability of guessing
a TSecr to fall within this valid range is not high. So the TSecr
value can be treated as a "pseudo cookie."
The timestamp option is normally used if the receive window of a
connection is large, and this is when TCP is more vulnerable to blind
spoofing attack. This makes the use of timestamp option to protect
against blind spoofing attack more attractive as it is "free."
4.1 Tracking the TSecr range
The first issue to resolve is how to track the TSecr valid range such
Poon & Demizu Expires April 24, 2005 [Page 7]
Internet-Draft Timestamp against spoofing October 2004
that a receiver can easily determine if an incoming segment is
spoofed. We propose to add two new variables to the TCP connection
state, TS.SndMax and TS.SndMin.
TS.SndMax holds the maximum value of TSval that has been used. It is
set whenever a new data segment is sent to the peer. Since the value
of TSecr in every segments is copied from TS.Recent on the peer node,
and the value of TS.Recent is copied from TSval, TSecr in every
received segments should never exceed TS.SndMax. TS.SndMax is the
upper bound of valid TSecr values in every non-spoofed segments.
TS.SndMin holds the value of TSecr in every acceptable segments
received which SEG.SEQ is equal to RCV.NXT. Its initial value is the
value of TSval in the first segment sent, which is either the SYN or
SYN|ACK segment. As TS.Recent in the peer node is monotonically
increasing and TSecr is copied from TS.Recent, TS.SndMin is the lower
bound of valid TSecr values in every non-spoofed segments.
With these two variables, a receiver can verify if an incoming
segment is valid or not by the following condition
If TS.SndMin <= SEG.TSecr <= TS.SndMax, the segment is accepted.
We refer the above condition as PASA (Protection Against Spoofing
Attack) [PASA] test.
4.2 Narrowing Down the Valid TSecr Range
To make the PASA test more effective, the valid range of TSecr must
be as narrow as possible. Because of a specification inconsistency
(refer to Appendix A), there can be more than one way by which
TS.Recent is updated. For example, if an implementation follows
section 3.4 of 1323bis, TSval in pure ACK segment can be used to
update TS.Recent. But an implementation following RFC 1323 does not
allow this. This causes different dynamics in the valid TSecr range
and makes narrowing down the range difficult. Refer to Appendix B
for a detailed explanation on how the different ways of updating
TS.Recent can cause problems with the PASA test.
As a sender can control what TSval to put in an outgoing segment, we
propose to change the rule in generating TSval so that the PASA test
can work well with different implementations using different methods
of updating TS.Recent. The new rule is
For TSval on segments with SEG.LEN > 0, use the current
timestamp clock as specified in RFC 1323. For TSval on
segments with SEG.LEN = 0, use the last value of TSval sent
to the peer.
Poon & Demizu Expires April 24, 2005 [Page 8]
Internet-Draft Timestamp against spoofing October 2004
Making use of the newly introduced TS.SndMax, the above rule is
equivalent to
When sending a segment with SEG.LEN > 0, set TS.SndMax to
the current timestamp clock. Use this TS.SndMax as
TSval in the outgoing segment.
Use TS.SndMax as TSval on segment with SEG.LEN = 0.
Using this new rule, only TSval in a segment with SEG.LEN > 0 will
update the TS.Recent value as other segments contain an old TSval.
This rule narrows down the valid range of TSecr. Note that it does
not affect RTTM as only TSecr in an incoming segment which
acknowledges data is used to make measurement. This means that only
the TSval in a segment with SEG.LEN > 0 is needed to update TS.Recent
for RTTM. Also see Appendix C for another proposal on how to deal
with this problem.
4.3 Unpredictable Timestamp
To make PASA robust, it is important to keep the value of TSval used
unpredictable from a malicious, off-path third party. Normally, the
SEG.TSval contains the value of the local timestamp clock
(my.TSclock) when a segment is sent. If a node uses one global
timestamp clock as the my.TSclock for all TCP connections, it will be
easy for a malicious, off-path third party to guess the valid value
for TSecr. This is because the current TSval could easily be
obtained by establishing another TCP connection with the target node.
To defend against such attack, we propose to have a random offset to
the timestamp clock for each connection or destination. The TCP
connection state is augmented by one 32-bit unsigned integer,
TS.SndOff. Each TSval is then calculated as my.TSclock + TS.SndOff,
instead of using my.TSclock directly.
The value of TS.SndOff may be a pseudo-random number or the result of
F(local-node, local-port, remote-node, remote-port) where F is a
cryptographic hash function. The latter is similar to the method of
choosing a good initial sequence number as discussed in RFC 1948.
If a new TCP connection is opened with the same four tuple of
addresses of an existing TCP connection in TIME-WAIT state, the
TS.SndOff should be carefully chosen so that:
1. Duplicate delayed segments are not accepted as valid segments.
2. It is hard to infer the new valid range of TSecr from the
connection state of the previous TCP connection. This is to
Poon & Demizu Expires April 24, 2005 [Page 9]
Internet-Draft Timestamp against spoofing October 2004
avoid spoofing attack by the previous address holder in a DHCP or
mobile environment.
We suggest adding a random number to the existing TS.SndOff instead
of assigning a newly generated random number to TS.SndOff.
4.4 TSval to use after the connection is idle
When a data segment is sent after the connection is idle for a long
period of time, TS.SndMax is set to the value of the current
my.TSclock, and the difference between TS.SndMax and TS.SndMin will
be very large until an ACK segment is returned. If the data segment
or the ACK segment in reply is lost, TS.SndMin will be unchanged
until the data segment sent is acknowledged after retransmission
timeout. During the period when the difference is large, the
probability of guessing a valid TSecr will also be large. Therefore,
a method of keeping the difference small is desired. Note that this
window of vulnerability is normally only a couple of RTOs.
We introduce an upper limit to the advancement of TSval. If no data
segment has been sent to the peer for more than the upper limit of
time, then the next value of TSval used should be TS.SndMax plus the
upper limit instead of the value of my.TSclock + TS.SndOff (Section
4.3). Note that TS.SndMax is still monotonically increasing with
this modification.
The upper limit should be long enough (at least longer than both RTT
and MSL) so that there would be no side effect on other mechanisms,
such as RTTM, PAWS, and Eifel [RFC3522]. A possible candidate for
the upper limit will be ten minutes. This solution can easily be
implemented by tweaking TS.SndOff as follows.
The TCP connection state is augmented by a new variable, TS.MaxAdv,
which is the upper limit of the advancement of TSval. Before sending
a segment (only when TS.SndMax is updated),
if (my.TSclock - TS.SndMax > TS.MaxAdv) then
TS.SndOff = TS.MaxAdv - (my.TSclock - TS.SndMax)
Since each TSval is calculated as my.TSclock + TS.SndOff (refer to
Section 4.3), when no segment is sent for longer than TS.MaxAdv, the
next TSval value used will be
TSval = TS.SndMax
= my.TSclock + TS.SndOff
= my.TSclock + (TS.MaxAdv - (my.TSclock -
old_TS.SndMax))
= old_TS.SndMax + TS.MaxAdv
Poon & Demizu Expires April 24, 2005 [Page 10]
Internet-Draft Timestamp against spoofing October 2004
4.5 RST Handling
On Page 18 of RFC 1323, it is recommended that a RST should not
contain a timestamp option and a TCP stack should ignore the
timestamp option of an incoming segment if it is a RST. To make use
of timestamp option for PASA test, a RST needs to carry the timestamp
option. We propose to change the way RST is generated in all TCP
states as follows.
If a RST is sent because of one of the reasons stated in RFC 793 for
an incoming segment and it has a timetstamp option, the RST MUST be
If the ACK bit is off, sequence number zero is used,
<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
<TSval=SEG.TSecr><TSecr=SEG.TSval>
If the ACK bit is on,
<SEQ=SEG.ACK><CTL=RST><TSval=SEG.TSecr><TSecr=SEG.TSval>
If the incoming segment does not contain a timestamp option, send a
RST without timestamp option according to RFC 793.
If a RST is sent because a connection is aborted, the RST MUST be
<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
<TSval=TS.SndMax><TSecr=TS.Recent>
With the above changes, a valid RST containing the above TSecr will
pass the PASA test and be accepted. And it is hard for an attacker
to spoof such a RST segment. The problem with RST handling is that
the TCP stack cannot know if its peer has this modification or not.
If it receives a RST without a timestamp option, should the RST be
accepted or not? This issue is discussed in the next section Section
4.6.
4.6 Level of Protection
Level 0 - No Protection
The PASA test requires the use of timestamp option. If the timestamp
option is not used for a connection, there is no protection at all.
Level 1 - Protection against spoofed segment, except RST
If the timestamps option is used for a connection, a node
implementing the PASA test is protected against "any" spoofed segment
Poon & Demizu Expires April 24, 2005 [Page 11]
Internet-Draft Timestamp against spoofing October 2004
except RST. As discussed in Section 4.5, the problem with RST is
that it requires the peer to be modified for RST segment handling
also. There is currently no way to communicate with the peer about
this information.
One solution is to introduce a new TCP option called PASA-OK (refer
to Appendix D). Its purpose is to indicate that the sender of the
PASA-OK option is modified to do what Section 4.5 suggests. Then the
TCP stack can know if the PASA test can be used to test against RST
segment. This leads to the next level of protection.
Level 2 - Protection against any spoofed segment
If both sides of a TCP connection know that its peer is PASA capable
by using the PASA-OK option, then "no" spoofed segment will be
accepted. If PASA-OK is not supported in either the local or peer
node, a TCP stack SHOULD allow an application to specify that any RST
segment not containing a timestamp option to be dropped. In this
way, the TCP connection is protected against any spoofed segment.
The only catch is that if the peer is not modified to do the RST
handling in Section 4.5, the application SHOULD have some form of
keep-alive probing mechanism to check the status of its peer.
A PASA capable implementation SHOULD allow an application to specify
the required level of protection for individual TCP connection. If
required level cannot be met, the TCP connection SHOULD be aborted
and a RST segment as described in Section 4.5 SHOULD be sent to its
peer. If the application specifies a protection level 2 and the peer
is not PASA capable (because PASA-OK option is not implemented in
either the local or peer node), the stack SHOULD let the application
know about this. The application can then decide whether to abort
this connection.
Poon & Demizu Expires April 24, 2005 [Page 12]
Internet-Draft Timestamp against spoofing October 2004
5. Modified Timestamp Option Handling
A TCP implementation MAY modify the timestamp option handling to
support PASA as described below. If PASA is used, the implementation
MUST provide a mechanism, such as a TCP socket option, for this
handling to be turned on or off for individual TCP connection.
The TCP connection state SHOULD be augmented by four variables:
TS.SndMax, TS.SndMin, TS.SndOff, and TS.MaxAdv. They should be
initialized as follows. Refer to Section 4.1, Section 4.3, and
Section 4.4.
TS.SndOff = random number
TS.SndMin = my.TSclock + TS.SndOff
TS.SndMax = my.TSclock + TS.SndOff
TS.MaxAdv = the upper limit to the advancement of TSval
5.1 Segment Sending
When sending:
1. SYN or SYN|ACK, follow Appendix D and Section 4.6 if an
application specifies a protection level.
2. RST, follow Section 4.5.
3. All other segments,
if (SEG.LEN > 0) {
if (my.TSclock - TS.SndMax > TS.MaxAdv)
TS.SndOff = TS.MaxAdv - ( my.TSclock - TS.SndMax );
TS.SndMax = my.TSclock + TS.SndOff;
}
<SEQ=SNT.NXT><ACK=RCV.NXT><CTL=ACK>
<TSval=TS.SndMax><TSecr=TS.Recent>
5.2 Segment Receiving
If a TCP connection cannot be found for an incoming segment, send
back a RST according to Section 4.5. If an application specifies
protection level 0, follow the receive processing of RFC 1323.
Otherwise, perform the following checks.
5.2.1 LISTEN, and SYN-SENT States
Follow the receive processing as in RFC 793. After the segment is
accepted, it SHOULD be tested for whether it satisfies the protection
Poon & Demizu Expires April 24, 2005 [Page 13]
Internet-Draft Timestamp against spoofing October 2004
level required by the application (either 1 or 2). This means that
the received segment MUST carry the TCP Timestamps option. If not,
send back a RST according to Section 4.5. If the TCP is in SYN-SENT
state, the connection should be aborted.
5.2.2 Other States
The incoming segment is a RST.
1. Protection level is 1: Follow the RFC 1323 receive processing.
2. Protection level is 2: If the segment does not contain the
timestamp option, drop it. Otherwise, perform the PASA test on
the. If the test fails, drop the RST segment. If not, follow
the RFC 1323 receive processing.
The incoming segment is not a RST.
If the segment does not contain the timestamp option, drop it.
Otherwise, perform the PASA test on the incoming segment. If the
test fails, an ACK segment SHOULD be sent in reply as specified on
page 69 of RFC 793. Then drop the segment. Note that this rule is
the same as that of PAWS in RFC 1323.
If the PASA test succeeds,
if (TS.SndMin < SEG.TSecr && SEG.SEQ == RCV.NXT)
TS.SndMin = SEG.TSecr;
Follow RFC 1323 for the rest of processing.
Poon & Demizu Expires April 24, 2005 [Page 14]
Internet-Draft Timestamp against spoofing October 2004
6. Security Considerations
The proposed method in this document is not a replacement of other
cryptographic mechanisms for authenticating TCP segments. It only
reduces the probability of a successful blind spoofing attack
provided that the attacker cannot obtain segments exchanged between
the two TCP end points of a connection.
Poon & Demizu Expires April 24, 2005 [Page 15]
Internet-Draft Timestamp against spoofing October 2004
7. Acknowledgement
The idea of using TCP timestamp option originates from discussion on
the TCPM WG mailing list [TCPM].
8 References
[1323bis] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions
for High Performance", (work in progress)
draft-jacobson-tsvwg-1323bis-00.txt, August 2003.
[NISCC] National Infrastructure Security Co-ordination Centre,
"NISCC Vulnerability Advisory 236929", April 2004,
<http://www.uniras.gov.uk/vuls/2004/236929/index.htm>.
[PASA] Demizu, N., "Protection Against Spoofing Attacks by Using
the TCP Timestamps Option", (work in progress)
draft-demizu-tcpm-pasa-issues-00.txt, October 2004.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", RFC 1122, October 1989.
[RFC1323] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L. and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm
for TCP", RFC 3522, April 2003.
Poon & Demizu Expires April 24, 2005 [Page 16]
Internet-Draft Timestamp against spoofing October 2004
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[TCPM] IETF TCPM Working Group,
"http://www.ietf.org/html.charters/tcpm-charter.html",
April 2004.
Authors' Addresses
Kacheong Poon
Sun Microsystems, Inc.
M/S USJC01-201
4150 Network Circle
Santa Clara, CA 95054
USA
EMail: kacheong.poon@sun.com
Noritoshi Demizu
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi, Koganei
Tokyo 184-8795
Japan
EMail: demizu@nict.go.jp
Poon & Demizu Expires April 24, 2005 [Page 17]
Internet-Draft Timestamp against spoofing October 2004
Appendix A. Timestamp Specification Inconsistency
When RFC 1323 was updated by 1323bis, one important change was when
to update TS.Recent as there was an inconsistency in RFC 1323.
Section 3.4 of RFC 1323 specifies that if the following condition is
true, TS.Recent is updated.
SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN - (A)
But in section 4.2.1 of RFC 1323, it uses this condition instead.
SEG.SEQ <= Last.ACK.sent
In 1323bis, this inconsistency was clarified and the condition was
updated as
SEG.TSval >= TS.Recent and SEG.SEQ <= Last.ACK.sent - (B)
There is still a problem. Note that there is a step (R2) in section
4.2 of both RFC 1323 and 1323bis. (R2) specifies that if an incoming
segment is not inside the receive window, the segment is rejected.
This is done before the condition comparing SEG.SEQ and Last.ACK.Sent
is checked. In effect, if (R2) is done, the condition (B) will
become
if (SEG.LEN > 0)
SEG.SEQ <= Last.ACK.sent <= RCV.NXT < SEG.SEQ + SEG.LEN
else if (SEG.LEN == 0)
SEG.SEQ == Last.ACK.sent == RCV.NXT - (B')
Another confusing fact is that the step (R2) is not shown in the
Appendix E PSEUDO-CODE SUMMARY of 1323bis. Because of the above, an
implementation may choose any one of the conditions for updating
TS.Recent.
As commented in Appendix C of 1323bis, it is good to be able to use
the TSval in "a retransmitted segment that resulted from a lost ACK"
(meaning duplicate segment). Both (A) and (B') do not allow this.
We propose to change the condition to be
SEG.TSval >= TS.Recent and
RCV.NXT - RCV.WND <= SEG.SEQ <= Last.ACK.sent
Using this condition, TS.Recent is also updated by duplicate
segments.
Poon & Demizu Expires April 24, 2005 [Page 18]
Internet-Draft Timestamp against spoofing October 2004
Appendix B. PASA Issues with Different TS.Recent Update Methods
As noted in Appendix A, there are different methods in updating
TS.Recent. As TSecr in a segment is copied from TS.Recent, this
means that the valid range of TSecr can be different if the peer uses
different methods to update TS.Recent. This affects the
effectiveness of the PASA test.
If a peer node uses condition (A) in Appendix A to update TS.Recent,
the valid range of SEG.TSecr would be within a few RTTs almost all
the time. The reason is that TS.Recent on the peer node is updated
only by new data segments. It is never updated by duplicate data
segments, window updates, or keep-alive segments. Therefore, in
cases where no segment is lost, the difference between TS.SndMax and
TS.SndMin will be at most around one RTT. And when a TCP connection
becomes idle, the difference will typically be zero. Even in cases
where some segments are lost, if the losses are recovered soon, say
within a few RTTs, the difference will be at most around a few RTTs.
If a peer node uses condition (B), the valid range of SEG.TSecr can
be very large for a long period of time. The reason is that
TS.Recent on the peer node is updated by non-data segments, such as
window updates and keep-alive probes. Assuming that the TCP also
follows the rule specified in RFC 1323 in generating TSval in an
outgoing segment. This means that TS.SndMax is updated whenever any
segment is sent. When a non-data segment is sent, TS.SndMin may not
be updated soon because no segment may be sent back in reaction to
that non-data segment. Consequently, the difference between
TS.SndMax and TS.SndMin can become very large for a long period of
time. The following are examples of scenarios where the valid range
of TSecr is very large.
Note: In the examples below, TS.SndMax is updated whenever any
segment is sent.
Example 1 - Window updates
Window updates can be delayed for a long period of time, because they
are sent when an application reads data. For example, when an
application is displaying a modal dialog and waiting for a user's
input, it often does not read the received data until the modal
dialog is closed. As another example, if a user suspends an
application for a long time, it cannot read received data during the
suspended period. In such cases, upon sending a window update,
TS.SndMax is advanced while TS.SndMin stays unchanged. The
difference between TS.SndMax and TS.SndMin can become very large.
And TS.SndMax and TS.SndMin will stay unchanged until some segments
are exchanged.
Poon & Demizu Expires April 24, 2005 [Page 19]
Internet-Draft Timestamp against spoofing October 2004
Example 2 - TCP receives a keep-alive probe from its peer
The interval between TCP keep-alive probes is typically a couple of
hours. When a peer node sends a TCP keep-alive probe, the TSecr in
the probe segment contains an old timestamp near the value of
TS.SndMin, which is a couple of hours earlier. TCP responds to the
probe with an ACK segment which has a TSval equals to the current
timestamp clock, TS.SndMax also needs to be updated to that value.
But TS.SndMin is not updated in this scenario. Hence, the difference
between TS.SndMax and TS.SndMin will become a couple of hours until
some segments are exchanged afterwards.
Example 3 - TCP sends a keep-alive probe to its peer
In the case when TCP sends a keep-alive probe to its peer, if the
keep-alive probe or its corresponding ACK segment is lost, the
difference between TS.SndMax and TS.SndMin will be a couple of hours
until the TCP keep-alive procedure finishes successfully after
retransmitting the probe. At that time, TS.SndMax and TS.SndMin will
become the same again. Fortunately, this should normally take a
couple of RTTs.
Poon & Demizu Expires April 24, 2005 [Page 20]
Internet-Draft Timestamp against spoofing October 2004
Appendix C. New Condition for Updating TS.Recent
As seen in Appendix B, the essential difference between conditions
(A) and (B) is that TS.Recent in a node using (A) is updated only by
new data segments while TS.Recent in a node using (B) can be updated
by duplicate data segments and non-data segments. Taking into
account of (B') in Appendix A, we propose the following condition to
replace both (A) and (B)
RCV.NXT - RCV.WND <= SEG.SEQ <= Last.ACK.sent &&
SEG.LEN > 0 - (C)
If a peer node uses (C), the valid range of SEG.TSecr would be
narrower than that of a peer node using (A) or (B). It does not have
the problems discussed in Appendix B. Furthermore, (C) also provides
RTT measurements for retransmitted segments like (B).
Using condition (C) to update TS.Recent can be considered as an
alternative to the method proposed in Section 4.2. The problem with
this is that it requires all peer nodes to be modified. This is a
difficult deployment issue to overcome.
Poon & Demizu Expires April 24, 2005 [Page 21]
Internet-Draft Timestamp against spoofing October 2004
Appendix D. TCP PASA-OK Option
The TCP PASA-OK option indicates that the sender supports PASA. This
option MAY be sent on a SYN segment. It also MAY be sent on a
SYN|ACK segment, but only if the option is received in the
corresponding SYN segment. This option SHOULD not be sent in other
segments. As discussed in Section 4.6, this option is not mandatory
in order to provide protection level 2.
The format of the TCP PASA-OK option is
+--------+--------+
|Kind=TBD|Length=2|
+--------+--------+
If the TCP PASA-OK option is sent on a SYN or SYN|ACK segment, the
TCP Timestamps option MUST be sent on the same segment.
Implementation note: These two TCP options can be sent in the
following format.
+--------+--------+--------+--------+
|PASA-OK | Len=2 | TSopt | Len=10 |
+--------+--------+--------+--------+
| TSval |
+--------+--------+--------+--------+
| TSecr |
+--------+--------+--------+--------+
In the above diagram, the TSval is equal to TS.SndMax. The TSecr is
equal to 0 if it is a SYN segment. If it is a SYN|ACK segment, the
TSecr is equal to the TSval in the corresponding SYN segment.
Poon & Demizu Expires April 24, 2005 [Page 22]
Internet-Draft Timestamp against spoofing October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Poon & Demizu Expires April 24, 2005 [Page 23]