Internet Engineering Task Force Yunzhou Li INTERNET-DRAFT Billy Ng Jyothi Hayes Nortel Networks 10 June 1999 Secure Multicast Plane between PIM-SM Domains (SMPP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), ftp.ietf.org (US East Coast), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This memo proposes a secure multicast plane between PIM-SM domains through a MSDP bridge. The MSDP bridge is the MSDP peering topology with a GRE tunnel associated with each pair of MSDP routers. A multicast protocol such as DVMRP, PIM-DM or BGMP runs over the MSDP bridge to forward secure multicast data in the global key space. As a RP, each security broker in an interested domain translates the data from the MSDP bridge to the local domain and forwards the data in the local key space. This approach is perceived as a transitional solution to the multicast security between PIM-SM domains. It will enable group security association to differ from one shared tree to another, and will essentially facilitate group key distribution. Li et al Expires 9 December 1999 [Page i] Internet Draft Secure Multicast Plane between PIM-SM 10 June 1999 1. Introduction One of the major issues with multicast security is the scalability of group key distribution ([Taxonomy]). Recent research, as in [Iolus], demonstrates it would be more scalable if we allow multiple regional, independent group security associations ([GSA]) for a single group. One disadvantage of the Iolus scheme is its latency incurred by decrypting and re-encrypting each packet from subgroup to subgroup, all the way to the destination members. On the other hand, encrypted data will not be allowed to be translated from one region to another. The data originator may only allow its authorised agent or broker to translate the data for the members in a particular region. This memo proposes a transitional solution to the multicast security between PIM-SM ([PIM-SM]) domains. As we see the existing MSDP ([MSDP]) peering topology will evolve to the future BGMP ([BGMP]) backbone, we proposes to run a multicast protocol over the MSDP peering topology, with a GRE tunnel configured for each pair of MSDP routers, to forward secure multicast data to all interested PIM-SM domains. The MSDP peering topology with this particular configuration is called MSDP bridge. The multicast protocol to run over the MSDP bridge is BGMP in the long run. In the near term, however, we can run DVMRP ([DVMRP]) over each community wide MSDP bridge since DVMRP has its own routing, while we can run PIM-DM ([PIM-DM]) over the MSDP bridge where the MBGP ([MBGP]) routing is in place. In this memo, we will demonstrate how DVMRP works with this secure multicast plane. A source security broker, a RP in a PIM-SM domain, receives and decrypts data from the local source, encrypts it with the global group specific key over the MSDP bridge, and forwards it in accordance with DVMRP over this bridge. Each receiving security broker, if determining it has secure members down the shared tree, will decrypt the data, encrypt it with the group key in the local PIM domain, and forward it down the shared tree. If there is no secure member, however, the receiving security broker will trigger DVMRP prune to the source security broker over the MSDP bridge. The security broker here is supposed to run both DVMRP and PIM-SM. However, generally DVMRP can be avoided since the security broker can run IGMP Host protocol instead. On the other hand, when it is just a host dedicated to security translation, the security broker does not have to run full PIM-SM protocol. With this approach, we allow group security association to differ from one shared tree to another, and thus minimize the impact of rekeying incurred by a single member's join/leave. On the other hand, the key distribution over the MSDP bridge is relatively stable, while members in a PIM-SM domain can easily learn the security broker from a directly-connected PIM router. Therefore this approach will substantially facilitate the group key distribution. Li et al Expires 9 December 1999 [Page 1] Internet Draft Secure Multicast Plane between PIM-SM 10 June 1999 1.1 Terminology Security Domain A security domain for a group is a PIM-SM domain or a group of PIM-SM domains where there is only one shared tree for the particular group. For simplicity, we assume a security domain is a single PIM domain. Security Broker The security broker for a group is the root of the shared tree in a security domain for the particular group. It is the elected RP for the group in the PIM domain. The security broker who translates data and sends it to the MSDP bridge on behalf of the source is called source security broker. Other security brokers are called member security broker. Secure Member A secure member is a member who has joined the particular group through IGMP protocol and also acquired a group key for the local security domain. MSDP Bridge The MSDP bridge is the MSDP peering topology, consisting of external peering between MSDP server pairs, and internal peering between MSDP server ([MSDP-SVR]) and RPs, where a GRE tunnel is configured for each pair of MSDP routers. The GRE tunnel is intended for transmitting multicast data and control messages of multicast protocols such as DVMRP, PIM-DM or BGMP. Within the MSDP bridge, a security broker is a RP and thus will internally peer with the MSDP server in the local PIM domain. 2. Running DVMRP over MSDP Bridge A source in a PIM-SM domain originates multicast data to a multicast group. The data will be forwarded to the source security broker through PIM Register message. The broker deregisters the data and forwards it down the shared tree without security translation. On the other hand, the broker decrypts the data with the local domain group specific key, encrypts it with the global group specific key for the MSDP bridge, and forwards it in accordance with DVMRP protocol over the MSDP bridge. Li et al Expires 9 December 1999 [Page 2] Internet Draft Secure Multicast Plane between PIM-SM 10 June 1999 Each receiving security broker, if it determines there are downstream secure members, decrypts the data with the global bridge group specific key, encrypts it with the local domain group specific key, and forwards it down the shared tree rooted at itself. If, however, there is no secure member down the shared tree, the receiving security broker will trigger DVMRP prune towards the source security domain over the MSDP bridge. As a result, subsequent data will not be forwarded to this particular security broker. If, at a later time, some secure members become present down the shared tree, the security broker will trigger a graft message towards the source security broker over the bridge. Subsequent data will again be forwarded to this particular security broker, and the broker in turn translates the data and forwards it to the shared tree of the local PIM domain. 3. Preventing Shortest Path Tree across PIM Domains 3.1 Bridge Mode and Native Mode Multicast data forwarding is in bridge mode if the data is translated by the source security broker, forwarded over the MSDP bridge, and received and translated by other security brokers in interested domains. Multicast data forwarding is in native mode if there is no security translation in all security brokers and the data is never forwarded over the MSDP bridge. In the native mode, PIM domains learn multicast source through MSDP protocol, triggers (S,G) join towards the source domain, and forwards multicast data down the shortest path tree across PIM domains. In the bridge mode, all PIM domains are separated without (S,G) join in between. Multicast data is originated from the source domain, forwarded over the MSDP bridge with support of a multicast protocol such as DVMRP, PIM-DM or BGMP, and received and translated by all interested PIM domains. Note that this multicast protocol (DVMRP, PIM-DM or BGMP) is not enabled anywhere else besides the MSDP bridge. The multicast data forwarding for a particular group should stay either constantly in the native mode or constantly in the bridge mode. Otherwise, PIM domains on the shortest path tree will receive duplicate data. Li et al Expires 9 December 1999 [Page 3] Internet Draft Secure Multicast Plane between PIM-SM 10 June 1999 3.2 Propagate Bridge Mode through MSDP SA Messages The security broker (the RP) should explicitly inform other PIM-SM domains of its configured secure groups thru the MSDP bridge. It will use the SA message in MSDP to indicate its decryption/encryption capability in bridge mode by setting a new G-bit in the reserved field. Since this message is used to indicate a secure group for all sources, the Sprefix Len and Source Address Prefix will be set to zero and is sent whenever the source security broker is configured with a secure group. The new format is shown below: IPv4 Source-Active TLV 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | x + y | Entry Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G| Reserved | Gprefix Len | zero | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Group Address Prefix | ) z +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | zero | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When this SA message is received on a PIM-SM domain from a MSDP bridge, the RP responsible for this group will correspondingly set a new G-bit in the reserved field of the encoded group address as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type |B|G| Reserved | Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This encoded group will be sent in the periodic C-RP advertisement. The bootstrap router will in turn carry this G-bit for the secure multicast group in each Bootstrap message. In this manner, all routers in this domain will learn the security broker and the forwarding mode for the particular group, and only join the shared tree. Note that the receivers on a domain where the source resides are allowed to switch to the shortest path tree if no other sources active in other domains for the same group. Li et al Expires 9 December 1999 [Page 4] Internet Draft Secure Multicast Plane between PIM-SM 10 June 1999 3.3 Prune Shortest Path Tree in Bridge Mode In the bridge mode, multicast data is forwarded down the shared tree instead of the shortest path tree. In order to enforce this behavior, each PIM router, when determining the G-bit is set for the elected RP for a particular group, should not trigger any (S,G) join. If this router receives a (S,G) join from downstream, it should stop propagating the (S,G) join upstream towards the source. If there is already a (S,G) state in the router for the particular group, this router should trigger (*,G) join (or remove the (S,G) prune) towards the relevant RP (security broker). When multicast data arrives from the shared tree, the router should trigger (S,G) prune towards the S across PIM domains. 4. Various Considerations 4.1 Minimize Routing in Security Broker As a RP, the security broker has a GRE tunnel with the MSDP server. This GRE tunnel is called the security broker's interface on the MSDP bridge. In general, we can run IGMP host protocol, instead of DVMRP, on this particular interface. We trigger IGMP Host Membership Report towards the MSDP server when the security broker has downstream secure members. When all downstream secure members go away, the security broker will trigger an IGMP Leave towards the MSDP server. The security broker can be a RP with full PIM-SM functionality. In some cases, however, the security broker can be a host that is dedicated to security translation. In this case, there is no need for the security broker to have PIM-SM functionality, such as the Hello procedure, the Join/Prune procedure and so on. Nevertheless, the security broker will still have to participate in Bootstrap procedure and periodically send Candidate RP advertisement messages to the bootstrap router provided that the boostrap router chooses to elect it as a RP for a particular group. On the other hand, each PIM-SM router should allow a host to be a RP, the root of a shared tree, whether the host has PIM-SM functionality. This means the PIM-SM router should have (*,G) state installed and have the incoming interface pointed to the LAN where the host resides, if it receives downstream (*,G) Join/Prune. 4.2 Forwarding States in Two Distinct Key Spaces Forwarding states should not be propagated between PIM domains and the MSDP Bridge since they are in distinct secure key spaces. Li et al Expires 9 December 1999 [Page 5] Internet Draft Secure Multicast Plane between PIM-SM 10 June 1999 4.3 Scalability of MSDP Bridge To scale, the MSDP bridge can be partitioned into numerous multicast domains, each running a multicast protocol such as DVMRP, PIM-DM, and BGMP. However, they all are in the MSDP bridge key space, and forwarding states should never be propagted to the underlying PIM domains. 4.4 Group Key Distribution This section briefly explains how this secure multicast plane faciliates group key distribution. However, it is not a group key distribution protocol and it does not imply what the future group key distribution protocol should look like. Member security brokers can learn the source security broker through the MSDP protocol. Each member security broker then exchanges private keys (note this key is different than the group key) with the source security broker through the IKE ([IKE]) protocol. The source security broker then encrypts the group key for the MSDP bridge, using the private key, to each individual member broker. The key distribution of group key for the local domain is easy. When a member joins the group through IGMP Report message, the local DR should inform the member of the relevant security broker (this protocol should be discussed elsewhere). The member then exchanges private keys with the security broker through the IKE ([IKE]) protocol. The security broker then encrypts the group key for the local domain, using the private key, to this individual member. 5. Acknowledgement Many thanks to Brad Cain, Kwok Ho Chan, Janet Doong, Thomas Hardjono, Indermohan Monga, and Hal Sandick for their valuable comments. Li et al Expires 9 December 1999 [Page 6] Internet Draft Secure Multicast Plane between PIM-SM 10 June 1999 References [MBGP] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, February 1998. [Taxonomy] R. Canetti, B. Pinkas, "A taxonomy of multicast security issues", draft-canetti-secure-multicast-taxonomy-01.txt, November 1998. [PIM-DM] S. Deering et al, "Protocol Independent Multicast Version 2 Dense Mode Specification", draft-ietf-pim-v2-dm-02.txt, May 1999. [PIM-SM] D. Estrin et al, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. [MSDP] D. Farinacci et al, Multicast Source Discovery Protocol (MSDP), Internet Draft, work in progress, June 1998. [GRE] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing Encapsulation (GRE). RFC 1701, October 1994. [IKE] D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)", Internet Draft, June 1998. [MSDP-SVR] Yunzhou Li, "Group Specific MSDP Peering", Internet Draft, work in progress, June 1999. [Iolus] S. Mittra. "Iolus: A Framework for Scalable Secure Multicast." In Proceedings of ACM SIGCOMM'97, Cannes, France, September 1997. [GSA] I. Monga and T. Hardjono. "Group Security Association (GSA) Definition for IP Multicast." Internet Draft , February 1999. [DVMRP] T. Pusateri. "Distance Vector Multicast Routing Protocol". , Inter-Domain Multicast Routing Working Group, March 1998. [IPsec] Stephen Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft draft-ietf-ipsec-arch-sec-07.txt, July 1998. [BGMP] D. Thaler, D. Estrin and D. Meyer. "Border Gateway Multicast Protocol (BGMP): Protocol Specification." , March 1998. Li et al Expires 9 December 1999 [Page 7] Internet Draft Secure Multicast Plane between PIM-SM 10 June 1999 Authors' Addresses Yunzhou Li Nortel Networks BL60-304 600 Technology Park Drive Billerica, MA 01821 Phone: 1-978-288-1130 Fax: 1-978-670-8760 E-mail: yunli@NortelNetworks.COM Billy Ng Nortel Networks BL60-304 600 Technology Park Drive Billerica, MA 01821 Phone: 1-978-288-8412 Fax: 1-978-670-8760 E-mail: bng@NortelNetworks.COM Jyothi Hayes Nortel Networks BL60-304 600 Technology Park Drive Billerica, MA 01821 Phone: 1-978-288-3796 Fax: 1-978-670-8760 E-mail: jyhayes@NortelNetworks.COM Li et al Expires 9 December 1999 [Page 8]