draft-moncaster-tcpm-rcv-cheat-01.txt   draft-moncaster-tcpm-rcv-cheat-02.txt 
TCP Maintenance and Minor T. Moncaster TCP Maintenance and Minor T. Moncaster
Extensions BT Extensions BT
Internet-Draft B. Briscoe Internet-Draft B. Briscoe
Intended status: Standards Track BT & UCL Intended status: Informational BT & UCL
Expires: December 7, 2007 A. Jacquet Expires: May 11, 2008 A. Jacquet
BT BT
June 5, 2007 November 8, 2007
A TCP Test to Allow Senders to Identify Receiver Non-Compliance A TCP Test to Allow Senders to Identify Receiver Non-Compliance
draft-moncaster-tcpm-rcv-cheat-01 draft-moncaster-tcpm-rcv-cheat-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 7, 2007. This Internet-Draft will expire on May 11, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The TCP protocol relies on receivers sending accurate and timely The TCP protocol relies on receivers sending accurate and timely
feedback to the sender. Currently the sender has no means to verify feedback to the sender. Currently the sender has no means to verify
that a receiver is correctly sending this feedback according to the that a receiver is correctly sending this feedback according to the
skipping to change at page 2, line 36 skipping to change at page 2, line 36
six months and may be updated, replaced, or obsoleted by other six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
Draft Shadow Directories can be accessed at Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Changes from previous drafts (to be removed by the RFC Editor) Changes from previous drafts (to be removed by the RFC Editor)
From -01 to -02:
A number of changes made following an extensive review from Alfred
Hoenes. These were largely to better comply with the stated aims
of the previous version but also included some tidying up of the
protocol details and a new section on a possible unwanted
interaction.
From -00 to -01: From -00 to -01:
Draft rewritten to emphasise testing for non-compliance. Some Draft rewritten to emphasise testing for non-compliance. Some
changes to protocol to remove possible unwanted interactions with changes to protocol to remove possible unwanted interactions with
other TCP variants. Sections added on comparison of solutions and other TCP variants. Sections added on comparison of solutions and
alternative uses of test. alternative uses of test.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 3, line 22 skipping to change at page 3, line 22
3.1. Concealing Lost Segments . . . . . . . . . . . . . . . . . 7 3.1. Concealing Lost Segments . . . . . . . . . . . . . . . . . 7
3.2. Optimistic Acknowledgements . . . . . . . . . . . . . . . 9 3.2. Optimistic Acknowledgements . . . . . . . . . . . . . . . 9
4. Requirements for a robust solution . . . . . . . . . . . . . . 11 4. Requirements for a robust solution . . . . . . . . . . . . . . 11
5. Existing Proposals . . . . . . . . . . . . . . . . . . . . . . 12 5. Existing Proposals . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Randomly Skipped Segments . . . . . . . . . . . . . . . . 12 5.1. Randomly Skipped Segments . . . . . . . . . . . . . . . . 12
5.2. The ECN nonce . . . . . . . . . . . . . . . . . . . . . . 12 5.2. The ECN nonce . . . . . . . . . . . . . . . . . . . . . . 12
5.3. A transport layer nonce . . . . . . . . . . . . . . . . . 13 5.3. A transport layer nonce . . . . . . . . . . . . . . . . . 13
6. The Test for Receiver Cheating . . . . . . . . . . . . . . . . 14 6. The Test for Receiver Non-compliance . . . . . . . . . . . . . 14
6.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 14 6.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 14
6.2. Probabilistic Testing . . . . . . . . . . . . . . . . . . 14 6.2. Probabilistic Testing . . . . . . . . . . . . . . . . . . 14
6.2.1. Performing the Probabilistic Test . . . . . . . . . . 15 6.2.1. Performing the Probabilistic Test . . . . . . . . . . 15
6.2.2. Assessing the Probabilistic Test . . . . . . . . . . . 17 6.2.2. Assessing the Probabilistic Test . . . . . . . . . . . 17
6.2.3. RTT Measurement Considerations . . . . . . . . . . . . 17 6.2.3. RTT Measurement Considerations . . . . . . . . . . . . 17
6.2.4. Negative Impacts of the Test . . . . . . . . . . . . . 19 6.2.4. Negative Impacts of the Test . . . . . . . . . . . . . 19
6.2.5. Protocol Details for the Probabilistic Test . . . . . 19 6.2.5. Protocol Details for the Probabilistic Test . . . . . 20
6.3. Deterministic Testing . . . . . . . . . . . . . . . . . . 21 6.3. Deterministic Testing . . . . . . . . . . . . . . . . . . 21
6.3.1. Performing the Deterministic Test . . . . . . . . . . 21 6.3.1. Performing the Deterministic Test . . . . . . . . . . 22
6.3.2. Assessing the Deterministic Test . . . . . . . . . . . 21 6.3.2. Assessing the Deterministic Test . . . . . . . . . . . 22
6.3.3. Protocol Details for the Deterministic Test . . . . . 22 6.3.3. Protocol Details for the Deterministic Test . . . . . 22
6.4. Responding to Non-Compliance . . . . . . . . . . . . . . . 22 6.4. Responding to Non-Compliance . . . . . . . . . . . . . . . 23
6.5. Possible Interactions With Other TCP Features . . . . . . 23 6.5. Possible Interactions With Other TCP Features . . . . . . 23
6.5.1. TCP Secure . . . . . . . . . . . . . . . . . . . . . . 23 6.5.1. TCP Secure . . . . . . . . . . . . . . . . . . . . . . 23
6.5.2. Nagle Algorithm . . . . . . . . . . . . . . . . . . . 23 6.5.2. Nagle Algorithm . . . . . . . . . . . . . . . . . . . 24
6.5.3. Delayed Acknowledgements . . . . . . . . . . . . . . . 23 6.5.3. Delayed Acknowledgements . . . . . . . . . . . . . . . 24
6.6. Possible Consequences of the Tests . . . . . . . . . . . . 23 6.5.4. Best Effort Transport Service . . . . . . . . . . . . 24
6.6. Possible Consequences of the Tests . . . . . . . . . . . . 24
7. Comparison of the Different Solutions . . . . . . . . . . . . 24 7. Comparison of the Different Solutions . . . . . . . . . . . . 25
8. Alternative Uses of the Test . . . . . . . . . . . . . . . . . 25 8. Alternative Uses of the Test . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27 11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
13. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 28 13. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
14.1. Normative References . . . . . . . . . . . . . . . . . . . 28 14.1. Normative References . . . . . . . . . . . . . . . . . . . 28
14.2. Informative References . . . . . . . . . . . . . . . . . . 28 14.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 31
1. Introduction 1. Introduction
This document specifies how a TCP sender implementation can be This document specifies how a TCP sender implementation can be
modified to detect a non-compliant receiver. It uses the standard modified to detect a non-compliant receiver. It uses the standard
wire protocol and protocol semantics of basic TCP [RFC0793] without wire protocol and protocol semantics of basic TCP [RFC0793] without
modification. modification.
When any network resource (e.g. a link) becomes congested, the When any network resource (e.g. a link) becomes congested, the
skipping to change at page 5, line 37 skipping to change at page 5, line 37
Simple attacks have been published showing that TCP receivers can Simple attacks have been published showing that TCP receivers can
manipulate feedback to fool TCP senders into massively exceeding the manipulate feedback to fool TCP senders into massively exceeding the
compliant rate [Savage]. Such receivers might want to make senders compliant rate [Savage]. Such receivers might want to make senders
unwittingly launch a denial of service attack on other flows sharing unwittingly launch a denial of service attack on other flows sharing
part of the path between them [Sherwood]. But a more likely part of the path between them [Sherwood]. But a more likely
motivation is simple self-interest---a receiver can improve its own motivation is simple self-interest---a receiver can improve its own
download speed, without any need for the sender to be a willing download speed, without any need for the sender to be a willing
accomplice. [Savage] quotes results that show this attack can reduce accomplice. [Savage] quotes results that show this attack can reduce
the time taken to download an HTTP file over a real network by half, the time taken to download an HTTP file over a real network by half,
even with a relatively cautious optimisitic acknowledgemnt strategy. even with a relatively cautious optimistic acknowledgemnt strategy.
There is currently no evidence that any TCP implementations are There is currently no evidence that any TCP implementations are
exploiting any of the attacks mentioned above. However this may be exploiting any of the attacks mentioned above. However this may be
simply a result of the fact that there is no widely available test to simply a result of the fact that there is no widely available test to
identify such attacks. This document describes a test process that identify such attacks. This document describes a test process that
can identify such non-compliance by receivers should it start to can identify such non-compliance by receivers should it start to
become an issue. The test can be deployed as a separate test suite, become an issue. The test can be deployed as a separate test suite,
or in existing senders, but this document does not mandate that it or in existing senders, but this document does not mandate that it
should be implemented by senders. The aim of the authors is to should be implemented by senders. The aim of the authors is to
provide a test that is safe to implement and that can be recommended provide a test that is safe to implement and that can be recommended
skipping to change at page 6, line 11 skipping to change at page 6, line 11
The measures in this specification are intended for senders that can The measures in this specification are intended for senders that can
be trusted to behave. As all senders can not be trusted, this scheme be trusted to behave. As all senders can not be trusted, this scheme
can not prevent misbehaving senders from causing congestion collapse can not prevent misbehaving senders from causing congestion collapse
of the Internet. However the very existence of a test scheme such as of the Internet. However the very existence of a test scheme such as
this should act as a disincentive against non-compliant receivers. this should act as a disincentive against non-compliant receivers.
Senders do not have to be motivated solely by "the common good" to Senders do not have to be motivated solely by "the common good" to
deploy these changes. It is directly in their own interest for deploy these changes. It is directly in their own interest for
senders serving multiple receivers (e.g. large file servers and senders serving multiple receivers (e.g. large file servers and
certain file-sharing peers) to detect non-compliant receivers. A certain file-sharing peers) to detect non-compliant receivers. A
large server relies in part on honest network congestion feedback to large server relies in part on network congestion feedback to
efficiently apportion its own resources between receivers. If such a efficiently apportion its own resources between receivers. If such a
large server devotes an excessive fraction of its own resources to large server devotes an excessive fraction of its own resources to
non-compliant receivers, it may well hit its own resource limits and non-compliant receivers, it may well hit its own resource limits and
have to starve other half-connections even if their network path has have to starve other half-connections even if their network path has
spare capacity. spare capacity.
In order for a sender to test a receiver, we avoid requiring the In order for a sender to test a receiver, we avoid requiring the
receiver to have deployed any new or optional protocol features, as receiver to have deployed any new or optional protocol features, as
any misbehaving receiver could simply circumvent the test by claiming any misbehaving receiver could simply circumvent the test by claiming
it did not support the optional feature. Instead, the sender it did not support the optional feature. Instead, the sender
emulates network re-ordering then network loss to test that the emulates network re-ordering and then network loss to test that the
receiver reacts as it should as defined within the basic TCP receiver reacts as it should according to the basic TCP protocol. It
protocol. It is important that the level of emulated re-ordering is important that the level of emulated re-ordering that such a test
that such a test introduces should not adversely impact compliant introduces should not adversely impact compliant receivers.
receivers.
This document specifies a two-stage test in which the sender This document specifies a two-stage test in which the sender
deliberately re-orders some data segments so as to check if the deliberately re-orders some data segments so as to check if the
destination correctly acknowledges out-of-order segments. The first destination correctly acknowledges out-of-order segments. The first
stage test introduces a small reordering which will have a related stage test introduces a small reordering which will have a related
very minor performance hit. It is not a conclusive test of very minor performance hit. It is not a conclusive test of
compliance. However, failing it strongly suggests the receiver is compliance. However, failing it strongly suggests the receiver is
non-compliant. This raises sufficient suspicion to warrant the more non-compliant. This raises sufficient suspicion to warrant the more
intrusive but conclusive second stage if this non-compliance is going intrusive but conclusive second stage if this non-compliance is going
to be sanctioned. The second stage proves beyond doubt whether the to be sanctioned. The second stage proves beyond doubt whether the
skipping to change at page 8, line 23 skipping to change at page 8, line 23
interest of a receiver to maximise the data rate it gets from the interest of a receiver to maximise the data rate it gets from the
sender. If it conceals lost segments by falsely generating sender. If it conceals lost segments by falsely generating
acknowledgements for them it will not suffer a reduction in data acknowledgements for them it will not suffer a reduction in data
rate. There are a number of ways to make an application loss- rate. There are a number of ways to make an application loss-
insensitive. Some applications such as streaming media are insensitive. Some applications such as streaming media are
inherently insensitive anyway, as a loss will just be seen as a inherently insensitive anyway, as a loss will just be seen as a
transient error. TCP is widely used to transmit media files, either transient error. TCP is widely used to transmit media files, either
audio or video, which are relatively insensitive to data loss audio or video, which are relatively insensitive to data loss
(depending on the encoding used). Also senders may be serving data (depending on the encoding used). Also senders may be serving data
containing redundant parity to allow the application to recreate lost containing redundant parity to allow the application to recreate lost
data. A cheating receiver can also exploit application layer data. A misbehaving receiver can also exploit application layer
protocols such as the partial GET in HTTP 1.1 [RFC2616] to recover protocols such as the partial GET in HTTP 1.1 [RFC2616] to recover
missing data over a secondary connection. missing data over a secondary connection.
|---.__ Drop | |---.__ Drop | |---.__ Drop | |---.__ Drop |
|---.__`---#200 | |---.__`---#200 | |---.__`---#200 | |---.__`---#200 |
| `---.__ | | `---.__ | | `---.__ | | `---.__ |
| `---.__ | | `---.__ | | `---.__ | | `---.__ |
| _,`300->| | _,`300->| | _,`300->| | _,`300->|
| __,---' | | __,---' | | __,---' | | __,---' |
| _,---' | | _,---' | | _,---' | | _,---' |
skipping to change at page 11, line 15 skipping to change at page 11, line 15
current parallel connection approach most use. Users of such current parallel connection approach most use. Users of such
software would be effectively innocent parties to the potential harm software would be effectively innocent parties to the potential harm
that such a non-compliant TCP could cause. that such a non-compliant TCP could cause.
4. Requirements for a robust solution 4. Requirements for a robust solution
Since the above problems come about through the inherent behaviour of Since the above problems come about through the inherent behaviour of
the TCP protocol, there is no gain in introducing a new protocol as the TCP protocol, there is no gain in introducing a new protocol as
misbehaving receivers can claim to only support the old protocol. misbehaving receivers can claim to only support the old protocol.
The best approach is to provide a mechanism within the existing The best approach is to provide a mechanism within the existing
protocol to test whether a receiver is cheating. The following protocol to test whether a receiver is compliant. The following
requirements should be met by any such test in TCP and are likely to requirements should be met by any such test in TCP and are likely to
be applicable for similar tests in other transport protocols: be applicable for similar tests in other transport protocols:
1. The compliance test must not adversely affect the existing 1. The compliance test must not adversely affect the existing
congestion control and avoidance algorithms since one of the congestion control and avoidance algorithms since one of the
primary aims of any compliance test is to reinforce the integrity primary aims of any compliance test is to reinforce the integrity
of congestion control. of congestion control.
2. Any test should utilise existing features of the TCP protocol. 2. Any test should utilise existing features of the TCP protocol.
If it can be implemented without altering the existing protocol If it can be implemented without altering the existing protocol
skipping to change at page 11, line 38 skipping to change at page 11, line 38
3. The receiver should not play an active role in the process. It 3. The receiver should not play an active role in the process. It
is much more secure to have a check for compliance that only is much more secure to have a check for compliance that only
requires the receiver to behave as it should anyway. requires the receiver to behave as it should anyway.
4. It should not require the use of any negotiable TCP options. 4. It should not require the use of any negotiable TCP options.
Since the use of such options is by definition optional, any Since the use of such options is by definition optional, any
misbehaving receiver could just choose not to use the appropriate misbehaving receiver could just choose not to use the appropriate
option. option.
5. If this is a periodic test, the receiver must not be aware that 5. If this is a periodic test, the receiver must not be aware that
it is being tested for compliance. If the receiver can tell that it is being tested for compliance. If a misbehaving receiver can
it is being tested (by identifying the pattern of testing) it can tell that it is being tested (by identifying the pattern of
choose to respond honestly only whilst it is being tested. If testing) it can choose to respond compliantly only whilst it is
the test is always performed this clearly doesn't apply. being tested. If the test is always performed this clearly
doesn't apply.
6. If the sender actively sanctions any non-compliance it 6. If the sender actively sanctions any non-compliance it
identifies, it should be certain of the receiver's non-compliance identifies, it should be certain of the receiver's non-compliance
before taking action against it. Any false positives might lead before taking action against it. Any false positives might lead
to inefficient use of network resources and could damage end-user to inefficient use of network resources and could damage end-user
confidence in the network. confidence in the network.
7. The testing should not significantly reduce the performance of an 7. The testing should not significantly reduce the performance of an
innocent receiver. innocent receiver.
skipping to change at page 12, line 18 skipping to change at page 12, line 21
[Sherwood] suggests a simple approach to test a receiver's [Sherwood] suggests a simple approach to test a receiver's
compliance. The test involves randomly dropping segments at the compliance. The test involves randomly dropping segments at the
sender before they are transmitted. All TCP "flavours" require that sender before they are transmitted. All TCP "flavours" require that
a receiver should generate duplicate acknowledgements for all a receiver should generate duplicate acknowledgements for all
subsequent segments until a missing segment is received. This system subsequent segments until a missing segment is received. This system
requires that SACK be enabled so the sender can reliably tell that requires that SACK be enabled so the sender can reliably tell that
the duplicate acknowledgements are generated by the segment that is the duplicate acknowledgements are generated by the segment that is
meant to be missing and are not concealing other congestion. Once meant to be missing and are not concealing other congestion. Once
the first duplicate acknowledgement arrives, the missing segment can the first duplicate acknowledgement arrives, the missing segment can
then be re-transmitted. Because this loss has been deliberately then be "re-transmitted". Because this loss has been deliberately
introduced, the sender doesn't treat it as a sign of congestion. If introduced, the sender doesn't treat it as a sign of congestion. If
a receiver sends an acknowledgement for a segment that was sent after a receiver sends an acknowledgement for a segment that was sent after
the gap, it proves it is behaving dishonestly and can thus be the gap, it proves it is misbehaving or that its TCP is completely
sanctioned. As soon as the first duplicate acknowledgement is non-compliant. It can then be sanctioned. As soon as the first
received the missing segment is re-transmitted. This will introduce duplicate acknowledgement is received the missing segment is "re-
a 1 RTT delay for some segments which could adversely affect some transmitted". This will introduce a 1 RTT delay for some segments
low-latency applications. which could adversely affect some low-latency applications.
This scheme does work perfectly well in principle and does allow the This scheme does work perfectly well in principle and does allow the
sender to clearly identify dishonest behaviour. However it fails to sender to clearly identify dishonest behaviour. However it fails to
meet requirement 4 in Section 4 above since it requires SACK to be meet requirement 4 in Section 4 above since it requires SACK to be
used. If SACK were not used then it would fail to meet requirement 1 used. If SACK were not used then it would fail to meet requirement 1
as it would be impossible to differentiate between the loss as it would be impossible to differentiate between the loss
introduced on purpose and any additional loss introduced by the introduced on purpose and any additional loss introduced by the
network. network.
It might be possible to incentivise the use of SACK by receivers by It might be possible to incentivise the use of SACK by receivers by
stating that senders are entitled to discriminate against receivers stating that senders are entitled to discriminate against receivers
that don't support it. Given that SACK is now widely implemented that don't support it. Given that SACK is now widely implemented
across the Internet this might be a feasible, but controversial, across the Internet this might be a feasible, but controversial,
deployment strategy. However the solution in Section 6 builds on deployment strategy. However the solution in Section 6 builds on
Sherwood's scheme but avoids the need for SACK. Sherwood's scheme but avoids the need for SACK.
5.2. The ECN nonce 5.2. The ECN nonce
The authors of the ECN scheme [RFC3168] identified the failure to The authors of the ECN scheme [RFC3168] identified the failure to
echo ECN marks as a potential attack on ECN. The ECN nonce was echo ECN marks as a potential attack on ECN. The ECN nonce was
proposed as a possible solution to this in experimental [RFC3540]. proposed as a possible solution to this in the experimental
It uses a 1 bit nonce in every IP header. The nonce works by [RFC3540]. It uses a 1 bit nonce in every IP header. The nonce
randomly setting the ECN field to ECN(0) or ECN(1). It then works by randomly setting the ECN field to ECN(0) or ECN(1). The
maintains the least significant bit of the sum of this value and sender then maintains the least significant bit of the sum of this
stores the expected sum for each segment boundary. At the receiver value and stores the expected sum for each segment boundary. At the
end, the same 1-bit sum is calculated and is echoed back in the NS receiver end, the same 1-bit sum is calculated and is echoed back in
(nonce sum) flag added to the TCP header. If a packet has been the NS (nonce sum) flag added to the TCP header. If a packet has
congestion marked then it loses the information of which ECT been congestion marked then it loses the information of which ECT
codepoint it was carrying. A receiver wishing to conceal the ECN codepoint it was carrying. A receiver wishing to conceal the ECN
mark will have to guess whether to increment NS or not. Once mark will have to guess whether to increment NS or not. Once
congestion has been echoed back and the source has started a congestion has been echoed back and the source has started a
congestion response the nonce sum in the TCP header is not checked. congestion response the nonce sum in the TCP header is not checked.
Once congestion recovery is over the source resets its NS to that of Once congestion recovery is over the source resets its NS to that of
the destination and starts checking again. the destination and starts checking again.
On the face of it this solution also fully covers the two problems On the face of it this solution also fully covers the two problems
identified in Section 3. If a receiver conceals a lost segment it identified in Section 3. If a receiver conceals a lost segment it
has to guess what mark was there and, over several guesses, is very has to guess what mark was there and, over several guesses, is very
skipping to change at page 14, line 7 skipping to change at page 14, line 11
requires the TCP header to be extended to include both these fields. requires the TCP header to be extended to include both these fields.
This proposal clearly breaches several of the requirements listed in This proposal clearly breaches several of the requirements listed in
Section 4. It breaches requirement 2 in that it needs a completely Section 4. It breaches requirement 2 in that it needs a completely
new TCP option or a change to the TCP header. It breaches new TCP option or a change to the TCP header. It breaches
requirement 3 because it needs the receiver to actively echo the requirement 3 because it needs the receiver to actively echo the
nonce (as does the ECN nonce scheme) and if it uses a TCP option it nonce (as does the ECN nonce scheme) and if it uses a TCP option it
breaches requirement 4. On the face of it there is no obvious route breaches requirement 4. On the face of it there is no obvious route
by which this sort of system can be widely implemented. by which this sort of system can be widely implemented.
6. The Test for Receiver Cheating 6. The Test for Receiver Non-compliance
6.1. Solution Overview 6.1. Solution Overview
The ideal solution to the above problems should fully meet the The ideal solution to the above problems should fully meet the
requirements set out in Section 4. The most important of these is requirements set out in Section 4. The most important of these is
that the solution should leverage existing TCP behaviours rather than that the solution should leverage existing TCP behaviours rather than
mandating new behaviours and options. The proposed solution utilises mandating new behaviours and options. The proposed solution utilises
TCP's receiver behaviour on detecting missing data. To test a TCP's receiver behaviour on detecting missing data. To test a
receiver the sender delays a segment during transmission by D receiver the sender delays a segment during transmission by D
segments. There is a trade off because increasing D increases the segments. There is a trade off because increasing D increases the
probability of detecting cheating but also increases the probability probability of detecting non-compliance but also increases the
of masking a congestion event during the test. The completely safe probability of masking a congestion event during the test. The
strategy for the sender would be to reduce its rate pessimistically completely safe strategy for the sender would be to reduce its rate
as if there were congestion during the test however this will impact pessimistically as if there were congestion during the test however
the performance of honest receivers, thus breaching requirement 7. this will impact the performance of its receivers, thus breaching
To overcome this dilemma, the test consists of two stages. In the requirement 7. To overcome this dilemma, the test consists of two
first stage, the sender uses small displacements without the stages. In the first stage, the sender uses small displacements
pessimistic congestion response to determine which receivers appear without the pessimistic congestion response to determine which
to be non-compliant. The sender can then prove the non-compliance of receivers appear to be non-compliant. The sender can then prove the
these receivers by subjecting them to a deterministic test. This non-compliance of these receivers by subjecting them to a
test uses a longer displacement but given the receiver is already deterministic test. This test uses a longer displacement but given
under suspicion, it can risk harming performance by pessimistically the receiver is already under suspicion, it can risk harming
reducing its rate as if the segment it held back was really lost by performance by pessimistically reducing its rate as if the segment it
the network. The tests can either be implemented as part of a test held back was really lost by the network. The tests can either be
suite or as a stand-alone modification to the TCP sender implemented as part of a test suite or as a stand-alone modification
implementation. References to the TCP sender in the rest of the to the TCP sender implementation. References to the TCP sender in
document should be taken to include either type of implementation. the rest of the document should be taken to include either type of
implementation.
6.2. Probabilistic Testing 6.2. Probabilistic Testing
The first requirement for a sender is to decide when to test a The first requirement for a sender is to decide when to test a
receiver. This document doesn't specify when the test should be receiver. This document doesn't specify when the test should be
performed but the following guidance may be helpful. The simplest performed but the following guidance may be helpful. The simplest
option is for a sender to perform the test at frequent random option is for a sender to perform the test at frequent random
intervals for all its half-connections. There are also some intervals for all its half-connections. There are also some
heuristic triggers that might indicate the need for a test. Firstly, heuristic triggers that might indicate the need for a test. Firstly,
if a sender is itself too busy, it would be sensible for it to test if a sender is itself too busy, it would be sensible for it to test
skipping to change at page 15, line 17 skipping to change at page 15, line 22
unclear whether the figures given are more widely applicable. unclear whether the figures given are more widely applicable.
The proposed solution depends, like the skipped segments solution, on The proposed solution depends, like the skipped segments solution, on
the strict requirement that all TCP receivers have to send a the strict requirement that all TCP receivers have to send a
duplicate acknowledgement as soon as they receive an out-of-order duplicate acknowledgement as soon as they receive an out-of-order
segment. This acknowledges that some data has been received, however segment. This acknowledges that some data has been received, however
the acknowledgement is for the last in order segment that was the acknowledgement is for the last in order segment that was
received (hence duplicating an acknowledgment already made). SACK received (hence duplicating an acknowledgment already made). SACK
extends this behaviour to allow the sender to infer exactly which extends this behaviour to allow the sender to infer exactly which
segments are missing. This leads to a simple statement: if a segments are missing. This leads to a simple statement: if a
receiver is behaving honestly it must respond to an out-of-order receiver is behaving compliantly it must respond to an out-of-order
packet by generating a duplicate acknowledgement. packet by generating a duplicate acknowledgement.
Following from the above statement, a sender can test the compliance Following from the above statement, a sender can test the compliance
of a given receiver by simply delaying transmission of a given of a given receiver by simply delaying transmission of a given
segment by several places. An honest receiver will respond to this segment by several places. A compliant receiver will respond to this
by generating a number of duplicate acknowledgements. The sender by generating a number of duplicate acknowledgements. The sender
would strongly suspect a receiver of cheating if it received no would strongly suspect a receiver of non-compliance if it received no
duplicate acknowledgements as a result of the test. A dishonest duplicate acknowledgements as a result of the test. A misbehaving
receiver can only conceal its actions by waiting until the delayed receiver can only conceal its actions by waiting until the delayed
segment arrives and then generating an appropriate stream of segment arrives and then generating an appropriate stream of
duplicate acknowledgements to appear to be honest. duplicate acknowledgements to appear to be honest.
6.2.1. Performing the Probabilistic Test 6.2.1. Performing the Probabilistic Test
The actual mechanism for conducting the test is extremely simple. The actual mechanism for conducting the test is extremely simple.
Having decided to conduct a test the sender selects a segment, N. It Having decided to conduct a test the sender selects a segment, N. It
then chooses a displacement, D (in segments) for this segment where then chooses a displacement, D (in segments) for this segment where
strictly 2 < D < K - 2 where K is the current window size. In strictly 2 < D < K - 2 where K is the current window size. In
practice only low values of D should be chosen to conceal the test practice only low values of D should be chosen to conceal the test
among the background reordering and limit the chance of masking among the background reordering and limit the chance of masking
congestion. D SHOULD be less than 6 for an initial test. If K is congestion. D SHOULD be 6 or less for an initial test. D MUST be
less than 5, the sender can proceed straight to the deterministic greater than 2 to allow for the standard fast retransmit trhreshold
test. To conduct the probabilistic test, instead of transmitting of 3 duplicate acknowledgements. If K is less than 5, the sender
segment N, it transmits N+1, N+2, etc. as shown in the figure below. should arguably not perform any compliance testing. This is because
Once it has transmitted N+D it can transmit segment N. The sender when the window is so small then non-compliance is not such a
needs to record the sequence number, N as well as the displacement, significnat issue. The exception to this might be when this test is
D. being used for testing new implementations. To conduct the
probabilistic test, instead of transmitting segment N, it transmits
N+1, N+2, etc. as shown in the figure below. Once it has transmitted
N+D it can transmit segment N. The sender needs to record the
sequence number, N as well as the displacement, D.
According to data in [Piratla], as much as 15% of segments in the According to data in [Piratla], as much as 15% of segments in the
Internet arrive out of order though this claim may not be accurate. Internet arrive out of order though this claim may not be accurate.
Whatever the actual degree of re-ordering, receivers always expect Whatever the actual degree of re-ordering, receivers always expect
occasional losses of packets which they cannot distinguish from re- occasional losses of packets which they cannot distinguish from re-
ordering without waiting for the re-ordered packet to arrive. ordering without waiting for the re-ordered packet to arrive.
Consequently a misbehaving receiver is unsure how to react to any Consequently a misbehaving receiver is unsure how to react to any
out-of-order packets it receives. It should be noted that the out-of-order packets it receives. It should be noted that the
natural reordering may reduce the displacement deliberately natural reordering may reduce the displacement deliberately
introduced by the test so the sender should conduct the test more introduced by the test so the sender should conduct the test more
than once. than once.
|--.._ | |--.._ |
|--.._`--.._ | |--.._`--.._ |
|--.._`--.._`--.._ | +----------------------------+ |--.._`--.._`--.._ | +----------------------------+
|--.._`--.._`--.._`--.._ | | This figure shows how an | |--.._`--.._`--.._`--.._ | | This figure shows how a |
|--.._`--.._`--.._`--.._`N-1->| | honest receiver reacts to | |--.._`--.._`--.._`--.._`N-1->| | compliant receiver reacts |
|--.._`--.._`--.._`--.._`N+1->| | a probabilistic test with | |--.._`--.._`--.._`--.._`N+1->| | to a probabilistic test |
|--.._`--.._`--.._`-=.._`N+2->| | D=4. It sends 4 duplicate | |--.._`--.._`--.._`-=.._`N+2->| | with D=4. It sends 4 dup. |
| `--.._`-=.._`-=.._`N+3->| | acknowledgements back to | | `--.._`-=.._`-=.._`N+3->| | acknowledgements back to |
| _,--'_-=.._`-=.._`N+4->| | the sender before sending | | _,--'_-=.._`-=.._`N+4->| | the sender before sending |
|<-N-1'_,--'__,--':-=.._`-N-->| | an acknowledgement for N+4 | |<-N-1'_,--'__,--':-=.._`-N-->| | an acknowledgement for N+4 |
|<-N-1'_,--'__,--'__,--'`N+5->| +----------------------------+ |<-N-1'_,--'__,--'__,--'`N+5->| +----------------------------+
|<-N-1'_,--'__,--'__,--'__,--'| |<-N-1'_,--'__,--'__,--'__,--'|
|<-N-1'_,--'__,--'__,--' | |<-N-1'_,--'__,--'__,--' |
|<-N-1'_,--'__,--' | |<-N-1'_,--'__,--' |
|<-N+4'_,--' | |<-N+4'_,--' |
|<-N+5' |<-N+5'
skipping to change at page 17, line 13 skipping to change at page 17, line 22
congestion, and the sender's window is still increasing congestion, and the sender's window is still increasing
exponentially, this might significantly exacerbate the situation. exponentially, this might significantly exacerbate the situation.
This does mean that any receiver being tested during this period will This does mean that any receiver being tested during this period will
suffer reduced throughput, but such testing should only be triggered suffer reduced throughput, but such testing should only be triggered
by the sender being overloaded. by the sender being overloaded.
6.2.2. Assessing the Probabilistic Test 6.2.2. Assessing the Probabilistic Test
This approach to testing receiver compliance appears to meet all the This approach to testing receiver compliance appears to meet all the
requirements set out in Section 4. The most attractive feature is requirements set out in Section 4. The most attractive feature is
that it enforces equivalence with honest behaviour. That is to say, that it enforces equivalence with compliant behaviour. That is to
a receiver can either honestly report the missing packets or it can say, a receiver can either honestly report the missing packets or it
suffer a reduced throughput by delaying segments and increasing the can suffer a reduced throughput by delaying segments and increasing
RTT. The only significant drawback is that during a test it the RTT. The only significant drawback is that during a test it
introduces some delay to the reporting of actual congestion. Given introduces some delay to the reporting of actual congestion. Given
that TCP only reacts once to congestion in each RTT the delay doesn't that TCP only reacts once to congestion in each RTT the delay doesn't
significantly adversely affect the overall response to severe significantly adversely affect the overall response to severe
congestion. congestion.
Some receivers may choose to behave dishonestly despite this. These Some receivers may choose to misbehave despite this. These can be
can be quickly identified by looking at their acknowledgements. A quickly identified by looking at their acknowledgements. A receiver
receiver that never sends duplicate acknowledgements in response to that never sends duplicate acknowledgements in response to being
being tested is likely to be misbehaving. Equally, a receiver that tested is likely to be misbehaving. Equally, a receiver that delays
delays transmission of the duplicate acknowledgements until it is transmission of the duplicate acknowledgements until it is sure it is
sure it is being tested will leave an obvious pattern of being tested will leave an obvious pattern of acknowledgements that
acknowledgements that the sender can identify. Because a receiver is the sender can identify. Because a receiver is unlikely to be able
unlikely to be able to differentiate this test from actual re- to differentiate this test from actual re-ordering events, the
ordering events, the receiver will be forced to behave in the same receiver will be forced to behave in the same fashion for any re-
fashion for any re-ordered packet even in the absence of a test, ordered packet even in the absence of a test, making it continually
making it continually appear to have longer RTT. appear to have longer RTT.
6.2.3. RTT Measurement Considerations 6.2.3. RTT Measurement Considerations
Clearly, if the sender has re-ordered segment N, it cannot use it to Clearly, if the sender has re-ordered segment N, it cannot use it to
take an accurate RTT measurement. However it is desirable to ensure take an accurate RTT measurement. However it is desirable to ensure
that, during a test, the sender still measures the RTT of the flow. that, during a test, the sender still measures the RTT of the flow.
One of the key aspects of this test is that the only way to cheat is One of the key aspects of this test is that the only way for an
for a dishonest receiver to delay sending acknowledgements until it actually dishonest receiver to cheat the test is to delay sending
is certain a test is happening. If accurate RTTs can be measured acknowledgements until it is certain a test is happening. If
during a test, this delay will cause a dishonest receiver to suffer accurate RTTs can be measured during a test, this delay will cause a
an increase in RTT and thus a reduction in data throughput. This dishonest receiver to suffer an increase in RTT and thus a reduction
will help act as a disincentive to cheating. in data throughput.
Measurement of the RTT usually depends on receiving an Measurement of the RTT usually depends on receiving an
acknowledgement for a segment and measuring the delay between when acknowledgement for a segment and measuring the delay between when
the segment was sent and when the acknowledgement arrives. The TCP the segment was sent and when the acknowledgement arrives. The TCP
timestamp option is often used to provide accurate RTT measurement timestamp option is often used to provide accurate RTT measurement
but again, this is not going to function correctly during a test but again, this is not going to function correctly during the test
phase. During a test therefore, the RTT has to be estimated using phase. During a test therefore, the RTT has to be estimated using
the arrival of duplicate acknowledgements. Figure 4 shows how one the arrival of duplicate acknowledgements. Figure 4 shows how one
can measure the RTT in this way, and also demonstrates how this will can measure the RTT in this way, and also demonstrates how this will
increase if a dishonest sender chooses to cheat. However it is not increase if a dishonest sender chooses to cheat. However it is not
sufficient simply to measure a single RTT during the test. A clever sufficient simply to measure a single RTT during the test.
receiver might decide that the safe reaction to any missing segment
is to immediately send one or two duplicate acknowledgements in order
to disrupt this RTT measurement without running the risk of
triggering a fast retransmit if the segment is genuinely missing.
|`--._ | |`--._ |
,--|`--._`--._ | +----------------------------+ ,--|`--._`--._ | +----------------------------+
| C |`--._`--._`--._ | | Segment N is delayed by 3 | | C |`--._`--._`--._ | | Segment N is delayed by 3 |
| h |`--._`--._`--._`--._ | | segments. This triggers 3 | | h |`--._`--._`--._`--._ | | segments. This triggers 3 |
| e |`--._`--._`--._`--._`-N-1->| | duplicate acknowledgements | | e |`--._`--._`--._`--._`-N-1->| | duplicate acknowledgements |
| c | `--._`--._`--._`-N+1->| +----------------------------+ | c | `--._`--._`--._`-N+1->| +----------------------------+
| k | `--._`--._`=N+2->| | k | `--._`--._`=N+2->|
| | `-=._`=N+3->| +----------------------------+ | | `-=._`=N+3->| +----------------------------+
| R | _,--'_,- `=-N=->| | The RTT can be measured by | | R | _,--'_,- `=-N=->| | The RTT can be measured by |
skipping to change at page 19, line 21 skipping to change at page 20, line 12
consequently will lead to receivers using additional resources. In consequently will lead to receivers using additional resources. In
order to mitigate against this, any sender that implements the test order to mitigate against this, any sender that implements the test
should only conduct the test at relatively long intervals (of the should only conduct the test at relatively long intervals (of the
order of several RTTs). order of several RTTs).
6.2.5. Protocol Details for the Probabilistic Test 6.2.5. Protocol Details for the Probabilistic Test
o Any TCP sender MAY check the compliance of its receivers using the o Any TCP sender MAY check the compliance of its receivers using the
probabilistic test periodically and randomly. In particular, it probabilistic test periodically and randomly. In particular, it
would be advantageous for any sender that is heavily loaded to would be advantageous for any sender that is heavily loaded to
identify if it is being taken advantage of by a non-compliant identify if it is being taken advantage of by non-compliant
receiver(s). receivers.
o The decision to test MUST be randomised and MAY be based on: the o The decision to test MUST be randomised and MAY be based on: the
current load on the sender; whether the receiver is undergoing a current load on the sender; whether the receiver is undergoing a
congestion response; whether the receiver appears to have congestion response; whether the receiver appears to have
different flow characteristics to the others; when the receiver different flow characteristics to the others; when the receiver
was last tested. The interval between tests SHOULD be relatively was last tested. The interval between tests SHOULD be relatively
long (order of several RTTs). long (order of several RTTs).
o To perform the test, the sender MUST select a segment N. The o To perform the test, the sender selects a segment N. The
transmission of this segment MUST be delayed by D places. D MUST transmission of this segment will be delayed by D places. D MUST
lie between 2 and K-2 exclusively where K is the current size of lie between 2 and K-2 exclusively where K is the current size of
the transmit window. D SHOULD lie between 2 and 6 exclusively the transmit window. D SHOULD lie between 3 and 6 inclusively
except in those circumstances when a receiver has failed to except in those circumstances when a receiver has failed to
respond as expected to an earlier test but the sender chooses not respond as expected to an earlier test but the sender chooses not
to proceed to the deterministic test. D MUST be generated pseudo- to proceed to the deterministic test. D MUST be generated pseudo-
randomly and unpredictably. The actual delay SHOULD be such that randomly and unpredictably. The actual delay SHOULD be such that
the receiver can't distinguish the test segment from the the receiver can't distinguish the test segment from the
background traffic. If there are less than D segments worth of background traffic. If there are less than D segments worth of
data in the send buffer then the test should be aborted. data in the send buffer then the test SHOULD be omitted.
o If K < 5, the sender should move straight to the deterministic o If K < 5, the sender should not conduct a compliance test.
test Section 6.3.3.
o The sequence number N of the delayed segment MUST be recorded by o The sequence number N of the delayed segment MUST be recorded by
the sender as must the amount of delay D. the sender as must the amount of delay D.
o The senders enters the test phase when it transmits segment N+1 o The senders enters the test phase when it transmits segment N+1
instead of N. instead of N.
o The sender MUST NOT use segment N to measure the RTT of the flow. o The sender MUST NOT use segment N to measure the RTT of the flow.
This is because it won't get a true acknowledgement for this This is because it won't get a true acknowledgement for this
segment. segment.
o The sender SHOULD use segment N+1 to measure the RTT using the o The sender SHOULD use segment N+1 to measure the RTT using the
first duplicate acknowledgement it receives to calculate the RTT. first duplicate acknowledgement it receives to calculate the RTT.
This is to ensure that a dishonest receiver will suffer from an This is to ensure that a dishonest receiver will suffer from an
increased RTT estimate. The sender SHOULD continue checking the increased RTT estimate. The sender SHOULD continue checking the
RTT throughout the test period. RTT throughout the test period.
o If the sender receives any duplicate acknowledgements during a o If the sender receives any duplicate acknowledgements during the
testing phase it MUST check to see if they were generated by test phase it MUST check to see if they were generated by the
segment N (i.e. the acknowledged sequence number will be N-1). If delayed segment (i.e. the acknowledged sequence number must be
they are caused by segment N the sender SHOULD NOT react as if that of the preceding segment). If they are generated to report
they are an indication of congestion. the missing segment N the sender SHOULD NOT react as if they are
an indication of congestion.
o If the sender receives an acknowledgement for a segment with a o If the sender receives an acknowledgement for a segment with a
sequence number between N and N+D inclusively it MUST treat this sequence number between N and N+D inclusively it MUST treat this
as an indication of congestion and react appropriately. as an indication of congestion and react appropriately.
o A sender stops being in a test phase when either it receives the o A sender stops being in the test phase when either it receives the
acknowledgement for segment N+D or when it has received at least D acknowledgement for segment N+D or when it has received at least D
duplicate acknowledgments, whichever happens sooner. duplicate acknowledgments, whichever happens sooner.
o If a sender in a test phase receives D or more duplicate o If a sender in the test phase receives D or more duplicate
acknowledgements, then it MUST retransmit segment N and react as acknowledgements, then it MUST retransmit segment N and react as
if there is congestion as specified in [RFC2581]. This is to if there is congestion as specified in [RFC2581]. This is to
allow for the possibility that segment N may be lost. allow for the possibility that segment N may be lost.
o If the sender is in the slow start phase it MUST move to o If the sender is in the slow start phase it MUST move to
congestion avoidance as soon as it begins a test. It MAY choose congestion avoidance as soon as it begins a test. It MAY choose
to return to slow start once the test is completed. to return to slow start once the test is completed.
o If a sender is in a test phase and receives no duplicate o If a sender is in the test phase and receives no duplicate
acknowledgements from the receiver it MUST treat this as acknowledgements from the receiver it MUST treat this as
suspicious and SHOULD perform the more rigorous deterministic test suspicious and SHOULD perform the more rigorous deterministic test
set out in Section 6.3.3. set out in Section 6.3.3.
o If a sender is in a test phase and the next segment to be o If a sender is in the test phase and the next segment to be
transmitted has either the SYN or RST bits set, then it must transmitted has either the FIN or RST bits set, then it must
immediately stop the test, and transmit segment N before immediately stop the test, and transmit segment N before
transmitting the SYN or RST segment. transmitting the FIN or RST segment.
o A sender MAY choose to monitor the pattern of acknowledgements o A sender MAY choose to monitor the pattern of acknowledgements
generated by a receiver. A dishonest receiver is likely to send a generated by a receiver. A dishonest receiver is likely to send a
distinctive pattern of duplicate acknowledgments during a test distinctive pattern of duplicate acknowledgments during the test
phase. As they are unable to detect whether it is a test or not phase. As they are unable to detect whether it is a test or not
they are also forced to behave the same in the presence of any they are also forced to behave the same in the presence of any
segment reordering caused by the network. segment reordering caused by the network.
6.3. Deterministic Testing 6.3. Deterministic Testing
If after one or more probabilistic tests the sender deems that a If after one or more probabilistic tests the sender deems that a
receiver is acting suspiciously, the sender can perform a receiver is acting suspiciously, the sender can perform a
deterministic test similar to the skipped segment scheme in deterministic test similar to the skipped segment scheme in
Section 5.1 above. Section 5.1 above.
skipping to change at page 21, line 37 skipping to change at page 22, line 29
[RFC2581]. [RFC2581].
6.3.2. Assessing the Deterministic Test 6.3.2. Assessing the Deterministic Test
A dishonest receiver that is concealing segment losses will establish A dishonest receiver that is concealing segment losses will establish
that this isn't a probabilistic test once the missing segment fails that this isn't a probabilistic test once the missing segment fails
to arrive within the space of 1 congestion window. In order to to arrive within the space of 1 congestion window. In order to
conceal the loss the receiver will simply carry on acknowledging all conceal the loss the receiver will simply carry on acknowledging all
subsequent data. The sender can therefore state that if it receives subsequent data. The sender can therefore state that if it receives
an acknowledgement for a segment with a sequence number greater than an acknowledgement for a segment with a sequence number greater than
M before it has actually sent segment M then the receiver must be M before it has actually sent segment M then the receiver must either
cheating. A sender would be expected to close a connection with any be cheating or is very non-compliant.
receiver that had failed the deterministic test, but this draft was
not written to specify what a sender should or must do if a receiver
fails the test, only how to establish such non-compliance.
It is important to be aware that a third party who is able to It is important to be aware that a third party who is able to
correctly guess the initial sequence number of a connection might be correctly guess the initial sequence number of a connection might be
able to masquerade as a receiver and send acknowledgements on their able to masquerade as a receiver and send acknowledgements on their
behalf to make them appear dishonest. Such an attack can be behalf to make them appear non-compliant or even dishonest. Such an
identified because an honest receiver will also be generating a attack can be identified because an honest receiver will also be
stream of duplicate acknowledgements until such time as it receives generating a stream of duplicate acknowledgements until such time as
the missing segment. it receives the missing segment.
6.3.3. Protocol Details for the Deterministic Test 6.3.3. Protocol Details for the Deterministic Test
o If a sender has reason to suspect that a receiver is reacting o If a sender has reason to suspect that a receiver is reacting in a
dishonestly to the probabilistic test it SHOULD perform the more non-compliant manner to the probabilistic test it SHOULD perform
thorough deterministic test. the more thorough deterministic test.
o To perform the deterministic test the sender MUST select a segment o To perform the deterministic test the sender MUST select a segment
M at random. The sender MUST store this segment in the buffer of M at random. The sender MUST store this segment in the buffer of
unacknowledged data without sending it and MUST record the unacknowledged data without sending it and MUST record the
sequence number. sequence number.
o If SACK is not being used, the receiver must pessimistically o If SACK is not being used, the receiver must pessimistically
perform a congestion response following the arrival of the first 3 perform a congestion response following the arrival of the first 3
duplicate acknowledgments for segment M-1 as mandated in duplicate acknowledgments for segment M-1 as mandated in
[RFC2581]. [RFC2581].
skipping to change at page 22, line 32 skipping to change at page 23, line 18
sent after segment M should have been sent, but before segment M sent after segment M should have been sent, but before segment M
is actually sent, then the receiver has proved its non-compliance. is actually sent, then the receiver has proved its non-compliance.
The only possible exception to this is if the receiver is also The only possible exception to this is if the receiver is also
sending a correct stream of duplicate acknowledgements as this sending a correct stream of duplicate acknowledgements as this
implies that a third party is interfering with the connection. implies that a third party is interfering with the connection.
o As soon as the first duplicate acknowledgement for segment M-1 o As soon as the first duplicate acknowledgement for segment M-1
arrives, segment M MUST be transmitted. The effective delay, D, arrives, segment M MUST be transmitted. The effective delay, D,
of segment M MUST be calculated and stored. of segment M MUST be calculated and stored.
o If a sender is in a test phase and the next segment to be o If a sender is in the test phase and the next segment to be
transmitted has either the SYN or RST bits set, then it must transmitted has either the FIN or RST bits set, then it must
immediately stop the test, and transmit segment N before immediately stop the test, and transmit segment N before
transmitting the SYN or RST segment. transmitting the FIN or RST segment.
o Any subsequent acknowledgement for a segment between M and M+D o Any subsequent acknowledgement for a segment between M and M+D
MUST be treated as an indication of congestion and responded to MUST be treated as an indication of congestion and responded to
appropriately as specified in [RFC2581]. appropriately as specified in [RFC2581].
6.4. Responding to Non-Compliance 6.4. Responding to Non-Compliance
Having identified that a receiver is actually being dishonest, the Having identified that a receiver is actually being dishonest, the
appropriate response is to terminate the connection with that appropriate response is to terminate the connection with that
receiver. If a sender is under severe attack it might also choose to receiver. If a sender is under severe attack it might also choose to
skipping to change at page 23, line 21 skipping to change at page 24, line 8
and seeks to show that they are not harmful. and seeks to show that they are not harmful.
6.5.1. TCP Secure 6.5.1. TCP Secure
[I-D.ietf-tcpm-tcpsecure] is a WG Internet Draft that provides a [I-D.ietf-tcpm-tcpsecure] is a WG Internet Draft that provides a
solution to some security issues around the injection of spoofed TCP solution to some security issues around the injection of spoofed TCP
packets into a TCP connection. The mitigations to these attacks packets into a TCP connection. The mitigations to these attacks
revolve round limiting the acceptable sequence numbers for RST and revolve round limiting the acceptable sequence numbers for RST and
SYN segments. In order to ensure there is no unforeseen interaction SYN segments. In order to ensure there is no unforeseen interaction
between TCP Secure and this test the test protocol has been specified between TCP Secure and this test the test protocol has been specified
such that a test will be aborted if a SYN or RST segment is sent. such that the test will be aborted if a RST segment is sent.
6.5.2. Nagle Algorithm 6.5.2. Nagle Algorithm
The Nagle algorithm allows a TCP sender to have one small segment The Nagle algorithm [RFC0896] allows a TCP sender to buffer data
waiting to be acknowledged at a time. This is designed for waiting to be sent until such time as it receives an acknowledgement
interactive applications where the data needs to be echoed back to for the previous segment. This means that there is only ever one
the sender and is intended to reduce the number of small packets that segment in flight and as such this test should not be performed when
are generated. The protocol definition for the probabilistic test the Nagle algorithm is being used.
only allows the test to proceed if there are D or more segments
waiting to be sent. This should remove any possible adverse
interactions with the Nagle algorithm. However this assertion will
need to be checked and the safe strategy may prove to be to ensure
that partial segments are never delayed if Nagle is in operation or
even to suspend testing altogether.
6.5.3. Delayed Acknowledgements 6.5.3. Delayed Acknowledgements
[RFC2581] allows for the generation of delayed acknowledgements for [RFC2581] allows for the generation of delayed acknowledgements for
data segments. However the tests in this document rely on triggering data segments. However the tests in this document rely on triggering
the generation of duplicate acknowledgements. These must be the generation of duplicate acknowledgements. These must be
generated for every out of order packet that is received and should generated for every out of order packet that is received and should
be generated immediately the packet is received. Consequently these be generated immediately the packet is received. Consequently these
mechanisms have no effect on the tests set out in this document. mechanisms have no effect on the tests set out in this document.
6.5.4. Best Effort Transport Service
The Best Effort Transport Service (BETS) is one operating mode of the
Space Communications Protocol Standards (SCPS) [SCPS]. SCPS is a set
of communications protocols optimised for extremely high bandwidth-
delay product links such as those that exist in space. SCPS-TP (SCPS
- Tranpsort Protocol) is based on TCP and is an official TCP option
(number 20). The BETS option within SCPS-TP is designed to provide a
semi-reliable transport between endpoints. As such it doesn't
necessarily ACK data in the same manner as TCP and thus, if this
option has been negotiated on a link the tests described above should
not be used.
6.6. Possible Consequences of the Tests 6.6. Possible Consequences of the Tests
Earlier in this document we asserted that these tests don't change Earlier in this document we asserted that these tests don't change
the TCP protocol. We make this assertion for two reasons. Firstly the TCP protocol. We make this assertion for two reasons. Firstly
the protocol can be implemented as a shim that sits between the TCP the protocol can be implemented as a shim that sits between the TCP
and IP layers. Secondly the network and receiver are unable to and IP layers. Secondly the network and receiver are unable to
differentiate between a sender that implements these tests and a differentiate between a sender that implements these tests and a
sender where the IP layer re-orders packets before transmission. sender where the IP layer re-orders packets before transmission.
However the tests might have some impact on the debugging of a TCP However the tests might have some impact on the debugging of a TCP
implementation. It will also have an impact on debugging traces as implementation. It will also have an impact on debugging traces as
skipping to change at page 27, line 20 skipping to change at page 27, line 38
transmits a new segment it increments a counter; every acknowledgment transmits a new segment it increments a counter; every acknowledgment
it receives decrements that counter; if the counter reaches zero, the it receives decrements that counter; if the counter reaches zero, the
sender won't increase its congestion window in response to a new sender won't increase its congestion window in response to a new
acknowledgement arriving. To comply with this document, senders MUST acknowledgement arriving. To comply with this document, senders MUST
implement a solution to this problem. implement a solution to this problem.
11. Conclusions 11. Conclusions
The issue of mutual trust between TCP senders and receivers is a The issue of mutual trust between TCP senders and receivers is a
significant one in the current Internet. This document has significant one in the current Internet. This document has
introduced a mechanism by which honest senders can verify that their introduced a mechanism by which senders can verify that their
receivers are compliant with the current TCP protocol. The whole receivers are compliant with the current TCP protocol. The whole
process is robust, lightweight, elegant and efficient. The process is robust, lightweight, elegant and efficient. The
probabilistic test might delay a congestion notification by a probabilistic test might delay a congestion notification by a
fraction of a RTT, however this is compensated for by the protocol fraction of a RTT, however this is compensated for by the protocol
reacting more rapidly to any such indication. The deterministic test reacting more rapidly to any such indication. The deterministic test
carries a greater risk of delaying congestion notification and carries a greater risk of delaying congestion notification and
consequently the protocol mandates that a congestion response should consequently the protocol mandates that a congestion response should
happen whilst performing the test. The two tests combine to provide happen whilst performing the test. The two tests combine to provide
a mechanism to allow the sender to judge the compliance of a receiver a mechanism to allow the sender to judge the compliance of a receiver
in a manner that both encourages compliant behaviour and proves non- in a manner that both encourages compliant behaviour and proves non-
skipping to change at page 28, line 11 skipping to change at page 28, line 29
In the longer term it would be hoped that the TCP protocol could be In the longer term it would be hoped that the TCP protocol could be
modified to make it robust against such non-compliant behaviour, modified to make it robust against such non-compliant behaviour,
possibly through the incorporation of a cumulative transport layer possibly through the incorporation of a cumulative transport layer
nonce as described in Section 5.3. nonce as described in Section 5.3.
12. Acknowledgements 12. Acknowledgements
The authors would like to acknowledge the assistance and comments The authors would like to acknowledge the assistance and comments
they received from contributors to the TCPM mailing list. In they received from contributors to the TCPM mailing list. In
particular we would like to thank Mark Allman, Caitlin Bestler, Lars particular we would like to thank Mark Allman, Caitlin Bestler, Lars
Eggert, Gorry Fairhurst, John Heffner, David Mallone, Gavin Eggert, Gorry Fairhurst, John Heffner, Alfred Hoenes, David Mallone,
McCullagh, Anantha Ramaiah, Rob sherwood, Joe Touch and Michael Gavin McCullagh, Anantha Ramaiah, Rob sherwood, Joe Touch and Michael
Welzl. Welzl.
13. Comments Solicited 13. Comments Solicited
Comments and questions are encouraged and very welcome. They can be Comments and questions are encouraged and very welcome. They can be
addressed to the IETF TCP Maintenance and Minor Extensions working addressed to the IETF TCP Maintenance and Minor Extensions working
group mailing list <tcpm@ietf.org>, and/or to the authors. group mailing list <tcpm@ietf.org>, and/or to the authors.
14. References 14. References
skipping to change at page 28, line 44 skipping to change at page 29, line 18
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999. Control", RFC 2581, April 1999.
14.2. Informative References 14.2. Informative References
[I-D.ietf-tcpm-tcpsecure] [I-D.ietf-tcpm-tcpsecure]
Ramaiah, A., "Improving TCP's Robustness to Blind In- Ramaiah, A., "Improving TCP's Robustness to Blind In-
Window Attacks", draft-ietf-tcpm-tcpsecure-07 (work in Window Attacks", draft-ietf-tcpm-tcpsecure-08 (work in
progress), February 2007. progress), February 2007.
[Piratla] Piratla, N., Jayasumana, A., and T. Banka, "On Reorder [Piratla] Piratla, N., Jayasumana, A., and T. Banka, "On Reorder
Density and its Application to Characterization of Packet Density and its Application to Characterization of Packet
Reordering", 2005. Reordering", 2005.
[RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks",
RFC 896, January 1984.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000. Protocol", RFC 2960, October 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
skipping to change at page 29, line 27 skipping to change at page 29, line 49
RFC 3168, September 2001. RFC 3168, September 2001.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, June 2003. RFC 3540, June 2003.
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion [RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion
Control for Voice Traffic in the Internet", RFC 3714, Control for Voice Traffic in the Internet", RFC 3714,
March 2004. March 2004.
[SCPS] CCSDS Secratariat, "Space Control Protocol Specification -
Transport Protocol", October 2006,
<http://public.ccsds.org/publications/archive/
714x0b2.pdf>.
[Savage] Savage, S., Wetherall, D., and T. Anderson, "TCP [Savage] Savage, S., Wetherall, D., and T. Anderson, "TCP
Congestion Control with a Misbehaving Receiver", 1999. Congestion Control with a Misbehaving Receiver", 1999.
[Sherwood] [Sherwood]
Sherwood, R., Bhattacharjee, B., and R. Braud, Sherwood, R., Bhattacharjee, B., and R. Braud,
"Misbehaving TCP Receivers Can Cause Internet-Wide "Misbehaving TCP Receivers Can Cause Internet-Wide
Congestion Collapse", 2005. Congestion Collapse", 2005.
[VU102014] [VU102014]
Doherty, "Optimistic TCP Acknowledgements Can Cause Denial Doherty, "Optimistic TCP Acknowledgements Can Cause Denial
 End of changes. 60 change blocks. 
155 lines changed or deleted 177 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/