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