One document matched: draft-demizu-tcpm-pasa-issues-00.txt
Network Working Group Noritoshi Demizu
INTERNET-DRAFT NICT
Expires: April 18, 2005 October 18, 2004
Protection Against Spoofing Attacks by Using the TCP Timestamps Option
<draft-demizu-tcpm-pasa-issues-00.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I 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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This memo describes a method of protecting TCP connections against
off-path, third party spoofing attacks, by making use of the TCP
Timestamps option specified in RFC1323.
The original basis of the idea was proposed by Kacheong Poon. This
memo discusses its issues to add complementary ideas to his original
approach. Viable ideas in this memo will be incorporated into his
upcoming draft.
Demizu Expires April 2005 [Page 1]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Description . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Tracking the Range . . . . . . . . . . . . . . . . . . . . 5
4.2 Narrowing the Range . . . . . . . . . . . . . . . . . . . . 6
4.3 Unpredictable Timestamps . . . . . . . . . . . . . . . . . 12
4.4 Changing the Range Slowly . . . . . . . . . . . . . . . . . 13
4.5 Timestamps to Send . . . . . . . . . . . . . . . . . . . . 15
4.6 Protection Levels . . . . . . . . . . . . . . . . . . . . . 18
4.7 Timestamps to Accept . . . . . . . . . . . . . . . . . . . 20
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1 Inequalities (A), (B), and (C) vs. RTTM, PAWS, and Eifel . 21
5.2 Proposal (2d) vs. RTTM, PAWS, and Eifel . . . . . . . . . . 23
5.3 Comparison of Proposed Solutions of Section 4.2 . . . . . . 24
6. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1 TCP PASA-OK option . . . . . . . . . . . . . . . . . . . . 25
6.2 Timestamps to Send . . . . . . . . . . . . . . . . . . . . 26
6.3 Protection Levels . . . . . . . . . . . . . . . . . . . . . 26
6.4 Timestamps to Accept . . . . . . . . . . . . . . . . . . . 28
6.5 The Processing Rule of PASA . . . . . . . . . . . . . . . . 29
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 34
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 34
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 35
Demizu Expires April 2005 [Page 2]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
1. Introduction
This memo describes a method of protecting TCP connections against
off-path, third party spoofing attacks, by making use of the TCP
Timestamps option [RFC1323].
In this memo, the proposed method of protecting against spoofing
attacks is called PASA (Protection Against Spoofing Attacks).
The original basis of this idea was proposed by Kacheong Poon
[Poon04]. This memo discusses its issues to provide complementary
ideas to his original idea. Viable ideas in this memo will be
incorporated into his upcoming draft. This memo would provide
background thought behind the method.
This memo is organized as follows. Section 2 describes the problems
caused by spoofing attacks. Section 3 introduces the basic idea for
protection against these attacks. Section 4 introduces key issues
and proposals, which are discussed further in section 5. Section 6
specifies the components of the PASA method, while section 7 gives
examples of how it works. Section 8 and 9 discuss security and IANA
considerations, respectively. In short, the purpose of sections 3
through 5 is to give the technical reasoning behind the specification
described in section 6.
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].
2. Problem Description
<<<TBD>>>
o Spoofing attacks to abort TCP connections by using RST segments.
o Spoofing attacks to abort TCP connections by using SYN segments.
o Spoofing attacks to close TCP connections by using FIN segments.
o Spoofing attacks to break TCP connections by using ACK segments.
o Spoofing attacks to inject false data segments.
3. Basic Idea
The TCP Timestamps option [RFC1323] has two fields: TSval and TSecr.
From the receiver's point of view, the values of these fields are
recognized as follows.
Demizu Expires April 2005 [Page 3]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
o TSval
The value of SEG.TSval (i.e., TSval on each incoming segment) is
determined in a monotonically non-decreasing manner by the peer
node. Each value of SEG.TSval is thus greater than or equal to
the value for the previous segment unless reordering occurs or the
TCP connection is idle for a significant amount of time (e.g.,
more than 24.8 days). The value of SEG.TSval is checked by PAWS
(Protect Against Wrapped Sequence numbers) [RFC1323]. The
probability of guessing a valid SEG.TSval is 1 in 2.
o TSecr
The value of SEG.TSecr (i.e., TSecr on each incoming segment) is
the value of TSval on the last segment that advanced the left edge
(RCV.NXT) of the receiving window of the peer node. The valid
range of SEG.TSecr would vary from a few RTTs to a few seconds.
Hence, the probability of guessing a valid SEG.TSecr would vary
from 1 in 2^32 during idle 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,
however, is not checked.
Since the probability of guessing a valid SEG.TSecr is not very high,
SEG.TSecr can be used to provide an additional obfuscation mechanism.
In other words, TCP connections can be protected against off-path,
third party spoofing attacks at a certain level by checking the
SEG.TSecr values of incoming segments. This is the basic idea of
PASA. This memo recommends using PAWS together with PASA as an
additional obfuscation mechanism.
[RFC1323] proposes to use the TCP Timestamps option for two
mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect
Against Wrapped Sequence numbers). [RFC3522] proposes another
mechanism using this option: Eifel. This memo proposes yet another
new mechanism based on the TCP Timestamp option.
[RFC1323] suggests but does not recommend checking the SEG.TSecr
values of incoming segments as a means of implementing PAWS. Since
the purpose of this proposal is different from that of PAWS and it is
not intended as a replacement for PAWS, the reason why [RFC1323] does
not recommend checking SEG.TSecr does not apply to this memo's
proposal.
Demizu Expires April 2005 [Page 4]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
4. Issues
The design of PASA involves the following issues.
1. Tracking the valid range of SEG.TSecr.
2. Keeping the valid range of SEG.TSecr narrow.
3. Making timestamps unpredictable.
4. Changing the valid range of SEG.TSecr slowly
5. Determining the timestamps that can be sent securely.
6. Classifying the protection levels.
7. Determining the timestamps that can be accepted securely.
This section discusses each of these issues one by one.
4.1 Tracking the Range
The key to this proposal is keeping track of the valid range of
SEG.TSecr accurately. This memo proposes tracking both the maximum
and the minimum values of SEG.TSecr.
The TCP per-connection state is augmented by two timestamps:
TS.SndMax and TS.SndMin.
o TS.SndMax --- Tracks the maximum valid value of SEG.TSecr.
Definition:
TS.SndMax holds the maximum value of TSval that has been sent.
Description:
TS.SndMax is monotonically non-decreasing.
The maximum value of TSval that has been sent is equal to the
value of TSval on the last data segment sent, because the value
of TSval on outgoing segments is monotonically non-decreasing.
Since the value of SEG.TSecr is copied from TS.Recent on the
peer node, and the value of TS.Recent is copied from SEG.TSval
on segments sent by the local node, SEG.TSecr never exceeds
TS.SndMax. When the TCP connection is idle, SEG.TSecr is
typically equal to TS.SndMax. Therefore, TS.SndMax is exactly
the upper limit of valid SEG.TSecr values.
Demizu Expires April 2005 [Page 5]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
o TS.SndMin --- Tracks the minimum valid value of SEG.TSecr.
Definition:
TS.SndMin holds the maximum value of SEG.TSecr that has been
received for an acceptable segments [RFC793]. Its initial
value is the value of TSval on the first segment sent.
Description:
TS.SndMin is monotonically non-decreasing.
Since TS.Recent on a peer node is monotonically non-decreasing
and SEG.TSecr is copied from TS.Recent on the peer node,
SEG.TSecr is also monotonically non-decreasing and is never
less than TS.SndMin, unless segments are reordered.
Taking account of reordering, it would be possible to choose an
appropriate margin "T1" so that SEG.TSecr would not exceed
TS.SndMin - T1 for almost all cases. Possible candidates for
the value of T1 would be one RTT or RTO.
A TCP module would maintain the estimated RTT and RTO from the
sender's point of view according to [RFC2988]. Although the
actual RTT from the receiver's point of view might be different
from the estimated RTT from the sender's point of view,
especially for asymmetric paths, the estimated RTT or RTO from
the sender's point of view would be a candidate for T1.
Note: TS.SndMin is the same as TS.Echo proposed in [Poon04].
Therefore, SEG.TSecr on any valid incoming segment is expected to
satisfy the following inequality with an appropriate margin "T1":
TS.SndMin - T1 <= SEG.TSecr <= TS.SndMax, where T1 = RTT or RTO.
This memo proposes to test incoming segments by applying this
inequality in order to detect spoofed segments. This test is called
the "PASA test" in this memo.
4.2 Narrowing the Range
To make PASA effective, it is important to keep the valid range of
SEG.TSecr as narrow as possible.
In fact, the width of the valid range depends on the implementation
of the TCP Timestamps option on a peer node.
Demizu Expires April 2005 [Page 6]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
4.2.1 Variants of the Timestamps Option
There are two implementation variants of the TCP Timestamps option.
The difference lies in the conformance level to the inequality
defined in step (2) in section 3.4 of [RFC1323].
o Some implementations use the following inequality:
SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN ... (A)
Note: (A) appears in step (2) in section 3.4 of [RFC1323].
o Other implementations use the following inequality:
SEG.SEQ <= Last.ACK.sent ... (B)
Note: (B) appears in step R3) in section 4.2.1 of [RFC1323].
It also appears in section 3.4 of both [JBB97] and [JBB03]
as "SEG.TSval >= TS.Recent and SEG.SEQ <= Last.ACK.sent".
For simplicity, here we ignore "SEG.TSval >= TS.Recent",
because it is part of the PAWS test and does not affect
the discussion below.
If a peer node complied with inequality (A), 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 was lost, the difference between TS.SndMax and TS.SndMin
would be at most around one RTT. And when a TCP connection became
idle, the difference would typically become zero. Even in cases
where some segments were lost, if the losses were recovered soon,
within a few RTTs, the difference would be at most around a few RTTs.
There are exceptions, however: if a recovery procedure after a
loss took a long period of time with numbers of unsuccessful
retransmission timeouts, the valid range of SEG.TSecr would become
wide. Under such bad situations, the best case would be where all
retransmitted data segments except the last one are lost. In this
case, TS.SndMax is updated on each retransmission timeout while
TS.SndMin is unchanged. When the loss is recovered, however,
TS.SndMin becomes equal to TS.SndMax. The worst case would be
where the first data segment arrives at the receiver, while all
ACK segments except one for the last retransmitted data segment
are lost. In this case, TS.SndMin keeps the time before the
retransmission started, while TS.SndMax holds the time when a
segment was last sent. Even when the loss is recovered, TS.SndMin
is not changed because TS.Recent on the peer node is not updated
Demizu Expires April 2005 [Page 7]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
by duplicate data segments. Hence, the difference between
TS.SndMax and TS.SndMin becomes large, and they would stay
unchanged until some segments were exchanged afterwards. In any
case, since the recovery period would be less than several
minutes, and the probability of these exceptional cases occurring
would not be high, these cases would not be a big problem.
On the other hand, if a peer node complies with inequality (B), the
valid range of SEG.TSecr could be very wide 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 segments.
Therefore, TS.SndMax MUST be updated whenever any segment is sent in
order for the peer node to comply with (B). When such non-data
segments are sent, however, TS.SndMin could not be updated because no
segment might be sent back. Consequently, the difference between
TS.SndMax and TS.SndMin could become very wide for a long period of
time. The following are examples of scenarios where the valid range
of SEG.TSecr would become very wide.
Note: In the examples below, TS.SndMax is updated whenever any
segment is sent.
Ex. 1 Window updates.
Window updates could 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 (e.g., by typing ^Z) for a long
time, it cannot read received data during the suspended period.
In such cases, upon sending window updates, TS.SndMax would be
advanced while TS.SndMin would stay unchanged. The difference
between TS.SndMax and TS.SndMin would become larger and nearly
equal to the difference between the time when all data are
received by the TCP module and the time when all data are read
by the application. Even worse, TS.SndMax and TS.SndMin would
stay unchanged until some segments were exchanged afterwards.
Ex. 2 TCP keep-alive from a peer node.
The interval between TCP keep-alive procedures is typically a
couple of hours. In the case where a peer node starts the TCP
keep-alive procedure, SEG.TSecr on each incoming keep-alive
segment contains an old timestamp near the value of TS.SndMin,
indicating a couple of hours earlier. The local node responds
with an ACK segment whose TSval contains the current timestamp
clock, which is equivalent to TS.SndMax. Note that TS.SndMin
Demizu Expires April 2005 [Page 8]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
is never updated in this scenario. Hence, the difference
between TS.SndMax and TS.SndMin would become a couple of hours
until some segments were exchanged afterwards.
Ex. 3 TCP keep-alive from a local node.
The interval between TCP keep-alive procedures is typically a
couple of hours, and the interval between retransmissions of
TCP keep-alive segments is normally very long compared to RTT.
In the case where a local node starts the TCP keep-alive
procedure, if a keep-alive segment or its corresponding ACK
segment was lost, the difference between TS.SndMax and
TS.SndMin would be a couple of hours until the TCP keep-alive
procedure finished successfully. Fortunately, in this case,
TS.SndMax and TS.SndMin would become the same once the TCP
keep-alive procedure finished.
In summary:
o If a peer node complies with (A) and the local node knows this,
the valid range of SEG.TSecr will be within a few RTTs almost all
the time, and there will be no problem with executing PASA.
o If a peer node complies with (B) or the local node does not know
which inequality the peer node complies with, TS.SndMax MUST be
updated whenever any segment is sent. Therefore, the valid range
of SEG.TSecr could be very wide for a long period of time. This
problem should be solved.
4.2.2 Proposed Solutions for (B)
The following proposals could be applied in response to the problem
introduced by nodes complying with (B), as described above.
(2a) Modify all peer nodes to comply with (A).
(2b) Inspect the variant types of peer nodes.
(2c) Introduce a new inequality (C).
(2d) Change the rule generating TSval.
These proposals are described below, and they are compared in section
5.3.
Note: Section 5.3 currently recommends (2d), and counts (2c) as the
second candidate. Readers may skip other proposals. The
author believes rejected proposals would inspire readers to
invent better proposals than (2c) or (2d). Rejected proposals
will be removed in future revisions, however.
Demizu Expires April 2005 [Page 9]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
4.2.2.1 Proposal (2a)
Proposal (2a) would modify all peer nodes to comply with (A).
Since (B) provides better RTT measurements for retransmitted segments
than does (A), (B) would supposedly be deployed widely. Therefore,
(2a) would be deployable only where administrators consider PASA much
more important than the advantages of using (B) and all peer nodes
are under control of such administrators. Hence, it would be
difficult to deploy (2a) widely. Interactions between inequality (A)
and RTTM, PAWS, and Eifel are discussed in sections 5.1.
Pros. No need to invent a new mechanism.
Cons. Every peer node complying with (B) must be modified.
4.2.2.2 Proposal (2b)
Proposal (2b) would inspect the variant type of the peer node and
switch the behavior of the local node properly.
The outline of this procedure is as follows: TS.SndMax should be
updated whenever any segment is sent, until the variant type of the
peer node can be inferred. When a TCP connection is idle, inspect
the variant type of the peer node by using the procedure described
below. If the peer node complies with (A), switch the rule for
updating TS.SndMax to the one described in section 4.1. If the peer
node complies with (B), or if its variant type has not yet been
inspected, then when the valid range of the TCP connection becomes
wide, start the TCP keep-alive procedure in order to make the valid
range on the local node narrow, as described below.
The variant type of a peer node can be inspected by applying the
following procedure:
When a TCP connection is idle for more than several RTOs, update
TS.SndMax with the current timestamp clock, send a TCP keep-alive
segment whose TSval contains TS.SndMax, and wait for an ACK
segment.
o If SEG.TSecr on the returned ACK segment is near TS.SndMin, the
peer node would comply with (A).
o If SEG.TSecr on the returned ACK segment is equal to TS.SndMax,
the peer node would comply with (B).
This test can be rewritten as follows:
Demizu Expires April 2005 [Page 10]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
If (TS.SndMin - T1 <= SEG.TSecr < TS.SndMax), then (A).
If (SEG.TSecr == TS.SndMax), then (B).
If the peer node complies with (B), do the following:
When the TCP connection is idle, if the valid range of SEG.TSecr
has been wide for a certain period of time, the node should start
the TCP keep-alive procedure. After the keep-alive procedure
finishes successfully, the valid range of SEG.TSecr on the node
will be narrow.
Note that this procedure only makes the valid range of the local
node narrow. It does not make the valid range on the peer node
narrow. Therefore, both nodes may need to start this procedure
independently.
Pros. Peer nodes need not be modified.
Cons. The implementation would be very complex.
4.2.2.3 Proposal (2c)
Proposal (2c) would introduce a new inequality for peer nodes.
As seen in section 4.2.1, the essential difference between (A) and
(B) is that TS.Recent on a node complying with (A) is updated only by
new data segments, while TS.Recent on a node complying with (B) is
updated by any segment including duplicate data segments and non-data
segments.
If inequality (A) was modified so that TS.Recent was updated by both
new and duplicate data segments, the worst case among the exceptional
cases described in section 4.2.1 would be mitigated. If inequality
(B) was modified so that TS.Recent was not updated by non-data
segments, the valid range of SEG.TSecr would become narrow enough.
The inequalities from both modifications are fortunately the same.
In addition, it would be better to set the lower limit of SEQ.SEQ.
The proposed inequality is the following:
RCV.NXT - RCV.WND <= SEG.SEQ <= Last.ACK.sent &&
(SEG.LEN > 0 || SYN || FIN) ... (C)
If a peer node complied with (C), the valid range of SEG.TSecr would
be narrower than that of the case where a peer node complied with (A)
or (B). Furthermore, (C) would provide good RTT measurements for
retransmitted segments like (B). Interactions between inequality (C)
and RTTM, PAWS, and Eifel are discussed in sections 5.1.
Demizu Expires April 2005 [Page 11]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
Unfortunately, (2c) would require all peer nodes to be modified.
Hence, (2c) would be deployable only where all peer nodes were under
control or cooperative. This would take many years to deploy.
Pros. The valid range of SEG.TSecr would be the narrowest among all
proposals.
Cons. Every peer node must be modified. There may be unknown side
effects.
4.2.2.4 Proposal (2d)
Proposal (2d) would change the rule generating TSval in the local
node.
The new rule to generate TSval would be the following:
For TSval on data segments, use the current timestamp clock, as
specified in [RFC1323]. For TSval on non-data segments, use the
same value of TSval on the last data segment.
In other words,
Update TS.SndMax before sending a data segment.
Then, use TS.SndMax for TSval on any segment.
With this rule, regardless of the variant type of a peer node,
TS.Recent on the peer node would be updated only by data segments.
Hence, PASA would work well with this rule.
Since (2d) does not require peer nodes to be modified, it would be
readily deployable. Currently, there is no known side effect of (2d)
as discussed in section 5.2.
Pros. Peer nodes need not be modified.
Cons. There may be unknown side effects.
4.3 Unpredictable Timestamps
Note: This section is based on the idea in section 6 of [Poon04].
To make PASA robust, it is important to keep the value of TSval sent
in the TCP Timestamps option unpredictable from a malicious, off-path
third party.
According to [RFC1323], TSval contains the value of the timestamp
clock when the segment was sent. Section 4.2.2.4 proposes a variant.
Demizu Expires April 2005 [Page 12]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
In either cases, if a node uses one global timestamp clock for all
TCP connections, it would be easy for a malicious, off-path third
party to guess a valid value for SEG.TSecr, because the current TSval
could easily be obtained by establishing a new TCP connection with
the target node.
To defend against such attacks, this memo proposes a random offset to
the timestamp clock for each connection or destination. That is, the
TCP per-connection state is augmented by one 32-bit unsigned integer:
TS.SndOff. Each timestamp is calculated as my.TSclock + TS.SndOff,
instead of using my.TSclock directly. Here, my.TSclock represents
the "local source of 32-bit timestamp values" [RFC1323].
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.
Note: This is suggested in section 6 of [Poon04].
If a new TCP connection is opened with an existing tuple of addresses
and ports, then the new TS.SndOff should be carefully chosen so that:
- Duplicate delayed segments are not accepted as valid segments.
- It is hard to infer a new valid range for SEG.TSecr in order to
avoid spoofing attacks by previous address holders in dial-up or
DHCP environments.
To achieve these requirements, this memo suggests adding a random
number to the existing TS.SndOff instead of assigning a newly
generated random number to TS.SndOff.
4.4 Changing the Range Slowly
To keep PASA safe, it is important not to leap TS.SndMax in order to
always keep the difference between TS.SndMax and TS.SndMin small.
Otherwise, spoofed segments could be injected at an unguarded moment.
4.4.1 Incrementing TS.SndMax Gradually
When a data segment is sent after a long period of idle, TS.SndMax
would be set to the value indicating the current timestamp clock, and
the difference between TS.SndMax and TS.SndMin would be very wide
until an ACK segment would be returned. If the data segment or the
ACK segment in reply was lost, TS.SndMin would be unchanged until an
ACK segment would be returned after the next or later retransmission
Demizu Expires April 2005 [Page 13]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
timeouts. During the moment when the difference is large, the
probability of guessing a valid SEG.TSval would also become large.
Therefore, a method of keeping the difference small is required.
The following method would prevent such accidental spoofing attacks.
Introduce an upper limit to the advancement of TS.SndMax. If any
data segment has not been sent on a TCP connection for more than
the upper limit of time, then the next value of TS.SndMax should
be TS.SndMax plus the upper limit instead of the value indicating
the current timestamp clock. Note that TS.SndMax is still
monotonically non-decreasing 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. A possible candidate
for the upper limit would be one hour, ten minutes, etc.
This solution can easily be implemented by tweaking TS.SndOff as
follows:
The TCP per-connection state is augmented by a timestamp:
TS.MaxAdv
Initially:
TS.MaxAdv = the upper limit of the advancement of TS.SndMax
Before sending a segment: (Only when TS.SndMax will be updated)
if (my.TSclock - TS.SndMax > TS.MaxAdv) then
TS.SndOff = TS.MaxAdv - ( my.TSclock - TS.SndMax )
Since each timestamp is calculated as my.TSclock + TS.SndOff (See
section 4.3), when a data segment had not been sent for more than the
time indicated by TS.MaxAdv, the next TSval value would be as
intended as follows.
TSval = TS.SndMax
= my.TSclock + TS.SndOff
= my.TSclock + (TS.MaxAdv - (my.TSclock - old_TS.SndMax))
= old_TS.SndMax + TS.MaxAdv
4.4.2 Keeping the Range Smaller Than 2^31
If the difference between TS.SndMax and TS.SndMin became larger than
or equal to 2^31, the PASA test introduced in section 4.1 would not
Demizu Expires April 2005 [Page 14]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
work at all, because TS.SndMax and TS.SndMin are 32-bit unsigned
integer. Hence, the difference must be kept less than 2^31. It
would be already achieved by the combination of the method proposed
in section 4.4.1 and the TCP timeout mechanisms.
Only in the case where this assumption could be false, the following
method would guarantee that the PASA test would be performed only
when the difference was smaller than 2^31.
Introduce a boolean variable: TS.Valid.
On sending a segment:
if (TS.SndMax < TS.SndMin), then TS.Valid = false.
On receiving a segment:
if (TS.SndMax >= TS.SndMin), then TS.Valid = true.
if (TS.Valid is true), then perform the PASA test.
Otherwise, treat the segment as if it passed the PASA test.
4.5 Timestamps to Send
To make PASA workable under all circumstances, it is important to
appropriately choose the timestamp values of TSval and TSecr in the
TCP Timestamps option on outgoing segments.
4.5.1 In-connection Segments and Out-of-connection Segments
To discuss the timestamp values on segments being sent, this memo
introduces two terms: "in-connection segments" and "out-of-connection
segments." All incoming and outgoing segments are grouped into one
of these categories.
o In-connection segments
In-connection segments are those that could be exchanged in a
normal TCP connection. They would appear in a TCP connection in
synchronizing, synchronized, or desynchronizing states.
Examples: SYN and SYN+ACK segments to establish a TCP connection,
a data segment, an ACK segment, a FIN segment to close a TCP
connection, a RST segment to abort a TCP connection, a keep-alive
segment, a window update segment, a retransmitted segment, a
delayed segment, etc.
Demizu Expires April 2005 [Page 15]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
o Out-of-connection segments
Out-of-connection segments are those incoming segments that are
apparently not intended for a given TCP connection and those
outgoing segments sent in reply to such incoming segments. They
would appear in accidentally desynchronized TCP connections or
half-open TCP connections.
Examples: an incoming segment for which [RFC793] specifies that a
RST segment should be sent in reply, and such a RST segment sent
in reply.
Note: The author thought there would be other examples before.
But now the author believes these two are the only examples
of "out-of-connection segments," and all other segments
should be grouped into "in-connection segments." Thus,
these terms should be renamed to more descriptive ones.
The timestamp values in the TCP Timestamps option on outgoing
segments should be discussed separately for these two groups of
segments, because they have different requirements.
The timestamp values for an outgoing in-connection segment should be
chosen so that the segment will pass both the PASA test and the PAWS
test at the peer node if the TCP connection is alive. The timestamp
values also should be meaningful for other mechanisms, such as RTTM
and Eifel.
The timestamp values for an outgoing out-of-connection segment should
be chosen so that the segment will pass both the PASA test and the
PAWS test at the remote node to indicate that the TCP connection is
desynchronized, if the corresponding incoming segment came from the
remote node. On the other hand, if the corresponding incoming
segment was spoofed, it would be better, but not required, for the
outgoing segment to fail either the PASA test or the PAWS test at the
remote node in order to suppress possible negative effects, such as a
needless Fast Retransmit. In either cases, the timestamp values can
be meaningless for other mechanisms such as RTTM and Eifel, because
the TCP connection would be not synchronized. Since the local node
does not have any state for the unsynchronized TCP connection, the
timestamps values for an outgoing segment should be generated from
the timestamp values on the corresponding incoming segments.
4.5.2 Timestamps on RST Segments
To protect TCP connections against spoofed RST segments by using
PASA, genuine RST segments need to carry the TCP Timestamps option in
Demizu Expires April 2005 [Page 16]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
order to be distinguished from spoofed RST segments.
[RFC1323], however, states, "It is recommended that RST segments NOT
carry timestamps, and that RST segments be acceptable regardless of
their timestamp."
The purpose of this recommendation would be to make out-of-connection
RST segments sent in reply to incoming out-of-connection segments
acceptable to remote nodes. Hence, in-connection RST segments would
be able to carry the TCP Timestamps option with the timestamp values
as specified in [RFC1323], because they would pass both the PASA test
and the PAWS test at the peer nodes if the TCP connection is
synchronized. On the other hand, to make it possible for outgoing
out-of-connection RST segments to carry the TCP Timestamps option, we
would need a special rule for their timestamp values. The rule would
be the same as that for outgoing out-of-connection non-RST segments,
which is discussed below in section 4.5.4.
Thus, to make PASA functional, this memo recommends that RST segments
DO carry timestamps with the special rule described later in this
memo, and that RST segments be tested by both PASA and PAWS.
Note: This is proposed in section 4.2 of [Poon04].
4.5.3 Timestamps on In-connection Segments
The timestamp values in the TCP Timestamps option on an outgoing
in-connection segment should be suitable for any mechanisms such as
RTTM, PAWS, and Eifel, as discussed in section 4.5.1, if the TCP
connection is synchronized. [RFC1323] specifies the values as
<TSval=my.TSclock,TSecr=TS.Recent>, which satisfies the requirement
above.
Regarding PASA, in cases where proposal (2a), (2b), or (2c) is chosen
as described in section 4.2, PASA would work with the timestamp
values specified by [RFC1323]. On the other hand, to make PASA work
in the case of proposal (2d), the TSval value SHOULD be TS.SndMax
instead of my.TSclock. In any case, the same timestamp values would
be applicable to RST segments, as suggested in section 4.5.2.
As a result, the timestamp values in the TCP Timestamps option on
outgoing in-connection segments SHOULD be the following:
<TSval=my.TSclock,TSecr=TS.Recent> for (2a), (2b), or (2c).
<TSval=TS.SndMax,TSecr=TS.Recent> for (2d).
Interactions between the timestamp values for (2d) and mechanisms
Demizu Expires April 2005 [Page 17]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
such as RTTM, PAWS, and Eifel are discussed in sections 5.2.
If an outgoing in-connection segment is a response to an incoming
in-connection segment, TS.SndMax and TS.Recent MUST be updated by the
incoming segment before determining the timestamp values for the
outgoing segment.
If the TCP Timestamps option is not used on a given TCP connection,
every outgoing in-connection segment SHOULD NOT carry the TCP
Timestamps option on that connection.
4.5.4 Timestamps on Out-of-connection Segments
The timestamp values in the TCP Timestamps option on an outgoing
out-of-connection segment should pass both the PASA test and the PAWS
test at the remote node, as discussed in 4.5.1, while the local node
does not have any corresponding state.
The timestamp values that would satisfy this requirement would be
<TSval=SEG.TSecr,TSecr=SEG.TSval>.
Note: This form is proposed in section 4.1 and 4.2 of [Poon04].
If an incoming out-of-connection segment does not carry the TCP
Timestamps option, an outgoing out-of-connection segment sent in
reply SHOULD not carry the TCP Timestamps option.
4.6 Protection Levels
To classify what kinds of spoofed segments can be detected on a given
TCP connection, this section proposes a concept called "protection
level."
The protection level of a TCP connection depends on whether the TCP
Timestamps option is used and whether PASA is supported by both end
nodes of the connection. For example, if the TCP Timestamps option
is not used on a TCP connection, PASA cannot protect the connection
against any spoofed segments. Even when the TCP Timestamps option is
used on a TCP connection, if a segment without the TCP Timestamps
option is received, PASA cannot determine whether that segment is
genuine or spoofed. For instance, [RFC1323] recommends that RST
segments not carry the TCP Timestamps option. For another instance,
there is a discussion to limit segments that carry the TCP Timestamps
option to save TCP options space.
Demizu Expires April 2005 [Page 18]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
4.6.1 Classification
This memo classifies protection levels into three, as follows:
Protection Level 0: No protection.
If the TCP Timestamps option is not used on a TCP connection,
or if the local node does not support PASA, the protection
level of the TCP connection is 0.
At this protection level, no spoofed segment can be detected.
Protection Level 1: Protection against spoofed non-RST segments.
If the TCP Timestamps option is used on a TCP connection, and
if the local node supports PASA but the peer node does not, the
protection level of the TCP connection is 1.
At this protection level, all incoming spoofed non-RST segments
would be detected if they carry the TCP Timestamps option.
The TCP Timestamps option SHOULD be sent on all outgoing
non-RST segments and SHOULD be tested for all incoming non-RST
segments. The TCP Timestamps option MAY be sent on RST
segments and MAY be tested for incoming RST segments.
Protection Level 2: Protection against any spoofed segment.
If the TCP Timestamps option is used on a TCP connection, and
if both the local node and the peer node support PASA, the
protection level of the TCP connection is 2.
At this protection level, all incoming spoofed segments
including RST segments would be detected if they carry the TCP
Timestamps option. The TCP Timestamps option SHOULD be sent on
all outgoing segments including RST segments and SHOULD be
tested for all incoming segments including RST segments.
4.6.2 The TCP PASA-OK option
An application might want to specify a required protection level for
a TCP connection. To make sure that the protection level of a given
TCP connection is 2, it is necessary to recognize whether the peer
node supports PASA. To exchange information about whether a node
supports PASA, this memo proposes a new TCP option called "PASA-OK,"
as described in section 6.1. The TCP PASA-OK option is carried on
SYN and SYN+ACK segments to indicate that the sender node supports
PASA.
Demizu Expires April 2005 [Page 19]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
The necessity of the TCP PASA-OK option depends on whether an
application needs to ensure that the protection level is 2 on a given
TCP connection. If there is no such demand, the TCP PASA-OK option
is unnecessary. Even if the TCP PASA-OK option was removed from the
PASA specification, PASA would still work as discussed in section
4.6.3.
This memo recommends supporting the TCP PASA-OK option.
4.6.3 If the TCP PASA-OK Option Was Removed
Even if the TCP PASA-OK option was removed from the specification,
PASA would still work. Applications, however, cannot ensure that a
given TCP connection is protected against spoofed RST segments.
In this case, the conditions of protection levels 1 and 2 would be
replaced with the following conditions.
Protection Level 1': Protection against spoofed non-RST segments.
If the TCP Timestamps option is used on a TCP connection, and
if the local node supports PASA and the application requires
this level, the protection level of the TCP connection is 1.
Protection Level 2': Protection against any spoofed segment.
If the TCP Timestamps option is used on a TCP connection, and
if the local node supports PASA and the application requires
this level, the protection level of the TCP connection is 2.
4.7 Timestamps to Accept
To detect spoofed segments precisely, it is important to properly
test the timestamp values in the TCP Timestamps option on received
segments.
The processing rules for received segments depend on the TCP state.
For example, in the CLOSED and LISTEN states, the only valid segment
is a SYN segment in the LISTEN state. A RST segment received in
either of these states MUST be silently discarded. If another
segment is received in either of these states, a RST segment SHOULD
be sent in reply. To implement these behaviors, the PASA test SHOULD
NOT be performed.
The SYN-SENT state is also a special state. One of its roles is to
Demizu Expires April 2005 [Page 20]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
detect half-open TCP connections. To test all received segment
according to [RFC793], the PASA test SHOULD NOT be performed.
Note: This is different from section 4.1 of [Poon04].
In other states, i.e., the SYN-RECEIVED state and the states after
the ESTABLISHED state has been reached, the PASA test SHOULD be
performed to protect TCP connections against spoofed segments.
Thus, the TCP states can be grouped into the following two
categories:
- The CLOSED, LISTEN, and SYN-SENT states.
- All other states.
The processing rules for received segments are specified for each
group in section 6.4.
5. Discussion
This section compares inequalities and proposals introduced in
section 4.2.
5.1 Inequalities (A), (B), and (C) vs. RTTM, PAWS, and Eifel
This subsection discusses whether inequalities (A), (B), and (C)
would work well with mechanisms utilizing the TCP Timestamps option:
RTTM, PAWS, and Eifel.
At first, this subsection discusses when TS.Recent is updated. When
one or more data segments have been received but an ACK segment has
not been sent in reply yet, if a new data segment was received,
TS.Recent would not not be updated. TS.Recent also would not be
updated when a new but out-of-order segment was received. In other
cases, TS.Recent would be updated as follows.
If a peer node complied with (A), TS.Recent on the peer node would be
updated only when a new data segment was received. On the other
hand, if a peer node complied with (B) or (C), TS.Recent on the peer
node would be updated when a duplicate data segment was received, as
well as when a new data segment was received. In addition, if a peer
node complied with (B), TS.Recent on the peer node would be updated
even when a non-data segment was received.
The following table summarizes the differences between these
Demizu Expires April 2005 [Page 21]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
inequalities.
+-------------------------------+-----+-----+-----+
| | (A) | (B) | (C) |
+-------------------------------+-----+-----+-----+
| New in-sequence data segment | Yes | Yes | Yes |
| Duplicate data segment | No | Yes | Yes |
| Non-data segment | No | Yes | No |
+-------------------------------+-----+-----+-----+
| New out-of-order data segment | No | No | No |
| New data while ACK is delayed | No | No | No |
+-------------------------------+-----+-----+-----+
Table 1: Which segments update TS.Recent?
Then, this subsection discusses whether the inequalities would work
well with RTTM, PAWS, Eifel, and PASA.
RTTM would work with any inequality, however, (B) and (C) provide
better RTT measurements for retransmitted segments than does (A),
because TS.Recent on peer nodes complying (B) or (C) is updated by
duplicate data segments as well as new data segments.
PAWS assumes that SEG.TSval is monotonically non-decreasing. Any
inequality does not break this assumption. Hence, PAWS would work
with any inequality (A), (B), or (C).
Eifel would work with any inequality. According to section 3.3 of
[RFC3522], however, (A) has a drawback in a corner case.
As described in section 4.2, PASA would work if the peer node
supported (A) or (C), or if the local node supported (2d).
These considerations can be summarized as follows.
+-------+--------------+--------------+--------------+
| | (A) | (B) | (C) |
+-------+--------------+--------------+--------------+
| RTTM | Acceptable | Preferred | Preferred |
+-------+--------------+--------------+--------------+
| PAWS | Workable | Workable | Workable |
+-------+--------------+--------------+--------------+
| Eifel | Workable | Preferred | Preferred |
+-------+--------------+--------------+--------------+
| PASA | Workable | OK iff (2d) | Preferred |
+-------+--------------+--------------+--------------+
Table 2: Inequalities vs. RTTM, PAWS, Eifel, and PASA
Demizu Expires April 2005 [Page 22]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
5.2 Proposal (2d) vs. RTTM, PAWS, and Eifel
This subsection discusses whether (2d) proposed in section 4.2 would
work well with mechanisms utilizing the TCP Timestamps option: RTTM,
PAWS, and Eifel.
5.2.1 Proposal (2d) vs. RTTM and Eifel
If the peer node complied with (A) or (C), TS.Recent on the peer node
would be updated only by data segments. Since (2d) changes only the
rule for the TSval value on non-data segments, the TS.Recent value on
the peer node would not be affected by whether the local node
supported (2d). Hence, (2d) would not have any side effects on RTTM
and Eifel in this case.
If the peer node complied with (B), TS.Recent on the peer node is
updated by non-data segments as well as data segments. Since (2d)
does not change the rule for the TSval value on data segments, and
RTTM and Eifel check the SEG.TSecr value only on segments that
acknowledge data, RTTM and Eifel would work well with (2d) in this
case.
Consequently, RTTM and Eifel would work well with (2d) regardless of
whether the peer node supported (A), (B), or (C).
5.2.2 Proposal (2d) vs. PAWS
PAWS assumes that SEG.TSval is monotonically non-decreasing. Since
(2d) does not break this assumption, PAWS would work with (2d)
regardless of whether the peer node supported (A), (B), or (C).
It would be worth to mention, however, that (2d) has a side effect on
PAWS if the method proposed in section 4.4 was not implemented, as
described below.
Suppose the method proposed in section 4.4 is not implemented. If
the local node supported (2d), the TSval value on a non-data segment
being sent might not be equal to the current timestamp clock. This
would cause the following side effect on PAWS.
If the local node did not send any data segment for more than 2^31
units of time (i.e., if the local current timestamp clock had
wrapped away), and if the local node had sent one or more non-data
segments within 24 days, then the next data segments sent by the
local node would be discarded by PAWS at the peer node.
Demizu Expires April 2005 [Page 23]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
In such cases, the value of TS.Recent on the peer node would be
judged valid, while it actually had been wrapped away. Hence, a
TCP connection under such a situation would be blocked for a long
period of time until TS.Recent on the peer node was invalidated or
TS.SndMax was wrapped again.
This phenomenon would happen if the age of TS.Recent was rewound
whenever a valid segment was received at the peer node even if its
TSval was equal to TS.Recent.
According to [RFC1323], TS.Recent is invalid if "a connection is idle
for more than 24 days." To cope with (2d), this condition should be
interpreted as "a connection whose TS.Recent has not changed for more
than 24 days." It would be impractical, however, to modify all peer
nodes to follow this interpretation.
Therefore, some solution to this side effect is required at the local
node. The method proposed in section 4.4 would effectively eliminate
this phenomenon.
5.3 Comparison of Proposed Solutions of Section 4.2
Section 4.2 describes the following proposals for the problem
introduced by nodes complying with (B).
(2a) Modify all peer nodes to comply with (A).
(2b) Inspect the variant types of peer nodes.
(2c) Introduce a new inequality (C).
(2d) Change the rule generating TSval.
This subsection compares these proposals.
The simplest proposal is (2a), because no new mechanism needs to be
invented. It would be difficult, however, to deploy (2a) in real
networks, because (B) would supposedly be deployed widely, and (B)
provides better RTT measurements for retransmitted segments than does
(A), as discussed in section 5.1.
Since it would be very complex to implement (2b), this memo does not
recommend it.
Although (2c) is similar to (2a), it would be deployable because (C)
would provide RTT measurement accuracy similar to that of (B). In
addition, the valid range of SEG.TSecr with (C) would be narrower
than that for both (A) and (B), as described in section 4.2.
Therefore, (2c) would be better than (2a) from the point of view of
both RTTM and PASA.
Demizu Expires April 2005 [Page 24]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
It would be practical to follow (2d), because it does not require
modifying peer nodes, and it would not be complex to implement (2d).
Note that protection level 1 does not require peer nodes to support
PASA. Therefore, with (2d), incoming spoofed segments except for RST
segments can be detected without modifying any peer nodes, as long as
they support the TCP Timestamps option.
Protection level 2, however, which would be the most useful,
desirable protection level, requires peer nodes to support PASA. In
other words, to detect spoofed RST segments at the local node, or
spoofed segments at the peer nodes, all peer nodes need to be
modified to support PASA. From this point of view, the advantage of
(2d) might be minor, and (2c) would also be deployable.
To support protection level 1 in communication with any nodes
supporting the TCP Timestamps option, this memo currently recommends
(2d). Nevertheless, (2c) is still a good candidate as a long-term
solution. Fortunately, (2c) and (2d) could coexist. Further
discussion of this issue is required.
6. Specification
A TCP implementation MAY support PASA. If PASA is implemented, its
implementation MUST obey the specification described in this section.
The technical reasoning behind this specification is discussed in
sections 3 through 5.
6.1 TCP PASA-OK option
The TCP PASA-OK option indicates that the sender node supports PASA.
The purpose of the TCP PASA-OK option is to exchange information
about whether a node supports PASA.
The TCP PASA-OK option MAY be sent on a SYN segment. It also MAY be
sent on a SYN+ACK segment, but only if the TCP PASA-OK option is
received in the corresponding SYN segment. The TCP PASA-OK option
SHOULD not be sent on other segments.
The format of the TCP PASA-OK option is as follows:
+--------+--------+
|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.
Demizu Expires April 2005 [Page 25]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
Implementation note: These two TCP options can be sent in the
following format:
+--------+--------+--------+--------+
|PASA-OK | Len=2 | TSopt | Len=10 |
+--------+--------+--------+--------+
| TSval |
+--------+--------+--------+--------+
| TSecr |
+--------+--------+--------+--------+
6.2 Timestamps to Send
To discuss the timestamp values on segments being sent, this memo
introduces two terms: "in-connection segments" and "out-of-connection
segments." All incoming and outgoing segments are grouped into one
of these categories.
o In-connection segments
In-connection segments are those that could be exchanged on a
normal TCP connection.
If the TCP Timestamps option is used on a TCP connection, the
timestamp values in the TCP Timestamps option on the outgoing
segment SHOULD be <TSval=TS.SndMax,TSecr=TS.Recent>. Otherwise,
the segment SHOULD NOT carry the TCP Timestamps option.
o Out-of-connection segments
Out-of-connection segments are those incoming segments that are
apparently not intended for a given TCP connection, and those
outgoing segments sent in reply to such incoming segments.
If a corresponding incoming segment carries the TCP Timestamps
option, the timestamp values in the TCP Timestamps option on the
outgoing segment SHOULD be <TSval=SEG.TSecr,TSecr=SEG.TSval>.
Otherwise, the segment sent in reply SHOULD not carry the TCP
Timestamps option.
6.3 Protection Levels
The protection level of a TCP connection is defined as follows:
Demizu Expires April 2005 [Page 26]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
Protection Level 0: No protection.
If the TCP Timestamps option is not exchanged on SYN and
SYN+ACK segments, or if the local node does not support PASA,
the protection level of the TCP connection is 0.
Protection Level 1: Protection against spoofed non-RST segments.
If the TCP Timestamps option is exchanged on SYN and SYN+ACK
segments, but the TCP PASA-OK option is not exchanged on SYN
and SYN+ACK segments and the local node supports PASA, the
protection level of the TCP connection is 1.
Protection Level 2: Protection against any spoofed segment.
If both the TCP Timestamps option and the TCP PASA-OK option
are exchanged on SYN and SYN+ACK segments, the protection level
of the TCP connection is 2.
Implementations SHOULD allow applications to specify the required
protection level for each TCP connection in the CLOSED or LISTEN
states. If the negotiated protection level does not satisfy the
required protection level, the TCP connection SHOULD be aborted and a
RST segment with the timestamp values for in-connection segments
SHOULD be sent in reply.
Note: This is suggested in section 4 of [Poon04].
6.4 Timestamps to Accept
The processing rule for received segments depends on the TCP states.
6.4.1 In the CLOSED, LISTEN, and SYN-SENT States
In these states, the PASA test SHOULD NOT be performed for received
segments, regardless of whether a received segment carries the TCP
Timestamps option.
When a SYN segment is received in the LISTEN state, or when a SYN or
SYN+ACK segment is received in the SYN-SENT state, after the segment
is accepted by rules other than PASA, it SHOULD be tested for whether
it satisfies the protection level required by an application, as
follows:
If the required protection level is 1, the received segment MUST
carry the TCP Timestamps option. If the required protection level
Demizu Expires April 2005 [Page 27]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
is 2, the received segment MUST carry both the TCP Timestamps
option and the TCP PASA-OK option. If the received segment does
not satisfy these requirements, the unestablished TCP connection
SHOULD be aborted, and a RST segment with the timestamp values for
in-connection segments SHOULD be sent in reply.
When a segment other than the above is received, and a RST segment
SHOULD be sent in reply, the received segment and the RST segment are
out-of-connection segments. If the received segment carries the TCP
Timestamps option, the RST segment sent in reply SHOULD carry the TCP
Timestamps option with the timestamp values for out-of-connection
segments.
6.4.2 In the Other States
In the other states (i.e., the SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1,
FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, and TIME-WAIT states), if
a segment with the TCP Timestamps option is received, the PASA test
SHOULD be performed.
Or, if a segment without the TCP Timestamps option is received, it
SHOULD be tested for whether it satisfies the required protection
level, as follows:
- If the required protection level is 2, the segment SHOULD be
treated as if it failed the PASA test.
- If the required protection level is 1, and
- if the segment is not a RST segment, it SHOULD be treated as
if it failed the PASA test; or
- if the segment is a RST segment, it SHOULD be treated as if
it passed the PASA test.
- If the required protection level is 0, the segment SHOULD be
treated as if it passed the PASA test.
If a received segment fails the PASA test, and if the segment is not
a RST segment, an ACK segment SHOULD be sent in reply as specified on
page 69 of [RFC793], and the received segment MUST be dropped. Note
that this rule is the same as that of PAWS [RFC1323].
An ACK throttling mechanism SHOULD be implemented.
Demizu Expires April 2005 [Page 28]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
6.5 The Processing Rule of PASA
The TCP per-connection state SHOULD be augmented by four timestamps:
TS.SndMax, TS.SndMin, TS.SndOff, and TS.MaxAdv.
Initially:
/* See section 4.3 */
TS.SndOff = random number
TS.SndMin = my.TSclock + TS.SndOff
TS.SndMax = my.TSclock + TS.SndOff
/* See section 4.4 */
TS.MaxAdv = the upper limit to the advancement of TS.SndMax
On sending a segment:
/* Only when TS.SndMax will be updated */
if (SEG.LEN > 0 || SYN || FIN) then
/* See section 4.4 */
if (my.TSclock - TS.SndMax > TS.MaxAdv) then
TS.SndOff = TS.MaxAdv - ( my.TSclock - TS.SndMax )
/* See section 4.2.2.4 (See also section 4.1) */
if (SEG.LEN > 0 || SYN || FIN) then
TS.SndMax = my.TSclock + TS.SndOff
/* See section 6.2 */
Send the segment according to section 6.2.
On receiving a segment:
/* See section 6.4 */
Perform the PASA test for the segment according to section 6.4
/* After this segment passes all TCP tests */
/* See section 4.1 */
if (TS.SndMin < SEG.TSecr) then
TS.SndMin = SEG.TSecr
Demizu Expires April 2005 [Page 29]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
7. Examples
The following are examples of how PASA would work.
7.1 Half-open Connections
A TCP connection is said to be "half-open" if one of the two nodes
has aborted the TCP connection or has rebooted itself while the other
does not know of this.
7.1.1 Half-open Connection: CLOSED vs. ESTABLISHED
In this example, suppose a TCP connection has been established
between TCP A and TCP B.
Suppose SND.NXT = 100 and RCV.NXT = 200 at TCP B.
Step 1: TCP A aborts the TCP connection and sends a RST segment as
an in-connection segment. But it is lost.
Step 2: TCP A moves to the CLOSED state.
Step 3: TCP B sends a data segment as an in-connection segment.
TCP A does not execute the PASA test, because TCP A is in
the CLOSED state. TCP A considers the data segment as an
out-of-connection segment.
Step 4: A RST segment is sent in reply as an out-of-connection
segment. It passes the PASA test at TCP B. It makes TCP
B discard the TCP connection.
Step 5: TCP B moves to the CLOSED state.
As seen above, TCP B succeeds to detect that TCP A has closed the TCP
connection. The following diagram illustrates this scenario.
TCP A TCP B
(SND.NXT=100,
RCV.NXT=200)
1. (Abort) ---> <CTL=RST> .... (lost) ESTABLISHED
<TSval=25,TSecr=5>
2. CLOSED ESTABLISHED
Demizu Expires April 2005 [Page 30]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
3. CLOSED <--- <SEQ=100><ACK=200> <--- ESTABLISHED
<TSval=10,TSecr=20> (with data)
4. CLOSED ---> <SEQ=200><CTL=RST> ---> (Abort)
<TSval=20,TSecr=10>
5. CLOSED CLOSED
7.1.2 Half-open Connection: SYN-SENT vs. ESTABLISHED
In this example, suppose a TCP connection has been established
between TCP A and TCP B.
Suppose SND.NXT = 100 and RCV.NXT = 200 at TCP B.
Step 1: TCP A crashes, but TCP B does not detect it.
Step 2: TCP A moves to the CLOSED state after a reboot.
Step 3: TCP A sends a SYN segment as an in-connection segment to
establish a new TCP connection. Suppose the SYN segment
fails the PASA test at TCP B. TCP B considers it as an
in-connection segment.
Step 4: TCP B sends an ACK segment in reply as an in-connection
segment. TCP A does not execute the PASA test, because
TCP A is in the SYN-SENT state. TCP A considers the ACK
segment as an out-of-connection segment.
Step 5: A RST segment is sent in reply as an out-of-connection
segment. It passes the PASA test at TCP B. It makes TCP
B discard the TCP connection.
Step 6: TCP B moves to the CLOSED state.
Step 7-9: A new TCP connection is established between TCP A and
TCP B.
This scenario is similar to Figure 10 of RFC793 (page 34). But
the SYN segment sent at step 3 above is supposed to be rejected by
PASA instead of a rule in [RFC793].
If the SYN segment accidentally passed the PASA test at step 3
above, the SYN segment would be processed according to [RFC793].
In such cases, if the sequence number of the SYN segment was
out-of-window, the scenario would be the same as above. If it was
in-window, a RST segment would be sent by TCP B to TCP A, and TCP
Demizu Expires April 2005 [Page 31]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
B would discard the TCP connection.
As seen above, TCP B succeeds to detect that TCP A has closed the TCP
connection. The following diagram illustrates this scenario.
TCP A TCP B
(SND.NXT=100,
RCV.NXT=200)
1. (crashed) ESTABLISHED
2. CLOSED ESTABLISHED
3. SYN-SENT ---> <SEQ=500><CTL=SYN> ---> ESTABLISHED
<TSval=50,TSecr=0>
4. SYN-SENT <--- <SEQ=100><ACK=200> <--- ESTABLISHED
<TSval=10,TSecr=20>
5. SYN-SENT ---> <SEQ=200><CTL=RST> ---> (Abort)
<TSval=20,TSecr=10>
6. SYN-SENT CLOSED
7. SYN-SENT ---> <SEQ=500><CTL=SYN> ---> CLOSED
<TSval=55,TSecr=0>
8. SYN-SENT <--- <SEQ=600><ACK=501><CTL=SYN,ACK>
<TSval=30,TSecr=55> SYN-RECEIVED
9. ESTABLISHED ---> <SEQ=501><ACK=601><CTL=ACK>
<TSval=60,TSecr=30> ESTABLISHED
7.1.3 Half-open Connection: SYN-SENT vs. ESTABLISHED
In this example, suppose a TCP connection has been established
between TCP A and TCP B.
Suppose SND.NXT = 100 and RCV.NXT = 200 at TCP B.
Step 1: TCP A crashes, but TCP B does not detect it.
Step 2: TCP A moves to the CLOSED state after a reboot.
Step 3: TCP A sends a SYN segment as an in-connection segment to
establish a new TCP connection. But it is lost.
Demizu Expires April 2005 [Page 32]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
Step 4: TCP B sends a data segment as an in-connection segment.
TCP A does not execute the PASA test, because TCP A is in
the SYN-SENT state. TCP A considers the data segment as
an out-of-connection segment.
Step 5: A RST segment is sent in reply as an out-of-connection
segment. It passes the PASA test at TCP B. It makes TCP
B discard the TCP connection.
Step 6: TCP B moves to the CLOSED state.
Step 7-9: A new TCP connection is established between TCP A and
TCP B.
As seen above, TCP B succeeds to detect that TCP A has closed the TCP
connection. The following diagram illustrates this scenario.
TCP A TCP B
(SND.NXT=100,
RCV.NXT=200)
1. (crashed) ESTABLISHED
2. CLOSED ESTABLISHED
3. SYN-SENT ---> <SEQ=500><CTL=SYN> ---> (lost)
<TSval=50,TSecr=0>
4. SYN-SENT <--- <SEQ=100><ACK=200> <--- ESTABLISHED
<TSval=10,TSecr=20> (with data)
5. SYN-SENT ---> <SEQ=200><CTL=RST> ---> (Abort)
<TSval=20,TSecr=10>
6. SYN-SENT CLOSED
7. SYN-SENT ---> <SEQ=500><CTL=SYN> ---> CLOSED
<TSval=55,TSecr=0>
8. SYN-SENT <--- <SEQ=600><ACK=501><CTL=SYN,ACK>
<TSval=30,TSecr=55> SYN-RECEIVED
9. ESTABLISHED ---> <SEQ=501><ACK=601><CTL=ACK>
<TSval=60,TSecr=30> ESTABLISHED
Demizu Expires April 2005 [Page 33]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
8. Security Considerations
This memo proposes a method of protecting TCP connections against
off-path, third party spoofing attacks, by making use of the TCP
Timestamps option. The proposal provides an obfuscation mechanism,
but it is not strong as cryptographic approaches.
9. IANA Considerations
One new TCP option value will need to be assigned for the TCP PASA-OK
option described in section 6.1
Acknowledgments
The original idea for the method described in this memo was proposed
by Kacheong Poon [Poon04]. He also provided many valuable comments
including a hint for the idea proposed as (2d) in section 4.2.2.4.
Normative References
[RFC793] J. Postel, "Transmission Control Protocol", RFC793,
September 1981
[RFC1323] V. Jacobson, R. Braden, D. Borman, "TCP Extensions for
High Performance", RFC1323, May 1992
[RFC2119] S. Bradner, "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC2119, BCP14, March 1997
[RFC3668] S. Bradner, "Intellectual Property Rights in IETF
Technology", RFC3668, BCP79, February 2004
[Poon04] K. Poon, "Use of TCP timestamp option to defend against
blind spoofing attack", (work in progress),
Internet-Draft <draft-poon-tcp-tstamp-mod-00.txt>,
June 2004
Informative References
[RFC2988] V. Paxson, M. Allman, "Computing TCP's Retransmission
Timer", RFC2988, November 2000
[RFC3522] R. Ludwig, M. Meyer, "The Eifel Detection Algorithm for
TCP", RFC3522, April 2003
Demizu Expires April 2005 [Page 34]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
[JBB97] V. Jacobson, R. Braden, D. Borman, "TCP Extensions for
High Performance", (work in progress), Internet-Draft
<draft-ietf-tcplw-high-performance-00.txt>, February 1997
[JBB03] V. Jacobson, R. Braden, D. Borman, "TCP Extensions for
High Performance", (work in progress), Internet-Draft
<draft-jacobson-tsvwg-1323bis-00.txt>, August 2003
Author's Address
Noritoshi Demizu
National Institute of Information and Communications Technology(NICT)
4-2-1 Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan
Phone: +81-42-327-7432 (Ex. 5813)
E-mail: demizu@nict.go.jp
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.
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.
Intellectual Property
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
Demizu Expires April 2005 [Page 35]
Internet-Draft <draft-demizu-tcpm-pasa-issues-00.txt> October 2004
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Demizu Expires April 2005 [Page 36] | PAFTECH AB 2003-2026 | 2026-04-20 15:02:24 |