idnits 2.17.1 draft-ietf-rtgwg-rfc3682bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 543. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 559), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 46. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document obsoletes RFC3682, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2004) is 7162 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3036' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'BFD' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC3618' is defined on line 506, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2842 (Obsoleted by RFC 3392) ** Obsolete normative reference: RFC 2893 (Obsoleted by RFC 4213) ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) -- Possible downref: Non-RFC (?) normative reference: ref. 'SBGP1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SBGP2' == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-00 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT V. Gill 3 draft-ietf-rtgwg-rfc3682bis-04.txt J. Heasley 4 D. Meyer 5 Category Proposed Standard 6 Obsoletes: RFC 3682 7 Expires: March 2005 September 2004 9 The Generalized TTL Security Mechanism (GTSM) 10 12 Status of this Memo 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all 17 provisions of section 3 of RFC 3667 [RFC3667]. By submitting 18 this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is 20 aware have been or will be disclosed, and any of which he or 21 she become aware will be disclosed, in accordance with RFC 22 3668 [RFC3668]. 24 Internet-Drafts are working documents of the Internet 25 Engineering Task Force (IETF), its areas, and its working 26 groups. Note that other groups may also distribute working 27 documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use 32 Internet-Drafts as reference material or to cite them other 33 than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed 39 at http://www.ietf.org/shadow.html. 41 This document is a product of the RTGWG WG. Comments should be 42 addressed to the authors, or the mailing list at rtgwg@ietf.org. 44 Copyright Notice 46 Copyright (C) The Internet Society (2004). All Rights Reserved. 48 Abstract 50 The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) 51 to protect a protocol stack from CPU-utilization based attacks has 52 been proposed in many settings (see for example, RFC 2461). This 53 document generalizes these techniques for use by other protocols such 54 as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP), 55 Bidirectional Forwarding Detection, and Label Distribution Protocol 56 (LDP) (RFC 3036). While the Generalized TTL Security Mechanism (GTSM) 57 is most effective in protecting directly connected protocol peers, it 58 can also provide a lower level of protection to multi-hop sessions. 59 GTSM is not directly applicable to protocols employing flooding 60 mechanisms (e.g., multicast), and use of multi-hop GTSM should be 61 considered on a case-by-case basis. This document obsoletes RFC 62 3682. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Assumptions Underlying GTSM. . . . . . . . . . . . . . . . . . 4 68 2.1. GTSM Negotiation. . . . . . . . . . . . . . . . . . . . . . 4 69 2.2. Assumptions on Attack Sophistication. . . . . . . . . . . . 5 70 3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Multi-hop Scenarios . . . . . . . . . . . . . . . . . . . . 6 72 3.1.1. Intra-domain Protocol Handling . . . . . . . . . . . . . 7 73 4. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 7 74 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 7 75 5.1. TTL (Hop Limit) Spoofing. . . . . . . . . . . . . . . . . . 8 76 5.2. Tunneled Packets. . . . . . . . . . . . . . . . . . . . . . 8 77 5.2.1. IP in IP . . . . . . . . . . . . . . . . . . . . . . . . 9 78 5.2.2. IP in MPLS . . . . . . . . . . . . . . . . . . . . . . . 10 79 5.3. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . . 11 80 6. Applicability Statement. . . . . . . . . . . . . . . . . . . . 12 81 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 8.1. Normative References. . . . . . . . . . . . . . . . . . . . 12 84 8.2. Informative References. . . . . . . . . . . . . . . . . . . 14 85 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 The Generalized TTL Security Mechanism (GTSM) is designed to protect 90 a router's TCP/IP based control plane from CPU-utilization based 91 attacks. In particular, while cryptographic techniques can protect 92 the router-based infrastructure (e.g., BGP [RFC1771], [RFC1772]) from 93 a wide variety of attacks, many attacks based on CPU overload can be 94 prevented by the simple mechanism described in this document. Note 95 that the same technique protects against other scarce-resource 96 attacks involving a router's CPU, such as attacks against processor- 97 line card bandwidth. 99 GTSM is based on the fact that the vast majority of protocol peerings 100 are established between routers that are adjacent [PEERING]. Thus 101 most protocol peerings are either directly between connected 102 interfaces or at the worst case, are between loopback and loopback, 103 with static routes to loopbacks. Since TTL spoofing is considered 104 nearly impossible, a mechanism based on an expected TTL value can 105 provide a simple and reasonably robust defense from infrastructure 106 attacks based on forged protocol packets from outside the network. 107 Note, however, that GTSM is not a substitute for authentication 108 mechanisms. In particular, it does not secure against insider on-the- 109 wire attacks, such as packet spoofing or replay. 111 Finally, the GTSM mechanism is equally applicable to both TTL (IPv4) 112 and Hop Limit (IPv6), and from the perspective of GTSM, TTL and Hop 113 Limit have identical semantics. As a result, in the remainder of this 114 document the term "TTL" is used to refer to both TTL or Hop Limit (as 115 appropriate). 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in BCP 14, RFC 2119 120 [RFC2119]. 122 2. Assumptions Underlying GTSM 124 GTSM is predicated upon the following assumptions: 126 (i) The vast majority of protocol peerings are between adjacent 127 routers [PEERING]. 129 (ii) It is common practice for many service providers to 130 ingress filter (deny) packets that have the provider's 131 loopback addresses as the source IP address. 133 (iii) Use of GTSM is OPTIONAL, and can be configured on a 134 per-peer (group) basis. 136 (iv) The router supports a method of classifying traffic 137 destined for the route processor into interesting/control 138 and not-control queues. 140 (v) The peer routers both implement GTSM. 142 2.1. GTSM Negotiation 144 This document assumes that, when used with existing protocols, GTSM 145 will be manually configured between protocol peers. That is, no 146 automatic GTSM capability negotiation, such as is envisioned by RFC 147 2842 [RFC2842] is assumed or defined. 149 If a new protocol is designed with built-in GTSM support, then it is 150 recommended that procedures are always used for sending and 151 validating received protocol packets (GTSM is always on, see for 152 example [RFC2461]). If, however, dynamic negotiation of GTSM support 153 is necessary, protocol messages used for such negotiation MUST be 154 authenticated using other security mechanisms to prevent DoS attacks. 156 Also note that this specification does not offer a generic GTSM 157 capability negotiation mechanism, so messages of the protocol 158 augmented with the GTSM behavior will need to be used if dynamic 159 negotiation is deemed necessary. 161 2.2. Assumptions on Attack Sophistication 163 Throughout this document, we assume that potential attackers have 164 evolved in both sophistication and access to the point that they can 165 send control traffic to a protocol session, and that this traffic 166 appears to be valid control traffic (i.e., has the source/destination 167 of configured peer routers). 169 We also assume that each router in the path between the attacker and 170 the victim protocol speaker decrements TTL properly (clearly, if 171 either the path or the adjacent peer is compromised, then there are 172 worse problems to worry about). 174 Since the vast majority of our peerings are between adjacent routers, 175 we can set the TTL on the protocol packets to 255 (the maximum 176 possible for IP) and then reject any protocol packets that come in 177 from configured peers which do NOT have an inbound TTL of 255. 179 GTSM can be disabled for applications such as route-servers and other 180 large diameter multi-hop peerings. In the event that an the attack 181 comes in from a compromised multi-hop peering, that peering can be 182 shut down (a method to reduce exposure to multi-hop attacks is 183 outlined below). 185 3. GTSM Procedure 187 If GTSM is not built into the protocol and used as an additional 188 feature (e.g., for BGPv4, or LDP), it SHOULD NOT be enabled by 189 default. Each session protected with GTSM is associated with a 190 variable TrustRadius that denotes the distance from the node 191 performing the GTSM check to the trusted sources of protocol packets. 193 (i) If GTSM is enabled, an implementation performs the 194 following procedure: 196 (a) For directly connected routers, 198 o Set the outbound TTL for the protocol connection to 199 255. 201 o For each configured protocol peer: 203 Update the receive path Access Control List (ACL) 204 or firewall to only allow protocol packets to pass 205 onto the Route Processor (RP) that have the correct 206 207 tuple. The TTL must either be 255 (for a directly 208 connected peer), or 255 - TrustRadius for a 209 multi-hop peer. We specify a range here to achieve 210 some robustness to changes in topology. Any 211 directly connected (i.e., such as may be used in a 212 BGP implementation to determine whether a peer is 213 directly connected) check MUST be disabled for 214 such peerings. 216 It is assumed that a receive path ACL is an ACL 217 that is designed to control which packets are 218 allowed to go to the RP. This procedure will only 219 allow protocol packets from adjacent router to pass 220 onto the RP. 222 (b) Otherwise, a TTL value in a received packet is 223 considered valid if it is not less than 224 (255 - TrustRadius). 226 In summary, if TrustRadius is set to zero for a particular 227 session, only packets from directly connected neighbors 228 (TTL=255) will be considered valid. As a result, 229 TrustRadius values greater than 0 will allow packets from 230 more remote nodes to be accepted. 232 (ii) If GTSM is not enabled, normal protocol behavior is followed. 234 3.1. Multi-hop Scenarios 236 When a multi-hop protocol session is required, we set the expected 237 TTL value to be 255 - TrustRadius. This approach provides a 238 qualitatively lower degree of security for the protocol implementing 239 GTSM (i.e., a DoS attack could theoretically be launched by 240 compromising some box in the path). However, GTSM will still catch 241 the vast majority of observed DDoS attacks (launched from outside the 242 network) against a given protocol. Note that since the number of hops 243 can change rapidly in real network situations, it is considered that 244 GTSM may not be able to handle this scenario adequately and an 245 implementation MAY provide OPTIONAL support. 247 3.1.1. Intra-domain Protocol Handling 249 In general, GTSM SHOULD NOT used for intra-domain protocol peers or 250 adjacencies. The special case of iBGP peers can be protected by 251 filtering at the network edge for any packet that has a source 252 address of one of the loopback addresses used for the intra-domain 253 peering. In addition, the current best practice is to further protect 254 such peers or adjacencies with an MD5 signature [RFC2385]. 256 4. Acknowledgments 258 The use of the TTL field to protect BGP originated with many 259 different people, including Paul Traina and Jon Stewart. Ryan 260 McDowell also suggested a similar idea. Steve Bellovin, Jay 261 Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Pekka Savola, 262 Robert Raszuk and Alex Zinin also provided useful feedback on earlier 263 versions of this document. David Ward provided insight on the 264 generalization of the original BGP-specific idea. 266 5. Security Considerations 268 GTSM is a simple procedure that protects single hop protocol 269 sessions, except in those cases in which the peer has been 270 compromised. In particular, it does not protect against the wide 271 range of on-the-wire attacks; protection from these attacks requires 272 more rigorous security mechanisms. 274 5.1. TTL (Hop Limit) Spoofing 276 The approach described here is based on the observation that a TTL 277 (or Hop Limit) value of 255 is non-trivial to spoof, since as the 278 packet passes through routers towards the destination, the TTL is 279 decremented by one. As a result, when a router receives a packet, it 280 may not be able to determine if the packet's IP address is valid, but 281 it can determine how many router hops away it is (again, assuming 282 none of the routers in the path are compromised in such a way that 283 they would reset the packet's TTL). 285 Note, however, that while engineering a packet's TTL such that it has 286 a particular value when sourced from an arbitrary location is 287 difficult (but not impossible), engineering a TTL value of 255 from 288 non-directly connected locations is not possible (again, assuming 289 none of the directly connected neighbors are compromised, the packet 290 hasn't been tunneled to the decapsulator, and the intervening routers 291 are operating in accordance with RFC 791 [RFC791]). 293 5.2. Tunneled Packets 295 An exception to the observation that a packet with TTL of 255 is 296 difficult to spoof occurs when a protocol packet is tunneled to a 297 decapsulator who then forwards the packet to a directly connected 298 protocol peer. In this case the decapsulator (tunnel endpoint) can 299 either be the penultimate hop, or the last hop itself. A related case 300 arises when the protocol packet is tunneled directly to the protocol 301 peer (the protocol peer is the decapsulator). 303 When the protocol packet is encapsulated in IP, it is possible to 304 spoof the TTL. It may also be impossible to legitimately get the 305 packet to the protocol peer with a TTL of 255, as in the IP in MPLS 306 cases described below. 308 Finally, note that the security of any tunneling technique depends 309 heavily on authentication at the tunnel endpoints, as well as how the 310 tunneled packets are protected in flight. Such mechanisms are, 311 however, beyond the scope of this memo. 313 5.2.1. IP in IP 315 Protocol packets may be tunneled over IP directly to a protocol peer, 316 or to a decapsulator (tunnel endpoint) that then forwards the packet 317 to a directly connected protocol peer (e.g., in IP-in-IP [RFC2003], 318 GRE [RFC2784], or various forms of IPv6-in-IPv4 [RFC2893]). These 319 cases are depicted below. 321 Peer router ---------- Tunnel endpoint router and peer 322 TTL=255 [tunnel] [TTL=255 at ingress] 323 [TTL=255 at egress] 325 Peer router ---------- Tunnel endpoint router ----- On-link peer 326 TTL=255 [tunnel] [TTL=255 at ingress] [TTL=254 at ingress] 327 [TTL=254 at egress] 329 In the first case, in which the encapsulated packet is tunneled 330 directly to the protocol peer, the encapsulated packet's TTL can be 331 set arbitrary value. In the second case, in which the encapsulated 332 packet is tunneled to a decapsulator (tunnel endpoint) which then 333 forwards it to a directly connected protocol peer, RFC 2003 specifies 334 the following behavior: 336 When encapsulating a datagram, the TTL in the inner IP 337 header is decremented by one if the tunneling is being 338 done as part of forwarding the datagram; otherwise, the 339 inner header TTL is not changed during encapsulation. If 340 the resulting TTL in the inner IP header is 0, the 341 datagram is discarded and an ICMP Time Exceeded message 342 SHOULD be returned to the sender. An encapsulator MUST 343 NOT encapsulate a datagram with TTL = 0. 345 Hence the inner IP packet header's TTL, as seen by the decapsulator, 346 can be set to an arbitrary value (in particular, 255). As a result, 347 it may not be possible to deliver the protocol packet to the peer 348 with a TTL of 255. 350 5.2.2. IP in MPLS 352 Protocol packets may also be tunneled over MPLS to a protocol peer 353 which either the penultimate hop (when the penultimate hop popping 354 (PHP) is employed [RFC3032]), or one hop beyond the penultimate hop. 355 These cases are depicted below. 357 Peer router ---------- Penultimate Hop (PH) and peer 358 TTL=255 [tunnel] [TTL=255 at ingress] 359 [TTL<=254 at egress] 361 Peer router ---------- Penultimate Hop -------- On-link peer 362 TTL=255 [tunnel] [TTL=255 at ingress] [TTL <=254 at ingress] 363 [TTL<=254 at egress] 365 TTL handling for these cases is described in RFC 3032. RFC 3032 366 states that when the IP packet is first labeled: 368 ... the TTL field of the label stack entry MUST BE set to the 369 value of the IP TTL field. (If the IP TTL field needs to be 370 decremented, as part of the IP processing, it is assumed that 371 this has already been done.) 373 When the label is popped: 375 When a label is popped, and the resulting label stack is empty, 376 then the value of the IP TTL field SHOULD BE replaced with the 377 outgoing TTL value, as defined above. In IPv4 this also 378 requires modification of the IP header checksum. 380 where the definition of "outgoing TTL" is: 382 The "incoming TTL" of a labeled packet is defined to be the 383 value of the TTL field of the top label stack entry when the 384 packet is received. 386 The "outgoing TTL" of a labeled packet is defined to be the larger of: 388 a) one less than the incoming TTL, 389 b) zero. 391 In either of these cases, the minimum value by which the TTL could be 392 decremented would be one (the network operator prefers to hide its 393 infrastructure by decrementing the TTL by the minimum number of LSP 394 hops, one, rather than decrementing the TTL as it traverses its MPLS 395 domain). As a result, the maximum TTL value at egress from the MPLS 396 cloud is 254 (255-1), and as a result the check described in section 397 3 will fail. 399 5.3. Multi-Hop Protocol Sessions 401 While the GTSM method is less effective for multi-hop protocol 402 sessions, it does close the window on several forms of attack. 403 However, in the multi-hop scenario GTSM is an OPTIONAL extension. 404 Protection of the protocol infrastructure beyond what is provided by 405 the GTSM method will likely require cryptographic machinery such as 406 is envisioned by Secure BGP (S-BGP) [SBGP1,SBGP2], and/or other 407 extensions. Finally, note that in the multi-hop case described 408 above, we specify a range of acceptable TTLs in order to achieve some 409 robustness to topology changes. This robustness to topological 410 change comes at the cost of the loss of some robustness to different 411 forms of attack. 413 6. Applicability Statement 415 As described above, GTSM is only applicable to environments with 416 inherently limited topologies (and is most effective in those cases 417 where protocol peers are directly connected). In particular, its 418 application should be limited to those cases in which protocol peers 419 are either directly connected, or in which the topology between peers 420 is fairly static and well known, and in which the intervening network 421 (between the peers) is trusted. 423 7. IANA Considerations 425 This document creates no new requirements on IANA namespaces 426 [RFC2434]. 428 8. References 430 8.1. Normative References 432 [RFC791] Postel, J., "Internet Protocol Specification", 433 STD 5, RFC 791, September 1981. 435 [RFC1771] Rekhter, Y. and T. Li (Editors), "A Border 436 Gateway Protocol (BGP-4)", RFC 1771, March 1995. 438 [RFC1772] Rekhter, Y. and P. Gross, "Application of the 439 Border Gateway Protocol in the Internet", RFC 440 1772, March 1995. 442 [RFC2003] Perkins, C., "IP Encapsulation with IP", RFC 443 2003, October 1996. 445 [RFC2119] Bradner, S., "Key words for use in RFCs to 446 Indicate Requirement Levels", BCP 14, RFC 2119, 447 March 1997. 449 [RFC2385] Heffernan, A., "Protection of BGP Sessions via 450 the TCP MD5 Signature Option", RFC 2385, August 451 1998. 453 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, 454 "Neighbor Discover for IP Version 6 (IPv6)", RFC 455 2461, December 1998. 457 [RFC2784] Farinacci, D., "Generic Routing Encapsulation 458 (GRE)", RFC 2784, March 2000. 460 [RFC2842] Chandra, R. and J. Scudder, "Capabilities 461 Advertisement with BGP-4", RFC 2842, May 2000. 463 [RFC2893] Gilligan, R. and E. Nordmark, "Transition 464 Mechanisms for IPv6 Hosts and Routers", RFC 2893, 465 August 2000. 467 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, 468 A. and B. Thomas, "LDP Specification", RFC 3036, 469 January 2001. 471 [RFC3032] Rosen, E. Tappan, D., Fedorkow, G., Rekhter, Y., 472 Farinacci, D., Li, T. and A. Conta, "MPLS Label 473 Stack Encoding", RFC 3032, January 2001. 475 [RFC3667] Bradner, S., "IETF Rights in Contributions", 476 BCP 78, RFC 3667, February, 2004. 478 [RFC3668] Bradner, S., "Intellectual Property Rights in 479 IETF Technology", BCP 79, RFC 3668, February, 480 2004. 482 [SBGP1] Kent, S., C. Lynn, and K. Seo, "Secure Border 483 Gateway Protocol (Secure-BGP)", IEEE Journal on 484 Selected Areas in Communications, volume 18, 485 number 4, April 2000. 487 [SBGP2] Kent, S., C. Lynn, J. Mikkelson, and K. Seo, 488 "Secure Border Gateway Protocol (S-BGP) -- Real 489 World Performance and Deployment Issues", 490 Proceedings of the IEEE Network and Distributed 491 System Security Symposium, February, 2000. 493 8.2. Informative References 495 [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding 496 Detection", draft-ietf-bfd-base-00.txt, Work in 497 Progress. 499 [PEERING] Empirical data gathered from the Sprint and AOL 500 backbones, October, 2002. 502 [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for 503 Writing an IANA Considerations Section in RFCs", 504 BCP 26, RFC 2434, October 1998. 506 [RFC3618] Meyer, D. and W. Fenner, Eds., "The Multicast 507 Source Discovery Protocol (MSDP)", RFC 3618, 508 October 2003. 510 9. Authors' Addresses 512 Vijay Gill 513 EMail: vijay@umbc.edu 515 John Heasley 516 EMail: heas@shrubbery.net 518 David Meyer 519 EMail: dmm@1-4-5.net 521 Intellectual Property Statement 523 The IETF takes no position regarding the validity or scope of any 524 Intellectual Property Rights or other rights that might be claimed to 525 pertain to the implementation or use of the technology described in 526 this document or the extent to which any license under such rights 527 might or might not be available; nor does it represent that it has 528 made any independent effort to identify any such rights. Information 529 on the procedures with respect to rights in RFC documents can be 530 found in BCP 78 and BCP 79. 532 Copies of IPR disclosures made to the IETF Secretariat and any 533 assurances of licenses to be made available, or the result of an 534 attempt made to obtain a general license or permission for the use of 535 such proprietary rights by implementers or users of this 536 specification can be obtained from the IETF on-line IPR repository at 537 http://www.ietf.org/ipr. 539 The IETF invites any interested party to bring to its attention any 540 copyrights, patents or patent applications, or other proprietary 541 rights that may cover technology that may be required to implement 542 this standard. Please address the information to the IETF at 543 ietf-ipr@ietf.org. 545 Disclaimer of Validity 547 This document and the information contained herein are provided on an 548 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 549 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 550 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 551 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 552 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 553 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 555 Copyright Statement 557 Copyright (C) The Internet Society (2004). This document is subject 558 to the rights, licenses and restrictions contained in BCP 78, and 559 except as set forth therein, the authors retain all their rights. 561 Acknowledgment 563 Funding for the RFC Editor function is currently provided by the 564 Internet Society.