Secure transport of multicast traffic

CROSS-REFERENCE TO RELATED APPLICATION

0001This application claims the benefit of U.S. Provisional Patent Application No. 60/516,346, filed Oct. 31, 2003, the contents of which are incorporated by reference herein.

BACKGROUND OF THE INVENTION

0002A. Field of the Invention

0003Systems and methods consistent with the principles of the invention relate generally to methods and apparatuses for secure network communications.

0004B. Description of Related Art

0005Network computing applications involving groups of computers may send the same information to multiple computers in the group. There are three conventional ways to design a network application for group communication: unicast, broadcast, and multicast. As shown in <figref idref="DRAWINGS">FIG. 1</figref>, unicast systems allow the transmission of a copy of each data packet to one specific recipient. In order to transmit to multiple recipients, a separate connection is made with each recipient. Making multiple direct connections requires a large amount of bandwidth as the number of recipients increases and can result in delays since the same packet must be repeatedly copied and then transmitted to each recipient. Under a broadcast system, one copy of each packet may be sent to a broadcast address. As a result, the broadcast transmission may be sent to a large number of people when only a small number actually wish to receive the broadcast.

0006With a multicast system, a network application may send one copy of a packet(s) addressed to a group of recipients instead of just sending the packet(s) to one recipient, as in unicast systems. One or more networks may then forward the packet(s) to the recipients. Because of the dependence on the network to forward the packet(s), multicast applications may only work on networks that are multicast enabled. Generally, transmissions such as unicast, broadcast, or multicast are not secure because the destination address may be visible to anyone on the network, even if the data payload of the packet has been encrypted.

0007There are several conventional methods to transmit data packets through a network. Some of these conventional methods may provide secure transmissions, while others may not. One technique for secure transmission of data packets is the use of a unicast tunnel. As shown in <figref idref="DRAWINGS">FIG. 2</figref>, a source device <b>210</b> may transmit data to a tunnel gateway <b>220</b> for transmission across a unicast tunnel <b>230</b> in order to reach a destination device <b>270</b> through a tunnel endpoint <b>250</b>. For secure transmissions, the packet may be conventionally encrypted using a unique key for the particular unicast tunnel <b>230</b> being used. The packet may be encapsulated in a unicast tunnel packet at tunnel gateway <b>220</b>. Conventional tunnels may use an encapsulation protocol such as Internet Protocol Security's Encapsulating Security Payload (IPsec ESP). IPsec may provide a range of tunneling security features. IPsec, alone or with other protocols, such as Internet Key Exchange (IKE), may build unique sets of security associations for each tunnel including access controls, encryption keys, and authentication keys for a given tunnel. As a result, both the data and the final destination of the packet cannot be deciphered once the data enters the tunnel <b>230</b>. Tunnel endpoint <b>250</b> may decrypt received packets based on the decryption key and perform authentication check for a given tunnel and may then forward the original packet toward the packet's final destination, i.e., destination device <b>270</b>.

SUMMARY OF THE INVENTION

0008In one aspect consistent with principles of the invention, a method is provided for enabling secure multicast transmission through a network. The method may include receiving a first join request from a first downstream router via a first tunnel established between a forwarding router and the first downstream router, the join request indicating a multicast group to be joined; transmitting group keys to the first downstream router via the first tunnel, wherein the group keys are based on at least the multicast group; cryptographically processing a first packet using the group keys to generate an encapsulated payload; appending a first header to the encapsulated payload to form a first encapsulated packet; establishing a second tunnel with the first downstream router based on the appended first header; and transmitting the first encapsulated packet through the first group keying tunnel to the first downstream router.

0009In a second aspect consistent with principles of the invention, a method for receiving a multicast transmission through a network is provided. The method may include transmitting a join request to a forwarding router via a unicast tunnel established between the forwarding router and a first downstream router, the join request indicating a multicast group to be joined; receiving group keys in response to the transmitted join request, the group keys based at least on the multicast group; establishing a group keying tunnel between the forwarding router and the first downstream router; receiving an encapsulated packet via the group keying tunnel; cryptographically processing the encapsulated packet using the group keys to reveal a multicast packet including an Internet Protocol (IP) header having a multicast destination address; forwarding the multicast packet on an interface toward at least one multicast recipient corresponding to the multicast destination address.

0010In a third aspect consistent with principles of the invention, a device for receiving and transmitting packets within a computer network is provided. The device may be configured to receive a first join request from a first downstream router via a first tunnel established between the first downstream router and a forwarding router, the first join request indicating a multicast group to be joined; transmit group keys based on at least the multicast group to the first downstream router via the first tunnel; cryptographically process a first packet using the group keys to generate an encapsulated payload; append a first header to the encapsulated payload to form a first encapsulated packet, wherein the first header includes information associated with the first downstream router; establish a second tunnel with the first downstream router based on the appended first header; and transmit the first encapsulated packet through the second tunnel to the first downstream router.

0011In a fourth aspect consistent with principles of the invention, a device for receiving and transmitting packets within a computer network is provided. The device may be configured to receive a first join request from a first downstream router via a first unicast tunnel established between the first downstream router and a forwarding router; receive a second join request from a second downstream router via a second unicast tunnel established between the second downstream router and the forwarding router, wherein the first and second join request indicate a multicast group to be joined; generate group keys based at least on the multicast group; transmit the group keys to the first downstream router via the first unicast tunnel; transmit the group keys to the second downstream router via the second unicast tunnel; cryptographically process a first multicast packet using the group keys to generate an encapsulated payload; append a first unicast Internet Protocol (IP) header to the encapsulated payload to form a first encapsulated packet, wherein the first unicast IP header is associated with the first downstream router; establish a first group keying tunnel with the first downstream router based on the appended first unicast IP header; copy the encapsulated payload; append a second unicast Internet Protocol (IP) header to the copied encapsulated payload to form a second encapsulated packet, wherein the second unicast IP header is associated with the second downstream router; establish a second group keying tunnel with the second downstream router based on the appended second unicast IP header; transmit the first encapsulated packet through the first group keying tunnel to the first downstream router; and transmit the second encapsulated packet through the second group keying tunnel to the second downstream router.

BRIEF DESCRIPTION OF DRAWINGS

0012The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an implementation of the invention and, together with the description, explain the invention. In the drawings,

0013<figref idref="DRAWINGS">FIG. 1</figref> is an illustration of network transmission modalities.

0014<figref idref="DRAWINGS">FIG. 2</figref> is schematic illustration of an exemplary network communication using a tunnel.

0015<figref idref="DRAWINGS">FIG. 3</figref> is schematic illustration of an exemplary multicast data transmission through a tunnel.

0016<figref idref="DRAWINGS">FIG. 4</figref> is a schematic illustration of an exemplary multicast data transmission over multiple tunnels.

0017<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart illustrating an exemplary process of receiving a tunnel packet and decrypting the tunnel packet into a multicast packet.

0018<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart describing an exemplary method for transmitting multicast packets through tunnels.

0019<figref idref="DRAWINGS">FIG. 7</figref> is a schematic diagram illustrating an exemplary implementation of an encryption and authentication scheme consistent with principles of the invention.

0020<figref idref="DRAWINGS">FIG. 8</figref> is a schematic diagram illustrating an exemplary implementation of an encapsulation scheme consistent with principles of the invention.

0021<figref idref="DRAWINGS">FIG. 9</figref> is a schematic diagram illustrating another exemplary implementation of an encapsulation scheme consistent with principles of the invention.

0022<figref idref="DRAWINGS">FIG. 10</figref> is a flowchart describing an exemplary method of multicast data transmission through tunnels.

DETAILED DESCRIPTION

0023The following detailed description of the invention refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims and equivalents.

0024<figref idref="DRAWINGS">FIG. 3</figref> is schematic illustration of an exemplary multicast data transmission through a tunnel. As shown in <figref idref="DRAWINGS">FIG. 3</figref>, multicast data transmission using tunnels may begin with a multicast source <b>300</b>. Multicast source <b>300</b> may transmit multicast data to tunnel gateway <b>310</b> in the form of multicast packets. A multicast packet may include both a multicast data payload and an IP header. The multicast data payload may be a piece of data from a multicast stream requested by a recipient downstream of tunnel gateway <b>310</b>. The Internet Protocol (IP) header may provide information including network addresses of multicast source <b>300</b> and a multicast group address subscribed to by recipient <b>340</b>. The network addresses may be, for example, IP addresses. The multicast stream may be defined as a group of packets that make up the data being multicast out for a particular source and group (notated as (S,G)).

0025The multicast stream may only be directly transmitted over a multicast-enabled network. Routers and other intermediate network nodes in a non-enabled network may not forward data packets containing a multicast header because the non-enabled devices may not read the multicast recipient address and therefore may not know where to forward the multicast packet. In order to transmit multicast data over a non-enabled network, source <b>300</b> may transmit multicast packets through a unicast tunnel, beginning with a tunnel gateway <b>310</b> and ending with a tunnel endpoint <b>330</b>. <figref idref="DRAWINGS">FIG. 3</figref> illustrates an exemplary path involving only one tunnel to provide clarity of the transmission path between multicast source <b>300</b> and multicast recipient <b>340</b>. Multiple tunnels may be used and are discussed below with respect to <figref idref="DRAWINGS">FIG. 4</figref>. A multicast packet may be translated into an encapsulated packet for transport through a unicast tunnel at tunnel gateway <b>310</b>. Tunnel gateway <b>310</b> may encrypt and authenticate a multicast packet and may then encapsulate the encrypted and authenticated packet in an encapsulated packet. The encapsulation may include attaching a header that includes the source and endpoint unicast address for the tunnel (e.g., a source and destination IP address in an IP tunnel). The IP header and the nature of the data packet may then be invisible to the network. Tunnel gateway <b>310</b> may then transmit a multicast packet through a non-multicast enabled network as an encapsulated packet to tunnel endpoint <b>330</b>.

0026Following transmission by tunnel gateway <b>310</b>, the encapsulated packet may encounter a number of intermediary node devices along the tunnel path to tunnel endpoint <b>330</b> including, for example, routers <b>320</b><i>a </i>and <b>320</b><i>b </i>(“routers <b>320</b>”) (e.g., a unicast node). Routers <b>320</b> may operate to forward packets along a particular path to the next destination, or hop, whether it be another router or the final destination. Routers <b>320</b> may examine the unicast tunnel header attached to the tunnel packet to determine the destination address for the tunneled packet. A routing table within each of routers <b>320</b> may be used by routers <b>320</b> to determine which path to forward a packet having a particular multicast group address. Using the routing table, routers <b>320</b> may determine the correct path for the tunnel packet and may forward the tunnel packet accordingly. The path between tunnel gateway <b>310</b> and tunnel endpoint <b>330</b> may traverse a number of intermediary nodes, with each intermediary node similarly forwarding the tunnel packet until it arrives at tunnel endpoint <b>330</b>. If not encapsulated with a unicast header, but instead left with the IP header, a non-multicast enabled node device may not recognize the multicast group address and consequently may not be able to route the packet to a next destination, resulting in a dropped packet.

0027Tunnel endpoint <b>330</b> may receive the encapsulated packet. Tunnel endpoint <b>330</b> may remove the encapsulation from the encapsulated packet and may decrypt and authenticate the resulting packet. The decryption and authentication process produces the original multicast packet having an IP header and a multicast data payload. Tunnel endpoint <b>330</b> may forward the multicast packet toward other multicast recipients <b>340</b> and additional downstream routers based on a destination found in the IP header, such as the multicast group address.

0028Referring now to <figref idref="DRAWINGS">FIG. 4</figref>, an exemplary multicast system using multiple tunnels is illustrated. A multicast source <b>400</b> may transmit a copy of each multicast packet to a forwarding router <b>410</b> for each multicast group. Although shown connected for purposes of simplicity, it should be understood that multicast source <b>400</b> and forwarding <b>410</b> may be operatively connected in any suitable manner, with additional intermediary devices (e.g., routers, etc.) potentially positioned therebetween. Additionally, as defined herein, a multicast group relates to a defined multicast group address on which a group of multicast recipients <b>460</b><i>a</i>-<b>460</b><i>h </i>(“multicast recipients <b>460</b>”) continually look for the multicast stream. Multicast recipients <b>460</b> located within a multicast network may be connected to the multicast stream via one of group keying tunnels <b>420</b><i>a</i>-<b>420</b><i>c </i>(collectively, “group keying tunnels <b>420</b>”) as well as one of pre-existing unicast tunnels <b>425</b><i>a</i>-<b>425</b><i>c </i>(“pre-existing unicast tunnels <b>425</b>”). In the present implementation, each of tunnels <b>420</b> relates to the same multicast group and therefore provides multicast packets encrypted, authenticated, and encapsulated using the same set of group keys, yet having differing IP destination headers. It should be understood that additional sets of unicast tunnels may be used for different multicast streams. Group keying tunnels <b>420</b> and pre-existing unicast tunnels <b>425</b> may be established for each multicast stream and for each pairing of forwarding router <b>410</b> and downstream router <b>440</b> through a unicast network <b>428</b> (e.g., the Internet, a local area network (LAN), etc.). Forwarding router <b>410</b> may be a compatible router, a network server, a computer, or some other tunnel compatible network interface including a component within a multicast source <b>400</b>.

0029In accordance with principles of the invention, a join request may be received from one of multicast recipients <b>460</b> via an associated one of downstream routers <b>440</b> through an associated one of pre-existing unicast tunnels <b>425</b> indicating participation in a group keying encryption scheme. Forwarding router <b>410</b> may then generate associated group keys and exchange the keys with the requesting one of downstream routers <b>440</b> again via the associated one of pre-existing unicast tunnels <b>425</b>. The forwarding router <b>410</b> may then encrypt and authenticate the original multicast packet, using the group keys, and encapsulate the multicast packet, as described with respect to <figref idref="DRAWINGS">FIG. 3</figref> above, to form encapsulated packets from each multicast packet. Additional details regarding the received join request, encryption, authentication, and encapsulation will be set forth in additional detail below.

0030Forwarding router <b>410</b> may also attach an IP header to each encapsulated packet and direct each encapsulated packet through the appropriate group keying tunnel <b>420</b> toward each requesting downstream router <b>440</b>. The processing associated with encrypting, authenticating, and encapsulating the multicast packets may be collectively referred to as tunneling encapsulation processing and may include any techniques necessary to prepare the multicast packets for forwarding to downstream routers <b>440</b> via tunnels <b>420</b>.

0031Additionally, it should be understood that the number of tunnels shown is illustrative only. Any number of tunnels may exist depending on the number of downstream routers, seeking multicast group data and the number of multicast groups (S,G) or (*,G) these downstream routers wish to join. The terminology (S,G) refers to a manner of identifying multicast groups by a source S and an group address G. For (*,G) groups, multiple sources may be generating the original multicast packets. The encapsulated packet may be transmitted through the appropriate one of group tunnels <b>420</b> corresponding to the unicast header to a downstream router <b>440</b><i>a</i>-<b>440</b><i>c </i>(“downstream routers <b>440</b>”). For example, downstream routers <b>440</b> on the multicast recipient end may be compatible routers, network servers, one of multicast recipients <b>460</b>, or some other tunnel compatible network interface. Further, if any of downstream routers <b>440</b> is a network server, the network between the network server serving as a downstream router and the multicast recipient should be multicast enabled so that the multicast packet may be transmitted to multicast recipient <b>460</b> from downstream router <b>440</b>. Otherwise, the method described above as occurring between forwarding router <b>410</b> and one of downstream routers <b>440</b> would occur again in a similar fashion between the downstream router <b>440</b> and additional routers downstream of routers <b>440</b> (not shown).

0032Upon reaching one of downstream routers <b>440</b>, each encapsulated packet may be de-encapsulated, decrypted and authenticated. The resulting multicast packet may then be routed by the downstream router <b>440</b> toward multicast recipients <b>460</b> in a known manner.

0033<figref idref="DRAWINGS">FIG. 5</figref> is a flow diagram illustrating one exemplary process for receiving multicast packets through a network in accordance with principles of the invention. In this exemplary implementation, a multicast packet is transmitted from multicast source <b>400</b> to multicast recipient <b>460</b><i>d </i>via forwarding router <b>410</b>, tunnel <b>420</b><i>b</i>, and downstream router <b>440</b><i>b</i>. This implementation is exemplary only and any suitable combination of network elements may be utilized in accordance with principles of the invention. Processing may begin by downstream router <b>440</b><i>b </i>establishing an initial unicast tunnel <b>425</b><i>b </i>with forwarding router <b>410</b> to facilitate an exchange of unicast packets (act <b>500</b>). Once tunnel <b>420</b><i>b </i>has been established, a join request may be received from multicast recipient <b>460</b><i>d </i>(act <b>502</b>), indicating that recipient <b>460</b><i>d </i>would like to subscribe to a particular multicast group and received transmissions relating to that group. The join request may follow any suitable multicast protocol as is known in the art. In one implementation consistent with principles of the invention, the join request may be a Protocol Independent Multicast—Sparse Mode (PIM-SM) join request. Alternatively, an Internet Group Management Protocol (IGMP) join request may be received. Regardless of the protocol used, the received join request should include at least an indication of which multicast group is desired to be joined (e.g., a multicast group address).

0034Upon receipt of a join request, downstream router <b>440</b><i>b </i>forwards the join request to forwarding router <b>410</b> through pre-existing unicast tunnel <b>425</b><i>b </i>(act <b>504</b>). As will be discussed in additional detail below, forwarding router <b>410</b> generates group encryption and authentication keys (collectively, “group keys”) associated with downstream router <b>440</b><i>b</i>. Following transmission of the join request, downstream router <b>440</b><i>b </i>may then receive security association parameters from forwarding router <b>410</b> (act <b>505</b>). In one implementation consistent with principles of the invention, the security association parameters may include specifics relating to the group keying scheme employed by forwarding router <b>410</b>, including, but not limited to, key lifetime, cipher used, key length, overlap handling instructions, request messages, acknowledgement messages, status and error messages, rollover protocols, etc. Once the security parameters have been exchanged, the generated keys are then communicated to and received by downstream router <b>440</b><i>b </i>via pre-existing unicast tunnel <b>425</b><i>b </i>(act <b>506</b>). Forwarding router <b>410</b> then encrypts and authenticates each incoming multicast packet associated with the selected multicast group using the group keys, and encapsulates the resulting payload into an encapsulated packet having a tunnel IP header incorporating source and destination addresses (e.g., forwarding router <b>410</b> and downstream router <b>440</b><i>b</i>) for the encapsulated payload. Next, a group keying tunnel <b>420</b><i>b </i>is established related to the tunnel IP header source and destination addresses, to accommodate the encapsulated packet (act <b>507</b>). The encapsulated packets are then transmitted to and received by downstream router <b>440</b><i>b </i>via group keying tunnel <b>420</b><i>b </i>(act <b>508</b>). The received packets are then de-encapsulated, thereby stripping the tunnel IP header and leaving the encrypted and authenticated data payload (act <b>510</b>). The received packets are then decrypted using the group keys received in act <b>506</b>, and in accordance with the negotiated security association parameters, to expose the initial multicast packet (act <b>512</b>). Downstream router <b>440</b><i>b </i>may then analyze the header of the original multicast packet to identify the interface on which multicast recipients are looking for the packet based on the group (destination) addresses in the header (act <b>514</b>). The de-encapsulated and decrypted packets are then forwarded out toward multicast recipient <b>460</b><i>d </i>on the identified interface (act <b>516</b>).

0035<figref idref="DRAWINGS">FIG. 6</figref> illustrates an exemplary method for secure multicast data transmission between a source and a recipient through tunnels. Initially, as described briefly above, forwarding router <b>410</b> receives a join request from downstream router <b>440</b><i>b </i>via pre-existing unicast tunnel <b>425</b><i>b </i>(act <b>600</b>). In response, forwarding router <b>410</b> first determines whether a join request has been previously received for the particular multicast group (act <b>602</b>). If so, the process proceeds to act <b>606</b> described below. However, if a join request has not been previously received, forwarding router <b>410</b> may exchange security association parameters with downstream router <b>440</b><i>b </i>(act <b>603</b>). As described above, the security association parameters may include specifics relating to the group keying scheme employed by forwarding router <b>410</b>, such as key lifetime, cipher used, key length, rollover protocols, etc. Group encryption and authentication keys are generated based at least on the multicast group (act <b>604</b>). Group keys of this form may be represented by the phrase K_g^p, where ‘p’ represents the type of key and ‘g’ represents the multicast group. Accordingly, one exemplary set of group keys may be K_239.1.1.1^aas the authentication key and K_239.1.1.1^eas the encryption key, where 239.1.1.1 is the IP address for the desired multicast group. In an alternative implementation consistent with principles of the invention, the group keys may be further based on the addressing information associated with forwarding router <b>410</b>. In this implementation, the group keys may be represented as K_{5.5.5.1,239.1.1.1}^afor authentication and K_{5.5.5.1,239.1.1.1}^efor encryption, where 5.5.5.1 is the IP address for forwarding router <b>410</b>.

0036Once generated, the groups keys may be forwarded to downstream router <b>440</b><i>b </i>via pre-existing unicast tunnel <b>425</b><i>b </i>to enable subsequent decryption and authentication of received multicast packets (act <b>606</b>). Upon receipt of a multicast packet associated with the selected multicast group (e.g., having a destination IP address of 239.1.1.1) from multicast source <b>400</b> (act <b>606</b>), forwarding router <b>410</b> initially encrypts and authenticates the packet header and payload information using the group keys generated in act <b>604</b> to generate an encrypted and authenticated multicast packet (act <b>608</b>). Next, the encrypted and authenticated multicast packet is encapsulated to form an encapsulated payload for an encapsulated packet (act <b>610</b>). In one implementation, the payload may be an Encapsulating Security Payload (ESP), as defined in RFC 2406 published by the IETF (Internet Engineering Task Force).

0037The next hop for the group keying tunnel is then determined (act <b>611</b>). More specifically, the destination address of the next downstream router or routers to receive the packet is identified. A tunnel IP header may then be appended to the encapsulated payload to form the encapsulated packet (act <b>612</b>). In one implementation consistent with principles of the invention, the tunnel IP header includes source and destination addresses associated with forwarding router <b>410</b> and downstream router <b>440</b><i>b</i>, respectively, as identified in act <b>611</b>. In accordance with these addresses, a group keying tunnel <b>420</b><i>b </i>may then be established between forwarding router <b>410</b> and downstream router <b>440</b><i>b </i>to facilitate exchange of multicast packets (act <b>613</b>).

0038In this manner, only one encapsulation is required for each multicast group, regardless of the number of multicast recipients subscribing to the multicast group. Accordingly, the only distinction between encapsulated packets destined for different downstream routers <b>440</b> is the tunnel IP header appended. Upon encapsulation, the received multicast packet is forwarded through group keying tunnel <b>420</b><i>b </i>to downstream router <b>440</b><i>b </i>(act <b>614</b>). It is next determined whether any downstream routers have not yet been serviced (act <b>616</b>). If so, the process returns to act <b>611</b>, where the appropriate next hop is determined. If not, the process ends, as the multicast packet has been router to all requesting downstream routers.

0039<figref idref="DRAWINGS">FIG. 7</figref> is a schematic diagram illustrating one exemplary implementation of an encryption scheme consistent with principles of the invention. As shown in <figref idref="DRAWINGS">FIG. 7</figref>, a multicast packet <b>700</b> received by forwarding router <b>410</b> may include a UDP (user datagram protocol) header (UDP) <b>702</b>, an IP header (IP) <b>704</b>, and a payload (P) <b>706</b>. Upon encryption by forwarding router <b>410</b>, an encrypted multicast packet <b>708</b> may be generated incorporating multicast packet <b>700</b>.

0040<figref idref="DRAWINGS">FIG. 8</figref> is a schematic diagram illustrating one exemplary implementation of an encapsulation scheme consistent with principles of the invention. As shown in <figref idref="DRAWINGS">FIG. 8</figref>, encapsulation consistent with principles of the invention may generate an encapsulated payload <b>800</b> incorporating encrypted multicast packet <b>708</b> described in <figref idref="DRAWINGS">FIG. 7</figref>, an ESP header <b>802</b> to facilitate de-encapsulation, and an authentication trailer <b>804</b> to facilitate authentication of the received packet.

0041<figref idref="DRAWINGS">FIG. 9</figref> is a schematic diagram illustrating several exemplary implementations of encapsulated packets consistent with principles of the invention. More specifically, a first encapsulated packet <b>900</b> is illustrated that includes the encapsulated payload <b>800</b> of <figref idref="DRAWINGS">FIG. 8</figref> as well as an IP header (IP′) <b>902</b> associated with a first downstream router <b>440</b><i>a</i>. Additionally, a second encapsulated packet <b>904</b> is illustrated that also includes the encapsulated payload <b>800</b> of <figref idref="DRAWINGS">FIG. 8</figref> as well as a second IP header (IP″) <b>906</b> associated with second downstream router <b>440</b><i>b</i>. A third encapsulated packet <b>908</b> is illustrated that also includes the encapsulated payload <b>800</b> of <figref idref="DRAWINGS">FIG. 8</figref> as well as a third IP header (IP′″) <b>910</b> associated with a third downstream router <b>440</b><i>c</i>. As shown, using the group keying and encapsulation scheme consistent with principles of the invention, encryption, authentication, and encapsulation need only be performed once for each multicast packet, with downstream router designation being accommodated by distinct IP headers appended to the encapsulated packet, thereby substantially reducing processing overhead for the multicast process.

0042One exemplary implementation of the multicast data transmission process through an IP network environment is described in <figref idref="DRAWINGS">FIG. 10</figref>. Initially, a first set of IPsec unicast tunnels <b>425</b> may be created between forwarding router <b>410</b> and each downstream router <b>440</b> (act <b>1000</b>). IPsec may provide a range of tunneling security features including the building of security associations for tunnels. The tunnel security associations may include access controls, encryption keys, and authentication keys for the tunnel.

0043After the establishment of IPsec tunnels <b>425</b> from forwarding router <b>410</b> to downstream routers <b>440</b>, one or more of the downstream routers <b>440</b> may receive a join request from a multicast recipient <b>460</b> to join a specific multicast group having a defined address (act <b>1002</b>). In response, the receiving downstream routers <b>440</b> may determine whether forwarding router <b>410</b> supports a group key encryption/authentication scheme (act <b>1004</b>). In one implementation, downstream routers <b>440</b> maintain a table indicating participation in the group key encryption scheme based on (S,G) or (*,G) of the multicast groups. Consultation of this table may enable downstream routers <b>440</b> to determined forwarding router <b>410</b>'s participation and ability to perform the group key tunneling function. If it is determined that forwarding router <b>410</b> supports group key encryption, a join request may then be transmitted to forwarding router <b>410</b> indicating group key participation via associated ones of tunnels <b>425</b> (act <b>1006</b>).

0044Upon receipt of the join request, forwarding router <b>410</b> exchanges security parameters with the requesting downstream routers <b>440</b> via tunnels <b>425</b> (act <b>1007</b>) and generates group keys for authentication and encryption in the manner set forth above with respect to <figref idref="DRAWINGS">FIG. 6</figref> (act <b>1008</b>). In an alternative implementation consistent with principles of the invention, additional downstream routers may have already signaled for the multicast group, therefore previously triggering group key generation by forwarding router <b>410</b>. In either case, the group keys are then forwarded to the requesting downstream routers <b>440</b> via tunnels <b>425</b> for use in decrypting and authenticating received encapsulated packets (act <b>1010</b>). Next, incoming multicast packets are encrypted, authenticated, and encapsulated using the group keys generated in act <b>1008</b> to generate encapsulated payloads (act <b>1012</b>).

0045Next, forwarding router <b>410</b> identifies IP addresses associated with each requesting downstream router <b>440</b> (act <b>1014</b>), and generates encapsulated packets for each identified downstream router <b>440</b> (act <b>1016</b>), where the individual encapsulated packets include a copy of the encapsulated payload generated in act <b>1012</b> and a unique IP header including a destination IP address associated with the respective downstream routers <b>440</b>. Additionally, following identification of the requesting downstream routers <b>440</b>, group keying IPsec tunnels <b>420</b> may then be established to facilitate the exchange of the encapsulated packets between forwarding router <b>410</b> and downstream routers <b>440</b> (act <b>1018</b>). The encapsulated packets are then forwarded via tunnels <b>420</b> to downstream routers <b>440</b> as identified in the tunnel IP headers of each encapsulated packet (act <b>1020</b>).

0046Once received by downstream routers <b>440</b>, the encapsulated packets are de-encapsulated, decrypted, and authenticated or otherwise cryptographically processed using the group keys received in act <b>1010</b> to generate the original multicast packets (act <b>1022</b>). The multicast packets are then forwarded towards multicast recipients <b>460</b> via appropriate interfaces according to the multicast destination addresses of the multicast packets (act <b>1024</b>). By enabling multicast packets to be encrypted and encapsulated using group keys associated with individual IPSec tunnels, it becomes unnecessary to cryptographically process multicast packets individually for each recipient.

0047The order of the above steps may be changed without affecting the result. For example, the group keys may be distributed after the creation of any specific encapsulated payloads using those keys in the security association for the group tunnels with the security associations generated for each of group tunnels <b>420</b> having the same key. Additionally, if the requests have been received so that the multicast recipients are known, groups can be defined and group tunnels <b>420</b> formed without first generating individual tunnels between multicast source <b>400</b> and each multicast recipient <b>460</b>.

0048Embodiments may be implemented in digital electronic circuitry, computer hardware, firmware, or software, or in combinations thereof. Embodiments may be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, a data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program may be deployed for execution on one computer or on multiple computers at one site or distributed across multiple sites interconnected by a communication network.

0049Method acts of embodiments may be performed by one or more programmable processors executing a computer program to perform functions consistent with the principles of the invention by operating on input data and generating output. Method acts may also be performed by, an apparatus consistent with the principles of the invention implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

0050Processors suitable for the execution of a computer program may include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer may also include, or may be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, for example, magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data may include all forms of nonvolatile memory, including, by way of example, semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices, magnetic disks, e.g., internal hard disks or removable disks, magneto-optical disks, CD-ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in special purpose logic circuitry.

0051Embodiments consistent with the principles of the invention may be implemented in a computing system that may include a back-end component, e.g., as a data server, or that may include a middleware component, e.g., an application server, or that may include a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user may interact with an implementation of the invention, or any combination of such back-end, middleware, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks may include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet.

0052The computing system may include clients and servers. A client and server are generally remote from each other and typically may interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

0053A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention.