draft-ietf-tcpm-icmp-attacks-05.txt   draft-ietf-tcpm-icmp-attacks-06.txt 
TCP Maintenance and Minor F. Gont TCP Maintenance and Minor F. Gont
Extensions (tcpm) UTN/FRH Extensions (tcpm) UTN/FRH
Intended status: Informational Intended status: Informational
Expires: December 6, 2009 Expires: February 25, 2010
ICMP attacks against TCP ICMP attacks against TCP
draft-ietf-tcpm-icmp-attacks-05.txt draft-ietf-tcpm-icmp-attacks-06.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 6, 2009. This Internet-Draft will expire on February 25, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 26 skipping to change at page 2, line 26
2.2. Handling of ICMP error messages . . . . . . . . . . . . . 6 2.2. Handling of ICMP error messages . . . . . . . . . . . . . 6
2.3. Handling of ICMP error messages in the context of IPsec . 7 2.3. Handling of ICMP error messages in the context of IPsec . 7
3. Constraints in the possible solutions . . . . . . . . . . . . 8 3. Constraints in the possible solutions . . . . . . . . . . . . 8
4. General counter-measures against ICMP attacks . . . . . . . . 9 4. General counter-measures against ICMP attacks . . . . . . . . 9
4.1. TCP sequence number checking . . . . . . . . . . . . . . . 9 4.1. TCP sequence number checking . . . . . . . . . . . . . . . 9
4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 10 4.2. Port randomization . . . . . . . . . . . . . . . . . . . . 10
4.3. Filtering ICMP error messages based on the ICMP payload . 10 4.3. Filtering ICMP error messages based on the ICMP payload . 10
5. Blind connection-reset attack . . . . . . . . . . . . . . . . 11 5. Blind connection-reset attack . . . . . . . . . . . . . . . . 11
5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Attack-specific counter-measures . . . . . . . . . . . . . 12 5.2. Attack-specific counter-measures . . . . . . . . . . . . . 12
6. Blind throughput-reduction attack . . . . . . . . . . . . . . 13 6. Blind throughput-reduction attack . . . . . . . . . . . . . . 15
6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Attack-specific counter-measures . . . . . . . . . . . . . 13 6.2. Attack-specific counter-measures . . . . . . . . . . . . . 15
7. Blind performance-degrading attack . . . . . . . . . . . . . . 14 7. Blind performance-degrading attack . . . . . . . . . . . . . . 15
7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Attack-specific counter-measures . . . . . . . . . . . . . 15 7.2. Attack-specific counter-measures . . . . . . . . . . . . . 17
7.3. The counter-measure for the PMTUD attack in action . . . . 19 7.3. The counter-measure for the PMTUD attack in action . . . . 20
7.3.1. Normal operation for bulk transfers . . . . . . . . . 19 7.3.1. Normal operation for bulk transfers . . . . . . . . . 21
7.3.2. Operation during Path-MTU changes . . . . . . . . . . 21 7.3.2. Operation during Path-MTU changes . . . . . . . . . . 23
7.3.3. Idle connection being attacked . . . . . . . . . . . . 22 7.3.3. Idle connection being attacked . . . . . . . . . . . . 24
7.3.4. Active connection being attacked after discovery 7.3.4. Active connection being attacked after discovery
of the Path-MTU . . . . . . . . . . . . . . . . . . . 23 of the Path-MTU . . . . . . . . . . . . . . . . . . . 24
7.3.5. TCP peer attacked when sending small packets just 7.3.5. TCP peer attacked when sending small packets just
after the three-way handshake . . . . . . . . . . . . 23 after the three-way handshake . . . . . . . . . . . . 25
7.4. Pseudo-code for the counter-measure for the blind 7.4. Pseudo-code for the counter-measure for the blind
performance-degrading attack . . . . . . . . . . . . . . . 24 performance-degrading attack . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31
10.2. Informative References . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. An analysis of ICMP hard errors . . . . . . . . . . . 32 Appendix A. Changes from previous versions of the draft (to
Appendix B. Advice and guidance to vendors . . . . . . . . . . . 33
Appendix C. Changes from previous versions of the draft (to
be removed by the RFC Editor before publishing be removed by the RFC Editor before publishing
this document as an RFC) . . . . . . . . . . . . . . 33 this document as an RFC) . . . . . . . . . . . . . . 34
C.1. Changes from draft-ietf-tcpm-icmp-attacks-04 . . . . . . . 33 A.1. Changes from draft-ietf-tcpm-icmp-attacks-05 . . . . . . . 34
C.2. Changes from draft-ietf-tcpm-icmp-attacks-03 . . . . . . . 34 A.2. Changes from draft-ietf-tcpm-icmp-attacks-04 . . . . . . . 34
C.3. Changes from draft-ietf-tcpm-icmp-attacks-02 . . . . . . . 34 A.3. Changes from draft-ietf-tcpm-icmp-attacks-03 . . . . . . . 34
C.4. Changes from draft-ietf-tcpm-icmp-attacks-01 . . . . . . . 34 A.4. Changes from draft-ietf-tcpm-icmp-attacks-02 . . . . . . . 34
C.5. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 34 A.5. Changes from draft-ietf-tcpm-icmp-attacks-01 . . . . . . . 35
C.6. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 35 A.6. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 35
C.7. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 35 A.7. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 35
C.8. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 35 A.8. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 36
C.9. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 36 A.9. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 36
C.10. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 36 A.10. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 36
C.11. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 36 A.11. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 36
A.12. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite,
and is used mainly for reporting network error conditions. However, and is used mainly for reporting network error conditions. However,
the current specifications do not recommend any kind of validation the current specifications do not recommend any kind of validation
checks on the received ICMP error messages, thus allowing variety of checks on the received ICMP error messages, thus allowing variety of
attacks against TCP [RFC0793] by means of ICMP, which include blind attacks against TCP [RFC0793] by means of ICMP, which include blind
connection-reset, blind throughput-reduction, and blind performance- connection-reset, blind throughput-reduction, and blind performance-
skipping to change at page 5, line 12 skipping to change at page 5, line 12
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Background 2. Background
2.1. The Internet Control Message Protocol (ICMP) 2.1. The Internet Control Message Protocol (ICMP)
The Internet Control Message Protocol (ICMP) is used in the Internet The Internet Control Message Protocol (ICMP) is used in the Internet
Architecture mainly to perform the fault-isolation function, that is, architecture mainly to perform the fault-isolation function, that is,
the group of actions that hosts and routers take to determine that the group of actions that hosts and routers take to determine that
there is some network failure [RFC0816]. there is some network failure [RFC0816].
When an intermediate router detects a network problem while trying to When an intermediate router detects a network problem while trying to
forward an IP packet, it will usually send an ICMP error message to forward an IP packet, it will usually send an ICMP error message to
the source system, to raise awareness of the network problem taking the source system, to raise awareness of the network problem taking
place. In the same way, there are a number of scenarios in which an place. In the same way, there are a number of scenarios in which an
end-system may generate an ICMP error message if it finds a problem end-system may generate an ICMP error message if it finds a problem
while processing a datagram. The received ICMP errors are handed to while processing a datagram. The received ICMP errors are handed to
the corresponding transport-protocol instance, which will usually the corresponding transport-protocol instance, which will usually
skipping to change at page 8, line 8 skipping to change at page 8, line 8
traffic, and that this control MUST be at the granularity of ICMP traffic, and that this control MUST be at the granularity of ICMP
type and MAY be at the granularity of ICMP type and code. type and MAY be at the granularity of ICMP type and code.
Additionally, an implementation SHOULD incorporate mechanisms and Additionally, an implementation SHOULD incorporate mechanisms and
parameters for dealing with such traffic. parameters for dealing with such traffic.
Thus, the policy to apply for the processing of unprotected ICMP Thus, the policy to apply for the processing of unprotected ICMP
error messages is left up to the implementation and administrator. error messages is left up to the implementation and administrator.
3. Constraints in the possible solutions 3. Constraints in the possible solutions
For ICMPv4, [RFC0792] states that the internet header plus the first For ICMPv4, [RFC0792] states that the IP header plus the first 64
64 bits of the packet that elicited the ICMP message are to be bits of the packet that elicited the ICMP message are to be included
included in the payload of the ICMP error message. Thus, it is in the payload of the ICMP error message. Thus, it is assumed that
assumed that all data needed to identify a transport protocol all data needed to identify a transport protocol instance and process
instance and process the ICMP error message is contained in the first the ICMP error message is contained in the first 64 bits of the
64 bits of the transport protocol header. Section 3.2.2 of [RFC1122] transport protocol header. Section 3.2.2 of [RFC1122] states that
states that "the Internet header and at least the first 8 data octets "the Internet header and at least the first 8 data octets of the
of the datagram that triggered the error" are to be included in the datagram that triggered the error" are to be included in the payload
payload of ICMP error messages, and that "more than 8 octets MAY be of ICMP error messages, and that "more than 8 octets MAY be sent",
sent", thus allowing implementations to include more data from the thus allowing implementations to include more data from the original
original packet than those required by the original ICMP packet than those required by the original ICMP specification. The
specification. The Requirements for IP Version 4 Routers RFC Requirements for IP Version 4 Routers RFC [RFC1812] states that ICMP
[RFC1812] states that ICMP error messages "SHOULD contain as much of error messages "SHOULD contain as much of the original datagram as
the original datagram as possible without the length of the ICMP possible without the length of the ICMP datagram exceeding 576
datagram exceeding 576 bytes". bytes".
Thus, for ICMP messages generated by hosts, we can only expect to get Thus, for ICMP messages generated by hosts, we can only expect to get
the entire IP header of the original packet, plus the first 64 bits the entire IP header of the original packet, plus the first 64 bits
of its payload. For TCP, this means that the only fields that will of its payload. For TCP, this means that the only fields that will
be included in the ICMP payload are: the source port number, the be included in the ICMP payload are: the source port number, the
destination port number, and the 32-bit TCP sequence number. This destination port number, and the 32-bit TCP sequence number. This
clearly imposes a constraint on the possible validation checks that clearly imposes a constraint on the possible validation checks that
can be performed, as there is not much information avalable on which can be performed, as there is not much information avalable on which
to perform them. to perform them.
skipping to change at page 9, line 14 skipping to change at page 9, line 14
Hosts could require ICMP error messages to be authenticated Hosts could require ICMP error messages to be authenticated
[RFC4301], in order to act upon them. However, while this [RFC4301], in order to act upon them. However, while this
requirement could make sense for those ICMP error messages sent by requirement could make sense for those ICMP error messages sent by
hosts, it would not be feasible for those ICMP error messages hosts, it would not be feasible for those ICMP error messages
generated by routers, as this would imply either that the attacked generated by routers, as this would imply either that the attacked
system should have a security association [RFC4301] with every system should have a security association [RFC4301] with every
existing intermediate system, or that it should be able to establish existing intermediate system, or that it should be able to establish
one dynamically. Current levels of deployment of protocols for one dynamically. Current levels of deployment of protocols for
dynamic establishment of security associations makes this unfeasible. dynamic establishment of security associations makes this unfeasible.
Also, there may be some scenarios, such as embedded devices, in which Additionally, this would require routers to use certificates with
the processing power requirements of authentication might not allow paths compatible for all hosts on the network. Finally, there may be
IPSec authentication to be implemented effectively. some scenarios, such as embedded devices, in which the processing
power requirements of authentication might not allow IPSec
authentication to be implemented effectively.
4. General counter-measures against ICMP attacks 4. General counter-measures against ICMP attacks
The following subsections describe a number of mitigation techniques The following subsections describe a number of mitigation techniques
that help to eliminate or mitigate the impact of the attacks that help to eliminate or mitigate the impact of the attacks
discussed in this document. Rather than being alternative counter- discussed in this document. Rather than being alternative counter-
measures, they can be implemented together to increase the protection measures, they can be implemented together to increase the protection
against these attacks. against these attacks.
4.1. TCP sequence number checking 4.1. TCP sequence number checking
skipping to change at page 10, line 19 skipping to change at page 10, line 21
It is important to note that while this check greatly increases the It is important to note that while this check greatly increases the
number of packets required to perform any of the attacks discussed in number of packets required to perform any of the attacks discussed in
this document, this may not be enough in those scenarios in which this document, this may not be enough in those scenarios in which
bandwidth is easily available, and/or large TCP windows [RFC1323] are bandwidth is easily available, and/or large TCP windows [RFC1323] are
in use. Additionally, this validation check does not help to prevent in use. Additionally, this validation check does not help to prevent
on-path attacks, that is, attacks performed in scenarios in which the on-path attacks, that is, attacks performed in scenarios in which the
attacker can sniff the packets that correspond to the target TCP attacker can sniff the packets that correspond to the target TCP
connection. connection.
It should be note that as there are no timeliness for ICMP error
messages, the TCP Sequence Number check described in this section
might cause legitimate ICMP error messages to be discarded.
4.2. Port randomization 4.2. Port randomization
As discussed in the previous sections, in order to perform any of the As discussed in the previous sections, in order to perform any of the
attacks described in this document, an attacker would need to guess attacks described in this document, an attacker would need to guess
(or know) the four-tuple that identifies the connection to be (or know) the four-tuple that identifies the connection to be
attacked. Increasing the port number range used for outgoing TCP attacked. Increasing the port number range used for outgoing TCP
connections, and randomizing the port number chosen for each outgoing connections, and randomizing the port number chosen for each outgoing
TCP conenctions would make it harder for an attacker to perform any TCP conenctions would make it harder for an attacker to perform any
of the attacks discussed in this document. of the attacks discussed in this document.
skipping to change at page 12, line 11 skipping to change at page 12, line 17
Some stacks are known to extrapolate ICMP hard errors across TCP Some stacks are known to extrapolate ICMP hard errors across TCP
connections, increasing the impact of this attack, as a single ICMP connections, increasing the impact of this attack, as a single ICMP
packet could bring down all the TCP connections between the packet could bring down all the TCP connections between the
corresponding peers. corresponding peers.
It is important to note that even if TCP itself were protected It is important to note that even if TCP itself were protected
against the blind connection-reset attack described in [Watson] and against the blind connection-reset attack described in [Watson] and
[I-D.ietf-tcpm-tcpsecure], by means authentication at the network [I-D.ietf-tcpm-tcpsecure], by means authentication at the network
layer [RFC4301], by means of the TCP MD5 signature option [RFC2385], layer [RFC4301], by means of the TCP MD5 signature option [RFC2385],
or by means of the mechanism proposed in [I-D.ietf-tcpm-tcpsecure], by means of the TCP-AO [I-D.ietf-tcpm-tcp-auth-opt], or by means of
the blind connection-reset attack described in this document would the mechanism proposed in [I-D.ietf-tcpm-tcpsecure], the blind
still succeed. connection-reset attack described in this document would still
succeed.
5.2. Attack-specific counter-measures 5.2. Attack-specific counter-measures
This section describes a modification to TCP's reaction to ICMP hard An analysis of the circumstances in which ICMP messages that indicate
errors that has been incorporated in a large number of TCP hard errors may be received can shed some light to mitigate the
implementations. An analysis of each of the different ICMP "hard impact of ICMP-based blind connection-reset attacks.
error" messages is included in Appendix A.
TCPs implementing this modification treat all ICMP "hard errors" ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable)
received for connections in any of the synchronized states
(ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK This ICMP error message indicates that the host sending the ICMP
or TIME-WAIT)as "soft errors". Therefore, they do not abort the error message received a packet meant for a transport protocol it
corresponding connection upon receipt of them. Additionally, they do does not support. For connection-oriented protocols such as TCP,
not extrapolate ICMP errors across TCP connections. This policy is one could expect to receive such an error as the result of a
based on the premise that TCP should be as robust as possible. connection-establishment attempt. However, it would be strange to
Aborting the connection would be to ignore the valuable feature of get such an error during the life of a connection, as this would
the Internet that for many internal failures it reconstructs its indicate that support for that transport protocol has been removed
function without any disruption of the end points [RFC0816]. from the system sending the error message during the life of the
corresponding connection.
ICMP type 3 (Destination Unreachable), code 3 (port unreachable)
This error message indicates that the system sending the ICMP
error message received a packet meant for a socket (IP address,
port number) on which there is no process listening. Those
transport protocols which have their own mechanisms for notifying
this condition should not be receiving these error messages, as
the protocol would signal the port unreachable condition by means
of its own messages. Assuming that once a connection is
established it is not usual for the transport protocol to change
(or be reloaded), it should be unusual to get these error
messages.
ICMP type 3 (Destination Unreachable), code 4 (fragmentation needed
and DF bit set)
This error message indicates that an intermediate node needed to
fragment a datagram, but the DF (Don't Fragment) bit in the IP
header was set. It is considered a soft error when TCP implements
PMTUD, and a hard error if TCP does not implement PMTUD. Those
TCP/IP stacks that do not implement PMTUD (or have disabled it)
but support IP fragmentation/reassembly should not be sending
their IP packets with the DF bit set, and thus should not be
receiving these ICMP error messages. Some TCP/IP stacks that do
not implement PMTUD and that do not support IP fragmentation/
reassembly are known to send their packets with the DF bit set,
and thus could legitimately receive these ICMP error messages.
ICMPv6 type 1 (Destination Unreachable), code 1 (communication with
destination administratively prohibited)
This error message indicates that the destination is unreachable
because of an administrative policy. For connection-oriented
protocols such as TCP, one could expect to receive such an error
as the result of a connection-establishment attempt. Receiving
such an error for a connection in any of the synchronized states
would mean that the administrative policy changed during the life
of the connection. However, in the same way this error condition
(which was not present when the conenction was established)
appeared, it could get solved solved in the near term.
ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable)
This error message is analogous to the ICMP type 3 (Destination
Unreachable), code 3 (Port unreachable) error message discussed
above. Therefore, the same considerations apply.
The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that
TCP SHOULD abort the corresponding connection in response to ICMP
messages of type 3, codes 2 (protocol unreachable), 3 (port
unreachable), and 4 (fragmentation needed and DF bit set). However,
Section 3.2.2.1 states that TCP MUST accept an ICMP port unreachable
(type 3, code 3) for the same purpose as an RST. Therefore, for ICMP
messages of type 3 codes 2 and 4 there is room to go against the
advice provided in the existing specifications, while in the case of
ICMP messages of type 3 code 3 there is ambiguity in the
specifications that may or may not provide some room to go against
that advice.
Based on this analysis, most popular TCP implementations treat all
ICMP "hard errors" received for connections in any of the
synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
CLOSING, LAST-ACK or TIME-WAIT)as "soft errors". That is, they do
not abort the corresponding connection upon receipt of them.
Additionally, they do not extrapolate ICMP errors across TCP
connections. This policy is based on the premise that TCP should be
as robust as possible. Aborting the connection would be to ignore
the valuable feature of the Internet that for many internal failures
it reconstructs its function without any disruption of the end points
[RFC0816].
It is interesting to note that, as ICMP error messages are It is interesting to note that, as ICMP error messages are
unreliable, transport protocols should not depend on them for correct unreliable, transport protocols should not depend on them for correct
functioning. In the event one of these messages were legitimate, the functioning. In the event one of these messages were legitimate, the
corresponding connection would eventually time out. Also, corresponding connection would eventually time out. Also,
applications may still be notified asynchronously about the error applications may still be notified asynchronously about the error
contition, and thus may still abort their connections on their own if contition, and thus may still abort their connections on their own if
they consider it appropriate. they consider it appropriate.
In scenarios such as that in which an intermediate system sets the DF In scenarios such as that in which an intermediate system sets the DF
bit in the segments transmitted by a TCP that does not implement bit in the segments transmitted by a TCP that does not implement
PMTUD, or the TCP at one of the endpoints of the connection is PMTUD, or the TCP at one of the endpoints of the connection is
dynamically disabled, TCP would only abort the connection after a dynamically disabled, TCP would only abort the connection after a
USER TIMEOUT [RFC0793], losing responsiveness. However, these USER TIMEOUT [RFC0793], losing responsiveness. However, these
scenarios are very unlikely in production environments, and it is scenarios are very unlikely in production environments, and it is
probably preferebable to potentially lose responsiveness for the sake probably preferable to potentially lose responsiveness for the sake
of robustness. It should also be noted that applications may still of robustness. It should also be noted that applications may still
be notified asynchronously about the error condition, and thus may be notified asynchronously about the error condition, and thus may
still abort their connections on their own if they consider it still abort their connections on their own if they consider it
appropriate. appropriate.
In scenarios of multipath routing or route changes, failures in some In scenarios of multipath routing or route changes, failures in some
(but not all) of the paths may elicit ICMP error messages that would (but not all) of the paths may elicit ICMP error messages that would
likely not cause a connection abort if any of the counter-measures likely not cause a connection abort if any of the counter-measures
described in this section were implemented. However, aborting the described in this section were implemented. However, aborting the
connection would be to ignore the valuable feature of the Internet connection would be to ignore the valuable feature of the Internet
skipping to change at page 13, line 47 skipping to change at page 15, line 30
bytes per RTT (round-trip time). The throughput achieved during an bytes per RTT (round-trip time). The throughput achieved during an
attack might be a little higher if a larger initial congestion window attack might be a little higher if a larger initial congestion window
is in use [RFC3390]. is in use [RFC3390].
6.2. Attack-specific counter-measures 6.2. Attack-specific counter-measures
As discussed in the Requirements for IP Version 4 Routers RFC As discussed in the Requirements for IP Version 4 Routers RFC
[RFC1812], research seems to suggest that ICMP Source Quench is an [RFC1812], research seems to suggest that ICMP Source Quench is an
ineffective (and unfair) antidote for congestion. [RFC1812] further ineffective (and unfair) antidote for congestion. [RFC1812] further
states that routers SHOULD NOT send ICMP Source Quench messages in states that routers SHOULD NOT send ICMP Source Quench messages in
response to congestion. On the other hand, TCP implements its own response to congestion. Furthermore, TCP implements its own
congestion control mechanisms [RFC2581] [RFC3168], that do not depend congestion control mechanisms [RFC2581] [RFC3168], that do not depend
on ICMP Source Quench messages. on ICMP Source Quench messages.
Based on this reasoning, a large number of implementations completely Based on this reasoning, a large number of implementations completely
ignore ICMP Source Quench messages meant for TCP connections. This ignore ICMP Source Quench messages meant for TCP connections. This
behavior has been implemented in, at least, Linux [Linux] since 2004, behavior has been implemented in, at least, Linux [Linux] since 2004,
and in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD] and in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD]
since 2005. However, it must be noted that this behaviour violates since 2005. However, it must be noted that this behaviour violates
the requirement in [RFC1122] to react to ICMP Source Quench messages the requirement in [RFC1122] to react to ICMP Source Quench messages
by slowing transmission on the connection. by slowing transmission on the connection.
skipping to change at page 15, line 42 skipping to change at page 17, line 24
unpredictable results. unpredictable results.
For IPv4, the reported Next-Hop MTU could be as low as 68 octets, as For IPv4, the reported Next-Hop MTU could be as low as 68 octets, as
[RFC0791] requires every internet module to be able to forward a [RFC0791] requires every internet module to be able to forward a
datagram of 68 octets without further fragmentation. For IPv6, the datagram of 68 octets without further fragmentation. For IPv6, the
reported Next-Hop MTU could be as low as 1280 octets (the minimum reported Next-Hop MTU could be as low as 1280 octets (the minimum
IPv6 MTU) [RFC2460]. IPv6 MTU) [RFC2460].
7.2. Attack-specific counter-measures 7.2. Attack-specific counter-measures
The IETF has standardized a Path-MTU Discuvery mechanism called
"Packetization Layer Path MTU Discovery" that does not depend on ICMP
error messages. Implementation of the aforementioned mechanism in
replacement of the traditional PMTUD (specified in [RFC1191] and
[RFC1981]) would eliminate this vulnerability. However, it might
also lead to an increase of the PMTUD convergence time.
This section describes a modification to the PMTUD mechanism This section describes a modification to the PMTUD mechanism
specified in [RFC1191] and [RFC1981] that has been implemented in a specified in [RFC1191] and [RFC1981] that has been implemented in a
variety of TCP implementations to improve TCP's resistance to the variety of TCP implementations to improve TCP's resistance to the
blind performance-degrading attack described in Section 7.1. The blind performance-degrading attack described in Section 7.1. The
described mechanism basically disregards ICMP messages when a described mechanism basically disregards ICMP messages when a
connection makes progress. This modification does not violate any of connection makes progress. This modification does not violate any of
the requirements stated in [RFC1191] and [RFC1981]. the requirements stated in [RFC1191] and [RFC1981].
Henceforth, we will refer to both ICMP "fragmentation needed and DF Henceforth, we will refer to both ICMP "fragmentation needed and DF
bit set" and ICMPv6 "Packet Too Big" messages as "ICMP Packet Too bit set" and ICMPv6 "Packet Too Big" messages as "ICMP Packet Too
skipping to change at page 28, line 19 skipping to change at page 30, line 19
widely-implemented counter-measures that either eliminate or reduce widely-implemented counter-measures that either eliminate or reduce
the impact of these attacks when they are performed by off-path the impact of these attacks when they are performed by off-path
attackers. attackers.
9. Acknowledgements 9. Acknowledgements
This document was inspired by Mika Liljeberg, while discussing some This document was inspired by Mika Liljeberg, while discussing some
issues related to [I-D.ietf-tcpm-tcp-soft-errors] by private e-mail. issues related to [I-D.ietf-tcpm-tcp-soft-errors] by private e-mail.
The author would like to thank (in alphabetical order): Bora Akyol, The author would like to thank (in alphabetical order): Bora Akyol,
Mark Allman, Ran Atkinson, James Carlson, Alan Cox, Theo de Raadt, Mark Allman, Ran Atkinson, James Carlson, Alan Cox, Theo de Raadt,
Ted Faber, Juan Fraschini, Markus Friedl, Guillermo Gont, John Wesley Eddy, Ted Faber, Juan Fraschini, Markus Friedl, Guillermo
Heffner, Alfred Hoenes, Vivek Kakkar, Michael Kerrisk, Mika Gont, John Heffner, Alfred Hoenes, Vivek Kakkar, Michael Kerrisk,
Liljeberg, Matt Mathis, David Miller, Miles Nordin, Eloy Paris, Mika Liljeberg, Matt Mathis, David Miller, Miles Nordin, Eloy Paris,
Kacheong Poon, Andrew Powell, Pekka Savola, Pyda Srisuresh, Fred Kacheong Poon, Andrew Powell, Pekka Savola, Pyda Srisuresh, Fred
Templin, and Joe Touch for contributing many valuable comments. Templin, and Joe Touch for contributing many valuable comments.
Juan Fraschini and the author of this document implemented freely- Juan Fraschini and the author of this document implemented freely-
available audit tools to help vendors audit their systems by available audit tools to help vendors audit their systems by
reproducing the attacks discussed in this document. This tools are reproducing the attacks discussed in this document. This tools are
available at http://www.gont.com.ar/tools/index.html . available at http://www.gont.com.ar/tools/index.html .
Markus Friedl, Chad Loder, and the author of this document, produced Markus Friedl, Chad Loder, and the author of this document, produced
and tested in OpenBSD [OpenBSD] the first implementation of the and tested in OpenBSD [OpenBSD] the first implementation of the
counter-measure described in Section 7.2. This first implementation counter-measure described in Section 7.2. This first implementation
helped to test the effectiveness of the ideas introduced in this helped to test the effectiveness of the ideas introduced in this
document, and has served as a reference implementation for other document, and has served as a reference implementation for other
operating systems. operating systems.
The author would like to thank the UK's National Infrastructure The author would like to thank the UK's Centre for the Protection of
Security Co-ordination Centre (NISCC) for coordinating the disclosure National Infrastructure (CPNI) -- formerly National Infrastructure
of these issues with a large number of vendors and CSIRTs (Computer Security Co-ordination Centre (NISCC) -- for coordinating the
Security Incident Response Teams). disclosure of these issues with a large number of vendors and CSIRTs
(Computer Security Incident Response Teams).
The author wishes to express deep and heartfelt gratitude to Jorge The author wishes to express deep and heartfelt gratitude to Jorge
Oscar Gont and Nelida Garcia, for their precious motivation and Oscar Gont and Nelida Garcia, for their precious motivation and
guidance. guidance.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
skipping to change at page 29, line 49 skipping to change at page 31, line 49
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
10.2. Informative References 10.2. Informative References
[DClark] Clark, D., "The Design Philosophy of the DARPA Internet [DClark] Clark, D., "The Design Philosophy of the DARPA Internet
Protocols", Computer Communication Review Vol. 18, No. 4, Protocols", Computer Communication Review Vol. 18, No. 4,
1988. 1988.
[FreeBSD] The FreeBSD Project, "http://www.freebsd.org". [FreeBSD] The FreeBSD Project, "http://www.freebsd.org".
[I-D.ietf-tcpm-tcp-auth-opt]
Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", draft-ietf-tcpm-tcp-auth-opt-05
(work in progress), July 2009.
[I-D.ietf-tcpm-tcp-soft-errors] [I-D.ietf-tcpm-tcp-soft-errors]
Gont, F., "TCP's Reaction to Soft Errors", Gont, F., "TCP's Reaction to Soft Errors",
draft-ietf-tcpm-tcp-soft-errors-09 (work in progress), draft-ietf-tcpm-tcp-soft-errors-09 (work in progress),
November 2008. November 2008.
[I-D.ietf-tcpm-tcpsecure] [I-D.ietf-tcpm-tcpsecure]
Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", Robustness to Blind In-Window Attacks",
draft-ietf-tcpm-tcpsecure-11 (work in progress), draft-ietf-tcpm-tcpsecure-11 (work in progress),
November 2008. November 2008.
[I-D.ietf-tsvwg-port-randomization] [I-D.ietf-tsvwg-port-randomization]
Larsen, M. and F. Gont, "Port Randomization", Larsen, M. and F. Gont, "Port Randomization",
draft-ietf-tsvwg-port-randomization-03 (work in progress), draft-ietf-tsvwg-port-randomization-04 (work in progress),
March 2009. July 2009.
[ICMP-Filtering] [ICMP-Filtering]
Gont, F., "Filtering of ICMP error messages", http:// Gont, F., "Filtering of ICMP error messages", http://
www.gont.com.ar/papers/ www.gont.com.ar/papers/
filtering-of-icmp-error-messages.pdf. filtering-of-icmp-error-messages.pdf.
[IP-filtering] [IP-filtering]
NISCC, "NISCC Technical Note 01/2006: Egress and Ingress NISCC, "NISCC Technical Note 01/2006: Egress and Ingress
Filtering", http://www.niscc.gov.uk/niscc/docs/ Filtering", http://www.niscc.gov.uk/niscc/docs/
re-20060420-00294.pdf?lang=en, 2006. re-20060420-00294.pdf?lang=en, 2006.
skipping to change at page 32, line 5 skipping to change at page 34, line 8
[US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP [US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP
Implementations do not adequately validate ICMP error Implementations do not adequately validate ICMP error
messages", http://www.kb.cert.org/vuls/id/222750, 2005. messages", http://www.kb.cert.org/vuls/id/222750, 2005.
[Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", [Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks",
2004 CanSecWest Conference , 2004. 2004 CanSecWest Conference , 2004.
[Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: [Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
The Implementation", Addison-Wesley , 1994. The Implementation", Addison-Wesley , 1994.
Appendix A. An analysis of ICMP hard errors Appendix A. Changes from previous versions of the draft (to be removed
by the RFC Editor before publishing this document as an
This appendix contains an analysis of ICMP hard errors. RFC)
ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable)
This ICMP error message indicates that the host sending the ICMP
error message received a packet meant for a transport protocol it
does not support. For connection-oriented protocols such as TCP,
one could expect to receive such an error as the result of a
connection-establishment attempt. However, it would be strange to
get such an error during the life of a connection, as this would
indicate that support for that transport protocol has been removed
from the system sending the error message during the life of the
corresponding connection.
ICMP type 3 (Destination Unreachable), code 3 (port unreachable)
This error message indicates that the system sending the ICMP
error message received a packet meant for a socket (IP address,
port number) on which there is no process listening. Those
transport protocols which have their own mechanisms for notifying
this condition should not be receiving these error messages, as
the protocol would signal the port unreachable condition by means
of its own messages. Assuming that once a connection is
established it is not usual for the transport protocol to change
(or be reloaded), it should be unusual to get these error
messages.
ICMP type 3 (Destination Unreachable), code 4 (fragmentation needed
and DF bit set)
This error message indicates that an intermediate node needed to
fragment a datagram, but the DF (Don't Fragment) bit in the IP
header was set. It is considered a soft error when TCP implements
PMTUD, and a hard error if TCP does not implement PMTUD. Those
TCPs that do not implement the PMTUD mechanism should not be
sending their IP packets with the DF bit set, and thus should not
be receiving these ICMP error messages.
ICMPv6 type 1 (Destination Unreachable), code 1 (communication with
destination administratively prohibited)
This error message indicates that the destination is unreachable
because of an administrative policy. For connection-oriented
protocols such as TCP, one could expect to receive such an error
as the result of a connection-establishment attempt. Receiving
such an error for a connection in any of the synchronized states
would mean that the administrative policy changed during the life
of the connection. However, in the same way this error condition
(which was not present when the conenction was established)
appeared, it could get solved solved in the near term.
ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable)
This error message is analogous to the ICMP type 3 (Destination
Unreachable), code 3 (Port unreachable) error message discussed
above. Therefore, the same considerations apply.
The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that
TCP SHOULD abort the corresponding connection in response to ICMP
messages of type 3, codes 2 (protocol unreachable), 3 (port
unreachable), and 4 (fragmentation needed and DF bit set). However,
Section 3.2.2.1 states that TCP MUST accept an ICMP port unreachable
(type 3, code 3) for the same purpose as an RST. Therefore, for ICMP
messages of type 3 codes 2 and 4 there is room to go against the
advice provided in the existing specifications, while in the case of
ICMP messages of type 3 code 3 there is ambiguity in the
specifications that may or may not provide some room to go against
that advice.
Appendix B. Advice and guidance to vendors
Vendors are urged to contact CPNI (vulteam@cpni.gsi.gov.uk) if they
think they may be affected by the issues described in this document.
As the lead coordination center for these issues, CPNI is well placed
to give advice and guidance as required.
CPNI works extensively with government departments and agencies, A.1. Changes from draft-ietf-tcpm-icmp-attacks-05
commercial organizations and the academic community to research
vulnerabilities and potential threats to IT systems especially where
they may have an impact on Critical National Infrastructure's (CNI).
Other ways to contact CPNI, plus CPNI's PGP public key, are available o Addresses feedback submitted by Wes Eddy
at http://www.cpni.gov.uk . (http://www.ietf.org/mail-archive/web/tcpm/current/msg04573.html
and
http://www.ietf.org/mail-archive/web/tcpm/current/msg04574.html)
and Joe Touch (on June 8th... couldn't find online ref, sorry) on
the TCPM WG mailing-list.
Appendix C. Changes from previous versions of the draft (to be removed A.2. Changes from draft-ietf-tcpm-icmp-attacks-04
by the RFC Editor before publishing this document as an
RFC)
C.1. Changes from draft-ietf-tcpm-icmp-attacks-04
o The draft had expired and thus is resubmitted with no further o The draft had expired and thus is resubmitted with no further
changes. Currently working on a rev of the document (Please send changes. Currently working on a rev of the document (Please send
feedback!). feedback!).
C.2. Changes from draft-ietf-tcpm-icmp-attacks-03 A.3. Changes from draft-ietf-tcpm-icmp-attacks-03
o The draft had expired and thus is resubmitted with no further o The draft had expired and thus is resubmitted with no further
changes. changes.
C.3. Changes from draft-ietf-tcpm-icmp-attacks-02 A.4. Changes from draft-ietf-tcpm-icmp-attacks-02
o Added a disclaimer to indicate that this document does not update o Added a disclaimer to indicate that this document does not update
the current specifications. the current specifications.
o Addresses feedback sent off-list by Alfred Hoenes. o Addresses feedback sent off-list by Alfred Hoenes.
o The text (particulary that which describes the counter-measures) o The text (particulary that which describes the counter-measures)
was reworded to document what current implementations are doing, was reworded to document what current implementations are doing,
rather than "proposing" the implementation of the counter- rather than "proposing" the implementation of the counter-
measures. measures.
o Some text has been removed: we're just documenting the problem, o Some text has been removed: we're just documenting the problem,
and what existing implementations have done. and what existing implementations have done.
o Miscelaneous editorial changes. o Miscelaneous editorial changes.
C.4. Changes from draft-ietf-tcpm-icmp-attacks-01 A.5. Changes from draft-ietf-tcpm-icmp-attacks-01
o Fixed references to the antispoof documents (were hardcoded and o Fixed references to the antispoof documents (were hardcoded and
missing in the References Section). missing in the References Section).
o The draft had expired and thus is resubmitted with only a minor o The draft had expired and thus is resubmitted with only a minor
editorial change. editorial change.
C.5. Changes from draft-ietf-tcpm-icmp-attacks-00 A.6. Changes from draft-ietf-tcpm-icmp-attacks-00
o Added references to the specific sections of each of the o Added references to the specific sections of each of the
referenced specifications referenced specifications
o Corrected the threat analysys o Corrected the threat analysys
o Added clarification about whether the counter-measures violate the o Added clarification about whether the counter-measures violate the
current specifications or not. current specifications or not.
o Changed text so that the document fits better in the Informational o Changed text so that the document fits better in the Informational
skipping to change at page 35, line 17 skipping to change at page 35, line 39
based on the ICMP payload based on the ICMP payload
o Updated references to obsoleted RFCs o Updated references to obsoleted RFCs
o Added a discussion of multipath scenarios, and possible lose in o Added a discussion of multipath scenarios, and possible lose in
responsiveness resulting from the reaction to hard errors as soft responsiveness resulting from the reaction to hard errors as soft
errors errors
o Miscellaneous editorial changes o Miscellaneous editorial changes
C.6. Changes from draft-gont-tcpm-icmp-attacks-05 A.7. Changes from draft-gont-tcpm-icmp-attacks-05
o Removed RFC 2119 wording to make the draft suitable for o Removed RFC 2119 wording to make the draft suitable for
publication as an Informational RFC. publication as an Informational RFC.
o Added additional checks that should be performed on ICMP error o Added additional checks that should be performed on ICMP error
messages (checksum of the IP header in the ICMP payload, and messages (checksum of the IP header in the ICMP payload, and
others). others).
o Added clarification of the rationale behind each the TCP SEQ check o Added clarification of the rationale behind each the TCP SEQ check
o Miscellaneous editorial changes o Miscellaneous editorial changes
C.7. Changes from draft-gont-tcpm-icmp-attacks-04 A.8. Changes from draft-gont-tcpm-icmp-attacks-04
o Added section on additional considerations for validating ICMP o Added section on additional considerations for validating ICMP
error messages error messages
o Added reference to (draft) [RFC4907] o Added reference to (draft) [RFC4907]
o Added stress on the fact that ICMP error messages are unreliable o Added stress on the fact that ICMP error messages are unreliable
o Miscellaneous editorial changes o Miscellaneous editorial changes
C.8. Changes from draft-gont-tcpm-icmp-attacks-03 A.9. Changes from draft-gont-tcpm-icmp-attacks-03
o Added references to existing implementations of the proposed o Added references to existing implementations of the proposed
counter-measures counter-measures
o The discussion in Section 4 was improved o The discussion in Section 4 was improved
o The discussion of the blind connection-reset vulnerability was o The discussion of the blind connection-reset vulnerability was
expanded and improved expanded and improved
o The proposed counter-measure for the attack against the PMTUD was o The proposed counter-measure for the attack against the PMTUD was
improved and simplified improved and simplified
o Section 7.4 was added o Section 7.4 was added
o Miscellaneous editorial changes o Miscellaneous editorial changes
C.9. Changes from draft-gont-tcpm-icmp-attacks-02 A.10. Changes from draft-gont-tcpm-icmp-attacks-02
o Fixed errors in in the discussion of the blind connection-reset o Fixed errors in in the discussion of the blind connection-reset
attack attack
o The proposed counter-measure for the attack against the PMTUD o The proposed counter-measure for the attack against the PMTUD
mechanism was refined to allow quick discovery of the Path-MTU mechanism was refined to allow quick discovery of the Path-MTU
o Section 7.3 was added so as to clarify the operation of the o Section 7.3 was added so as to clarify the operation of the
counter-measure for the attack against the PMTUD mechanism counter-measure for the attack against the PMTUD mechanism
o Added Appendix B o Added CPNI contact information.
o Miscellaneous editorial changes o Miscellaneous editorial changes
C.10. Changes from draft-gont-tcpm-icmp-attacks-01 A.11. Changes from draft-gont-tcpm-icmp-attacks-01
o The document was restructured for easier reading o The document was restructured for easier reading
o A discussion of ICMPv6 was added in several sections of the o A discussion of ICMPv6 was added in several sections of the
document document
o Added Section on Acknowledgement number checking o Added Section on Acknowledgement number checking
o Added Section 4.3 o Added Section 4.3
o Added Section 7 o Added Section 7
o Fixed typo in the ICMP types, in several places o Fixed typo in the ICMP types, in several places
skipping to change at page 36, line 45 skipping to change at page 37, line 19
o Added Section 4.3 o Added Section 4.3
o Added Section 7 o Added Section 7
o Fixed typo in the ICMP types, in several places o Fixed typo in the ICMP types, in several places
o Fixed typo in the TCP sequence number check formula o Fixed typo in the TCP sequence number check formula
o Miscellaneous editorial changes o Miscellaneous editorial changes
C.11. Changes from draft-gont-tcpm-icmp-attacks-00 A.12. Changes from draft-gont-tcpm-icmp-attacks-00
o Added a proposal to change the handling of the so-called ICMP hard o Added a proposal to change the handling of the so-called ICMP hard
errors during the synchronized states errors during the synchronized states
o Added a summary of the relevant RFCs in several sections o Added a summary of the relevant RFCs in several sections
o Miscellaneous editorial changes o Miscellaneous editorial changes
Author's Address Author's Address
Fernando Gont Fernando Gont
Universidad Tecnologica Nacional / Facultad Regional Haedo Universidad Tecnologica Nacional / Facultad Regional Haedo
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
 End of changes. 41 change blocks. 
182 lines changed or deleted 197 lines changed or added

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