draft-ietf-tcpm-tcpsecure-11.txt   draft-ietf-tcpm-tcpsecure-12.txt 
TCP Maintenance and Minor A. Ramaiah TCP Maintenance and Minor A. Ramaiah
Extensions Working Group R. Stewart Extensions Working Group Cisco Systems
Internet-Draft M. Dalal Internet-Draft R. Stewart
Updates: 793 (if approved) Cisco Systems Updates: 793 (if approved) Researcher
Intended status: Standards Track November 3, 2008 Intended status: Standards Track M. Dalal
Expires: May 7, 2009 Expires: March 17, 2010 Cisco Systems
September 13, 2009
Improving TCP's Robustness to Blind In-Window Attacks Improving TCP's Robustness to Blind In-Window Attacks
draft-ietf-tcpm-tcpsecure-11.txt draft-ietf-tcpm-tcpsecure-12.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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 May 7, 2009. This Internet-Draft will expire on March 17, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
TCP has historically been considered protected against spoofed off- TCP has historically been considered protected against spoofed off-
path packet injection attacks by relying on the fact that it is path packet injection attacks by relying on the fact that it is
difficult to guess the 4-tuple (the source and destination IP difficult to guess the 4-tuple (the source and destination IP
addresses and the source and destination ports) in combination with addresses and the source and destination ports) in combination with
the 32 bit sequence number(s). A combination of increasing window the 32 bit sequence number(s). A combination of increasing window
sizes and applications using longer term connections (e.g. H-323 or sizes and applications using longer term connections (e.g. H-323 or
Border Gateway Protocol [RFC4271]) have left modern TCP Border Gateway Protocol [RFC4271]) have left modern TCP
skipping to change at page 3, line 35 skipping to change at page 4, line 4
9.1. Middlebox that resend RST's . . . . . . . . . . . . . . . 18 9.1. Middlebox that resend RST's . . . . . . . . . . . . . . . 18
9.2. Middleboxes that advance sequence numbers . . . . . . . . 18 9.2. Middleboxes that advance sequence numbers . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
14.1. Normative References . . . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . . 24
14.2. Informative References . . . . . . . . . . . . . . . . . . 24 14.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
1. Introduction 1. Introduction
TCP [RFC0793] is widely deployed and the most common reliable end to TCP [RFC0793] is widely deployed and the most common reliable end to
end transport protocol used for data communication in today's end transport protocol used for data communication in today's
Internet. Yet when it was standardized over 20 years ago, the Internet. Yet when it was standardized over 20 years ago, the
Internet, was a different place, lacking many of the threats that are Internet, was a different place, lacking many of the threats that are
now common. The off-path TCP spoofing attacks, which are seen in the now common. The off-path TCP spoofing attacks, which are seen in the
Internet today, fall into this category. Internet today, fall into this category.
skipping to change at page 5, line 31 skipping to change at page 5, line 31
both ends of the connection. For one side (usually the server) both ends of the connection. For one side (usually the server)
guessing the port number is a trivial exercise. The client side 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 may or may not be easy for an attacker to guess depending on a
number of factors, most notably the operating system and number of factors, most notably the operating system and
application involved. application involved.
2) A sequence number that will be used in the RST. This sequence 2) A sequence number that will be used in the RST. This sequence
number will be a starting point for a series of guesses to attempt number will be a starting point for a series of guesses to attempt
to present a RST segment to a connection endpoint that would be to present a RST segment to a connection endpoint that would be
acceptable to it. Any random value may be used to guess the acceptable to it. Any random value may be used to guess the
initial sequence number. starting sequence number.
3) The window size that the two endpoints are using. This value does 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 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 lieu of the correct one will just cause the attacker to generate
more segments before succeeding in his mischief. Most modern more segments before succeeding in his mischief. Most modern
operating systems have a default window size which usually is operating systems have a default window size which usually is
applied to most connections. Some applications however may change applied to most connections. Some applications however may change
the window size to better suit the needs of the application. So the window size to better suit the needs of the application. So
often times the attacker, with a fair degree of certainty (knowing often times the attacker, with a fair degree of certainty (knowing
the application that is under attack), can come up with a very the application that is under attack), can come up with a very
skipping to change at page 7, line 40 skipping to change at page 7, line 40
unavailability due to the need to rebuild routing tables and route unavailability due to the need to rebuild routing tables and route
flapping; see [NISCC] for further details. flapping; see [NISCC] for further details.
For applications that can use the TCP MD5 option [RFC2385], such as For applications that can use the TCP MD5 option [RFC2385], such as
BGP, that option makes the attacks described in this specification BGP, that option makes the attacks described in this specification
effectively impossible. However, some applications or effectively impossible. However, some applications or
implementations may find that option expensive to implement. implementations may find that option expensive to implement.
There are alternative protections against the threats that this There are alternative protections against the threats that this
document addresses. For further details regarding the attacks and document addresses. For further details regarding the attacks and
the existing techniques, please refer to [RFC4953] the existing techniques, please refer to [RFC4953]. It also needs to
be emphasized that, as suggested in
[I-D.ietf-tsvwg-port-randomization](port randomization) and [RFC1948]
(ISN randomization) would help improve the robustness of the TCP
connection against off-path attacks.
2. Terminology 2. Terminology
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 [RFC2119]. TCP document are to be interpreted as described in [RFC2119]. TCP
terminology should be interpreted as described in [RFC0793]. terminology should be interpreted as described in [RFC0793].
3. Blind reset attack using the RST bit 3. Blind reset attack using the RST bit
skipping to change at page 11, line 38 skipping to change at page 11, line 38
1) If the SYN bit is set, irrespective of the sequence number, TCP 1) If the SYN bit is set, irrespective of the sequence number, TCP
MUST send an ACK (also referred to as challenge ACK) to the remote MUST send an ACK (also referred to as challenge ACK) to the remote
peer: peer:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the acknowledgment, TCP MUST drop the unacceptable After sending the acknowledgment, TCP MUST drop the unacceptable
segment and stop processing further. segment and stop processing further.
By sending an ACK, the remote end sender is challenged to confirm the By sending an ACK, the remote peer is challenged to confirm the loss
loss of the previous connection and the request to start a new of the previous connection and the request to start a new connection.
connection. A legitimate peer, after restart, would not have a TCB A legitimate peer, after restart, would not have a TCB in the
in the synchronized state. Thus when the ACK arrives the peer should synchronized state. Thus when the ACK arrives the peer should send a
send a RST segment back with the sequence number derived from the ACK RST segment back with the sequence number derived from the ACK field
field that caused the RST. that caused the RST.
This RST will confirm that the remote TCP endpoint has indeed closed This RST will confirm that the remote peer has indeed closed the
the previous connection. Upon receipt of a valid RST, the local TCP previous connection. Upon receipt of a valid RST, the local TCP
endpoint MUST terminate its connection. The local TCP endpoint endpoint MUST terminate its connection. The local TCP endpoint
should then rely on SYN retransmission from the remote end to re- should then rely on SYN retransmission from the remote end to re-
establish the connection. establish the connection.
A spoofed SYN, on the other hand, will then have generated an A spoofed SYN, on the other hand, will then have generated an
additional ACK which the peer will discard as a duplicate ACK and additional ACK which the peer will discard as a duplicate ACK and
will not affect the established connection. will not affect the established connection.
Note that this mitigation does leave one corner case un-handled which 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. 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 it is a non-spoofed SYN wherein a peer really did restart). This
problem occurs when the restarting host chooses the exact same IP problem occurs when the restarting host chooses the exact same IP
address and port number that it was using prior to its restart. By address and port number that it was using prior to its restart. By
chance the restarted host must also choose an initial sequence number 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 of exactly (RCV.NXT - 1) of the remote peer that is still in the
the established state. Such a case would cause the receiver to established state. Such a case would cause the receiver to generate
generate a "challenge" ACK as described above. But since the ACK a "challenge" ACK as described above. But since the ACK would be
would be within the outgoing connections window the inbound ACK would within the outgoing connections window the inbound ACK would be
be acceptable, and the sender of the SYN will do nothing with the acceptable, and the sender of the SYN will do nothing with the
response ACK. This sequence will continue as the SYN sender response ACK. This sequence will continue as the SYN sender
continually times out and retransmits the SYN until such time as the continually times out and retransmits the SYN until such time as the
connection attempt fails. connection attempt fails.
This corner case is a result of the [RFC0793] specification and is This corner case is a result of the [RFC0793] specification and is
not introduced by these new requirements. not introduced by these new requirements.
Note that the above mitigation may cause a non-amplification ACK Note that the above mitigation may cause a non-amplification ACK
exchange. This concern is discussed in Section 10. exchange. This concern is discussed in Section 10.
skipping to change at page 14, line 16 skipping to change at page 14, line 16
All TCP stacks MAY implement the following mitigation. TCP stacks All TCP stacks MAY implement the following mitigation. TCP stacks
which implement this mitigation MUST add an additional input check to which implement this mitigation MUST add an additional input check to
any incoming segment. The ACK value is considered acceptable only if any incoming segment. The ACK value is considered acceptable only if
it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=
SND.NXT). All incoming segments whose ACK value doesn't satisfy the SND.NXT). All incoming segments whose ACK value doesn't satisfy the
above condition MUST be discarded and an ACK sent back. It needs to above condition MUST be discarded and an ACK sent back. It needs to
be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a
duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK
acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an
ACK, drop the segment, and return." This mitigation makes the ACK ACK, drop the segment, and return." The "ignored" above implies that
check more stringent since any ACK < SND.UNA wouldn't be accepted, the processing of the incoming data segment continues, which means
instead only ACKs which are in the range ((SND.UNA - MAX.SND.WND) <= the ACK value is treated as acceptable. This mitigation makes the
SEG.ACK <= SND.NXT) gets through. ACK check more stringent since any ACK < SND.UNA wouldn't be
accepted, instead only ACKs which are in the range ((SND.UNA -
MAX.SND.WND) <= SEG.ACK <= SND.NXT) gets through.
A new state variable MAX.SND.WND is defined as the largest window A new state variable MAX.SND.WND is defined as the largest window
that the local sender has ever received from its peer. This window that the local sender has ever received from its peer. This window
may be scaled to a value larger than 65,535 bytes ([RFC1323]). This may be scaled to a value larger than 65,535 bytes ([RFC1323]). This
small check will reduce the vulnerability to an attacker guessing a small check will reduce the vulnerability to an attacker guessing a
valid sequence number, since, not only one must guess the in-window valid sequence number, since, not only one must guess the in-window
sequence number, but also guess a proper ACK value within a scoped sequence number, but also guess a proper ACK value within a scoped
range. This mitigation reduces, but does not eliminate, the ability range. This mitigation reduces, but does not eliminate, the ability
to generate false segments. It does however reduce the probability to generate false segments. It does however reduce the probability
that invalid data will be injected. that invalid data will be injected.
skipping to change at page 15, line 11 skipping to change at page 15, line 11
Note that the above mitigation may cause a non-amplification ACK Note that the above mitigation may cause a non-amplification ACK
exchange. This concern is discussed in Section 10. exchange. This concern is discussed in Section 10.
6. Suggested Mitigation strengths 6. Suggested Mitigation strengths
As described in the above sections, recommendation levels for RST, As described in the above sections, recommendation levels for RST,
SYN and DATA are tagged as SHOULD, SHOULD and MAY respectively. The SYN and DATA are tagged as SHOULD, SHOULD and MAY respectively. The
reason that DATA mitigation is tagged as MAY, even though it reason that DATA mitigation is tagged as MAY, even though it
increased the TCP robustness in general is because, the DATA increased the TCP robustness in general is because, the DATA
injection is perceived to be more difficult (twice less unlikely) injection is perceived to be more difficult (twice as unlikely) when
when compared to RST and SYN counterparts. However, it needs to be compared to RST and SYN counterparts. However, it needs to be noted
noted that all the suggested mitigations improve TCP's robustness in that all the suggested mitigations improve TCP's robustness in
general and hence the choice of implementing some or all mitigations general and hence the choice of implementing some or all mitigations
recommended in the document is purely left to the implementer. recommended in the document is purely left to the implementer.
7. ACK throttling 7. ACK throttling
In order to alleviate multiple RSTs/SYNs from triggering multiple In order to alleviate multiple RSTs/SYNs from triggering multiple
challenge ACKs, an ACK throttling mechanism is suggested as follows : challenge ACKs, an ACK throttling mechanism is suggested as follows :
1) The system administrator can configure the number of challenge 1) The system administrator can configure the number of challenge
ACKs that can be sent out in a given interval. For example, in ACKs that can be sent out in a given interval. For example, in
skipping to change at page 16, line 27 skipping to change at page 16, line 27
levels of threat and/or system resources. levels of threat and/or system resources.
It should be noted that these numbers are empirical in nature and It should be noted that these numbers are empirical in nature and
have been obtained from the RST throttling mechanisms existing in have been obtained from the RST throttling mechanisms existing in
some implementations. Also note that no timer is needed to implement some implementations. Also note that no timer is needed to implement
the above mechanism, instead a timestamp and a counter can be used. the above mechanism, instead a timestamp and a counter can be used.
An implementation SHOULD include an ACK throttling mechanism to be An implementation SHOULD include an ACK throttling mechanism to be
conservative. While we have not encountered a case where the lack of conservative. While we have not encountered a case where the lack of
ACK throttling can be exploited, as a fail-safe mechanism we ACK throttling can be exploited, as a fail-safe mechanism we
recommend it's use. An implementation may take an excessive number recommend its use. An implementation may take an excessive number of
of invocations of the throttling mechanism as an indication that invocations of the throttling mechanism as an indication that network
network conditions are unusual or hostile. conditions are unusual or hostile.
An administrator who is more concerned about protecting his bandwidth An administrator who is more concerned about protecting his bandwidth
and CPU utilization may set smaller ACK throttling values whereas an and CPU utilization may set smaller ACK throttling values whereas an
administrator who is more interested in faster cleanup of stale administrator who is more interested in faster cleanup of stale
connections (i.e. concerned about excess TCP state) may decide to set 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 a higher value thus allowing more RST's to be processed in any given
time period. time period.
The time limit SHOULD be tunable to help timeout brute force attacks The time limit SHOULD be tunable to help timeout brute force attacks
faster than a potential legitimate flood of RSTs. faster than a potential legitimate flood of RSTs.
skipping to change at page 23, line 9 skipping to change at page 23, line 9
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.
13. Acknowledgments 13. Acknowledgments
Special thanks to Mark Allman, Ted Faber, Steve Bellovin, Vern Special thanks to Mark Allman, Ted Faber, Steve Bellovin, Vern
Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong, Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong,
Joe Touch, Alfred Hoenes, Andre Oppermann and other members of the Joe Touch, Alfred Hoenes, Andre Oppermann, Fernando Gont, Sandra
tcpm WG for suggestions and comments. ACK throttling was introduced Murphy, Brian Carpenter and other members of the tcpm WG for
to this document by combining the suggestions from the tcpm working suggestions and comments. ACK throttling was introduced to this
group. document by combining the suggestions from the tcpm working group.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Informative References 14.2. Informative References
[I-D.ietf-tcpm-icmp-attacks] [I-D.ietf-tcpm-icmp-attacks]
Gont, F., "ICMP attacks against TCP", Gont, F., "ICMP attacks against TCP",
draft-ietf-tcpm-icmp-attacks-04 (work in progress), draft-ietf-tcpm-icmp-attacks-06 (work in progress),
October 2008. August 2009.
[I-D.ietf-tsvwg-port-randomization]
Larsen, M. and F. Gont, "Port Randomization",
draft-ietf-tsvwg-port-randomization-04 (work in progress),
July 2009.
[Medina05] [Medina05]
Medina, A., Allman, M., and S. Floyd, "Measuring the Medina, A., Allman, M., and S. Floyd, "Measuring the
Evolution of Transport Protocols in the Internet. ACM Evolution of Transport Protocols in the Internet. ACM
Computer Communication Review, 35(2), April 2005. Computer Communication Review, 35(2), April 2005.
http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps
(figure 6)". (figure 6)".
[NISCC] NISCC, "NISCC Vulnerability Advisory 236929 - [NISCC] NISCC, "NISCC Vulnerability Advisory 236929 -
Vulnerability Issues in TCP". Vulnerability Issues in TCP".
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992. for High Performance", RFC 1323, May 1992.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
skipping to change at page 26, line 17 skipping to change at page 26, line 17
Anantha Ramaiah Anantha Ramaiah
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 (408) 525-6486 Phone: +1 (408) 525-6486
Email: ananth@cisco.com Email: ananth@cisco.com
Randall R. Stewart Randall R. Stewart
Cisco Systems Researcher
4875 Forest Drive Chapin
Suite 200 SC 29036
Columbia, SC 29206
USA USA
Phone: +1 (803) 345-0369 Phone: +1 (803) 345-0369
Email: rrs@cisco.com Email: randall@lakerest.net
Mitesh Dalal Mitesh Dalal
Cisco Systems Cisco Systems
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
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 20 change blocks. 
51 lines changed or deleted 70 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/