draft-ietf-rtgwg-rfc3682bis-02.txt   draft-ietf-rtgwg-rfc3682bis-03.txt 
INTERNET-DRAFT V. Gill INTERNET-DRAFT V. Gill
draft-ietf-rtgwg-rfc3682bis-02.txt J. Heasley draft-ietf-rtgwg-rfc3682bis-03.txt J. Heasley
D. Meyer D. Meyer
Category Experimental Category Proposed Standard
Expires: October 2004 April 2004 Updates: RFC 3682
Expires: March 2005 September 2004
The Generalized TTL Security Mechanism (GTSM) The Generalized TTL Security Mechanism (GTSM)
<draft-ietf-rtgwg-rfc3682bis-02.txt> <draft-ietf-rtgwg-rfc3682bis-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions Status of this Memo
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering This document is an Internet-Draft and is subject to all
Task Force (IETF), its areas, and its working groups. Note that provisions of section 3 of RFC 3667 [RFC3667]. By submitting
other groups may also distribute working documents as Internet- this Internet-Draft, each author represents that any
Drafts. 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 become aware will be disclosed, in accordance with RFC
3668 [RFC3668].
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are working documents of the Internet
and may be updated, replaced, or obsoleted by other documents at any Engineering Task Force (IETF), its areas, and its working
time. It is inappropriate to use Internet-Drafts as reference groups. Note that other groups may also distribute working
material or to cite them other than as "work in progress." documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use
Internet-Drafts as reference 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/1id-abstracts.html 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
http://www.ietf.org/shadow.html at http://www.ietf.org/shadow.html.
This document is a product of the RTG WG 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
skipping to change at page 2, line 18 skipping to change at page 2, line 23
to protect a protocol stack from CPU-utilization based attacks has to protect a protocol stack from CPU-utilization based attacks has
been proposed in many settings (see for example, RFC 2461). This been proposed in many settings (see for example, RFC 2461). This
document generalizes these techniques for use by other protocols such document generalizes these techniques for use by other protocols such
as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP), as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP),
Bidirectional Forwarding Detection, and Label Distribution Protocol Bidirectional Forwarding Detection, and Label Distribution Protocol
(LDP) (RFC 3036). While the Generalized TTL Security Mechanism (GTSM) (LDP) (RFC 3036). While the Generalized TTL Security Mechanism (GTSM)
is most effective in protecting directly connected protocol peers, it is most effective in protecting directly connected protocol peers, it
can also provide a lower level of protection to multi-hop sessions. can also provide a lower level of protection to multi-hop sessions.
GTSM is not directly applicable to protocols employing flooding GTSM is not directly applicable to protocols employing flooding
mechanisms (e.g., multicast), and use of multi-hop GTSM should be mechanisms (e.g., multicast), and use of multi-hop GTSM should be
considered on a case-by-case basis. considered on a case-by-case basis. This document updates RFC 3682.
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. . . . . . . . . . . . 5 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 . . . . . . . . . . . . . 7
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. . . . . . . . . . . . . . . . . . 8
5.2. Tunneled Packets. . . . . . . . . . . . . . . . . . . . . . 8 5.2. Tunneled Packets. . . . . . . . . . . . . . . . . . . . . . 8
5.2.1. IP in IP . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2.1. IP in IP . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2.2. IP in MPLS . . . . . . . . . . . . . . . . . . . . . . . 9 5.2.2. IP in MPLS . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . . 10 5.3. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . . 11
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 11 6. Applicability Statement. . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References. . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References. . . . . . . . . . . . . . . . . . . 12 8.1. Normative References. . . . . . . . . . . . . . . . . . . . 12
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References. . . . . . . . . . . . . . . . . . . 14
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
10. Intellectual Property . . . . . . . . . . . . . . . . . . . . 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], [RFC1772]) from the router-based infrastructure (e.g., BGP [RFC1771], [RFC1772]) from
a wide 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 from outside the network.
Note, however, that GTSM is not a substitute for authentication
mechanisms. In particular, it does not secure against insider on-the-
wire attacks, such as packet spoofing or replay.
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 BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
skipping to change at page 4, line 38 skipping to change at page 4, line 39
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.
(v) 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, when used with existing protocols, GTSM
protocol peers. That is, no automatic GTSM capability negotiation, will be manually configured between protocol peers. That is, no
such as is envisioned by RFC 2842 [RFC2842] is assumed or defined. automatic GTSM capability negotiation, such as is envisioned by RFC
2842 [RFC2842] is assumed or defined.
If a new protocol is designed with built-in GTSM support, then it is
recommended that procedures are always used for sending and
validating received protocol packets (GTSM is always on, see for
example [RFC2461]). If, however, dynamic negotiation of GTSM support
is necessary, protocol messages used for such negotiation MUST be
authenticated using other security mechanisms to prevent DoS attacks.
Also note that this specification does not offer a generic GTSM
capability negotiation mechanism, so messages of the protocol
augmented with the GTSM behavior will need to be used if dynamic
negotiation is deemed necessary.
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
evolved in both sophistication and access to the point that they can evolved in both sophistication and access to the point that they can
send control traffic to a protocol session, and that this traffic send control traffic to a protocol session, and that this traffic
appears to be valid control traffic (i.e., has the source/destination appears to be valid control traffic (i.e., has the source/destination
of configured peer routers). of configured peer routers).
We also assume that each router in the path between the attacker and We also assume that each router in the path between the attacker and
skipping to change at page 5, line 31 skipping to change at page 5, line 40
from configured peers which do NOT have an inbound TTL of 255. from configured peers which do NOT have an inbound TTL of 255.
GTSM can be disabled for applications such as route-servers and other GTSM can be disabled for applications such as route-servers and other
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 If GTSM is not built into the protocol and used as an additional
describes the per-peer behavior: feature (e.g., for BGPv4, or LDP), it SHOULD NOT be enabled by
default. Each session protected with GTSM is associated with a
variable TrustRadius that denotes the distance from the node
performing the GTSM check to the trusted sources of protocol packets.
(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, srcPort, destination, destPort, TTL>
either be 255 (for a directly connected peer), or tuple. The TTL must either be 255 (for a directly
255-(configured-range-of-acceptable-hops) connected peer), or 255 - TrustRadius for a
for a multi-hop peer. We specify a range here to multi-hop peer. We specify a range here to achieve
achieve some robustness to changes in topology. Any some robustness to changes in topology. Any
directly connected check MUST be disabled for such directly connected (i.e., such as may be used in a
peerings. BGP implementation to determine whether a peer is
directly connected) check MUST be disabled for
such 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 adjacent router to pass allow protocol packets from adjacent router to pass
onto the RP. onto the RP.
(b) If the inbound TTL is less than 255 for a directly (b) Otherwise, a TTL value in a received packet is
connected peer, or less than considered valid if it is not less than
255-(configured-range-of-acceptable-hops) for a (255 - TrustRadius).
multi-hop peer, the packet is NOT processed. Rather,
the packet is placed into a low priority queue, and In summary, if TrustRadius is set to zero for a particular
subsequently logged and/or silently discarded. In session, only packets from directly connected neighbors
this case, an ICMP message MUST NOT be generated. (TTL=255) will be considered valid. As a result,
TrustRadius values greater than 0 will allow packets from
more remote nodes to be accepted.
(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 - TrustRadius. This approach provides a
approach provides a qualitatively lower degree of security for the qualitatively lower degree of security for the protocol implementing
protocol implementing GTSM (i.e., a DoS attack could theoretically be GTSM (i.e., a DoS attack could theoretically be launched by
launched by compromising some box in the path). However, GTSM will compromising some box in the path). However, GTSM will still catch
still catch the vast majority of observed DDoS attacks against a the vast majority of observed DDoS attacks (launched from outside the
given protocol. Note that since the number of hops can change rapidly network) against a given protocol. Note that since the number of hops
in real network situations, it is considered that GTSM may not be can change rapidly in real network situations, it is considered that
able to handle this scenario adequately and an implementation MAY GTSM may not be able to handle this scenario adequately and an
provide OPTIONAL support. implementation MAY 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 SHOULD 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].
4. Acknowledgments 4. Acknowledgments
The use of the TTL field to protect BGP originated with many The use of the TTL field to protect BGP originated with many
different people, including Paul Traina and Jon Stewart. Ryan different people, including Paul Traina and Jon Stewart. Ryan
McDowell also suggested a similar idea. Steve Bellovin, Jay McDowell also suggested a similar idea. Steve Bellovin, Jay
Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Pekka Savola, and Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Pekka
Robert Raszuk also provided useful feedback on earlier versions of Savola, Robert Raszuk aand Alex Zinin lso provided useful
this document. David Ward provided insight on the generalization of feedback on earlier versions of this document. David Ward
the original BGP-specific idea. provided insight on the generalization of the original
BGP-specific idea.
5. Security Considerations 5. Security Considerations
GTSM is a simple procedure that protects single hop protocol GTSM is a simple procedure that protects single hop protocol
sessions, except in those cases in which the peer has been sessions, except in those cases in which the peer has been
compromised. compromised. In particular, it does not protect against the
wide range of on-the-wire attacks; protection from these
attacks requires more rigorous security mechanisms.
5.1. TTL (Hop Limit) Spoofing 5.1. TTL (Hop Limit) Spoofing
The approach described here is based on the observation that a TTL The approach described here is based on the observation that a TTL
(or Hop Limit) value of 255 is non-trivial to spoof, since as the (or Hop Limit) value of 255 is non-trivial to spoof, since as the
packet passes through routers towards the destination, the TTL is packet passes through routers towards the destination, the TTL is
decremented by one. As a result, when a router receives a packet, it decremented by one. As a result, when a router receives a packet, it
may not be able to determine if the packet's IP address is valid, but may not be able to determine if the packet's IP address is valid, but
it can determine how many router hops away it is (again, assuming it can determine how many router hops away it is (again, assuming
none of the routers in the path are compromised in such a way that none of the routers in the path are compromised in such a way that
skipping to change at page 11, line 8 skipping to change at page 12, line 8
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 extensions. Finally, note that in the multi-hop case described
above, 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 robustness to topology changes. This robustness to topological
change comes at the cost of the loss of some robustness to different change comes at the cost of the loss of some robustness to different
forms of attack. forms of attack.
6. IANA Considerations 6. Applicability Statement
As described above, GTSM is only applicable to environments with
inherently limited topologies (and is most effective in those cases
where protocol peers are directly connected). In particular, its
application should be limited to those cases in which protocol peers
are either directly connected, or in which the topology between peers
is fairly static and well known, and in which the intervening network
(between the peers) is trusted.
7. IANA Considerations
This document creates no new requirements on IANA namespaces This document creates no new requirements on IANA namespaces
[RFC2434]. [RFC2434].
7. References 8. References
7.1. Normative References 8.1. Normative References
[RFC791] Postel, J., "Internet Protocol Specification", [RFC791] Postel, J., "Internet Protocol Specification",
STD 5, 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 1995. Gateway Protocol (BGP-4)", RFC 1771, March 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.
skipping to change at page 12, line 20 skipping to change at page 13, line 31
August 2000. August 2000.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette,
A. and B. Thomas, "LDP Specification", RFC 3036, A. and B. Thomas, "LDP Specification", RFC 3036,
January 2001. January 2001.
[RFC3032] Rosen, E. Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E. Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T. and A. Conta, "MPLS Label Farinacci, D., Li, T. and A. Conta, "MPLS Label
Stack Encoding", RFC 3032, January 2001. Stack Encoding", RFC 3032, January 2001.
[RFC3667] Bradner, S., "IETF Rights in Contributions",
BCP 78, RFC 3667, February, 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in
IETF Technology", BCP 79, RFC 3668, February,
2004.
[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 8.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-ietf-bfd-base-00.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
Involved in the IETF Standards Process", BCP 11,
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 RFCs", Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998. BCP 26, RFC 2434, October 1998.
[RFC3618] Meyer, D. and W. Fenner, Eds., "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. Authors' Addresses 9. 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 Intellectual Property Statement
Copyright (C) The Internet Society (2004). 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 translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
10. 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
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
11. Acknowledgement Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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