Network Working Group K. Poon
Internet-Draft Sun Microsystems, Inc.
Expires: December 16, 2004 June 17, 2004
Use of TCP timestamp option to defend against blind spoofing attack
draft-poon-tcp-tstamp-mod-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 December 16, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
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 timetstamp option as an
alternative.
Poon Expires December 16, 2004 [Page 1]
Internet-Draft Timestamp against spoofing June 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 Expires December 16, 2004 [Page 2]
Internet-Draft Timestamp against spoofing June 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, and the received segment
length SEG.LEN. For example, suppose TCP receives a 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.
Another form of attack is an attacker can inject spoofed data to a
TCP connection. 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
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
Poon Expires December 16, 2004 [Page 3]
Internet-Draft Timestamp against spoofing June 2004
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 checking. It can also be used
to strength the TCP segment acceptance test if the handling is
modified a little as described in RFC1323.
Poon Expires December 16, 2004 [Page 4]
Internet-Draft Timestamp against spoofing June 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 original use is for demultiplexing. But it can also be seen as a
light weight method for defending against blind spoofing attack as 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.
As specified in RFC1323, the TCP timestamp option contains two
values, the sender's timestamp and the echo reply of the timestamp
received from its peer end point. The sender's timestamp is used for
PAWS checking and the timestamp echo reply is used for RTT
calculation. While the timetstamp value can be considered as an
"extension" to the sequence number space, the timestamp echo reply
may be considered as a "pseudo cookie." The reason is that a
receiver should know exactly what timestamp values it has used to
send segments to its peer, and the timestamp echo reply only contains
those values. This means that a receiver should be able to verify
that a timemstamp echo reply value is one of those timestamps it has
used. If the timestamp option value used is not easy to guess by an
attacker, the timestamp echo reply can be treated as a "pseudo
cookie." Note also that the timestamp option has to be used if the
receive window of a connection is large, and this is when TCP is more
vulnerable to blind spoofing attack.
Poon Expires December 16, 2004 [Page 5]
Internet-Draft Timestamp against spoofing June 2004
4. Modified Timestamp Option Handling
A TCP implementation MAY add the following modified timestamp option
handling to defend against blind spoofing attack. If it 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.
A new state variable TS.Echo is added. It is initialized to be the
first timestamp sent to the peer. And it is updated using the
timestamp echo reply value in a segment. See below on the procedure.
4.1 Connection setup
The timestamp option MUST be negotiated in setting up a connection in
both passive and active open. If the peer does not accept timestamp
option, send a RST to end the connection setup.
SYN-SENT state
<SEQ=SNT.NXT><CTL=RST>
SYN-RECEIVED state
<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
In SYN-SENT state, if the ACK is not acceptable according to RFC793,
send back a RST
<SEQ=SEG.ACK><CTL=RST><TSval=TSecr><TSecr=TSval>
and discard the segment.
4.2 RST generation
On Page 18 of RFC1323, 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 stricter segment acceptance test, we propose
to change the way RST is generated in all TCP states.
If a RST is sent because of one of the reasons stated in RFC793 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=TSecr><TSecr=TSval>
Poon Expires December 16, 2004 [Page 6]
Internet-Draft Timestamp against spoofing June 2004
If the ACK bit is on,
<SEQ=SEG.ACK><CTL=RST><TSval=TSecr><TSecr=TSval>
If the incoming segment does not contain a timestamp option, send a
RST without timestamp option according to RFC793.
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=my.TSclock><TSecr=TS.Recent>
4.3 Modified acceptance test in ESTABLISHED state
If an incoming segment does not contain a timestamp option, drop it.
Follow RFC1323 to verify the timestamp value TSval of the segment.
If it is not acceptable, follow RFC1323 to send back an ACK.
If the segment is a SYN, the peer may have restarted. The TCP stack
SHOULD send a keep-alive segment, as specified on Page 101 of
[RFC1122], to check if the peer has really restarted. If the peer
has restarted, it will send back a RST.
If the segment is acceptable according to the timestamp test, verify
the timestamp echo reply TSecr value. The value should be between
the TS.Echo and the current timestamp. If it is not, drop the
segment. If the segment is acceptable, and SEG.SEQ equals to
RCV.NXT, update the TS.Echo with TSecr.
Follow RFC1323 for the rest of processing.
Poon Expires December 16, 2004 [Page 7]
Internet-Draft Timestamp against spoofing June 2004
5. Limitations
The proposed method requires both sides of a TCP connection to
support the timetstamp option. This is generally not a problem in
today's host TCP implementations. Most, if not all, support RFC1323
extensions. This may not be true for TCP implementations in small
devices as they usually do not need to support high speed TCP
transfer, thus no need for RFC1323 extensions . But those devices
are also less likely to be hit by a blind spoofing attack.
If only one side of a TCP connection has the proposed change, it
means that the unchanged side may not send an acceptable RST to its
modified peer. This is following the recommendation on Page 18 of
RFC1323. And this may create a "hung" TCP connection. An
application which enables this protection mechanism SHOULD use an
application timer to guard against this case.
When a connection has been idle for a long time T, the protection
becomes weaker. Any TSecr value between TS.Echo + T is acceptable.
For example, if the local clock increases 1 per 10ms and the
connection has been idle of 120s, the window of acceptable TSecr is
120000. In such a case, the acceptance test MAY be modified to a
stricter check as follows.
If the connection has been idle for a time period longer than T,
the TSecr value of an incoming segment MUST be equal to TS.Echo to
be acceptable. T SHOULD be greater than 60s.
Poon Expires December 16, 2004 [Page 8]
Internet-Draft Timestamp against spoofing June 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. The initial timestamp chosen
MUST not be guessed easily. A similar algorithm as in choosing a
good initial sequence number, such as RFC1948, SHOULD be used.
Poon Expires December 16, 2004 [Page 9]
Internet-Draft Timestamp against spoofing June 2004
7. Acknowledgment
The idea of using TCP timestamp option originates from discussion on
the TCPM WG mailing list [TCPM].
8 References
[NISCC] National Infrastructure Security Co-ordination Centre,
"NISCC Vulnerability Advisory 236929", April 2004, <http:/
/www.uniras.gov.uk/vuls/2004/236929/index.htm>.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", October 1989.
[RFC1323] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions
for High Performance", May 1992.
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", March 1995.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
May 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", August 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", 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", October 2000.
[RFC793] Postel, J., "Transmission Control Protocol", September
1981.
[TCPM] IETF TCPM Working Group and mailing list,
"http://www.ietf.org/html.charters/tcpm-charter.html",
April 2004.
Poon Expires December 16, 2004 [Page 10]
Internet-Draft Timestamp against spoofing June 2004
Author's Address
Kacheong Poon
Sun Microsystems, Inc.
M/S USJC01-201
4150 Network Circle
Santa Clara, CA 95054
US
EMail: kacheong.poon@sun.com
Poon Expires December 16, 2004 [Page 11]
Internet-Draft Timestamp against spoofing June 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Poon Expires December 16, 2004 [Page 12]
Internet-Draft Timestamp against spoofing June 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Poon Expires December 16, 2004 [Page 13]