Subject: Secure Multicast Plane between PIM-SM Domains

From: Yunzhou Li <[email-masked]>
Date: Thu, 10 Jun 1999 10:52:39 -0400

We have submitted the following new internet draft to the Internet Drafts
directory. We will appreciate it if you can review and comment it...

Thanks,
Yunzhou

=================================

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)
	     <draft-lietal-pim-sec-mcast-plane-00.txt>

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."

   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
       <draft-irtf-smug-gsadef-00.txt>, February 1999.

   [DVMRP]   T. Pusateri. "Distance Vector Multicast Routing Protocol".
       <draft-ietf-idmr-dvmrp-v3-06.txt>, 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."
       <draft-ietf-idmr-gum-02.txt>, 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: [email-masked]

   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: [email-masked]

   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: [email-masked]

Li et al               Expires 9 December 1999                  [Page 8]