msec Anni. Wei Internet-Draft Huawei Technologies Intended status: Informational July 8, 2009 Expires: January 9, 2010 Multicast security algorithm based on agent node draft-wei-msec-multicast-sec-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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. This Internet-Draft will expire on January 9, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Wei Expires January 9, 2010 [Page 1] Internet-Draft Multicast security July 2009 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Multicast security algorithm based on agent node can select the group node corresponding to the smallest path cost to be the agent node, and multicast in accordance with the optimal multicast routing. In addition, the multicast source node uses the key different from the group key to encrypt multicast data to meet the requirements of multicast security. The agent nodes can be different for different multicast sources, which can spread the burden of the agent node and avoid the excessive burden problem when the same node as the agent node of different sources. Wei Expires January 9, 2010 [Page 2] Internet-Draft Multicast security July 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology used in this document . . . . . . . . . . . . . . 4 3. Problem statement and analysis . . . . . . . . . . . . . . . . 4 3.1. Proposed Solutions . . . . . . . . . . . . . . . . . . . . 5 3.2. Proposed solution overview . . . . . . . . . . . . . . . . 5 3.3. The method to determine multicast agent node . . . . . . . 5 4. Security of multicast transmission . . . . . . . . . . . . . . 7 5. Multicast Routing repair . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Wei Expires January 9, 2010 [Page 3] Internet-Draft Multicast security July 2009 1. Introduction There are two ways for realization of multicast: one requires that all data source nodes must be the group members, security of multicast transmission relies on the group key; another is that the source node may not be a member of the group, adopt different approaches in and out of the group to make sure the multicast security, while the group security is similar to the first case. This document presents a multicast security algorithm based on agent node, focus on the secure transmission from source node out of group to group nodes. The secure transmission in the group can be protected by existing algorithm. 2. Terminology used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Problem statement and analysis Multicast can be achieved in two ways. One requires that all data sources have to be the group members, multicast transmission security can be protected through the group key. So that all source nodes must join the group before sending data and leave when no need to send data. Joining and leaving the group will be accompanied by the allocation of Group Key or update operation to all group members. Another one is when the source node is not a group member. At this case, the security between the source and the group nodes and the security between group nodes can take different secure keys, which to some extent can reduce the group key distribution or update operation. For instance, some receiving nodes are changeless mostly, but the sending nodes change frequently, and the latter approach can make all the receiving nodes as a group other than sending node. The change of sending node does not cause the correlative processing of the group key. In the latter approach, usually each of the groups sets up a multicast group manager. It is one of the group members responsible for the centralized management of security. All multicast data initiated by non-group members are first sent to the multicast manager, which uses multicast group key to encrypt packets, and then sends to the group members. Deficiencies in this method lie on the fact that for all the multicast data to be sent to the multicast manager, the routing may not be optimal; and the multicast manager is the same for different multicast source nodes, which cause heavier Wei Expires January 9, 2010 [Page 4] Internet-Draft Multicast security July 2009 burden on multicast manager as well as failure problem of a single point. 3.1. Proposed Solutions 3.2. Proposed solution overview This document presents a method of secure multicast, which not only ensures the multicast security but also avoids the issues due to centralized security management. This method is only for source node which is not group member. This method and the secure multicast method as the source is the group member can be combined to form a complete program of secure multicast. This[RFC3740] secure multicast method is based on agent node, the source node use unicast secure key to send packets to its own corresponding secure multicast agent node, and then the secure agent node multicast packets using the group key. The distributed security management is form as each source node is corresponding to different agent node. 3.3. The method to determine multicast agent node The method to determine multicast agent node can adopt the general unicast routing discovery methods, such as the multicast source node sends the multicast agent nodes discovery request; the member nodes of group receive the request or nodes that store routing information of the group members response the hop count hop count to the source node. The hop count indicates the cost between source node and the group member. The source chooses the group node which is corresponding to the least cost routing path as the agent node. The method to determine multicast agent node includes the following specific steps: 1. Multicast source node broadcast multicast agent node discovery request which carries the identity of target group. 2. Before the request arrives at each member nodes of group, it usually goes through intermediate nodes which may be members of the group or not. When receive a request, the node has to determine whether it is member of the group through identity carried in the request. If it is group member, then returns to the source node the multicast hop count information; if not member of the group , then adds 1 to the previous hop count, and then transmits the request to the neighbor nodes, until arrives to members of the Group. 3. Every member of group receives the request, checks the hop count to source node, and then returns it to the source node. Wei Expires January 9, 2010 [Page 5] Internet-Draft Multicast security July 2009 4. Source node selects the member of the group corresponding to the smallest routing path cost as a agent node for the target group according to the hop count information returned by each member of group. +--+ +--+ +--+ +--+ | |----| |----|K |----|S | +--+ +--+ +--+ +--+ | | | | +--+ +--+ +--+ +--+ | |----| B|----|A |----|I | +--+ +--+ +--+ +--+ | | | | +--+ +--+ +--+ +--+ | E|----| |----| |----|H | +--+ +--+ +--+ +--+ | | | | +--+ +--+ +--+ +--+ | |----|D |----|C |----| | +--+ +--+ +--+ +--+ Figure 1 As shown in Figure 1, node A, B, C, D, E belong to the multicast Group G, all members of Group G share a key Kg, non-group members can not access the key. Node S who is non-group member needs to send multicast data to all members of Group G. In other words, in this multicast process, node S is multicast source node. In the network, the way to choose multicast agent node is as follows: Multicast source node S broadcast multicast agent discovery request to its neighbor node K and I. The request carries identity and hop count of the target of Group G. Here the initial value for the hop count is 0. After node K receives the request node, it checks itself do not belong to Group G according to the identity. Therefore, it cumulates hop count from the node S to node K to 1, and then re-broadcast multicast agent discovery request which carries the cumulative cost of the routing. The cumulative cost of the routing is 1 at the time. Node A receives the re-broadcast multicast agent discovery request from node K and finds that itself belongs to the Group G according to the identity of target Group G .Therefore, the cumulative hop count from the K to the A turns to 2 from 1,and returns the cumulative cost to the multicast source node S. Similarly, node A would receive the multicast agent discovery requests forwarded by other non-group node Wei Expires January 9, 2010 [Page 6] Internet-Draft Multicast security July 2009 (for example, node I), cumulates the cost routing and returns to the multicast source node S. Other members of the group node B, C, D, E will also receive the multicast agent node discovery request forwarded by non-group nodes and returned the cumulative hop count to the multicast source node. Source node S chooses a member of the group corresponding to the smallest routing path cost as the agent node for the target Group G according to the hop count information returned by each member of Group G. On the assumption that node A is correspond to the minimum cost routing path, and node A should be the multicast agent node. It should be noted that node A is multicast agent node for Group G and source S. For different multicast source nodes, or a different groups, multicast agent nodes may be different. 4. Security of multicast transmission This chapter describes the detailed steps of multicast: Multicast source node uses the unicast key shared with the agent node to encrypt multicast data, and sends it in accordance with the default routing. Multicast agent node is the group member node corresponding to the smallest hop count path between source node and members of group. It is a pre-determined and stored in the multicast source node. The method to choose multicast agent node is introduced in the front section. The default routing is the minimal cost routing path between source node and agent node. Receiving multicast data, agent node uses the shared key to decrypt the multicast data and transmits to the next higher layer, and re- encrypts the multicast data using the group key and transfer to other group members after decrypting. Before decryption of the multicast data, multicast agent node can determine if it is agent node corresponding to the received multicast data. The multicast source node carry the identity of the target group and Flag tag included in multicast data. when the multicast agent node receive multicast data, if it finds that it is a member of the group and the multicast data has not been transmitted by any node of the group according to identity of the group and Flag tag. Then it is the multicast agent. Next, details the applications of the multicast method mentioned above according to the network shown in Figure 1. Wei Expires January 9, 2010 [Page 7] Internet-Draft Multicast security July 2009 The multicast source node S uses unicast key Ks shared with multicast agent node A to encrypt multicast packets (i.e. encrypt the payload frame with Ks) and sends the multicast packets along the default routing. The packet carries the identity of target Group G (In this document, it is the address of the target group) and a Flag tag, with the initial value of 0 which indicates that the packet has not been forwarded by any group nodes. If the multicast packet has been transmitted by at least one group member, the Flag should be set to 1. Table 1 shows a possible frame format of a multicast packet, including the Flag tag, the address of source node and the target group[RFC4046]. +------+--------+---------+---------+-----+--------+-------+ | | |Address |Address |Hop |Sequence| | |Header|Flag(=0)|of target|of source|limit|Number |Payload| | | | group | node | | | | +------+--------+---------+---------+-----+--------+-------+ Table 1 a possible frame format of a multicast packet In this method, the multicast source node stores each multicast group , the corresponding multicast group routing and the key shared by the multicast source nod and corresponding multicast agent node. As shown in Table2, in the routing table, the identity of Group G is indicated by its address, which is 0x1234. At the same time, routing table storage also has the smallest cost routing from S to A. Before multicast source node sends multicast packets, it checks self-storage routing table in accordance with the address of target group and gets the routing and shared key. Wei Expires January 9, 2010 [Page 8] Internet-Draft Multicast security July 2009 +----------+--------+--------------------------+ |address of| | key shared with | | target |routing | corresponding multicast | | group | | agent node | +----------+--------+--------------------------+ | | | | | 0x1234 |...... |Ks1 | | | | | +----------+--------+--------------------------+ | | | | | 0x5678 |...... |Ks2 | | | | | +----------+--------+--------------------------+ | | | | | 0x9abc |...... |Ks3 | | | | | +----------+--------+--------------------------+ Table 2 routing table Multicast packet arrives to node K in accordance with the default routing. Node K finds that it is a non-group node from the identity of group and then forwarded multicast packet in accordance with the default routing. As node K does not know the key Ks, it can not intercept content packet. Multicast packet arrives to node A in accordance with the default routing. Node A finds that it is a member of the group accordance with the identity of group and then checkes the value of Flag (=0), therefore Node A determines it is multicast agent node. At the same time, node A finds the source node is S according to address of the source node, therefore, it uses the group key Ks shared with S to decrypt the data packet, and then transmits to higher layer to process. In addition, node A changes the value of flag to 1, and uses group key Kg to re-encryption multicast packets, and then transmits the multicast packet between nodes in the group. The transmission can used current multicast algorithm. After Nodes B, C, D, E receive the multicast packets, they find that they are members of the target group in accordance with the identity of group and checked the flag is 1, therefore, they directly use the group key Kg to decrypt the data packet, transmit to higher layer to process, and then transmit the multicast packet between nodes in the group. Wei Expires January 9, 2010 [Page 9] Internet-Draft Multicast security July 2009 5. Multicast Routing repair Multicast Routing repair using the reconstruction of the source node routing method. The node who found the interruption of link should send the multicast routing error command to the source node in broadcast or unicast. The multicast routing error command contains the address of the target group, address of the report node and other information. In the unicast approach, the command was sent along the reverse routing to the source node. The nodes that receive the command, no matter intermediate nodes or source node, should delete the error routing or set the state to be failure. In the broadcast approach, the node broadcast multicast routing wrong command among the nodes. The nodes who receive the command, no matter intermediate nodes or source node, check the routing of storage to see whether the address of next hop is the address of the node that sent the command. If it is, delete the error routing or set the state to be failure, and then the intermediate node should continue to broadcast the command. If not, then discard the command. When the source node receives the command, it should initiate routing re-discovery process for the reconstruction of multicast routing. 6. Security Considerations For this document provides a multicast security algorithm, conerns have been addressed above. 7. IANA Considerations There have been no IANA considerations so far in this document. 8. Acknowledgments TBD 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004. [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Wei Expires January 9, 2010 [Page 10] Internet-Draft Multicast security July 2009 Architecture", RFC 4046, April 2005. Author's Address Anni Wei Huawei Technologies Huawei Building, Xinxi Road No.3 Haidian District, Beijing 100085 P. R. China Phone: +86-10-82836297 Email: weianni@huawei.com Wei Expires January 9, 2010 [Page 11]