draft-ietf-tcpm-icmp-attacks-01.txt   draft-ietf-tcpm-icmp-attacks-02.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: April 26, 2007 Expires: November 5, 2007
ICMP attacks against TCP ICMP attacks against TCP
draft-ietf-tcpm-icmp-attacks-01.txt draft-ietf-tcpm-icmp-attacks-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 April 26, 2007. This Internet-Draft will expire on November 5, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document discusses the use of the Internet Control Message This document discusses the use of the Internet Control Message
Protocol (ICMP) to perform a variety of attacks against the Protocol (ICMP) to perform a variety of attacks against the
Transmission Control Protocol (TCP) and other similar protocols. It Transmission Control Protocol (TCP) and other similar protocols. It
proposes several counter-measures to eliminate or minimize the impact proposes several counter-measures to eliminate or minimize the impact
of these attacks. of these attacks.
Table of Contents Table of Contents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
6.2. Attack-specific counter-measures . . . . . . . . . . . . . 17 6.2. Attack-specific counter-measures . . . . . . . . . . . . . 17
7. Blind performance-degrading attack . . . . . . . . . . . . . . 17 7. Blind performance-degrading attack . . . . . . . . . . . . . . 17
7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Attack-specific counter-measures . . . . . . . . . . . . . 19 7.2. Attack-specific counter-measures . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. The counter-measure for the PMTUD attack in action . 26 Appendix A. The counter-measure for the PMTUD attack in action . 26
A.1. Normal operation for bulk transfers . . . . . . . . . . . 26 A.1. Normal operation for bulk transfers . . . . . . . . . . . 27
A.2. Operation during Path-MTU changes . . . . . . . . . . . . 28 A.2. Operation during Path-MTU changes . . . . . . . . . . . . 28
A.3. Idle connection being attacked . . . . . . . . . . . . . . 29 A.3. Idle connection being attacked . . . . . . . . . . . . . . 29
A.4. Active connection being attacked after discovery of A.4. Active connection being attacked after discovery of
the Path-MTU . . . . . . . . . . . . . . . . . . . . . . . 30 the Path-MTU . . . . . . . . . . . . . . . . . . . . . . . 30
A.5. TCP peer attacked when sending small packets just A.5. TCP peer attacked when sending small packets just
after the three-way handshake . . . . . . . . . . . . . . 30 after the three-way handshake . . . . . . . . . . . . . . 31
Appendix B. Pseudo-code for the counter-measure for the blind Appendix B. Pseudo-code for the counter-measure for the blind
performance-degrading attack . . . . . . . . . . . . 31 performance-degrading attack . . . . . . . . . . . . 32
Appendix C. Additional considerations for the validation of Appendix C. Additional considerations for the validation of
ICMP error messages . . . . . . . . . . . . . . . . . 35 ICMP error messages . . . . . . . . . . . . . . . . . 35
Appendix D. Advice and guidance to vendors . . . . . . . . . . . 35 Appendix D. Advice and guidance to vendors . . . . . . . . . . . 36
Appendix E. Changes from previous versions of the draft . . . . . 36 Appendix E. Changes from previous versions of the draft (to
E.1. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 36 be removed by the RFC Editor before publishing
this document as an RFC) . . . . . . . . . . . . . . 36
E.1. Changes from draft-ietf-tcpm-icmp-attacks-01 . . . . . . . 36
E.2. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 36 E.2. Changes from draft-ietf-tcpm-icmp-attacks-00 . . . . . . . 36
E.3. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 36 E.3. Changes from draft-gont-tcpm-icmp-attacks-05 . . . . . . . 37
E.4. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 37 E.4. Changes from draft-gont-tcpm-icmp-attacks-04 . . . . . . . 37
E.5. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 37 E.5. Changes from draft-gont-tcpm-icmp-attacks-03 . . . . . . . 37
E.6. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 37 E.6. Changes from draft-gont-tcpm-icmp-attacks-02 . . . . . . . 38
E.7. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 38 E.7. Changes from draft-gont-tcpm-icmp-attacks-01 . . . . . . . 38
E.8. Changes from draft-gont-tcpm-icmp-attacks-00 . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . . . . 40
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-
degrading attacks. All of these attacks can be performed even being degrading attacks. All of these attacks can be performed even being
skipping to change at page 7, line 4 skipping to change at page 7, line 4
instance, and the corresponding action will be performed. instance, and the corresponding action will be performed.
Therefore, in the case of TCP, an attacker could send a forged ICMP Therefore, in the case of TCP, an attacker could send a forged ICMP
message to the attacked system, and, as long as he is able to guess message to the attacked system, and, as long as he is able to guess
the four-tuple (i.e., Source IP Address, Source TCP port, Destination the four-tuple (i.e., Source IP Address, Source TCP port, Destination
IP Address, and Destination TCP port) that identifies the IP Address, and Destination TCP port) that identifies the
communication instance to be attacked, he will be able to use ICMP to communication instance to be attacked, he will be able to use ICMP to
perform a variety of attacks. perform a variety of attacks.
Generally, the four-tuple required to perform these attacks is not Generally, the four-tuple required to perform these attacks is not
known. However, as discussed in [Watson] and [Touch-antispoof], known. However, as discussed in [Watson] and
there are a number of scenarios (notably that of TCP connections [I-D.ietf-tcpm-tcp-antispoof], there are a number of scenarios
established between two BGP routers), in which an attacker may be (notably that of TCP connections established between two BGP routers
able to know or guess the four-tuple that identifies a TCP [RFC4271]), in which an attacker may be able to know or guess the
connection. In such a case, if we assume the attacker knows the two four-tuple that identifies a TCP connection. In such a case, if we
systems involved in the TCP connection to be attacked, both the assume the attacker knows the two systems involved in the TCP
client-side and the server-side IP addresses could be known or be connection to be attacked, both the client-side and the server-side
within a reasonable number of possibilities. Furthermore, as most IP addresses could be known or be within a reasonable number of
Internet services use the so-called "well-known" ports, only the possibilities. Furthermore, as most Internet services use the so-
client port number might need to be guessed. In such a scenario, an called "well-known" ports, only the client port number might need to
attacker would need to send, in principle, at most 65536 packets to be guessed. In such a scenario, an attacker would need to send, in
perform any of the attacks described in this document. However, as principle, at most 65536 packets to perform any of the attacks
most systems choose the port numbers they use for outgoing described in this document. However, as most systems choose the port
connections from a subset of the whole port number space, the amount numbers they use for outgoing connections from a subset of the whole
of packets needed to successfully perform any of the attacks port number space, the amount of packets needed to successfully
discussed in this document could be further reduced. perform any of the attacks discussed in this document could be
further reduced.
It is clear that TCP should be more cautious when processing received It is clear that TCP should be more cautious when processing received
ICMP error messages, in order to mitigate or eliminate the impact of ICMP error messages, in order to mitigate or eliminate the impact of
the attacks described in this document [I-D.iab-link-indications]. the attacks described in this document [I-D.iab-link-indications].
2.3. Handling of ICMP error messages in the context of IPSec 2.3. Handling of ICMP error messages in the context of IPSec
Section 5.2 of [RFC4301] describes the processing inbound IP Traffic Section 5.2 of [RFC4301] describes the processing inbound IP Traffic
in the case of "unprotected-to-protected". In the case of ICMP, when in the case of "unprotected-to-protected". In the case of ICMP, when
an unprotected ICMP error message is received, it is matched to the an unprotected ICMP error message is received, it is matched to the
skipping to change at page 10, line 27 skipping to change at page 10, line 27
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. Therefore, implementation of the attack-specific counter- in use. Therefore, implementation of the attack-specific counter-
measures discussed in this document is strongly recommended. measures discussed in this document is strongly recommended.
A TCP that implements the TCP sequence number checking as the only A TCP that implements the TCP sequence number checking as the only
validation of ICMP error messages will have the same susceptibility validation of ICMP error messages will have the same susceptibility
to attacks as the one TCP currently has in the case of TCP-based to attacks as the one TCP currently has in the case of TCP-based
attacks. Further information on this issue can be found in [Touch- attacks. Further information on this issue can be found in
antispoof]. [I-D.ietf-tcpm-tcp-antispoof].
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 24, line 17 skipping to change at page 24, line 17
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.iab-link-indications] [I-D.iab-link-indications]
Aboba, B., "Architectural Implications of Link Aboba, B., "Architectural Implications of Link
Indications", draft-iab-link-indications-05 (work in Indications", draft-iab-link-indications-10 (work in
progress), July 2006. progress), March 2007.
[I-D.ietf-pmtud-method] [I-D.ietf-pmtud-method]
Mathis, M. and J. Heffner, "Packetization Layer Path MTU Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", draft-ietf-pmtud-method-10 (work in progress), Discovery", draft-ietf-pmtud-method-11 (work in progress),
September 2006. December 2006.
[I-D.ietf-tcpm-tcp-antispoof]
Touch, J., "Defending TCP Against Spoofing Attacks",
draft-ietf-tcpm-tcp-antispoof-06 (work in progress),
February 2007.
[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-02 (work in progress), draft-ietf-tcpm-tcp-soft-errors-05 (work in progress),
October 2006. April 2007.
[I-D.ietf-tcpm-tcpsecure] [I-D.ietf-tcpm-tcpsecure]
Stewart, R. and M. Dalal, "Improving TCP's Robustness to Ramaiah, A., "Improving TCP's Robustness to Blind In-
Blind In-Window Attacks", draft-ietf-tcpm-tcpsecure-05 Window Attacks", draft-ietf-tcpm-tcpsecure-07 (work in
(work in progress), June 2006. progress), February 2007.
[I-D.larsen-tsvwg-port-randomisation] [I-D.larsen-tsvwg-port-randomisation]
Larsen, M., "Port Randomisation", Larsen, M., "Port Randomisation",
draft-larsen-tsvwg-port-randomisation-00 (work in draft-larsen-tsvwg-port-randomisation-00 (work in
progress), October 2004. progress), October 2004.
[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/filtering-icmp-error-messages.pdf. www.gont.com.ar/papers/filtering-icmp-error-messages.pdf.
skipping to change at page 26, line 5 skipping to change at page 26, line 10
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
RFC 2923, September 2000. RFC 2923, September 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
Initial Window", RFC 3390, October 2002. Initial Window", RFC 3390, October 2002.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[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.
skipping to change at page 36, line 5 skipping to change at page 36, line 20
placed to give advice and guidance as required. placed to give advice and guidance as required.
NISCC works extensively with government departments and agencies, NISCC works extensively with government departments and agencies,
commercial organizations and the academic community to research commercial organizations and the academic community to research
vulnerabilities and potential threats to IT systems especially where vulnerabilities and potential threats to IT systems especially where
they may have an impact on Critical National Infrastructure's (CNI). they may have an impact on Critical National Infrastructure's (CNI).
Other ways to contact NISCC, plus NISCC's PGP public key, are Other ways to contact NISCC, plus NISCC's PGP public key, are
available at http://www.uniras.gov.uk/vuls/ . available at http://www.uniras.gov.uk/vuls/ .
Appendix E. Changes from previous versions of the draft Appendix E. Changes from previous versions of the draft (to be removed
by the RFC Editor before publishing this document as an
E.1. Changes from draft-gont-tcpm-icmp-attacks-05 RFC)
o Removed RFC 2119 wording to make the draft suitable for
publication as an Informational RFC.
o Added additional checks that should be performed on ICMP error E.1. Changes from draft-ietf-tcpm-icmp-attacks-01
messages (checksum of the IP header in the ICMP payload, and
others).
o Added clarification of the rationale behind each the TCP SEQ check o Fixed references to the antispoof documents (were hardcoded and
missing in the References Section).
o Miscellaneous editorial changes o The draft had expired and thus is resubmitted with no further
changes.
E.2. Changes from draft-ietf-tcpm-icmp-attacks-00 E.2. 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.
skipping to change at page 36, line 39 skipping to change at page 37, line 4
o Changed text so that the document fits better in the Informational o Changed text so that the document fits better in the Informational
path path
o Added an specific section on IPsec (Section 2.3) o Added an specific section on IPsec (Section 2.3)
o Added clarification and references on the use of ICMP filtering o Added clarification and references on the use of ICMP filtering
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 (in Section 5.2.3) errors (in Section 5.2.3)
o Miscellaneous editorial changes o Miscellaneous editorial changes
E.3. Changes from draft-gont-tcpm-icmp-attacks-04 E.3. Changes from draft-gont-tcpm-icmp-attacks-05
o Removed RFC 2119 wording to make the draft suitable for
publication as an Informational RFC.
o Added additional checks that should be performed on ICMP error
messages (checksum of the IP header in the ICMP payload, and
others).
o Added clarification of the rationale behind each the TCP SEQ check
o Miscellaneous editorial changes
E.4. Changes from draft-gont-tcpm-icmp-attacks-04
o Added Appendix C o Added Appendix C
o Added reference to [I-D.iab-link-indications] o Added reference to [I-D.iab-link-indications]
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
E.4. Changes from draft-gont-tcpm-icmp-attacks-03 E.5. 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 in Section 5.2.1 was expanded and improved o The discussion in Section 5.2.1 was 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 Appendix B was added o Appendix B was added
o Miscellaneous editorial changes o Miscellaneous editorial changes
E.5. Changes from draft-gont-tcpm-icmp-attacks-02 E.6. Changes from draft-gont-tcpm-icmp-attacks-02
o Fixed errors in Section 5.2.1 o Fixed errors in Section 5.2.1
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 Appendix A was added so as to clarify the operation of the o Appendix A 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 D o Added Appendix D
o Miscellaneous editorial changes o Miscellaneous editorial changes
E.6. Changes from draft-gont-tcpm-icmp-attacks-01 E.7. 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
skipping to change at page 38, line 4 skipping to change at page 38, line 31
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
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
E.7. Changes from draft-gont-tcpm-icmp-attacks-00 E.8. 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
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fernando@gont.com.ar Email: fernando@gont.com.ar
URI: http://www.gont.com.ar
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
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, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 32 change blocks. 
65 lines changed or deleted 89 lines changed or added

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