idnits 2.17.1 draft-ietf-mboned-imrp-some-issues-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages -- Found 12 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (1997 March 1997) is 7916 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: 'CERTCA9501' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'RFC1636' is defined on line 432, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BELLOVIN89' == Outdated reference: A later version (-09) exists of draft-ietf-idmr-cbt-spec-06 ** Downref: Normative reference to an Historic draft: draft-ietf-idmr-cbt-spec (ref. 'CBT') -- Possible downref: Non-RFC (?) normative reference: ref. 'CERTCA9501' == Outdated reference: A later version (-11) exists of draft-ietf-idmr-dvmrp-v3-03 ** Downref: Normative reference to an Informational draft: draft-ietf-idmr-dvmrp-v3 (ref. 'DVMRP') ** Downref: Normative reference to an Experimental draft: draft-harney-gkmp-arch (ref. 'GKMPID') -- Possible downref: Non-RFC (?) normative reference: ref. 'HDVMRP' -- Possible downref: Non-RFC (?) normative reference: ref. 'LABOV97' == Outdated reference: A later version (-05) exists of draft-ietf-idmr-pim-arch-04 -- Possible downref: Normative reference to a draft: ref. 'PIMARCH' -- No information found for draft-ietf-idmr-PIM-DM-spec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PIM-DM' -- No information found for draft-ietf-idmr-PIMBR-spec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PIMMBR' -- No information found for draft-ietf-idmr-PIM-SM-spec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PIM-SM' -- No information found for draft-thaler-interop - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'THALER96' -- Possible downref: Non-RFC (?) normative reference: ref. 'ESTRIN97' ** Downref: Normative reference to an Informational RFC: RFC 1636 ** Downref: Normative reference to an Informational RFC: RFC 1704 ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) ** Downref: Normative reference to an Experimental RFC: RFC 1949 ** Downref: Normative reference to an Informational RFC: RFC 2104 -- No information found for draft-ietf-idr-rout-dampen - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'VILLAM95' Summary: 19 errors (**), 0 flaws (~~), 8 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBONE Deployment Working Group David Meyer 2 Internet Draft University of Oregon 3 Expiration Date: September 1997 March 1997 5 Some Issues for an Inter-domain Multicast Routing Protocol 7 draft-ietf-mboned-imrp-some-issues-01.txt 9 1. Status Of This Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 2. Introduction 29 The IETF's Inter-Domain Multicast Routing (IDMR) working group has 30 produced several multicast routing protocols, including Core Based 31 Trees [CBT] and Protocol Independent Multicasting [PIMARCH]. In 32 addition, the IDMR WG has formalized the specification of the 33 Distance Vector Multicast Routing Protocol [DVMRP]. Various 34 specifications for protocol inter-operation have also been produced 35 (see, for example, [THALER96] and [PIMMBR]). However, none of these 36 protocols seems ideally suited to the inter-domain routing case; that 37 is, while these protocols are appropriate for the intra-domain 38 routing environment, they break down in various ways when applied in 39 to the multi-provider inter-domain case. 41 This document considers some of the scaling, stability and policy 42 issues that are of primary importance in a inter-domain, multi- 43 provider multicast environment. 45 3. Forwarding State Requirements 47 Any scalable protocol will have to minimize forwarding state 48 requirements. In the case of dense mode protocols [DVMRP,PIM-DM], 49 routers may carry forwarding or prune state for every (S,G) pair in 50 the Internet. This is true even for routers that may not be on any 51 delivery tree. It seems likely that as multicast deployment scales to 52 the size of the Internet, maintenance of (S,G) state will become 53 intractable. 55 Shared tree protocols, on the other hand, have the advantage of 56 maintaining a single (*,G) entry for a group's receivers (thus 57 relaxing the requirement of maintaining (S,G) for the entire 58 Internet). However, this is not without its own disadvantages; see 59 the section on "Third-party Resource Dependencies" below. 61 4. Forwarding State Distribution 63 The objective of a multicast forwarding state distribution mechanism 64 is to ensure that multicast traffic is efficiently distributed to 65 those parts of the topology where there are receivers. Dense and 66 sparse mode protocols will accept differing overheads based on design 67 tradeoffs. In the dense mode case, the data-driven nature state 68 distribution has disadvantage that data is periodically distributed 69 to branches of the distribution tree which don't have receivers 70 ("Flood and Prune" behavior). It seems unlikely that this mechanism 71 will be scalable to Internet-wide case. 73 On the other hand, sparse mode protocols use receiver-initiated, 74 explicit joins to establish a forwarding path along a shared 75 distribution tree. While the on-demand nature of sparse mode 76 protocols have favorable properties with respect to distribution of 77 forwarding state, it also has the possible disadvantage of creating 78 dependencies on shared resources (again, see the section on "Third- 79 Party Resource Dependencies" below). 81 5. Forwarding State Maintenance 83 The many current multicast protocols attempt to accurately and 84 rapidly maintain distribution trees that are as close to the tree of 85 shortest-path routes (as defined by unicast) as possible. This means 86 that the shape of a distribution tree can be rapidly changing. In 87 addition, since distribution trees can be global, they can be subject 88 to high frequency control traffic. 90 In contrast, the focus in the inter-domain unicast routing 91 environment is on minimizing routing traffic (see, for example, 92 [VILLAM95]), and controlling stability [LABOV97]. The implication is 93 that protocol overhead and stability must be controlled if we hope 94 multicast to scale to Internet sizes. Thus it seems likely that 95 Inter-domain multicast routing protocols will have to do less 96 forwarding state maintenance, and hence be less aggressive in 97 reshaping distribution trees. Note that this reshaping is related to 98 what has been termed "routing flux" (again, see [LABOV97]), since the 99 routing traffic does not directly affect path selection. Rather, the 100 primary effect is to require significant processing resources in a 101 border router. Finally, note that unlike the unicast case, we do not 102 have good data characterizing this effect for multicast routers. 104 5.1. Bursty Source Problem 106 When a source's inter-burst period is longer than the router state 107 timeout period, some or all of a source's packets can be lost. This 108 effect has been termed the "Bursty Source Problem" [ESTRIN97]. The 109 current set of multicast routing protocols attempt, where possible, 110 to avoid this problem (i.e., maximize response to bursty sources). 112 6. Mixed Control 114 Mixing control of topology discovery and distribution tree 115 construction can lead to efficiencies but also imposes various 116 constraints on topology discovery mechanisms. For example, DVMRP 117 [DVMRP] uses topology discovery facilities ("split horizon with 118 poison reverse") to eliminate duplicate packets on a LAN, and to 119 detect non-leaf networks (an upstream router uses this information 120 when pruning downstream interfaces). 122 On the other hand, PIM [PIM-DM] does not use any topology discovery 123 algorithm features when building delivery trees. However, this 124 independence is not without cost: PIM-DM accepts some duplicates on 125 multi-access LANs as a tradeoff for reduced protocol complexity. 127 7. Neighbor Model 129 The current inter-domain unicast routing model has some key 130 differences with proposed inter-domain multicast routing models with 131 respect to neighbor (peer) discovery. In particular, the current set 132 of multicast protocols depend heavily on dynamic neighbor discovery. 133 This is analogous to the situation with intra-domain unicast routing, 134 but is unlike current inter-domain unicast routing, where neighbors 135 are typically statically configured. 137 The static neighbor configuration model has several benefits for 138 inter-domain routing. First, neighbors are predefined, which is a 139 policy requirement in most cases. In addition, the set of peers in 140 the inter-domain unicast routing system defines the set of possible 141 inter-domain topologies (with the current active topology represented 142 by the collection of AS paths). 144 Another important difference relates to how inter-domain regions are 145 modeled. For purposes of this document, consider an inter-domain 146 region defined to be a part of an arbitrary topology in which a 147 higher level (inter-domain) routing protocol is used to calculate 148 paths between regions. In addition, each pair of adjacent regions is 149 connected by one or more multicast border routers. Current IDMR 150 proposals (e.g., [HDVMRP], [THALER96]) model an inter-domain region 151 as a routing domain. That is, border routers internetwork between one 152 or more intra-domain regions and an inter-domain region (again, 153 possibly more than one). In this model, inter-networking occurs 154 "inside" router. However, the inter-provider unicast routing model in 155 use today is quite different. In particular, the "peering" between 156 two providers occurs in neither of the provider's routing domains, 157 nor does it occur in some shared "inter-domain" routing domain. The 158 separation provides the administrative and policy control that is 159 required in today's Internet. 161 8. Unicast Topology Dependency 163 Ideally, unicast and multicast topologies are congruent in the 164 Internet. However, since it is frequently difficult to field new 165 facilities (such as IP multicast) in the "core" the Internet 166 infrastructure, there will continue to be many cases in which unicast 167 and multicast topologies are not congruent (either because a region 168 is not multicast capable at all, or because the region is not 169 natively forwarding multicast traffic). Thus, it is unlikely that the 170 entire IPv4 Internet will be able to carry native multicast traffic 171 in the foreseeable future. In addition, various policy requirements 172 will in certain cases cause to topologies to further diverge. The 173 implication is that a successful IDMR will need a topology discover 174 mechanism, or have other mechanisms for dealing with those cases in 175 which unicast and multicast topologies are not congruent. 177 8.1. Multicast Policies and Unicast Routes 179 Multicast and unicast packet forwarding algorithms assign different 180 semantics to a unicast route. In particular, if a router B accepts a 181 route from router A covering prefix P, then B will to forward packets 182 "to" those destinations covered by P, using A as the next hop when 183 forwarding unicast packets. However, in the multicast case, the same 184 route means B will accept packets "from" sources covered by P (though 185 not necessarily from A, but through the same interface as is used to 186 reach A). It is this difference in unicast route semantics that makes 187 formulation of precise multicast policy difficult. 189 9. Third-Party Resource Dependencies 191 Shared tree protocols require one or more globally shared Rendezvous 192 Points (RPs) [PIM-SM] or Cores [CBT]. The RP or Core effectively 193 serves as the root of a group specific shared tree. Data is sent to 194 the RP/Core for delivery on the shared tree. This means that some 195 groups may have an RP (or core) that is fielded by a third party. For 196 example, if providers A, B and C share a PIM-SM inter-domain region, 197 then there may exist an RP that is mapped to C's multicast border 198 router. In this case, C is hosting a kind of "transit RP" for A and B 199 (A and B register to C to communicate between themselves, even if C 200 has no receivers for the group(s) served by the RP. 202 10. Traffic Concentration Problem 204 Traffic can be "concentrated" on a shared tree. This can lead to 205 increased latency or packet loss. However, this is less of a problem 206 in the shared-media exchange point environment. 208 11. Distant RP/Core Problem 210 In the shared tree model, if the RP or Core is distant 211 (topologically), then joins will travel to the distant RP/Core, even 212 if the data is being delivered locally. Note that this problem will 213 be exacerbated if the RP/Core space is global; if a router is 214 registering to a RP/Core that is not in the local domain (say, 215 fielded by the site's direct provider), then the routing domain is 216 flat. 218 12. Multicast Internal Gateway Protocol (MIGP) Independence 220 A shared tree, explicit join protocol inter-domain routing protocol 221 may require modification to a leaf domain's internal multicast 222 routing mechanism. The problem arises when a domain is running a 223 "flood and prune" protocol such as DVMRP or PIM-DM internally while 224 participating in a shared tree inter-domain protocol. In this case, 225 there can be areas of the (internal) topology that has receivers but 226 will not receive inter-domain traffic. 228 [THALER96] describes interoperability rules to alleviate this 229 problem. Consider the case where a border router has interfaces in an 230 inter-domain shared tree region and a DVMRP region. The rules 231 covering this case state that either the DVMRP region must implement 232 Region Wide Reports [HDVMRP], or the DVMRP component of the border 233 router must be a wildcard receiver for externally reached sources, 234 while the shared tree component is a wildcard receiver for internally 235 reached sources. Alternatively, many current implementations use a 236 "receiver-is-sender" approach (which depends for the most part on 237 RTCP reports) to get around this problem. 239 13. Encapsulations 241 Encapsulations should be minimized where ever possible. PIM-SM 242 encapsulates packets sent to the shared tree in PIM Register messages 243 (data can be delivered natively if the last hop router or the RP 244 switches to the shortest path tree). The design of an shared tree 245 inter-domain protocol should avoid the "O(N) Encapsulation" problem: 246 For paths that traverse N administrative domains, the number of 247 encapsulations can approach O(N). 249 14. Policy Provisions 251 Current inter-domain unicast routing protocols have a rich and well 252 developed policy model. In contrast, multicast routing protocols 253 have little or no provision for implementing routing policy 254 (administrative scoping is one major exception). A concrete example 255 of this need is the various problems with inadvertent injection of 256 unicast routing tables into the MBONE, coupled with our inability to 257 propagate the resultant large DVMRP routing tables, point out the 258 need for such policy oriented controls. 260 A simple example illustrates why a successful inter-domain multicast 261 routing protocol will need to have a well developed policy model: 262 Consider three providers, A, B, and C, that have connections to a 263 shared-media exchange point. Assume that connectivity is non- 264 transitive due to some policy (the common case, since bi-lateral 265 agreements are a very common form of peering agreement). That is, A 266 and B are peers, B and C are peers, but A and C are not peers. Now, 267 consider a source S covered by a prefix P, where P belongs to a 268 customer of A (i.e., P is advertised by A). Now, multicast packets 269 forwarded by A's border router will be correctly accepted by B's 270 border router, since it sees the RPF interface for P to be the 271 shared-media of the exchange. Likewise, C's border router will reject 272 the packets forwarded by A's border router because, by definition, 273 C's border router does not have A's routes through its interface on 274 the exchange (so packets sourced "inside" A fail the RPF check in C's 275 border router). 277 In the example above, RPF is a powerful enough mechanism to inform C 278 that it should not accept packets sourced in P from A over the 279 exchange. However, consider the common case in which P is multi- 280 homed to both A and B. C now sees a route for P from B though its 281 interface on the exchange. Without some form of multi-provider 282 cooperation and/or packet filtering (or a more sophisticated RPF 283 mechanism), C could accept multicast packets sourced by S from A 284 across the shared media exchange, even though A and C have not 285 entered into any agreement on the exchange. The situation described 286 above is caused by the overloading of the semantics of unicast route 287 (as described above), and the reliance on the RPF check as a policy 288 mechanism. 290 14.1. "Wrong" RPF Neighbor 292 The example above illustrates a the problem that, in most current 293 implementations, the RPF check considers only the incoming interface, 294 and not the upstream neighbor (RPF neighbor). This can result in 295 accepting packets from the "wrong" RPF neighbor (the neighbor is 296 "wrong" since, while the RPF check succeeds and the packet is 297 forwarded, the unicast policy would not have forwarded the packet). 299 14.2. RPF as a Policy Mechanism 301 In the example above, C is relying on its RPF check to protect it 302 from A's packets. However, not only is RPF too weak enough to cover 303 those cases in which a source prefix is multi-homed (as described in 304 the example above), it is essentially a packet filter and as such is 305 not an attractive policy mechanism. 307 15. Today's MBONE 309 Another way to view the policy issues described above is to consider 310 the perspective of unicast reachability. Today's MBONE is comprised 311 of a single flat AS. Further, this AS running a simple distance 312 vector topology discovery protocol. This arrangement is unlikely to 313 scale gracefully or provide the same rich policy control that we find 314 in the unicast Internet. There are additional problems with a flat AS 315 model: the flat AS model fits neither the operational or 316 organizational models commonly found in Internet today. 318 16. Equal Cost Multipath 320 A common way to incrementally scale available bandwidth is to provide 321 parallel equal cost paths. It would be an advantage if a multicast 322 routing protocol could support this. However, this would seem 323 difficult to achieve when using Reverse Path Forwarding, so it is 324 unclear whether this goal is achievable. 326 17. Conclusion 328 Deployment of a general purpose IP multicast infrastructure for the 329 Internet has been slowed by various factors. One of the primary 330 reasons, however, is the lack of a true inter-domain Multicast 331 Routing Protocol. Several proposals have been advanced to solve this 332 problem, including PIM-SM [PIM-SM], DVMRP [PIMMBR], and Hierarchical 333 DVMRP [HDVMRP]. However, the concerns outlined above have prevented 334 any of these protocols from being adopted as the standard inter- 335 domain multicast routing protocol. Finally, it is worth noting that 336 DVMRP, since it is the common denominator among router vendor 337 offerings, is currently the de-facto inter-domain routing protocol. 339 18. Security Considerations 341 Historically, routing protocols used within the Internet have lacked 342 strong authentication mechanisms [RFC1704]. In the late 1980s, 343 analysis revealed that there were a number of security problems in 344 Internet routing protocols then in use [BELLOVIN89]. During the 345 early 1990s it became clear that adversaries were selectively 346 attacking various intra-domain and inter-domain routing protocols 347 (e.g. via TCP session stealing of BGP sessions) [CERTCA9501, 348 RFC1636]. More recently, cryptographic authentication mechanisms have 349 been developed for RIPv2, OSPF, and the proprietary EIGRP routing 350 protocols. BGP protection, in the form of a Keyed MD5 option for 351 TCP, has also become widely deployed. 353 At present, most multicast routing protocols lack strong 354 cryptographic protection. One possible approach to this is to 355 incorporate a strong cryptographic protection mechanism (e.g. Keyed 356 HMAC MD5 [RFC2104]) within the routing protocol itself. Alternately, 357 the routing protocol could be designed and specified to use the IP 358 Authentication Header (AH) [RFC1825, RFC1826, RFC2085] to provide 359 cryptographic authentication. 361 Because the intent of any routing protocol is to propagate routing 362 information to other parties, confidentiality is not generally 363 required in routing protocols. In those few cases where local 364 security policy might require confidentiality, the use of the IP 365 Encapsulating Security Payload (ESP) [RFC1825, RFC1827] is 366 recommended. 368 Scalable dynamic multicast key management is an active research area 369 at this time. Candidate technologies for scalable dynamic multicast 370 key management include CBT-based key management [RFC1949] and the 371 Group Key Management Protocol (GKMP) [GKMPID]. The IETF IP Security 372 Working Group is actively working on GKMP extensions to the 373 standards-track ISAKMP key management protocol being developed in the 374 same working group. 376 19. References 378 [BELLOVIN89] S. Bellovin, "Security Problems in the TCP/IP 379 Protocol Suite", ACM Computer Communications Review, 380 Volume 19, Number 2, pp. 32-48, April 1989. 382 [CBT] A. Ballardie, et. al., "Core Based Trees (CBT) 383 Multicast -- Protocol Specification --", 384 draft-ietf-idmr-cbt-spec-06.txt, September, 1996. 386 [CERTCA9501] CERT, "IP Spoofing Attacks and Hijacked Terminal 387 Connections", ftp://ftp.cert.org/cert_advisories/, 388 January 1995. 390 [DVMRP] T. Pusateri, "Distance Vector Multicast Routing 391 Protocol", draft-ietf-idmr-dvmrp-v3-03, September, 392 1996. 394 [GKMPID] H. Harney, "Group Key Management Protocol (GKMP)", 395 draft-harney-gkmp-arch-01.txt && 396 draft-harney-gkmp-spec-01.txt, August 1996, 397 Informational RFC publication is pending. 399 [HDVMRP] A. Thyagarajan and Steve Deering, "Hierarchical 400 Distance-Vector Multicast Routing for the MBone", In 401 Proceedings of the ACM SIGCOMM, pages 60-66, 402 October, 1995. 404 [LABOV97] C. Labovitz, et. al., "Internet Routing 405 Instability", Submitted to SIGCOMM97. 407 [PIMARCH] D. Estrin, et. al., "Protocol Independent Multicast 408 Sparse Mode (PIM-SM): Motivation and Architecture", 409 draft-ietf-idmr-pim-arch-04.ps , October, 1996. 411 [PIM-DM] D. Estrin, et. al., "Protocol Independent Multicast 412 Dense Mode (PIM-DM): Protocol Specification", 413 draft-ietf-idmr-PIM-DM-spec-04.ps, September, 1996. 415 [PIMMBR] D. Estrin, et. al., "PIM Multicast Border Router 416 (PMBR) specification for connecting PIM-SM domains 417 to a DVMRP Backbone", draft-ietf-idmr-PIMBR-spec-01.ps, 418 September, 1996. 420 [PIM-SM] D. Estrin, et. al., "Protocol Independent Multicast 421 Sparse Mode (PIM-SM): Protocol Specification", 422 draft-ietf-idmr-PIM-SM-spec-09.ps, October, 1996. 424 [THALER96] D. Thaler, "Interoperability Rules for Multicast 425 Routing Protocols", draft-thaler-interop-00.ps, 426 November, 1996. 428 [ESTRIN97] D. Estrin, et. al., "A Dynamic Bootstrap Mechanism 429 for Rendezvous-based Multicast Routing", USC/ISI 430 Technical Report, 1997. 432 [RFC1636] Braden, R., Clark, D., Crocker, S., and C. Huitema, 433 "Report of IAB Workshop on Security in the Internet 434 Architecture", RFC1636, June 1994. 436 [RFC1704] N. Haller and R. Atkinson, "On Internet 437 Authentication", RFC1704, October 1994. 439 [RFC1825] Atkinson, R., "IP Security Architecture", August 1995. 441 [RFC1826] Atkinson, R., "IP Authentication Header", August 1995. 443 [RFC1827] Atkinson, R., "IP Encapsulating Security Payload", 444 August 1995. 446 [RFC1949] A. Ballardie, "Scalable Multicast Key Distribution", 447 RFC1949, June 1996. 449 [RFC2085] M. Oehler & R. Glenn, "HMAC-MD5 IP Authentication 450 with Replay Prevention", February 1997. 452 [RFC2104] H. Krawczyk, M. Bellare, & R. Canetti, "HMAC: Keyed 453 Hashing for Message Authentication", RFC2104, 454 February 1997. 456 [VILLAM95] C. Villamizar, Ravi Chandra, and Ramesh Govindan, 457 "Controlling BGP/IDRP Routing Overhead", 458 draft-ietf-idr-rout-dampen-00.ps, July, 1995. 460 20. Acknowledgments 462 Dino Farinacci, Dave Thaler, and Yakov Rekhter provided several 463 insightful comments on earlier versions of this document. Ran 464 Atkinson contributed most of the security ideas contained in this 465 document. 467 21. Author Information 469 David Meyer 470 University of Oregon 471 1225 Kincaid St. 472 Eugene, OR 97403 473 Phone: (541) 346-1747 474 e-mail: meyer@antc.uoregon.edu