Internet Research Task Force                Haixiang He, Nortel Networks
INTERNET-DRAFT                                 Thomas Hardjono, Verisign
                                              Brad Cain, Cereva Networks
Expire: May, 2002                                         November, 2001



                Simple Multicast Receiver Access Control
                     <draft-irtf-gsec-smrac-00.txt>




Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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.



Abstract


   This document seeks to provide a solution to secure the multicast
   edge, in particular the "last-hop" of the multicast between multicast
   edge routers and hosts within a network. In this document, we
   proposed a simple and light-weight solution to prevent an illegal
   host from pulling the multicast distribution tree into the host's
   network when no other legal hosts exists in that same network.



1. Introduction



He, Hardjono, Cain                                              [Page 1]


Internet Draft        draft-irtf-gsec-smrac-00.txt             May, 2002


   Multicast technology [1] provides an efficient transport mechanism
   for delivering packets to multiple destinations. An IP system (host
   or router) uses Internet Group Management Protocol (IGMP) [2,3] to
   express its interest in receiving multicast packets to a specific
   multicast address to its neighboring multicast routers. IGMPv3 [4]
   allows a system also to report interest in receiving packets only
   from specific source addresses, or from all but specific source
   addresses.

   The current multicast model allows any host to join a multicast group
   by issuing a join message. When it receives an IGMP request to join a
   given group, if it is not yet receiving the traffic for that group, a
   router typically issues a join request upstream towards the multicast
   distribution tree using a multicast routing protocol. Once the join
   request succeeds, the multicast distribution tree is effectively
   expanded towards the router and the host starts to receive the
   traffic.

   The multicast traffic is typically broadcasted in a shared network
   even there is only one host is interested in receiving it. Other
   hosts in the same network that are uninterested in receiving the
   traffic simply ignore the broadcasted packets. The end-to-end data
   encryption can be used to preventing these hosts from reading the
   data. However, there is currently no mechanism to prevent a host from
   joining groups by issuing bogus join messages to multicast routers.

   The lack of this security mechanism may cause access control
   problems, denial-of-service attacks, and many other problems. For
   example, a host can simply joins a multicast group without any
   intention of using the date being delivered to it. In such an attack,
   the host essentially extends or "pulls" the multicast distribution
   tree towards its network.  This results a waste in bandwidth
   resources and in memory resources for state information within all
   the affected routers.

   Solving these problems needs a solution that provides security
   between a host and its neighboring multicast routers. Particularly a
   solution should provide the ability for a multicast router to
   authenticate and authorize a host's IGMP join requests.

   In this paper, we propose a simple method to achieve the goal of
   authenticating and authorizing a host's IGMP join requests. The
   method uses the approach: Proof of Membership. A host needs to
   provide its neighboring multicast routers with a proof of membership
   before its IGMP join requests are processed. The proof of membership
   in this method is an Access Token. The method is a light-weight
   solution and the light-weight feature maintains the scalability of
   multicast and provides enough incentives for this solution to be



He, Hardjono, Cain                                              [Page 2]


Internet Draft        draft-irtf-gsec-smrac-00.txt             May, 2002


   turned on.


2. Motivations for Receiver Access Control

   There are two main motivations for multicast receiver access control.
   The first motivation is to protect the multicast infrastructure. The
   second motivation is provide a simple solution to protect the
   multicast data.


2.1. Multicast Infrastructure Protection

   The multicast infrastructure can be divided into two parts, the core
   and the edge. The core contains all the multicast routers and
   multicast routing protocols are used to construct the multicast
   distribution trees.  The edge contains multicast edge routers and
   hosts and IGMP is used to communicate the group membership
   subscriptions. There are three steps to deliver multicast packets to
   a host. First a host communicates its interests to its neighboring
   multicast edge routers.  And then those group membership
   subscriptions are used to trigger the construction of the multicast
   distribution tree in the multicast core.  Then the packets flow to
   the host along the newly constructed distribution tree.

   One of the main goals of the current multicast service model is
   scalability. To achieve this goal, a multicast router is designed to
   only keep track of whether or not there is an interest in packets to
   a particular multicast address from a particular source for an
   interface. It is not designed to keep track of each individual system
   that has the same interest. In another word, the receivers or hosts
   are anonymous especially in the multicast edge. The edge multicast
   routers don't maintain host identification information and don't pass
   any host identification information.

   The original IP multicast model [1,2] does not address multicast
   security issues. To secure the multicast infrastructure, both the
   multicast core and the multicast edge have to be secured. The
   multicast core protection is achieved by protecting the multicast
   routing protocol. In particular, the control messages of the
   multicast routing protocol are protected to ensure the correct
   construction of the distribution tree.  For example, in MOSPF [5] and
   in PIM [6], the control messages are authenticated. Unfortunately,
   those solutions to protect the multicast core are not sufficient
   enough. They only ensure that the group membership subscription
   information maintained in the edge multicast routers are populated
   correctly. They don't check and don't have the ability to check
   whether the subscription information is legal or not. Bogus



He, Hardjono, Cain                                              [Page 3]


Internet Draft        draft-irtf-gsec-smrac-00.txt             May, 2002


   subscriptions can also attack the multicast core. This is why the
   multicast edge should be secured first.

   The current multicast model allows any host to join a multicast
   group.  When there is no other receiver on the same network, a host
   can easily attack the multicast infrastructure by issuing bogus IGMP
   join messages without any intention of using the multicast data.
   These IGMP join messages trigger the multicast routing protocol and
   eventually cause the multicast tree to be extended or pulled towards
   the host's network. The encryption of the multicast data does not
   prevent such attacks since the encrypted packets still are delivered
   along the distribution tree to the host's network. The lack of host
   identification information makes it even harder for an edge router to
   pinpoint an illegal host.

   Such an attack can cause large amounts of unused data to be forwarded
   to the attacking host's network and hence wastes the network
   bandwidth resource and may affect other services on the same network.
   The network bandwidth resources along the expanded branches of the
   multicast distribution tree are also wasted. Besides the waste of
   bandwidth resources, it also wastes the memory resources that routers
   used to maintain the state information and the processing power used
   to process the control messages.

   A host can start another kind of denial-of-service attack to the
   multicast infrastructure even if there are no multicast packets
   flowing in the network. The current multicast routing protocols
   create multicast data forwarding states on the multicast routers
   along the reverse path from the receiver to the sender before the
   multicast packets flow into the network. A host can subscribe traffic
   to thousands of multicast addresses and from thousands of source
   addresses. This can cause routers to create huge amounts of
   forwarding states that may beyond the limits that routers can handle.
   Eventually a router starts to deny other legal multicast service
   requests. This is particularly true to routers that are roots or near
   the roots of the multicast distribution tree since they maintain the
   most multicast forwarding states. Such routers are Rendezvous Points
   (RPs) in Protocol Independent Multicast-Sparse Mode (PIM-SM) [7,8]
   and Designate Routers (DRs) in Source-Specific Multicast (SSM) [9,
   10].


2.2. Multicast Data Protection

   Multicast data protection is usually achieved through end-to-end data
   encryption. End-to-end data encryption ensures date integrity, source
   authentication, and data confidentiality. Another completely
   different security infrastructure targeted specifically for multicast



He, Hardjono, Cain                                              [Page 4]


Internet Draft        draft-irtf-gsec-smrac-00.txt             May, 2002


   data protection needs to be developed to manage and deliver the
   keying material used for data encryption. Such an infrastructure is
   typically called Group Key Management (GKM) protocol. Some of them
   have been developed in the IETF especially in the Multicast Security
   (MSEC) working group [11,12,13,14].

   Developing and deploying a multicast security infrastructure is very
   expensive. In a non shared medium network such as switch Ethernet, it
   is enough to prevent users from getting multicast data by just using
   access control on the edge. Comparatively, the access control is
   cheaper and simpler.

   In some scenarios, even the encrypted multicast data is required not
   to deliver to illegal users since they may decrypt the data sooner or
   later and acquire the secret information. This can be achieved by
   using receiver access control on non share medium network.

   In a shared medium network, multicast packets are broadcasted. So if
   the legal hosts and illegal hosts coexist in the same network, the
   illegal hosts will also receive the packets even if they are
   encrypted. Access control won't help in this scenario. However, for
   some applications such as Internet TV, it may be tolerable for some
   illegal users to receive the packets for free as long as at least one
   legal user on the same network. Access control may be the best
   solution since it is simple and cheap.


3. Solution Goals and Requirements

   The primary goal of the multicast receiver access control solution
   proposed in this document is to prevent an illegal host from pulling
   the multicast distribution tree into the host's network when there
   are no other legal hosts in the same network. In another word, the
   primary goal is to protect the multicast routing infrastructure.

   The solution does not address the situation when there is already an
   legal host in a shared medium network. It does not solve the problem
   of hosts on a shared network intercepting data packets. However, the
   secondary goal of the solution is to provide a simple and cheap
   substitute to a complicated and expensive multicast security
   infrastructure used to protect multicast data.

   There is also some cost to provide last hop security. Similar to
   other scenarios requiring security, the cost of providing security
   must be considered against the amount of state that will result in
   the multicast edge routers if no last hop security is afforded.  So
   in some circumstances rather than turning on the last hop security,
   it may perhaps be tolerable to allow an illegal host to pull the the



He, Hardjono, Cain                                              [Page 5]


Internet Draft        draft-irtf-gsec-smrac-00.txt             May, 2002


   multicast distribution tree to its network. This requires a receiver
   access control solution to be light weight. So that it can provide
   enough incentives to be turned on.


4. Receiver Access Control Framework

   In this section, we propose the use of the Access Token to achieve
   the goal of receiver access control. We also describe the details of
   the solution framework.


4.1. Solution Overview

   The receiver access control solution proposed in this document also
   uses the same approach introduced in [15]: Proof of Membership. The
   approach is for a receiver or a host to provide its neighboring
   routers with some "proof-of-membership". The proof must be pre-
   established before the receiver issues control messages to the
   multicast edge routers.

   Here the proof-of-membership is an access token that is digitally
   signed by a trusted authority such as Group Controller Key Server
   (GCKS) using the private key of a public-key pair designated for
   receiver access control. The solution requires that only legitimate
   multicast routers posses the public key of the key pair.

   The whole process of the solution is as follows. First, a host needs
   to communicate with a trusted authority. The trusted authority
   authenticates the host and delivers a signed access token to the host
   for multicast packets to a specific multicast address and from
   specific source address(es) if the host is authorized to access the
   multicast packets. Then the host attaches the access token to its
   IGMP report messages when it is required by a multicast edge router.
   Once it receives the access token, the router forwards it to the
   authentication module. According to the results of the
   authentication, the router will take appropriate actions.  If the
   request is authenticated and authorized, the router updates the IGMP
   state information that it maintains. This may trigger the multicast
   router protocol when the router does not have the packets a host
   requests and eventually causes the packets to be forwarded to the
   host's network. If the request is not authenticated or not
   authorized, the router ignores the IGMP requests. The multicast
   routing infrastructure is protected and the illegal host won't
   receive the packets if there are no other legal hosts in the same
   network.





He, Hardjono, Cain                                              [Page 6]


Internet Draft        draft-irtf-gsec-smrac-00.txt             May, 2002


4.2. Content of the Access Token

   An access token contains at least the following information:
           - Subscription information
           - Host IP address
           - Expiration time

   The subscription information is a multicast address and a list of
   source addresses. There can be zero, one, or more source addresses in
   the list.  An access token can contain other information.

   Each information in the access token is used to counter one kind of
   attack. The subscription information defines the usage scope of the
   access token. It prevents a host to use the same access token for
   other subscriptions. In another word, it prevent a host to access
   packets that is not sent to the multicast address and from the source
   addresses that are in the access token.

   The host IP address is used to prevent another host outside the same
   network to use the same access token. When a router receive the
   access token, the authentication module compares the IP address of
   the IP packet that contains the access token with the IP address in
   the access token. If the two IP addresses don't match, then the
   request is not authenticated. A router has the ability to identify
   whether an IP packet is a legal packet from a network and drops the
   illegal packet. So even if a host fakes the IP address, the same
   access token still can not be used outside its legal owner's network.

   The expiration time is used to prevent a host to reuse the same
   access token after the expiration time. The expiration time is set
   according to the agreement between the host and the trust authority.
   The agreement related issues are beyond this document.


4.3. Access Token Management and Delivery

   The trust authority should manage the access tokens and deliver them
   to appropriate hosts through secure channel. There is some cost to
   develop a trust authority and the secure channel between the host and
   the trust authority. However we may use an infrastructure that has
   already been deployed.

   If the multicast security infrastructure has been deployed to protect
   the multicast data, the Group Controller Key Server (GCKS) [16] can
   also be used as the trust authority for receiver access control. When
   the host communicates with GCKS and is authenticated by the GCKS,
   besides delivering the group keys to decrypt the multicast data, the
   GCKS can also deliver the access tokens to the hosts through the same



He, Hardjono, Cain                                              [Page 7]


Internet Draft        draft-irtf-gsec-smrac-00.txt             May, 2002


   secure channel.

   If such a multicast security infrastructure is not deployed, the
   trust authority can co-locate with the billing server or the
   multicast session announcement server. The access token can be
   delivered with the multicast session information or billing
   information.


4.4. Upload the Access Token using IGMP

   When required by its neighboring multicast edge routers, a host has
   to attach the access token to its IGMP report messages. The necessary
   IGMP changes to upload authentication information from a host as well
   as the APIs between the IGMP module and the authentication module in
   the multicast edge routers are proposed in document [17].

   To use the modified IGMP proposed in [17], we set the authentication
   type to 1 for uploading access token. The authentication module uses
   the system time, the subscription information in the group record,
   and the IP address of the IGMP report packet to authenticate the
   request as we described above.  To avoid the complexity, we propose
   the Access Token is per multicast group based and is per group-and-
   source based for SSM.


5. Advantage of the Solution

   The big advantage of this solution is that it is a very simple and
   light-weight solution. In this solution, a multicast edge router only
   needs to maintain the public key of the public-key pair used for
   access control.  The router need not identify any host since it trust
   the key management service to operate correctly.

   The previous approach [18] was considered too heavy-weight for
   multicast edge routers since it requires multiple challenge-response
   handshakes to be performed between a host and a multicast router.
   Furthermore, it requires an authentication server to be available
   continuously for the multicast edge routers in the domain to verify
   membership of hosts to multicast groups. It also changes the current
   multicast model and hence may cause the decrease of the multicast
   scalability.

   Compare to the approach [15], this solution is also light-weight. In
   [15], a Token-List has to be distributed to the multicast edge
   routers by the key server. If there are lots of hosts and each host
   subscribes many multicast traffic, there will be large amounts of
   access tokens. So the Token-List can be huge. Maintaining and



He, Hardjono, Cain                                              [Page 8]


Internet Draft        draft-irtf-gsec-smrac-00.txt             May, 2002


   distributing the huge Token-List is expensive and heavy-weight.  In
   the same approach, a host also uses access token as the proof-of-
   membership, but the access token can only be used once. This may
   require the key server to generate new access tokens. There is also
   some cost to update and deliver the new access tokens.


6. Solution Weakness and Improvement

   There is a weakness in this solution. It can be improved but there
   are some extra costs for the improvement.


6.1. Solution Weakness

   The solution proposed in this document does not protect the IGMP
   control message itself directly, particularly the IGMP report
   messages.  Although the IGMP control messages are not forwarded
   outside its network, but they can be intercepted within the network.
   A system on the same network can forge the IGMP control messages and
   cause lots of problem. The details of these problems can be found in
   [4].

   When a host uses the access token, e.g., attaches the access token to
   its IGMP report messages, another host on the same network can
   intercept the access token. It cannot read or change the access token
   since it does not have the public key of the public-key pair used for
   access control, only legitimate multicast routers have the public
   key. But that host can reuse the same access token with faking the IP
   address using the access token's legal owner's IP address to
   subscribe the same subscription. As described above, the IP address
   of the access token's legal owner and the subscription information
   within IGMP report messages are not protected.  However that host
   does not gain anything by reusing the same access token if the a
   legal is also subscribing the traffic since the multicast packets
   have already been forwarded into the network.

   Unfortunately, if the legal host stops subscribing the same multicast
   traffic before the expiration time contained in the access token,
   another illegal host can benefit from reusing the same access token.
   Reusing the same access token by an illegal host on the same network
   causes the multicast packets from the same subscription to be
   continuously forwarded into the network. To some service providers,
   this may not be a big issue and is tolerable. Since to them, the
   multicast packets are already allowed to be forwarded to the legal
   host's network until the expiration time.





He, Hardjono, Cain                                              [Page 9]


Internet Draft        draft-irtf-gsec-smrac-00.txt             May, 2002


6.2. Solution Improvement

   The current solution can be improved to counter the attack of reusing
   the same access token within the same network.  One simple
   improvement is to use another public-key pair to protect the IGMP
   report messages from a legal host. It works as follows.

   The trusted authority generates a new public-key pair for each host.
   It puts the public key of the new public-key pair in the access token
   to replace the host IP address. The host's IP address is not used in
   the improved solution. Then the trust authority delivers the private
   key of the new public-key along with the new access token that
   contains the public key to the host through the secure channel. The
   host uses the private key of the new public-key pair to sign its IGMP
   report messages and attaches the digital signature to its IGMP report
   messages. When it receives a IGMP report message, a multicast edge
   router must first verify the access token. Then it must verify the
   host's digital signature using the public key in the access token.

   And there is also some extra cost in this improvement. First, there
   are some cost in managing and delivering the new public-key pair.
   Second, there are some costs for a host to sign its IGMP report
   messages. Third, there are some extra bandwidth usage wastes to
   upload the digital signature. Fourth, there are some costs for a
   multicast edge router to verify the digital signature. Some of the
   costs can be reduced. For example, a host does not need to upload the
   digital signature every time for the same IGMP request. And a
   multicast edge router may ignore the digital signature sometimes.


References

   [1]  Deering, S., "Multicast Routing in a Datagram Network", PhD
        Thesis, Stanford University, Palo Alto, California, Dec. 1991.
   [2]  Deering, S., "Host Extension for IP Multicasting", RFC 1112,
        August 1989.
   [3]  Fenner, W., "Internet Group Management Protocol, Version2",
        RFC 2236, November 1997.
   [4]  Cain, B., Deering, S., Fenner, W., Kouvelas, I., Thyagarajan, A.,
        "Internet Group Management Protocol, Version 3", Internet-Draft,
        January 2001.
   [5]  Moy, J., "Anatomy of an Internet Routing Protocol",
        Addison-Wesley, 1998.
   [6]  Wei, L., "Authenticate PIM Version 2 Messages", Internet-Draft,
        Work in progress.
   [7]  Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
        Handley, M., Jacobson, V., Liu, C., Sharma, P., and Wei, L.,
        "Protocol Independent Multicast-Sparse Mode (PIM-SM), Protocol



He, Hardjono, Cain                                             [Page 10]


Internet Draft        draft-irtf-gsec-smrac-00.txt             May, 2002


        Specification", RFC 2362, June 1998.
   [8]  Fenner, B., Handley, M., Holbrook, H., and Kouvelas, I.,
        "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
        Specification (Revised)", draft-ietf-pim-sm-v2-new-03.txt,
        July 2001.
   [9]  Holbrook, H., and Cain, B., "Using IGMPv3 For Source-Specific
        Multicast", draft-holbrook-idmr-igmpv3-ssm-01.txt, March 2001.
   [10] Holbrook, H., and Cain, B., "Source-Specific Multicast for IP",
        Internet-Draft, work in Progress.
   [11] Harney, H. and Muckenhim, C., "Group Key Management Protocol
        (GKMP) Architecture", RFC 2094.
   [12] Hardjono, T., Cain, B., and Monga, I., "Intra-Domain Group
        Key Management Protocol", draft-ietf-ipsec-intragkm-01.txt,
        March 2000.
   [13] Baugher, M., Hardjono, T., Harney, H., and Weis, B., "The Group
        Domain of Interpretation", draft-ietf-msec-gdoi-01.txt,
        July 2001, Work in Progress.
   [14] Harney, H., Colegrove, A., Harder, E., Meth, U., and
        Fleischer, R., "Group Secure Association Key Management
        Protocol", draft-ietf-msec-gsakmp-sec-00.txt, March 2001.
   [15] Hardjono, T. and Cain, B., "Key Establishment for IGMP
        Authentication in IP Multicast", IEEE European Conference on
        Universal Multiservice Networks (ECUMN), CERF, Colmar, France,
        September 2000.
   [16] Hardjono, T., Canetti, R., Baugher, M., Dinsmore, P., "Secure
        IP Multicast: Problem Areas, Framework and Building Blocks",
        draft-irtf-smug-framework-01.txt, September 2000,
        Work in Progress.
   [17] He, H., Cain, B., and Hardjono, T., "Upload Authentication
        Information Using IGMPv3", Internet-Draft, Work in Progress.
   [18] Ishikawa, N., Yamanouchi, N., and Takahashi, O., "IGMP Extension
        for Authentication of IP Multicast Senders and Receivers",
        draft-ishikawa-igmp-auth-01.txt, August 1998, Work in Progress.



Author's Address:

     Haixiang He
     Nortel Networks
     600 Technology Park Drive
     Billerica, MA 01821
     Phone: 978-288-7482
     Email: haixiang@nortelnetworks.com

     Thomas Hardjono
     Verisign
     401 Edgewater Place, Suite 208



He, Hardjono, Cain                                             [Page 11]


Internet Draft        draft-irtf-gsec-smrac-00.txt             May, 2002


     Wakefield, MA 01880
     Email: thardjono@verisign.com

     Brad Cain
     Cereva Networks
     Email: bcain@cereva.com













































He, Hardjono, Cain                                             [Page 12]