idnits 2.17.1 draft-ietf-mboned-imrp-some-issues-03.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-23) 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 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 (November 1997) is 9656 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 387, but no explicit reference was found in the text == Unused Reference: 'RFC1636' is defined on line 433, 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 (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONE Deployment Working Group David Meyer 3 Internet Draft University of Oregon 4 November 1997 6 Some Issues for an Inter-domain Multicast Routing Protocol 8 draft-ietf-mboned-imrp-some-issues-03.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 ("Flood and Prune" behavior). It seems unlikely that this mechanism 72 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. Bursty Source Problem 107 When a source's inter-burst period is longer than the router state 108 timeout period, some or all of a source's packets can be lost. This 109 effect has been termed the "Bursty Source Problem" [ESTRIN97]. The 110 current set of multicast routing protocols attempt, where possible, 111 to avoid this problem (i.e., maximize response to bursty sources). 113 6. Mixed Control 115 Mixing control of topology discovery and distribution tree 116 construction can lead to efficiencies but also imposes various 117 constraints on topology discovery mechanisms. For example, DVMRP 118 [DVMRP] uses topology discovery facilities ("split horizon with 119 poison reverse") to eliminate duplicate packets on a LAN, and to 120 detect non-leaf networks (an upstream router uses this information 121 when pruning downstream interfaces). 123 On the other hand, PIM [PIM-DM] does not use any topology discovery 124 algorithm features when building delivery trees. However, this 125 independence is not without cost: PIM-DM accepts some duplicates on 126 multi-access LANs as a tradeoff for reduced protocol complexity. 128 7. Neighbor Model 130 The current inter-domain unicast routing model has some key 131 differences with proposed inter-domain multicast routing models with 132 respect to neighbor (peer) discovery. In particular, the current set 133 of multicast protocols depend heavily on dynamic neighbor discovery. 134 This is analogous to the situation with intra-domain unicast routing, 135 but is unlike current inter-domain unicast routing, where neighbors 136 are typically statically configured. 138 The static neighbor configuration model has several benefits for 139 inter-domain routing. First, neighbors are predefined, which is a 140 policy requirement in most cases. In addition, the set of peers in 141 the inter-domain unicast routing system defines the set of possible 142 inter-domain topologies (with the current active topology represented 143 by the collection of AS paths). 145 Another important difference relates to how inter-domain regions are 146 modeled. For purposes of this document, consider an inter-domain 147 region defined to be a part of an arbitrary topology in which a 148 higher level (inter-domain) routing protocol is used to calculate 149 paths between regions. In addition, each pair of adjacent regions is 150 connected by one or more multicast border routers. Current IDMR 151 proposals (e.g., [HDVMRP], [THALER96]) model an inter-domain region 152 as a routing domain. That is, border routers internetwork between one 153 or more intra-domain regions and an inter-domain region (again, 154 possibly more than one). In this model, inter-networking occurs 155 "inside" router. However, the inter-provider unicast routing model in 156 use today is quite different. In particular, the "peering" between 157 two providers occurs in neither of the provider's routing domains, 158 nor does it occur in some shared "inter-domain" routing domain. The 159 separation provides the administrative and policy control that is 160 required in today's Internet. 162 8. Unicast Topology Dependency 164 Ideally, unicast and multicast topologies are congruent in the 165 Internet. However, since it is frequently difficult to field new 166 facilities (such as IP multicast) in the "core" the Internet 167 infrastructure, there will continue to be many cases in which unicast 168 and multicast topologies are not congruent (either because a region 169 is not multicast capable at all, or because the region is not 170 natively forwarding multicast traffic). Thus, it is unlikely that the 171 entire IPv4 Internet will be able to carry native multicast traffic 172 in the foreseeable future. In addition, various policy requirements 173 will in certain cases cause to topologies to further diverge. The 174 implication is that a successful IDMR will need a topology discover 175 mechanism, or have other mechanisms for dealing with those cases in 176 which unicast and multicast topologies are not congruent. 178 8.1. Multicast Policies and Unicast Routes 180 Multicast and unicast packet forwarding algorithms assign different 181 semantics to a unicast route. In particular, if a router B accepts a 182 route from router A covering prefix P, then B will to forward packets 183 "to" those destinations covered by P, using A as the next hop when 184 forwarding unicast packets. However, in the multicast case, the same 185 route means B will accept packets "from" sources covered by P (though 186 not necessarily from A, but through the same interface as is used to 187 reach A). It is this difference in unicast route semantics that makes 188 formulation of precise multicast policy difficult. 190 9. Third-Party Resource Dependencies 192 Shared tree protocols require one or more globally shared Rendezvous 193 Points (RPs) [PIM-SM] or Cores [CBT]. The RP or Core effectively 194 serves as the root of a group specific shared tree. Data is sent to 195 the RP/Core for delivery on the shared tree. This means that some 196 groups may have an RP (or core) that is fielded by a third party. For 197 example, if providers A, B and C share a PIM-SM inter-domain region, 198 then there may exist an RP that is mapped to C's multicast border 199 router. In this case, C is hosting a kind of "transit RP" for A and B 200 (A and B register to C to communicate between themselves, even if C 201 has no receivers for the group(s) served by the RP. 203 10. Traffic Concentration Problem 205 Traffic can be "concentrated" on a shared tree. This can lead to 206 increased latency or packet loss. However, this is less of a problem 207 in the shared-media exchange point environment. 209 11. Distant RP/Core Problem 211 In the shared tree model, if the RP or Core is distant 212 (topologically), then joins will travel to the distant RP/Core, even 213 if the data is being delivered locally. Note that this problem will 214 be exacerbated if the RP/Core space is global; if a router is 215 registering to a RP/Core that is not in the local domain (say, 216 fielded by the site's direct provider), then the routing domain is 217 flat. 219 12. Multicast Internal Gateway Protocol (MIGP) Independence 221 A shared tree, explicit join protocol inter-domain routing protocol 222 may require modification to a leaf domain's internal multicast 223 routing mechanism. The problem arises when a domain is running a 224 "flood and prune" protocol such as DVMRP or PIM-DM internally while 225 participating in a shared tree inter-domain protocol. In this case, 226 there can be areas of the (internal) topology that has receivers but 227 will not receive inter-domain traffic. 229 [THALER96] describes interoperability rules to alleviate this 230 problem. Consider the case where a border router has interfaces in an 231 inter-domain shared tree region and a DVMRP region. The rules 232 covering this case state that either the DVMRP region must implement 233 Region Wide Reports [HDVMRP], or the DVMRP component of the border 234 router must be a wildcard receiver for externally reached sources, 235 while the shared tree component is a wildcard receiver for internally 236 reached sources. Alternatively, many current implementations use a 237 "receiver-is-sender" approach (which depends for the most part on 238 RTCP reports) to get around this problem. 240 13. Encapsulations 242 Encapsulations should be minimized where ever possible. PIM-SM 243 encapsulates packets sent to the shared tree in PIM Register messages 244 (data can be delivered natively if the last hop router or the RP 245 switches to the shortest path tree). The design of an shared tree 246 inter-domain protocol should avoid the "O(N) Encapsulation" problem: 247 For paths that traverse N administrative domains, the number of 248 encapsulations can approach O(N). 250 14. Policy Provisions 252 Current inter-domain unicast routing protocols have a rich and well 253 developed policy model. In contrast, multicast routing protocols 254 have little or no provision for implementing routing policy 255 (administrative scoping is one major exception). A concrete example 256 of this need is the various problems with inadvertent injection of 257 unicast routing tables into the MBONE, coupled with our inability to 258 propagate the resultant large DVMRP routing tables, point out the 259 need for such policy oriented controls. 261 A simple example illustrates why a successful inter-domain multicast 262 routing protocol will need to have a well developed policy model: 263 Consider three providers, A, B, and C, that have connections to a 264 shared-media exchange point. Assume that connectivity is non- 265 transitive due to some policy (the common case, since bi-lateral 266 agreements are a very common form of peering agreement). That is, A 267 and B are peers, B and C are peers, but A and C are not peers. Now, 268 consider a source S covered by a prefix P, where P belongs to a 269 customer of A (i.e., P is advertised by A). Now, multicast packets 270 forwarded by A's border router will be correctly accepted by B's 271 border router, since it sees the RPF interface for P to be the 272 shared-media of the exchange. Likewise, C's border router will reject 273 the packets forwarded by A's border router because, by definition, 274 C's border router does not have A's routes through its interface on 275 the exchange (so packets sourced "inside" A fail the RPF check in C's 276 border router). 278 In the example above, RPF is a powerful enough mechanism to inform C 279 that it should not accept packets sourced in P from A over the 280 exchange. However, consider the common case in which P is multi- 281 homed to both A and B. C now sees a route for P from B though its 282 interface on the exchange. Without some form of multi-provider 283 cooperation and/or packet filtering (or a more sophisticated RPF 284 mechanism), C could accept multicast packets sourced by S from A 285 across the shared media exchange, even though A and C have not 286 entered into any agreement on the exchange. The situation described 287 above is caused by the overloading of the semantics of unicast route 288 (as described above), and the reliance on the RPF check as a policy 289 mechanism. 291 14.1. "Wrong" RPF Neighbor 293 The example above illustrates a the problem that, in most current 294 implementations, the RPF check considers only the incoming interface, 295 and not the upstream neighbor (RPF neighbor). This can result in 296 accepting packets from the "wrong" RPF neighbor (the neighbor is 297 "wrong" since, while the RPF check succeeds and the packet is 298 forwarded, the unicast policy would not have forwarded the packet). 300 14.2. RPF as a Policy Mechanism 302 In the example above, C is relying on its RPF check to protect it 303 from A's packets. However, not only is RPF too weak enough to cover 304 those cases in which a source prefix is multi-homed (as described in 305 the example above), it is essentially a packet filter and as such is 306 not an attractive policy mechanism. 308 15. Today's MBONE 310 Another way to view the policy issues described above is to consider 311 the perspective of unicast reachability. Today's MBONE is comprised 312 of a single flat AS. Further, this AS running a simple distance 313 vector topology discovery protocol. This arrangement is unlikely to 314 scale gracefully or provide the same rich policy control that we find 315 in the unicast Internet. There are additional problems with a flat AS 316 model: the flat AS model fits neither the operational or 317 organizational models commonly found in Internet today. 319 16. Equal Cost Multipath 321 A common way to incrementally scale available bandwidth is to provide 322 parallel equal cost paths. It would be an advantage if a multicast 323 routing protocol could support this. However, this would seem 324 difficult to achieve when using Reverse Path Forwarding, so it is 325 unclear whether this goal is achievable. 327 17. Conclusion 329 Deployment of a general purpose IP multicast infrastructure for the 330 Internet has been slowed by various factors. One of the primary 331 reasons, however, is the lack of a true inter-domain Multicast 332 Routing Protocol. Several proposals have been advanced to solve this 333 problem, including PIM-SM [PIM-SM], DVMRP [PIMMBR], and Hierarchical 334 DVMRP [HDVMRP]. However, the concerns outlined above have prevented 335 any of these protocols from being adopted as the standard inter- 336 domain multicast routing protocol. Finally, it is worth noting that 337 DVMRP, since it is the common denominator among router vendor 338 offerings, is currently the de-facto inter-domain routing protocol. 340 18. Security Considerations 342 Historically, routing protocols used within the Internet have lacked 343 strong authentication mechanisms [RFC1704]. In the late 1980s, 344 analysis revealed that there were a number of security problems in 345 Internet routing protocols then in use [BELLOVIN89]. During the 346 early 1990s it became clear that adversaries were selectively 347 attacking various intra-domain and inter-domain routing protocols 348 (e.g. via TCP session stealing of BGP sessions) [CERTCA9501, 349 RFC1636]. More recently, cryptographic authentication mechanisms have 350 been developed for RIPv2, OSPF, and the proprietary EIGRP routing 351 protocols. BGP protection, in the form of a Keyed MD5 option for 352 TCP, has also become widely deployed. 354 At present, most multicast routing protocols lack strong 355 cryptographic protection. One possible approach to this is to 356 incorporate a strong cryptographic protection mechanism (e.g. Keyed 357 HMAC MD5 [RFC2104]) within the routing protocol itself. Alternately, 358 the routing protocol could be designed and specified to use the IP 359 Authentication Header (AH) [RFC1825, RFC1826, RFC2085] to provide 360 cryptographic authentication. 362 Because the intent of any routing protocol is to propagate routing 363 information to other parties, confidentiality is not generally 364 required in routing protocols. In those few cases where local 365 security policy might require confidentiality, the use of the IP 366 Encapsulating Security Payload (ESP) [RFC1825, RFC1827] is 367 recommended. 369 Scalable dynamic multicast key management is an active research area 370 at this time. Candidate technologies for scalable dynamic multicast 371 key management include CBT-based key management [RFC1949] and the 372 Group Key Management Protocol (GKMP) [GKMPID]. The IETF IP Security 373 Working Group is actively working on GKMP extensions to the 374 standards-track ISAKMP key management protocol being developed in the 375 same working group. 377 19. References 379 [BELLOVIN89] S. Bellovin, "Security Problems in the TCP/IP 380 Protocol Suite", ACM Computer Communications Review, 381 Volume 19, Number 2, pp. 32-48, April 1989. 383 [CBT] A. Ballardie, et. al., "Core Based Trees (CBT) 384 Multicast -- Protocol Specification --", 385 draft-ietf-idmr-cbt-spec-06.txt, September, 1996. 387 [CERTCA9501] CERT, "IP Spoofing Attacks and Hijacked Terminal 388 Connections", ftp://ftp.cert.org/cert_advisories/, 389 January 1995. 391 [DVMRP] T. Pusateri, "Distance Vector Multicast Routing 392 Protocol", draft-ietf-idmr-dvmrp-v3-03, September, 393 1996. 395 [GKMPID] H. Harney, "Group Key Management Protocol (GKMP)", 396 draft-harney-gkmp-arch-01.txt && 397 draft-harney-gkmp-spec-01.txt, August 1996, 398 Informational RFC publication is pending. 400 [HDVMRP] A. Thyagarajan and Steve Deering, "Hierarchical 401 Distance-Vector Multicast Routing for the MBone", In 402 Proceedings of the ACM SIGCOMM, pages 60-66, 403 October, 1995. 405 [LABOV97] C. Labovitz, et. al., "Internet Routing 406 Instability", Submitted to SIGCOMM97. 408 [PIMARCH] D. Estrin, et. al., "Protocol Independent Multicast 409 Sparse Mode (PIM-SM): Motivation and Architecture", 410 draft-ietf-idmr-pim-arch-04.ps , October, 1996. 412 [PIM-DM] D. Estrin, et. al., "Protocol Independent Multicast 413 Dense Mode (PIM-DM): Protocol Specification", 414 draft-ietf-idmr-PIM-DM-spec-04.ps, September, 1996. 416 [PIMMBR] D. Estrin, et. al., "PIM Multicast Border Router 417 (PMBR) specification for connecting PIM-SM domains 418 to a DVMRP Backbone", draft-ietf-idmr-PIMBR-spec-01.ps, 419 September, 1996. 421 [PIM-SM] D. Estrin, et. al., "Protocol Independent Multicast 422 Sparse Mode (PIM-SM): Protocol Specification", 423 draft-ietf-idmr-PIM-SM-spec-09.ps, October, 1996. 425 [THALER96] D. Thaler, "Interoperability Rules for Multicast 426 Routing Protocols", draft-thaler-interop-00.ps, 427 November, 1996. 429 [ESTRIN97] D. Estrin, et. al., "A Dynamic Bootstrap Mechanism 430 for Rendezvous-based Multicast Routing", USC/ISI 431 Technical Report, 1997. 433 [RFC1636] Braden, R., Clark, D., Crocker, S., and C. Huitema, 434 "Report of IAB Workshop on Security in the Internet 435 Architecture", RFC1636, June 1994. 437 [RFC1704] N. Haller and R. Atkinson, "On Internet 438 Authentication", RFC1704, October 1994. 440 [RFC1825] Atkinson, R., "IP Security Architecture", August 1995. 442 [RFC1826] Atkinson, R., "IP Authentication Header", August 1995. 444 [RFC1827] Atkinson, R., "IP Encapsulating Security Payload", 445 August 1995. 447 [RFC1949] A. Ballardie, "Scalable Multicast Key Distribution", 448 RFC1949, June 1996. 450 [RFC2085] M. Oehler & R. Glenn, "HMAC-MD5 IP Authentication 451 with Replay Prevention", February 1997. 453 [RFC2104] H. Krawczyk, M. Bellare, & R. Canetti, "HMAC: Keyed 454 Hashing for Message Authentication", RFC2104, 455 February 1997. 457 [VILLAM95] C. Villamizar, Ravi Chandra, and Ramesh Govindan, 458 "Controlling BGP/IDRP Routing Overhead", 459 draft-ietf-idr-rout-dampen-00.ps, July, 1995. 461 20. Acknowledgments 463 Dino Farinacci, Dave Thaler, and Yakov Rekhter provided several 464 insightful comments on earlier versions of this document. Ran 465 Atkinson contributed most of the security ideas contained in this 466 document. 468 21. Author Information 470 David Meyer 471 University of Oregon 472 1225 Kincaid St. 473 Eugene, OR 97403 474 Phone: (541) 346-1747 475 e-mail: meyer@antc.uoregon.edu