draft-ietf-tcpm-tcpsecure-03.txt   draft-ietf-tcpm-tcpsecure-04.txt 
Network Working Group M. Dalal Network Working Group R. Stewart
Internet-Draft Editor Internet-Draft M. Dalal
Expires: November 19, 2005 May 18, 2005 Expires: August 17, 2006 Editor
February 13, 2006
Improving TCP's Robustness to Blind In-Window Attacks Improving TCP's Robustness to Blind In-Window Attacks
draft-ietf-tcpm-tcpsecure-03.txt draft-ietf-tcpm-tcpsecure-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she becomes 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 November 19, 2005. This Internet-Draft will expire on August 17, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
TCP (RFC793 [1]) is widely deployed and one of the most often used A recent study indicates that some types of TCP connections have an
reliable end to end protocols for data communication. Yet when it increased vulnerability to spoofed packet injection attacks than
was defined over 20 years ago the internet, as we know it, was a previously believed [SITW]. TCP has historically been considered
different place lacking many of the threats that are now common. protected against spoofed packet injection attacks by relying on the
Recently several rather serious threats have been detailed that can fact that it is difficult to guess the 4-tuple (the source and
pose new methods for both denial of service and possibly data destination IP addresses and the source and destination ports) in
injection by blind attackers. This document details those threats combination with the 32 bit sequence number(s). A combination of
and also proposes some small changes to the way TCP handles inbound increasing window sizes and applications using a longer term
segments that either eliminate the threats or at least minimize them connections (e.g. H-323 or Border Gateway Protocol [RFC1771]) have
to a more acceptable level. left modern TCP implementation more vulnerable to these types of
spoofed packet injection attacks.
Note: Both [SITW] and [DTASA] provide charts which can give the
reader an idea as to the time it takes to penetrate an unprotected
system.
Many of these long term TCP applications tend to have predictable IP
addresses and ports which makes it far easier for the 4-tuple to be
guessed. Having guessed the 4-tuple correctly, an attacker can
inject a RST, SYN or DATA segment into a TCP connection by carefly
crafting the sequence number of the spoofed segment to be in the
current receive window. This can cause the connection to either
abort or possibly cause data corruption. This document proposes
small modifications to the way TCP handles inbound segments that can
reduce the probability of such an attack.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Blind reset attack using the RST bit . . . . . . . . . . . . . 5 1.1. The RESET attack . . . . . . . . . . . . . . . . . . . . . 4
2.1 Description of the attack . . . . . . . . . . . . . . . . 5 1.2. Attack probabilities . . . . . . . . . . . . . . . . . . . 5
2.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Blind reset attack using the SYN bit . . . . . . . . . . . . . 7 3. Blind reset attack using the RST bit . . . . . . . . . . . . . 9
3.1 Description of the attack . . . . . . . . . . . . . . . . 7 3.1. Description of the attack . . . . . . . . . . . . . . . . 9
3.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Blind data injection attack . . . . . . . . . . . . . . . . . 9 4. Blind reset attack using the SYN bit . . . . . . . . . . . . . 11
4.1 Description of the attack . . . . . . . . . . . . . . . . 9 4.1. Description of the attack . . . . . . . . . . . . . . . . 11
4.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Backward Compatibility and Other considerations . . . . . . . 11 5. Blind data injection attack . . . . . . . . . . . . . . . . . 13
6. Middlebox considerations . . . . . . . . . . . . . . . . . . . 13 5.1. Description of the attack . . . . . . . . . . . . . . . . 13
6.1 Middlebox that cache RST's . . . . . . . . . . . . . . . . 13 5.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2 Middleboxes that advance sequence numbers . . . . . . . . 13 6. ACK throttling . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Backward Compatibility and Other considerations . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Middlebox considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Middlebox that resend RST's . . . . . . . . . . . . . . . 17
9.1 Normative References . . . . . . . . . . . . . . . . . . . 17 8.2. Middleboxes that advance sequence numbers . . . . . . . . 17
9.2 Informative References . . . . . . . . . . . . . . . . . . 17 9. Interoperability Testing . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
1. Introduction 1. Introduction
TCP (RFC793 [1]) is widely deployed and one of the most often used TCP [RFC0793] is widely deployed and the most common reliable end to
reliable end to end protocols for data communication. Yet when it end transport protocol used for data communication in todays
was defined over 20 years ago the internet, as we know it, was a Internet. Yet when it was defined over 20 years ago the Internet, as
different place lacking many of the threats that are now common. we know it, was a different place lacking many of the threats that
Recently several rather serious threats have been detailed that can are now common. TCP spoofing attacks are one such attack that are
pose new methods for both denial of service and possibly data seen on the Internet today.
injection by blind attackers. This document details those threats
and also proposes some small changes to the way TCP handles inbound
segments that either eliminate the threats or at least minimize them
to a more acceptable level.
Most of these proposals modify handling procedures for DATA, RST and In a TCP spoofing attack, an off-path attacker crafts TCP packets by
SYN's as defined in RFC793 [1] but do not cause interoperability forging the IP source and destination addresses as well as the source
issues. The authors feel that many of the changes proposed in this and destination ports (commonly referred to as a 4-tuple value) so
document would, if TCP were being standardized today, be required to that a target TCP endpoint can associate such a packet with an
be in the base TCP document and the lack of these procedures is more existing TCP connection. Note that in and of itself guessing this
an artifact of the time when TCP was developed than any strict 4-tuple value is not always easy for an attacker. But there are some
requirement of the protocol. applications (e.g. BGP [RFC1771]) that may have a tendency to use
the same set(s) of ports on either endpoint making the odds of
guessing correctly the 4-tuple value much easier. When an attacker
is successful in guessing the 4-tuple value, one of three types of
injection attacks may be waged against a long-lived connection.
For some uses of TCP, an alternative protection against the threats RST - Where an attacker injects a reset segment hoping to cause the
that these changes address has already been implemented and deployed connection to be torn down.
in the TCP MD5 Signature Option (RFC2385 [2]). Because this option
is not negotiated and is implemented with a manually established
shared key or password, it has been used for protecting uses of TCP
in which the endpoints are managed, such as for BGP peers. RFC3562
[3] provides importance guidance for users of RFC2385 [2] for
decreasing their vulnerability to key-guessing.
Yet another commonly known mitigation technique is cryptography, SYN - Where an attacker injects a 'SYN' hoping to cause the receiver
especially IPSec. For IPSec to work, both ends of the connection to believe the peer has restarted and so tear down the connection
need to agree on the properties to use for the connection and also state.
agree upon a pre-shared key. In the absence of PKI infrastructure,
this may be inconvenient. IPSec with manual keys can be used to
avoid using ISAKMP. However, this adds considerable burden on the
administration of such solution. If ISAKMP were to be used, this
would typically require all firewalls in the path between the two TCP
endpoints to allow UDP traffic for at least ISAKMP to function.
Further, IPSec and NAT have long been known to have interoperability
issues.
TCP implementations SHOULD also introduce ephemeral port DATA - Where an attacker tries to inject a "DATA" segment to corrupt
randomization. By randomizing ephemeral ports an attacker would have the contents of the transmission.
a less easy time in guessing the four tuples needed to mount a
successful attack. Since ephemeral ports are 16 bit values and are a
subset of the entire available port numbers, it is a weaker defense
than an exact sequence number match as proposed here which is a 32-
bit value and changes dramatically within the life of a connection.
Nevertheless, both of them are complimentary solutions that will make
it difficult to launch attacks discussed below.
Alternative proposals, including the use of cookies (or, use of the 1.1. The RESET attack
timestamp option as a cookie) require both peers to implement the
changes before any additional protection can be realized.
2. Blind reset attack using the RST bit Focusing upon the RESET attack, let's examine this attack in more
detail to get an overview as to how it works and how this document
proposes addressing the issue. For this attack the goal is to cause
one of the two endpoints of the connection to incorrectly tear down
the connection state, effectively closing the connection. To do this
the attacker needs to have or guess several pieces of information
(namely):
2.1 Description of the attack 1) The 4-tuple value containing the IP address and TCP port number of
both ends of the connection. For one side (usually the server)
guessing the port number is a trivial exercise. The client side
may or may not be easy for an attacker to guess depending on a
number of factors most notably the operating system and
application involved.
It has been traditionally thought that for a blind attacker to reset 2) A sequence number that will be used in the RST. This sequence
a TCP connection the attacker would have to guess a single sequence number will be a starting point for a series of guesses to attempt
number in the TCP sequence space. This would in effect require an to present a RST segment to a connection endpoint that would be
attacker to generate (2^^32) segments in order to reset a connection. acceptable to it. Any random value may be used to guess the
Recent papers have shown this to not necessarily be the case. An initial sequence number.
attacker need only guess a number that lies between the last sequence
number acknowledged and the last sequence number acknowledged added
to the receiver window (RCV.WND)[4]. Modern operating systems
normally default the RCV.WND to about 32,768 bytes. This means that
a blind attacker need only guess 65,535 RST segments (2^^32/RCV.WND)
in order to reset a connection. At DSL speeds this means that most
connections (assuming the attacker can accurately guess both ports)
can be reset in under 200 seconds (usually far less). With the rise
of broadband availability and increasing available bandwidth, many
Operating Systems have raised their default RCV.WND to as much as
64k, thus making these attacks even easier.
2.2 Solution 3) The window size that the two endpoints are using. This value does
NOT have to be the exact window size since a smaller value used in
lieu of the correct one will just cause the attacker to generate
more segments before succeeding in his mischieve. Most modern
operating systems have a default window size which usually is
applied to most connections. Some applications however may change
the window size to better suit the needs of the application. So
often times the attacker, with a fair degree of certainty (knowing
the application that is under attack), can come up with a very
close approximation as to the actual window size in use on the
connection.
RFC793 [1] currently requires handling of a segment with the RST bit After assembling the above set of information the attacker begins
when in a synchronized state to be processed as follows: sending spoofed TCP segments with the RST bit set and a guessed TCP
sequence number. Each time a new RST segment is sent, the sequence
number guess is incremented by the window size. Without mitigation
[SITW] has shown that such an attack is much easier to accomplish
then previously assumed. This is because RFC793 [RFC0793] specifies
that any RST within the current window is acceptable.
A slight modification to the TCP state machine can be made which
makes such an attack much more difficult to accomplish. If the
receiver examines the incoming RST segment and validates that the
sequence number exactly matches the sequence number that is next
expected, then such an attack becomes much more difficult then
outlined in [SITW] (i.e. the attacker would have to generate 1/2 the
entire sequence space, on average). This document will discuss the
exact details of what needs to be changed within TCP's state machine
to mitigate all three types of attacks (RST, SYN and DATA).
1.2. Attack probabilities
Every application has control of a number of factors that effect
drastically the probability of a successful spoofing attack. These
factors include such things as:
Window Size - Normally settable by the application but often times
defaulting to 32,768 or 65,535 depending upon the operating system
(Medina05 [Medina05]).
Server Port number - This value is normally a fixed value so that a
client will know where to connect to the peer at. Thus this value
normally provides no additional protection.
Client Port number - This value may be a random ephemeral value, if
so, this makes a spoofing attack more difficult. There are some
clients, however, that for whatever reason either pick a fixed
client port or have a very guessable one (due to the range of
ephemeral ports available with their operating system or other
application considerations) for such applications a spoofing
attack becomes less difficult.
For the purposes of the rest of this discussion we will assume that
the attacker knows the 4-tuple values. This assumption will help us
focus on the effects of the window size verses the number of TCP
packets an attacker must generate. This assumption will rarely be
true in the real Internet since at least the client port number will
provide us with some amount of randomness (depending on operating
system).
To successfully inject a spoofed packet (RST, SYN or DATA), in the
past, the entire sequence space (i.e. 2^32) was often considered
available to make such an attack unlikely. [SITW] demonstrated that
this assumption was incorrect and that instead of [1/2 X 2^32]
packets (assuming a random distribution) [1/2 X (2^32/window)]
packets is required.
Placing real numbers on this formula we see that for a window size of
32,768, an average of 65,536 packets would need to be transmitted in
order to "spoof" a TCP segment that would be acceptable to a TCP
receiver. A window size of 65,535 reduces this even further to
32,768 packets. With rises in bandwidth to both the home and office,
it can only be expected that the values for default window sizes will
continue to rise in order to better take advantage of the newly
available bandwidth.
As we can see from the above discussion this weakness lowers the bar
quite considerably for likely attacks. But there is one additional
dependency which is the duration of the TCP connection. A TCP
connection that lasts only a few brief packets, as often is the case
for web traffic, would not be subject to such an attack since the
connection may not be established long enough for an attacker to
generate enough traffic. However there is a set of applications such
as BGP [RFC1771] which is judged to be potentially most affected by
this vulnerability. BGP relies on a persistent TCP session between
BGP peers. Resetting the connection can result in medium term
unavailability due to the need to rebuild routing tables and route
flapping see [NISCC] for further details.
It should be noted that there are existing alternative protection
against the threats that this document addresses. For further
details regarding the attacks and the existing techniques, please
refer to draft [DTASA]
2. Terminology
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 [RFC2119].
TCP terminology should be interpreted as described in RFC793
[RFC0793].
3. Blind reset attack using the RST bit
3.1. Description of the attack
As described in the introduction, it is possible for an attacker to
generate a "RST" segment that would be acceptable to a TCP receiver
by guessing a "in-window" sequence numbers. In particulary RFC 793,
p37, states the following:
"In all states except SYN-SENT, all reset (RST) segments are
validated by checking their SEQ-fields [sequence numbers]. A reset
is valid if its sequence number is in the window. In the SYN-SENT
state (a RST received in response to an initial SYN), the RST is
acceptable if the ACK field acknowledges the SYN."
3.2. Mitigation
RFC793 [RFC0793] currently requires handling of a segment with the
RST bit when in a synchronized state to be processed as follows:
1) If the RST bit is set and the sequence number is outside the 1) If the RST bit is set and the sequence number is outside the
expected window, silently drop the segment. current receive window (SEG.SEQ <= RCV.NXT || SEG.SEQ > RCV.NXT+
RCV.WND) , silently drop the segment.
2) If the RST bit is set and the sequence number is acceptable i.e.: 2) If the RST bit is set and the sequence number is acceptable i.e.:
(RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND) then reset the connection. (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND) then reset the connection.
Instead, the following changes should be made to provide some Instead, this document proposes the following changes should be made
protection against such an attack. to provide protection against such an attack.
A) If the RST bit is set and the sequence number is outside the A) If the RST bit is set and the sequence number is outside the
expected window, silently drop the segment. current receive window, silently drop the segment.
B) If the RST bit is set and the sequence number exactly matches the B) If the RST bit is set and the sequence number exactly matches the
next expected sequence number, reset the connection. next expected sequence number (RCV.NXT), then TCP MUST reset the
connection.
C) If the RST bit is set and the sequence number does not exactly C) If the RST bit is set and the sequence number does not exactly
match the next expected sequence value, yet is within the match the next expected sequence value, yet is within the current
acceptable window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND) send an receive window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND), TCP MUST
acknowledgment: send an acknowledgment (challenge ACK):
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the acknowledgment, drop the unacceptable segment After sending the challenge ACK, TCP MUST drop the unacceptable
and return. segment and stop processing the incoming packet further.
This solution forms a challenge/response with any RST where the The previous text,quoted from RFC793 pg 37 would thus become:
value does not exactly match the expected value and yet the RST is
within the window. In cases of a legitimate reset without the
exact sequence number, the consequences of this new challenge/
response will be that the peer requires an extra round trip time
before the connection can be reset.
In order to alleviate multiple RSTs/SYNs from triggering multiple In all states except SYN-SENT, all reset (RST) segments are
challenge ACKs, a ACK throttling mechanism SHOULD be implemented. validated by checking their SEQ-fields [sequence numbers]. A
Suggested values are to send no more than 10 challenge ACKs in a 5 reset is valid if its sequence number exactly matches the next
second window. These values MUST be tunable to accommodate different expected sequence number. If the the RST arrives and its sequence
requirements. ACK throttling if implemented successfully can lead to number field does NOT match the next expected sequence number but
several advantages. Besides preventing the RST/ACK war outlined in is within the window, then the receiver should generate an ACK.
the section below, it can also alleviate spurious fast retransmits at In all other cases where the SEQ-field does not match and is
the remote end caused by flood of duplicate ACKs and also save outside the window, the receiver MUST silently discard the
spurious processing required to send an ACK on the victim side. segment.
3. Blind reset attack using the SYN bit In the SYN-SENT state (a RST received in response to an initial
SYN), the RST is acceptable if the ACK field acknowledges the SYN.
In all other cases the receiver MUST silently discard the segment.
3.1 Description of the attack With the above slight change to the TCP state machine, it becomes
much harder for an attacker to generate an acceptable reset
segment.
Analysis of the reset attack, which uses the RST flag bit, highlights In cases where the remote peer did generate a RST but it fails to
another possible avenue for a blind attacker. Instead of using the meet the above criteria (the RST sequence number was within the
RST bit an attacker can use the SYN bit as well to tear down a window but NOT the exact expected sequence number) when the
connection. Using the same guessing technique, repeated SYN's can be challenge ACK is sent back, it will no longer have the
generated with sequence numbers incrementing by an amount not larger transmission control block (TCB) related to this connection and
than the window size apart and thus eventually cause the connection hence as per RFC793 [RFC0793], the remote peer will send a second
to be terminated. RST back. The sequence number of the second RST is derived from
the acknowledgment number of the incoming ACK. This second RST if
it reaches the sender will cause the connection to be aborted
since the sequence number would now be an exact match.
3.2 Solution Note that the above mitigation may cause a non-amplification ACK
exchange. This concern is detailed in
RFC793 [1] currently requires handling of a segment with the SYN bit 4. Blind reset attack using the SYN bit
set in the synchronized state to be as follows:
4.1. Description of the attack
Analysis of the reset attack using the RST bit, highlights another
possible avenue for a blind attacker using a similar set of sequence
number guessing. Instead of using the RST bit an attacker can use
the SYN bit with the exact same symantics to tear down a connection.
4.2. Mitigation
RFC793 [RFC0793] currently requires handling of a segment with the
SYN bit set in the synchronized state to be as follows:
1) If the SYN bit is set and the sequence number is outside the 1) If the SYN bit is set and the sequence number is outside the
expected window, send an ACK back to the sender. expected window, send an ACK back to the sender.
2) If the SYN bit is set and the sequence number is acceptable i.e.: 2) If the SYN bit is set and the sequence number is acceptable i.e.:
(RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then send a RST segment to (RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then send a RST segment to
the sender. the sender.
Instead, changing the handling of the SYN to the following will Instead, changing the handling of the SYN in the synchronized state
provide complete protection from this attack: to the following will mitigate this attack:
1) If the SYN bit is set, irrespective of the sequence number, send A) If the SYN bit is set, irrespective of the sequence number, TCP
an ACK to the remote peer: MUST send an ACK (also referred to as challenge ACK) to the remote
peer:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the acknowledgment, drop the unacceptable segment After sending the acknowledgment, TCP MUST drop the unacceptable
and return. segment and stop processing further.
This solution again forms a challenge response with the peer as in By sending an ACK, the remote end sender is challenged to confirm the
the previous section. loss of the previous connection and the request to start a new
connection. A legitimate peer, after restart, would not have a TCB
in the synchronized state. Thus when the ACK arrives the peer should
send a RST segment back with the sequence number derived from the ACK
field that caused the RST.
By always sending an ACK to the sender, a challenge/response is setup This RST will confirm that the remote TCP endpoint has indeed closed
with the peer. A legitimate peer, after restart, would not have a the previous connection. Upon receipt of a valid RST, the local TCP
TCB in the synchronized state. Thus when the ACK arrives the peer endpoint MUST terminate its connection. The local TCP endpoint
should send a RST segment with the sequence number derived from the should then rely on SYN retransmission from the remote end to re-
ACK field that caused the RST. establish the connection.
Note, there is one corner case for the SYN attack problem that will A spoofed SYN, on the other hand, will then have generated an
prevent the successful reset of the connection. This is a result of additional ACK which the peer will discarded as a duplicate ACK and
the RFC793 [1] specification and is nothing to do with the proposed will not affect the established connection.
solution. In this problem, if a restarting host generates a SYN with
an initial sequence number that is exactly equal to RCV.NXT - 1 of
the remote TCP endpoint that is still in the established state and if
the SYN arrives at the peer that is still holding the stale
connection, an ACK will be generated. This ACK will have an ack
value of RCV.NXT and will be acceptable to the restarting host which
will accept the ACK and do nothing. The SYN will then be
retransmitted and the behavior will repeat. This could lead to an
initialization failure. Subsequent connection attempts will
hopefully succeed by choosing a new ISN that is not equal to RCV.NXT
- 1. A similar problem will be seen should the SYN contain data.
4. Blind data injection attack Note that this mitigation does leave one corner case un-handled which
will prevent the reset of a connection when it should be reset (i.e.
it is a non spoofed SYN wherein a peer really did restart). This
problem occurs when the restarting host chooses the exact same IP
address and port number that it was using prior to its restart. By
chance the restarted host must also choose an initial sequence number
of exactly (RCV.NXT - 1) of the remote TCP endpoint that is still in
the established state. Such a case would cause the receiver to
generate a "challenge" ack as described above. But since the ACK
would be within the outgoing connections window the inbound ACK would
be acceptable, and the sender of the SYN will do nothing with the
response ACK. This sequence will continue as the SYN sender
continually times out and retransmits the SYN until such time as the
connection attempt fails.
4.1 Description of the attack This corner case is a result of the RFC793 [RFC0793] specification
and is not introduced by the proposed mitigations.
Note that the above mitigation may cause a non-amplification ACK
exchange. This concern is detailed in Section 10
5. Blind data injection attack
5.1. Description of the attack
A third type of attack is also highlighted by both the RST and SYN A third type of attack is also highlighted by both the RST and SYN
attacks. It is quite possible to inject data into a TCP connection attacks. It is also possible to inject data into a TCP connection by
by simply guessing a sequence value that is within the window. The simply guessing the a sequence number within the current receive
ACK value of any data segment is considered valid as long as it does window of the victim. The ACK value of any data segment is
not acknowledge data ahead of the next segment to send. In other considered valid as long as it does not acknowledge data ahead of the
words an ACK value is acceptable if it is (SND.UNA-(2^^31-1)) <= next segment to send. In other words an ACK value is acceptable if
SEG.ACK <= SND.NXT). This means that an attacker simply need guess it is (SND.UNA-(2^31-1)) <= SEG.ACK <= SND.NXT). This means that an
two ACK values with every guessed sequence number so that the chances attacker has to guess two ACK values with every guessed sequence
of successfully injecting data into a connection are 1 in ((2^^32 / number so that the chances successfully injecting data into a
RCV.WND) * 2). connection are 1 in ((2^32 / RCV.WND) * 2).
When an attacker successfully injects data into a connection the data When an attacker successfully injects data into a connection the data
will sit in the receiver's re-assembly queue until the peer sends will sit in the receiver's re-assembly queue until the peer sends
enough data to bridge the gap between the RCV.NXT value and the enough data to bridge the gap between the RCV.NXT value and the
injected data. At that point one of two things will occur either: injected data. At that point one of two things will occur either:
a) An ACK war will ensue with the receiver indicating that it has a) An packet war will ensue with the receiver indicating that it has
received data up until RCV.NXT (which includes the attackers data) received data up until RCV.NXT (which includes the attackers data)
and the sender sending a corrective ACK with a value less than and the sender sending an ACK with an acknowledgment number less
RCV.NXT (the real sequence number of the last byte sent). than RCV.NXT.
b) The sender will send enough data to the peer which will move b) The sender will send enough data to the peer which will move
RCV.NXT even further along past the injected data. RCV.NXT even further along past the injected data.
In either case the injected data will be made readable to the upper Depending upon the TCP implementation in question and the TCP traffic
layer and in case <a> the connection will eventually be reset by one characteristics at that time, data corruption may result. In case
of the sides. Note that the protections illustrated in this section (a) the connection will eventually be reset by one of the sides
neither cause an ACK war nor prevent one from occurring if data is unless the sender produces more data that will transform the ACK war
actually injected into a connection. The ACK war is a natural into case (b). The reset will usually occur via User Time Out (UTO)
consequence of any data injection that is successful. (see section 4.2.3.5 of [RFC1122]).
4.2 Solution Note that the protections illustrated in this section neither cause
an ACK war nor prevent one from occurring if data is actually
injected into a connection. The ACK war is a product of the attack
itself and cannot be prevented (other than by preventing the data
from being injected).
5.2. Mitigation
An additional input check should be added to any incoming segment. An additional input check should be added to any incoming segment.
The ACK value should be acceptable only if it is in the range of The ACK value MUST be acceptable only if it is in the range of
((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). MAX.SND.WND is ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). MAX.SND.WND is
defined as the largest window that the local receiver has ever defined as the largest window that the local receiver has ever
advertised to it's peer. This window is the scaled value i.e. the advertised to its peer. This window may be a scaled value i.e. the
value may be larger than 65,535 bytes. This small check will greatly value may be larger than 65,535 bytes (RFC1323 [RFC1323]). This
reduce the vulnerability of an attacker guessing a valid sequence small check will greatly reduce the vulnerability to an attacker
number since not only must he/she guess the sequence number in guessing a valid sequence number since not only must he/she guess the
window, but must also guess a proper ACK value within a scoped range. sequence number in window, but must also guess a proper ACK value
This solution reduces but does not eliminate the ability to generate within a scoped range. This mitigation reduces but does not
false segments. It does however reduce the probability that invalid eliminate the ability to generate false segments. It does however
data will be injected to a more acceptable level. For those reduce the probability that invalid data will be injected.
applications that wish to close this attack completely RFC2385 [2]
should be deployed between the two endpoints.
5. Backward Compatibility and Other considerations Note that the above mitigation may cause a non-amplification ACK
exchange. This concern is detailed in
1) The proposed solution is backward compatible as it uses the 6. ACK throttling
semantics laid down in RFC793 [1] to defend against it's own
weakness. Referring to the figure below, if we assume that the
RST (1.c) was in flight when the ACK (2) left TCP A, TCP B has no
way of knowing what triggered the ACK. For all it cares, the ACK
might have been a result of the data or the RST that it had sent
earlier. Hence in either case, TCP B must reply to this ACK with
an appropriate RST that is in keeping with RFC793 [1].
2) Concerns have been raised that the challenge response mechanism In order to alleviate multiple RSTs/SYNs from triggering multiple
will lead to a reflector kind of attack. In this attack, it is challenge ACKs, an ACK throttling mechanism SHOULD be implemented.
believed that an attacker with higher bandwidth can potentially Suggested values are to send no more than 10 challenge ACKs in a 5
spoof SYN or RST packets within the window and cause ACK flooding second window. These numbers are empirical in nature and have been
to a remote peer that may have a lower bandwidth. These concerns obtained from the RST throttling mechanism implemented in some OS's.
are misplaced because it is trivial to cause a victim to generate These value MUST be tunable by a system administrator to accommodate
an ACK. A spoofer can simply send packets with sequence numbers different preceived threats.
that are outside the acceptable window of the attacker or send an
ACK that acknowledges something that is not yet sent. Further, an
attacker can also simply generate data packets that fall within
the window to cause an ACK to be sent. RFC793 [1] also mandates
that an ACK be sent if the incoming SYN to an established
connection falls outside the acceptable window. All these
scenarios can be used to launch a flood attack. However, the
potential harm of such attacks are low and can be easily detected
due to the volume of packets generated. The latter is a strong
deterrent to such attacks.
3) There is a corner scenario in the above proposed solutions which An alternative mechanism may also be used that does not involve an
additional timer. In such an implementation a sender would only send
X acks between any window advancment. Note that such a limitation
will not require a timer but must be implemented with care to avoid a
deadlock in the face of ack loss.
An implementation SHOULD include a ACK throttling mechanism to be
conservative. Currently there is no known bad behavior that can be
attributed to the lack of ACK throttling, but as a general principle,
if ever invoked, something incorrect is occuring and such a mechanisn
will act as a failsafe that protects both the sender and the network.
An administrator who is more concerned about protecting his bandwidth
and CPU utilization may set smaller ACK thottling values whereas an
administrator who is more interested in faster cleanup of stale
connections (i.e. concerned about excess TCP state) may decide to set
a higher value thus allowing more RST's to be processed in any given
time period.
The time limit SHOULD be tunable to help timeout brute force attacks
faster than a potential legitimate flood of RSTs.
7. Backward Compatibility and Other considerations
1) All of the proposed mitigation techniques in this document are
totally compatible with existing (RFC793 [RFC0793]) compliant TCP
implementations as this document introduces no new assumptions or
conditions.
2) There is a corner scenario in the above proposed mitigations which
will require more than one round trip time to successfully abort will require more than one round trip time to successfully abort
the connection as per the figure below. This scenario is similar the connection as per the figure below. This scenario is similar
to the one in which the original RST was lost in the network. to the one in which the original RST was lost in the network.
TCP A TCP B TCP A TCP B
1.a. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=ACK><DATA> <-- ESTABLISHED 1.a. ESTAB <-- <SEQ=300><ACK=101><CTL=ACK><DATA> <-- ESTAB
b. (delayed) ... <SEQ=400><ACK=101><CTL=ACK><DATA> <-- ESTABLISHED b. (delayed) ... <SEQ=400><ACK=101><CTL=ACK><DATA> <-- ESTAB
c. (in flight) ... <SEQ=500><ACK=101><CTL=RST> <-- CLOSED c. (in flight) ... <SEQ=500><ACK=101><CTL=RST> <-- CLOSED
2. ESTABLISHED --> <SEQ=101><ACK=400><CTL=ACK> --> CLOSED 2. ESTAB --> <SEQ=101><ACK=400><CTL=ACK> --> CLOSED
(ACK for 1.a) (ACK for 1.a)
... <SEQ=400><ACK=0><CTL=RST> <-- CLOSED ... <SEQ=400><ACK=0><CTL=RST> <-- CLOSED
3. CHALLENGE --> <SEQ=101><ACK=400><CTL=ACK> --> CLOSED 3. CHALLENGE --> <SEQ=101><ACK=400><CTL=ACK> --> CLOSED
(for 1.c) (for 1.c)
... <SEQ=400><ACK=0><CTL=RST> <-- RESPONSE ... <SEQ=400><ACK=0><CTL=RST> <-- RESPONSE
4.a. ESTABLISHED <-- <SEQ=400><ACK=101><CTL=ACK><DATA> 1.b reaches A 4.a. ESTAB <-- <SEQ=400><ACK=101><CTL=ACK><DATA> 1.b reaches A
b. ESTABLISHED --> <SEQ=101><ACK=500><CTL=ACK> b. ESTAB --> <SEQ=101><ACK=500><CTL=ACK>
c. (in flight) ... <SEQ=500><ACK=0><CTL=RST> <-- CLOSED c. (in flight) ... <SEQ=500><ACK=0><CTL=RST> <-- CLOSED
5. RESPONSE arrives at A, but is dropped because of being out of window. 5. RESPONSE arrives at A, but dropped since its outside of window.
6. ESTABLISHED <-- <SEQ=500><ACK=0><CTL=RST> 4.c reaches A 6. ESTAB <-- <SEQ=500><ACK=0><CTL=RST> 4.c reaches A
7. CLOSED CLOSE 7. CLOSED CLOSED
4) For the solution to be totally effective against the 3) For the mitigation to be maximally effective against the
vulnerabilities discussed in this document, both ends of the TCP vulnerabilities discussed in this document, both ends of the TCP
connection need to have the fix. Although, having it at one end connection need to have the fix. Although, having the mitagations
might prevent that end from being exposed to the attack, the at one end might prevent that end from being exposed to the
connection is still vulnerable at the other end. attack, the connection is still vulnerable at the other end.
6. Middlebox considerations 8. Middlebox considerations
The following scenarios were brought to notice by the tcpm working 8.1. Middlebox that resend RST's
group members as middlebox issues which may cause the proposed
solution to behave in an unexpected manner.
6.1 Middlebox that cache RST's Consider a middlebox M-B tracking connection between two TCP endhosts
E-A and E-C. If E-C sends a RST with a sequence number that is
within the window but not an exact match to reset the connection and
M-B does not have the fix proposed here, it may clear the connection
and forward the RST to E-A saving an incorrect sequence number. If
E-A does not have the fix it will clear the connection and everything
will be fine. However if E-A does have the proposed fix above, it
will send a challenge ACK to E-C. M-B, being a middlebox, may
intercept this ACK and resend the RST on behalf of E-C with the old
sequence number. This RST, will again, not acceptable and may
trigger a challenge ACK.
Consider a middlebox B tracking connection between two TCP endhosts A This may cause a RST/ACK war to occur. However we believe that if
and C. If C sends a RST with a sequence number that is within the such a case exists in the Internet the middle box design itself is
window but not an exact match to reset the connection and if B does flawed. Consider a similar scenario where the RST from M-B to E-A
not have the fix proposed here, it will clear the connection and ask gets lost, E-A will continue to hold the connection and E-A might
A to do the same. If A does not have the fix it will clear the send an ACK an arbitrary time later after the connection state was
connection and everything will be fine. However if A does have the destroyed at M-B. For this case, M-B will have to cache the RST for
proposed fix above, it will send a challenge ACK. B being a an arbitrary amount of time till until it is confirmed that the
middlebox will intercept this ACK and resend the RST cached earlier connection has been cleared at E-A. Further, this is not compliant
that was responsible for bringing down the connection. However, the to RFC793 which dictates that the sequence number of a RST has to be
RST will again be not acceptable and will trigger a challenge ACK derived from the acknowledgment number of the incoming ACK segment.
again. This will cause a RST/ACK war to happen. However, we are not
aware of middleboxes that actually do this and believe the design
itself is flawed in that given the scenario that the RST from B to A
got lost on the way, A will continue to hold the connection and A
might send an ACK an arbitrary time after the connection was brought
down at B. In this case, B will have to cache the RST for an
arbitrary amount of time till it's confirmed that the connection has
been cleared at A.
6.2 Middleboxes that advance sequence numbers 8.2. Middleboxes that advance sequence numbers
Some Middleboxes may compute RST sequence numbers at the higher end Some middleboxes may compute RST sequence numbers at the higher end
of the acceptable window. The setup is the same as the earlier case, of the acceptable window. The scenario is the same as the earlier
but in this case instead of sending the cached RST, the middlebox case, but in this case instead of sending the cached RST, the
sends a RST that computes it's sequence number as a sum of the ack middlebox (M-B) sends a RST that computes its sequence number as a
field in the ACK and the window advertised by the ACK that was sent sum of the ack field in the ACK and the window advertised by the ACK
by A to challenge the RST as depicted below. The difference in the that was sent by E-A to challenge the RST as depicted below. The
sequence numbers between step 1 and 2 below is due to data lost in difference in the sequence numbers between step 1 and 2 below is due
the network. to data lost in the network.
TCP A Middlebox TCP A Middlebox
1. ESTABLISHED <-- <SEQ=500><ACK=100><CTL=RST> <-- CLOSED 1. ESTABLISHED <-- <SEQ=500><ACK=100><CTL=RST> <-- CLOSED
2. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED 2. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED
3. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED 3. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED
4. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED 4. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED
5. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED 5. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED
Although the authors are not aware of a working implementation that Although the authors are not aware of an implementation that does the
does the above, it could be mitigated by implementing the RST above, it could be mitigated by implementing the ACK throttling
throttling mechanism described earlier. mechanism described earlier.
7. Contributors 9. Interoperability Testing
Interoperability testing was performed among the operating systems
from Juniper Networks, WindRiver Systems, QNX Software and Cisco
Systems. The following topology was used:
+---------+ +---------+
|TCP A |----+------|Victim B |
+---------+ | +---------+
|
+---------+ |
|Attacker |----+
+---------+
In the above topology B is the unit under test. TCP A is a remote
peer and the attacker workstation is used to generate malicious
spoofed packets.
First, an unmodifed stack had the following tests performed upon it.
A TCP connection was brought up between TCP endpoint A and B. The
4-tuple of the connection was manually populated in the brute force
attack script running on the attacker workstation. The script
crafted TCP packets by using the 4-tuple and by generating sequence
numbers that incremented from 0 to the max permissible sequence
number (2^32 -1) in varying increments of window size of 8K to 64K
(the window size agreed by A and B was larger than 8K, but was
ignored to make the test conservative). The time it took to cause
the connection to reset/corrupt was then recorded.
The test was repeated by then generating sequence numbers that were
window (the one agreed between endpoints A and B) size apart. It was
observed that increasing the window size caused the connection to be
reset faster than with a smaller window. Further, it was also
observed that the initial sequence number (ISN) selection also played
a role in how fast a connection was aborted, with ISN selection in
the lower half of the sequence space aborting sooner than an ISN in
the upper half. Results were also found to be influenced by any
active data transfer on the connection.
Active data transfer sometimes caused the connection to be reset
faster and some other times to slow the attack. The window size
selection at the attacker workstation and how it compares to the
actual window size between A and B was also found to be a factor.
The tests were repeated with a stack that did have the fix and as
expected it became difficult as compared to the previous results to
cause the connection to abort.
[Editors Note: Add time test data gathered at inter-op here!!]
10. Security Considerations
A reflector attack is possible with the proposed RST/SYN mitigation
techniques. Here an off-path attacker can cause a victim to send an
ACK segment for each spoofed RST/SYN segment that lies within the
current receive window of the victim. This, however, does not cause
any sort of amplification since the attacker must generate a segment
for each one that the victim will generate.
11. IANA Considerations
This document contains no IANA considerations.
12. Contributors
Mitesh Dalal and Amol Khare of Cisco Systems came up with the Mitesh Dalal and Amol Khare of Cisco Systems came up with the
solution for the RST/SYN attacks. Anantha Ramaiah and Randall solution for the RST/SYN attacks. Anantha Ramaiah and Randall
Stewart of Cisco Systems discovered the data injection vulnerability Stewart of Cisco Systems discovered the data injection vulnerability
and together with Patrick Mahan and Peter Lei of Cisco Systems found and together with Patrick Mahan and Peter Lei of Cisco Systems found
solutions for the same. Paul Goyette, Mark Baushke, Frank solutions for the same. Paul Goyette, Mark Baushke, Frank
Kastenholz, Art Stine and David Wang of Juniper Networks provided the Kastenholz, Art Stine and David Wang of Juniper Networks provided the
insight that apart from RSTs, SYNs could also result in formidable insight that apart from RSTs, SYNs could also result in formidable
attacks. Shrirang Bage of Cisco Systems, Qing Li and Preety Puri of attacks. Shrirang Bage of Cisco Systems, Qing Li and Preety Puri of
Wind River Systems and Xiaodan Tang of QNX Software along with the Wind River Systems and Xiaodan Tang of QNX Software along with the
folks above helped in ratifying and testing the interoperability of folks above helped in ratifying and testing the interoperability of
the suggested solutions. the suggested solutions.
8. Acknowledgments 13. Acknowledgments
Special thanks to Sharad Ahlawat, Mark Allman, Steve Bellovin, Vern Special thanks to Mark Allman, Ted Faber, Steve Bellovin, Vern
Paxson, Allison Mankin, Damir Rajnovic, John Wong and the tcpm WG Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong and
members for suggestions and comments. the tcpm WG members for suggestions and comments. Some of the text
in this document has been derived from
9. References 14. References
9.1 Normative References 14.1. Normative References
[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
September 1981. RFC 793, September 1981.
[2] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Signature Option", RFC 2385, August 1998. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2 Informative References 14.2. Informative References
[3] Leech, M., "Key Management Considerations for the TCP MD5 [DTASA] Touch, J., "Defending TCP Against Spoofing Attacks",
draft-touch-tcp-antispoof-00 (work in progress),
July 2004.
[Medina05]
Medina, A., Allman, M., and S. Floyd, "Measuring the
Evolution of Transport Protocols in the Internet. ACM
Computer Communication Review, 35(2), April 2005.
http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps
(figure 6)".
[NISCC] NISCC, "NISCC Vulnerability Advisory 236929 -
Vulnerability Issues in TCP".
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003. Signature Option", RFC 3562, July 2003.
[4] Watson, P., ""Slipping in the Window: TCP Reset attacks"". [SITW] Watson, P., "Slipping in the Window: TCP Reset attacks".
Author's Address Authors' Addresses
Randall R. Stewart
Editor
4875 Forest Drive
Suite 200
Columbia, SC 29206
USA
Phone:
Email: rrs@cisco.com
Mitesh Dalal Mitesh Dalal
Editor Editor
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1-408-853-5257 Phone: +1-408-853-5257
Email: mdalal@cisco.com Email: mdalal@cisco.com
skipping to change at page 18, line 41 skipping to change at page 27, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 75 change blocks. 
298 lines changed or deleted 557 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/