draft-ietf-rtgwg-rfc3682bis-00.txt   draft-ietf-rtgwg-rfc3682bis-01.txt 
INTERNET-DRAFT V. Gill INTERNET-DRAFT V. Gill
draft-ietf-rtgwg-rfc3682bis-00.txt J. Heasley draft-ietf-rtgwg-rfc3682bis-01.txt J. Heasley
D. Meyer D. Meyer
Category Experimental Category Experimental
Expires: September 2004 March 2004 Expires: September 2004 March 2004
The Generalized TTL Security Mechanism (GTSM) The Generalized TTL Security Mechanism (GTSM)
<draft-ietf-rtgwg-rfc3682bis-00.txt> <draft-ietf-rtgwg-rfc3682bis-01.txt>
Status of this Document Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of Section 10 of RFC2026.
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/1id-abstracts.html
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 document is a product of the RTG WG. Comments should be This document is a product of the RTG WG WG. Comments should be
addressed to the authors, or the mailing list at rtgwg@ietf.org. addressed to the authors, or the mailing list at rtgwg@ietf.org.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
The use of a packet's TTL (IPv4) or Hop Limit (IPv6) to protect a The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6)
protocol stack from CPU-utilization based attacks has been proposed to protect a protocol stack from CPU-utilization based attacks has
in many settings (see for example, RFC 2461). This document been proposed in many settings (see for example, RFC 2461). This
generalizes these techniques for use by other protocols such as BGP document generalizes these techniques for use by other protocols such
(RFC 1771), MSDP, Bidirectional Forwarding Detection, and LDP (RFC as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP),
3036). While the Generalized TTL Security Mechanism (GTSM) is most Bidirectional Forwarding Detection, and Label Distribution Protocol
effective in protecting directly connected protocol peers, it can (LDP) (RFC 3036). While the Generalized TTL Security Mechanism (GTSM)
also provide a lower level of protection to multi-hop sessions. GTSM is most effective in protecting directly connected protocol peers, it
is not directly applicable to protocols employing flooding mechanisms can also provide a lower level of protection to multi-hop sessions.
(e.g., multicast), and use of multi-hop GTSM should be considered on GTSM is not directly applicable to protocols employing flooding
a case-by-case basis. mechanisms (e.g., multicast), and use of multi-hop GTSM should be
considered on a case-by-case basis.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Assumptions Underlying GTSM. . . . . . . . . . . . . . . . . . 4 2. Assumptions Underlying GTSM. . . . . . . . . . . . . . . . . . 4
2.1. GTSM Negotiation. . . . . . . . . . . . . . . . . . . . . . 4 2.1. GTSM Negotiation. . . . . . . . . . . . . . . . . . . . . . 4
2.2. Assumptions on Attack Sophistication. . . . . . . . . . . . 4 2.2. Assumptions on Attack Sophistication. . . . . . . . . . . . 5
3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5 3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Multi-hop Scenarios . . . . . . . . . . . . . . . . . . . . 6 3.1. Multi-hop Scenarios . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Intra-domain Protocol Handling . . . . . . . . . . . . . 6 3.1.1. Intra-domain Protocol Handling . . . . . . . . . . . . . 6
4. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 7 4. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 7
5.1. TTL (Hop Limit) Spoofing. . . . . . . . . . . . . . . . . . 7 5.1. TTL (Hop Limit) Spoofing. . . . . . . . . . . . . . . . . . 7
5.2. Tunneled Packets. . . . . . . . . . . . . . . . . . . . . . 8 5.2. Tunneled Packets. . . . . . . . . . . . . . . . . . . . . . 8
5.2.1. IP in IP . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2.1. IP in IP . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2.2. IP in MPLS . . . . . . . . . . . . . . . . . . . . . . . 9 5.2.2. IP in MPLS . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . . 10 5.3. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . . 10
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References. . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References. . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References. . . . . . . . . . . . . . . . . . . 12 7.2. Informative References. . . . . . . . . . . . . . . . . . . 12
8. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 13 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
10. Intellectual Property . . . . . . . . . . . . . . . . . . . . 14 10. Intellectual Property . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Generalized TTL Security Mechanism (GTSM) is designed to protect The Generalized TTL Security Mechanism (GTSM) is designed to protect
a router's TCP/IP based control plane from CPU-utilization based a router's TCP/IP based control plane from CPU-utilization based
attacks. In particular, while cryptographic techniques can protect attacks. In particular, while cryptographic techniques can protect
the router-based infrastructure (e.g., BGP [RFC1771]) from a wide the router-based infrastructure (e.g., BGP [RFC1771], [RFC1772]) from
variety of attacks, many attacks based on CPU overload can be a wide variety of attacks, many attacks based on CPU overload can be
prevented by the simple mechanism described in this document. Note prevented by the simple mechanism described in this document. Note
that the same technique protects against other scarce-resource that the same technique protects against other scarce-resource
attacks involving a router's CPU, such as attacks against processor- attacks involving a router's CPU, such as attacks against processor-
line card bandwidth. line card bandwidth.
GTSM is based on the fact that the vast majority of protocol peerings GTSM is based on the fact that the vast majority of protocol peerings
are established between routers that are adjacent [PEERING]. Thus are established between routers that are adjacent [PEERING]. Thus
most protocol peerings are either directly between connected most protocol peerings are either directly between connected
interfaces or at the worst case, are between loopback and loopback, interfaces or at the worst case, are between loopback and loopback,
with static routes to loopbacks. Since TTL spoofing is considered with static routes to loopbacks. Since TTL spoofing is considered
nearly impossible, a mechanism based on an expected TTL value can nearly impossible, a mechanism based on an expected TTL value can
provide a simple and reasonably robust defense from infrastructure provide a simple and reasonably robust defense from infrastructure
attacks based on forged protocol packets. attacks based on forged protocol packets.
Finally, the GTSM mechanism is equally applicable to both TTL (IPv4) Finally, the GTSM mechanism is equally applicable to both TTL (IPv4)
and Hop Limit (IPv6), and from the perspective of GTSM, TTL and Hop and Hop Limit (IPv6), and from the perspective of GTSM, TTL and Hop
Limit have identical semantics. As a result, in the remainder of this Limit have identical semantics. As a result, in the remainder of this
document the term "TTL" is used to refer to both TTL or Hop Limit (as document the term "TTL" is used to refer to both TTL or Hop Limit (as
appropriate). appropriate).
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 BCP 14, RFC 2119
[RFC2119].
2. Assumptions Underlying GTSM 2. Assumptions Underlying GTSM
GTSM is predicated upon the following assumptions: GTSM is predicated upon the following assumptions:
(i). The vast majority of protocol peerings are between adjacent (i) The vast majority of protocol peerings are between adjacent
routers [PEERING]. routers [PEERING].
(ii). It is common practice for many service providers to (ii) It is common practice for many service providers to
ingress filter (deny) packets that have the provider's ingress filter (deny) packets that have the provider's
loopback addresses as the source IP address. loopback addresses as the source IP address.
(iii). Use of GTSM is OPTIONAL, and can be configured on a (iii) Use of GTSM is OPTIONAL, and can be configured on a
per-peer (group) basis. per-peer (group) basis.
(iv). The router supports a method of classifying traffic (iv) The router supports a method of classifying traffic
destined for the route processor into interesting/control destined for the route processor into interesting/control
and not-control queues. and not-control queues.
(iv). The peer routers both implement GTSM. (v) The peer routers both implement GTSM.
2.1. GTSM Negotiation 2.1. GTSM Negotiation
This document assumes that GTSM will be manually configured between This document assumes that GTSM will be manually configured between
protocol peers. That is, no automatic GTSM capability negotiation, protocol peers. That is, no automatic GTSM capability negotiation,
such as is envisioned by RFC 2842 [RFC2842] is assumed or defined. such as is envisioned by RFC 2842 [RFC2842] is assumed or defined.
2.2. Assumptions on Attack Sophistication 2.2. Assumptions on Attack Sophistication
Throughout this document, we assume that potential attackers have Throughout this document, we assume that potential attackers have
skipping to change at page 5, line 30 skipping to change at page 5, line 34
large diameter multi-hop peerings. In the event that an the attack large diameter multi-hop peerings. In the event that an the attack
comes in from a compromised multi-hop peering, that peering can be comes in from a compromised multi-hop peering, that peering can be
shut down (a method to reduce exposure to multi-hop attacks is shut down (a method to reduce exposure to multi-hop attacks is
outlined below). outlined below).
3. GTSM Procedure 3. GTSM Procedure
GTSM SHOULD NOT be enabled by default. The following process GTSM SHOULD NOT be enabled by default. The following process
describes the per-peer behavior: describes the per-peer behavior:
(i). If GTSM is enabled, an implementation performs the (i) If GTSM is enabled, an implementation performs the
following procedure: following procedure:
(a). For directly connected routers, (a) For directly connected routers,
o Set the outbound TTL for the protocol connection to o Set the outbound TTL for the protocol connection to
255. 255.
o For each configured protocol peer: o For each configured protocol peer:
Update the receive path Access Control List (ACL) Update the receive path Access Control List (ACL)
or firewall to only allow protocol packets to pass or firewall to only allow protocol packets to pass
onto the Route Processor (RP) that have the correct onto the Route Processor (RP) that have the correct
<source, destination, TTL> tuple. The TTL must <source, destination, TTL> tuple. The TTL must
either be 255 (for a directly connected peer), or either be 255 (for a directly connected peer), or
255-(configured-range-of-acceptable-hops) 255-(configured-range-of-acceptable-hops)
for a multi-hop peer. We specify a range here to for a multi-hop peer. We specify a range here to
achieve some robustness to changes in topology. Any achieve some robustness to changes in topology. Any
directly connected check MUST be disabled for such directly connected check MUST be disabled for such
peerings. peerings.
It is assumed that a receive path ACL is an ACL It is assumed that a receive path ACL is an ACL
that is designed to control which packets are that is designed to control which packets are
allowed to go to the RP. This procedure will only allowed to go to the RP. This procedure will only
allow protocol packets from an adjacent router to allow protocol packets from adjacent router to pass
pass onto the RP. onto the RP.
(b). If the inbound TTL is less than 255 (for a directly (b) If the inbound TTL is 255 (for a directly connected
connected peer), or 255-(configured-range-of-acceptable-hops) peer), or 255-(configured-range-of-acceptable-hops) (for
(for multi-hop peers), the packet is NOT multi-hop peers), the packet is NOT processed. Rather,
processed. Rather, the packet is placed into a low the packet is placed into a low priority queue, and
priority queue, and subsequently logged and/or subsequently logged and/or silently discarded. In this
silently discarded. In this case, an ICMP message case, an ICMP message MUST NOT be generated.
MUST NOT be generated.
(ii). If GTSM is not enabled, normal protocol behavior is followed. (ii) If GTSM is not enabled, normal protocol behavior is followed.
3.1. Multi-hop Scenarios 3.1. Multi-hop Scenarios
When a multi-hop protocol session is required, we set the expected When a multi-hop protocol session is required, we set the expected
TTL value to be 255-(configured-range-of-acceptable-hops). This TTL value to be 255-(configured-range-of-acceptable-hops). This
approach provides a qualitatively lower degree of security for the approach provides a qualitatively lower degree of security for the
protocol implementing GTSM (i.e., an DoS attack could be protocol implementing GTSM (i.e., a DoS attack could theoretically be
theoretically be launched by compromising some box in the path). launched by compromising some box in the path). However, GTSM will
However, GTSM will still catch the vast majority of observed DDoS still catch the vast majority of observed DDoS attacks against a
attacks against a given protocol. Note that since the number of hops given protocol. Note that since the number of hops can change rapidly
can change rapidly in real network situations, it is considered that in real network situations, it is considered that GTSM may not be
GTSM may not be able to handle this scenario adequately and an able to handle this scenario adequately and an implementation MAY
implementation MAY provide OPTIONAL support. provide OPTIONAL support.
3.1.1. Intra-domain Protocol Handling 3.1.1. Intra-domain Protocol Handling
In general, GTSM is not used for intra-domain protocol peers or In general, GTSM is not used for intra-domain protocol peers or
adjacencies. The special case of iBGP peers can be protected by adjacencies. The special case of iBGP peers can be protected by
filtering at the network edge for any packet that has a source filtering at the network edge for any packet that has a source
address of one of the loopback addresses used for the intra-domain address of one of the loopback addresses used for the intra-domain
peering. In addition, the current best practice is to further protect peering. In addition, the current best practice is to further protect
such peers or adjacencies with an MD5 signature [RFC2385]. such peers or adjacencies with an MD5 signature [RFC2385].
skipping to change at page 10, line 46 skipping to change at page 10, line 46
3 will fail. 3 will fail.
5.3. Multi-Hop Protocol Sessions 5.3. Multi-Hop Protocol Sessions
While the GTSM method is less effective for multi-hop protocol While the GTSM method is less effective for multi-hop protocol
sessions, it does close the window on several forms of attack. sessions, it does close the window on several forms of attack.
However, in the multi-hop scenario GTSM is an OPTIONAL extension. However, in the multi-hop scenario GTSM is an OPTIONAL extension.
Protection of the protocol infrastructure beyond what is provided by Protection of the protocol infrastructure beyond what is provided by
the GTSM method will likely require cryptographic machinery such as the GTSM method will likely require cryptographic machinery such as
is envisioned by Secure BGP (S-BGP) [SBGP1,SBGP2], and/or other is envisioned by Secure BGP (S-BGP) [SBGP1,SBGP2], and/or other
extensions. Finally, note that in the multi-hop case described above, extensions. Finally, note that in the multi-hop case described
we specify a range of acceptable TTLs in order to achieve some above, we specify a range of acceptable TTLs in order to achieve some
robustness to topology changes. This robustness to topological change robustness to topology changes. This robustness to topological
comes at the cost of the loss some robustness to different forms of change comes at the cost of the loss of some robustness to different
attack. forms of attack.
6. IANA Considerations 6. IANA Considerations
This document creates a no new requirements on IANA namespaces This document creates no new requirements on IANA namespaces
[RFC2434]. [RFC2434].
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC791] Postel, J., "INTERNET PROTOCOL PROTOCOL [RFC791] Postel, J., "Internet Protocol Specification",
SPECIFICATION", RFC 791, September, 1981. STD 5, RFC 791, September 1981.
[RFC1771] Rekhter, Y., and T. Li (Editors), "A Border [RFC1771] Rekhter, Y. and T. Li (Editors), "A Border
Gateway Protocol (BGP-4)", RFC 1771, March, Gateway Protocol (BGP-4)", RFC 1771, March 1995.
1995.
[RFC1772] Rekhter, Y., and P. Gross, "Application of the [RFC1772] Rekhter, Y. and P. Gross, "Application of the
Border Gateway Protocol in the Internet", RFC Border Gateway Protocol in the Internet", RFC
1772, March, 1995. 1772, March 1995.
[RFC2003] Perkins, C., "IP Encapsulation with IP", RFC [RFC2003] Perkins, C., "IP Encapsulation with IP", RFC
2003, October, 1996. 2003, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119, March, Indicate Requirement Levels", BCP 14, RFC 2119,
1997. March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via [RFC2385] Heffernan, A., "Protection of BGP Sessions via
the TCP MD5 Signature Option", RFC 2385, August, the TCP MD5 Signature Option", RFC 2385, August
1998. 1998.
[RFC2461] Narten, T., E. Nordmark, and W. Simson, "Neighbor [RFC2461] Narten, T., Nordmark, E. and W. Simpson,
Discovery for IP Version 6 (IPv6)", RFC 2461, "Neighbor Discover for IP Version 6 (IPv6)", RFC
December, 1998. 2461, December 1998.
[RFC2784] Farinacci, D., "Generic Routing Encapsulation [RFC2784] Farinacci, D., "Generic Routing Encapsulation
(GRE)", RFC 2784, March, 2000. (GRE)", RFC 2784, March 2000.
[RFC2842] Chandra, R. and J. Scudder, "Capabilities [RFC2842] Chandra, R. and J. Scudder, "Capabilities
Advertisement with BGP-4", RFC 2842, May, 2000. Advertisement with BGP-4", RFC 2842, May 2000.
[RFC2893] Gilligan, R., and E. Nordmark, "Transition [RFC2893] Gilligan, R. and E. Nordmark, "Transition
Mechanisms for IPv6 Hosts and Routers", RFC 2893, Mechanisms for IPv6 Hosts and Routers", RFC 2893,
August, 2000. August 2000.
[RFC3036] Andersson, L., et. al., "LDP Specification", RFC [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette,
3036, January, 2001. January, 2001. A. and B. Thomas, "LDP Specification", RFC 3036,
January 2001.
[RFC3032] Rosen, E., et. al., "MPLS Label Stack Encoding", [RFC3032] Rosen, E. Tappan, D., Fedorkow, G., Rekhter, Y.,
RFC 3032, Farinacci, D., Li, T. and A. Conta, "MPLS Label
Stack Encoding", RFC 3032, January 2001.
[SBGP1] Kent, S., C. Lynn, and K. Seo, "Secure Border [SBGP1] Kent, S., C. Lynn, and K. Seo, "Secure Border
Gateway Protocol (Secure-BGP)", IEEE Journal on Gateway Protocol (Secure-BGP)", IEEE Journal on
Selected Areas in Communications, volume 18, Selected Areas in Communications, volume 18,
number 4, April, 2000. number 4, April 2000.
[SBGP2] Kent, S., C. Lynn, J. Mikkelson, and K. Seo, [SBGP2] Kent, S., C. Lynn, J. Mikkelson, and K. Seo,
"Secure Border Gateway Protocol (S-BGP) -- Real "Secure Border Gateway Protocol (S-BGP) -- Real
World Performance and Deployment Issues", World Performance and Deployment Issues",
Proceedings of the IEEE Network and Distributed Proceedings of the IEEE Network and Distributed
System Security Symposium, February, 2000. System Security Symposium, February, 2000.
7.2. Informative References 7.2. Informative References
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", draft-katz-ward-bfd-02.txt. Work in Detection", draft-katz-ward-bfd-02.txt, Work in
progress. Progress.
[PEERING] Empirical data gathered from the Sprint and AOL [PEERING] Empirical data gathered from the Sprint and AOL
backbones, October, 2002. backbones, October, 2002.
[RFC2028] Hovey, R. and S. Bradner, "The Organizations [RFC2028] Hovey, R. and S. Bradner, "The Organizations
Involved in the IETF Standards Process", RFC Involved in the IETF Standards Process", BCP 11,
2028/BCP 11, October, 1996. RFC 2028, October 1996.
[RFC2434] Narten, T., and H. Alvestrand, "Guidelines for [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in Writing an IANA Considerations Section in RFCs",
RFCs", RFC 2434/BCP 0026, October, 1998. BCP 26, RFC 2434, October 1998.
[RFC3618] Meyer, D., and W. Fenner (Editors), "The Multicast [RFC3618] Meyer, D. and W. Fenner, Eds., "The Multicast
Source Discovery Protocol (MSDP)", RFC 3618, Source Discovery Protocol (MSDP)", RFC 3618,
October, 2003. October 2003.
8. Author's Addresses 8. Authors' Addresses
Vijay Gill Vijay Gill
Email: vijay@umbc.edu EMail: vijay@umbc.edu
John Heasley John Heasley
Email: heas@shrubbery.net EMail: heas@shrubbery.net
David Meyer David Meyer
Email: dmm@1-4-5.net EMail: dmm@1-4-5.net
9. Full Copyright Statement 9. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
skipping to change at page 13, line 37 skipping to change at page 13, line 39
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
10. Intellectual Property 10. Intellectual Property
 End of changes. 

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