Sunteți pe pagina 1din 7

PROACTIVE MULTICAST-BASED IPSEC DISCOVERY PROTOCOL AND MULTICAST EXTENSION Trung H.

Tran SPAWAR Systems Center, San Diego


ABSTRACT In a large-scale network, manual configuring IPsec tunnels and security policies is labor intensive and difficult to manage. In some cases, a full-mesh IPsec tunnels are required so that all Plain Text (PT) networks behind the IPsec devices can be reachable. Without an IPsec Discovery Protocol (IDP), static routes have to be configured at all PT routers that are connected to the IPsec devices so that a PT packet can be encrypted and sent to a remote PT network. Another disadvantage of not having an IDP is that an IPsec device has no way of knowing if an IPsec peer is down so that security policy (SP) can be updated. As a result, data are sent to IPsec dead peer will be dropped in the Cipher Text (CT) network until the Security Association (SA) timer expires which can take a long period of time. Several IPsec Discovery Protocols with different mechanisms for IPsec discovery have been designed and implemented. The two most common mechanisms are the Multicast-based and the Client-Server. Another mechanism is used in Implicit Peer Enclave Prefix Discovery (IM-PEPD) protocol. While these protocols are reactive, the protocol described in the paper is proactive and well suited for dynamic networks in which IPsec devices are often unreachable and their mobility requires IPsec tunnels and SP to be updated dynamically. This paper presents an IDP called the Proactive Multicastbased IPsec Discovery Protocol (PMIDP) that has been designed, developed, and demonstrated in the multinational Interoperable Networks for Secure Communications (INSC) network an IPv6 network based on the CT Core Routing Architecture. For PMIDP, at the end of the discovery process, all IPsec devices in the network have full-meshed IPsec tunnels, and SPs are setup and ready for PT traffics. The paper also describes the benefits of the Proactive Discovery Mechanism including support for security gateway, network mobility, PT-to-PT dynamic routing, dead peer detection, and PT/CT address separation. Finally, the paper presents a multicast mechanism of the PMIDP that enables an IPsec to dynamically multicast route PT multicast IP packets in CT network without compromising security protection of PT prefixes and multicast addresses in the CT network. PROTOCOL OVERVIEW The PMIDP is a proactive protocol that sends Hello and PT Prefix Advertisement Packets periodically to a known multicast IP address for discovery process. The Hello Packet is sent un-encrypted. The PT prefixes Advertisement Packets are encrypted and sent over a multicast IPsec tunnel. The PT prefixes are encrypted for security protection in the CT network. At the end of the discovery process, the IPsec will have a full-mesh SAs and Security Policies ready to encrypt and forward any PT network packet arrives at the PT interface. The PMIDP also detects if a remote IPsec is down if the Hello Packets from the remote IPsec are not received in the duration of 4 times of the Hello timer interval. When a down IPsec is detected, all policies associated with the IPsec are deleted from the security policy database. To support dynamic routing between PT networks, the IPsec is required to run Open Shortest Path First (OSPF) or Routing Information Protocol (RIP) on the PT interface to learn all the PT prefixes behind the PT router. Figure 1 shows the connection between an IPsec and the PT/CT routers.
Redistribute Red Network Prefix A

Red router into OSPF IPsec Blk router OSPF


Link State Update Advertise prefix A (encrypted)

BLK NETWORK

Figure 1. IPsec and PT/CT (red/blk) routers basic diagram On the outbound direction (PT to CT), security policies are updated dynamically based on the updates in the routing table about the PT prefixes via OSPF/RIP routing protocol. On the inbound direction (CT to PT), any security policy updates (add or delete) that are requested by peer IPsec will be redistributed to the routing table of the OSPF/RIP routing protocol. As a result, the PT router has a route to a

remote PT prefix in its routing table only if there are SA and security policies for the remote PT prefix between the local and the remote IPsec. REQUIREMENTS

protocol declares that the IPsec devices has been restarted and remove all current SPs with that IPsec. New SP will be added when PT Prefix Advertisement PDUs from the restarted IPsec are received. QUIET MODE

Cipher Text Network: PMIDP requires the CT Network to support IP Multicast routing. The IPsec running PMIDP will function as a multicast host in the CT routing domain. The protocol requires two IP multicast addresses. One multicast address (HELLO_MULT_IP_ADDR) is used for sending and receiving un-encrypted Protocol Data Unit (PDU) packets and the other multicast address (ADV_MULT_IP_ADDR) is used for encrypted PDU packets. Plain Text Network: The PT interface of the IPsec device is required to run an Internal Gateway Protocol (IGP) such as RIP or OSPF. The interface between the PMIDP and the IGP enables the protocol to dynamically update Security Policies based on dynamically changing of PT networks that the IPsec device is fronting. Key Management: PMIDP requires IPsec to run in Tunnel mode with Encapsulating Security Payload (ESP) for security services. The PMIDP requires a protocol key and a data key. The protocol key must be a pre-shared key that is used for encryption and protection of PT prefixes that are advertised in the CT network. The data key can be either static or dynamic key that is used for encryption of data between PT networks. The PMIDP also requires the IPsec protocol to be able to encrypt protocol data using the pre-shared key and send them over an IPsec tunnel whose destination IP address is a multicast address. DEAD PEER DETECTION When Hello PDU from the same IPsec is not received in 4 times of the Hello Timer interval, the PMIDP declares that the IPsec is down. The protocol then removes all SPs that are associated with the down IPsec. In addition to detecting when a peer IPsec is down, the protocol also detects to determine when a remote IPsec has been restarted. When a remote IPsec restart is detected, all SPs with that IPsec are removed. This is a necessary action to prevent mismatch, overlapping, or stale SPs that may cause some security problem later on. One approach to detect a restart of an IPsec is as followed. Data of each Hello PDU that is sent by the IPsec is a timestamp that is taken during the initialization process. This timestamp can be used as a unique number by the dead peer detection process. When the timestamp of the Hello PDUs from the same IPsec device changed, the

To conserve bandwidth at steady state, PMIDP goes to Quiet mode in which only Hello PDUs are sent as keep alive. A steady state is defined as when there is no SPs are updated in 4 times of the Hello Interval. This implies that all IPsec devices are steady in up status, and there are no remote or local PT prefixes updated by the PT routers. When SP database is updated or there is a new IPsec device is detected, the PMIDP goes back to active mode in which Advertisement PDUs are sent periodically until the condition for the Quiet mode is met. In quiet mode, PMIDP only sends 4 bytes of UDP data on the CT network. DYNAMIC ROUTING BETWEEN PLAIN TEXT NETWORKS As mentioned above, at the end of the discovery process, an IPsec will have a full meshed SAs and SPs to all other IPsec devices in the network. If an outbound SP is found for a PT IP packet, it will be encrypted and sent over the appropriate IPsec Tunnel. If not, it will be dropped. When a PT network (prefix) behind a PT router from a remote IPsec is down, a local IPsec continues to encrypt and forward IP packets to that down PT prefix as long as there is outbound SP to that PT prefix in the SP database. This is clearly the case of IPsec wasting the bandwidth in the CT network because the IP packets to the remote prefix should be dropped at the local PT router instead of the remote PT router. One solution to this problem is to provide an IPsec a capability to learn dynamically change of PT prefixes behind the PT router. When a change of local PT prefixes occurs, the IPsec shall inform other IPsec devices to update their SPs by sending new PT Prefix ADV.PDU reflecting the change. When the remote receives the updated PT Prefix ADV.PDU, it can be either adding SPs for new prefixes learned or deleting SPs for prefixes that are no longer existed. One approach to provide an IPsec the capability is to run an IGP (OSPF, RIP, etc) on the PT interface to the PT router. The IGP cant be run on the CT interface for obvious security reason that there should be no PT prefixes to be seen in the CT network. The IGP will provide the PMIDP the necessary routing information in the PT network. The PMIDP will informs other IPsec devices via Advertisement PDUs when the IGP routing database is

changed. This function is similar to redistribution of OSPF/RIP into PMIDP in which all PT prefix routing database in OSPF/RIP are redistributed in PMIDP SP database. Dynamic routing between the PT networks also requires the PT routers to have routes to each remote PT prefix that is discovered by the PMIDP. This function is similar to redistribution PMIDP into OSPF/RIP in which all SPs database are redistributed in OSPF/RIP routing database. One technique to implement this function is to add a route for each new SP created for PT prefix that is discovered from the PMIDP and to configure the IPsec to redistribute the new routes into OSPF/RIP. As a result, the PT router will have route to a remote PT prefix when there is a SP for that prefix at the IPsec. In another word, no route to a remote PT prefix at the PT router means that there is no SP for that prefix at the IPsec device. MOBILITY SUPPORT The capability of an IPsec running PMIDP to learn the PT prefixes behind a PT router via OSPF/RIP on the PT interface enables the IPsec to detect when a PT mobile network has been move from one IPsec to another. Figures 2 and 3 show PT Mobile Network with Prefix X moves from IPsec B to IPsec A.
Advertise prefix A (encrypted) Red Network Prefix A

prefix X to IPsec B and C. IPsec B and C will create security policies for Prefix X with IPsec A. SECURITY GATEWAY BETWEEN CIPHERTEXT NETWORKS Because the PMIDP is a proactive protocol that advertises PT prefixes, it can function as a Security Gateway (SG) between two CT Core Routing Networks as shown in Figure 4.
Red Network Prefix C Red Network Prefix D Red Network Prefix E

Red Network Prefix B

Adv prefix C (encrypted) Adv prefix B (encrypted) BLACK NETWORK X

Adv prefix D (encrypted)

Adv prefix E (encrypted) BLACK NETWORK Y

Adv prefix ADE (encrypted)

Adv prefix ABC (encrypted)

SECURITY GATEWAY

SECURITY GATEWAY

Red Network Prefix A

Figure 4. Security Gateway Between 2 CT Core Routing Domains The SG IPsec learns the PT prefixes from the other CT Network via OSPF routing table and advertises the learnt PT prefixes on the connected CT Network. Ideally, if the PT prefixes of the other CT Network can be summarized in a single prefix, the number of Security Policies that the SW IPsec has to handle is minimized. And the sizes of the PT Prefix Advertisement Packets are smaller thus reducing the protocol overhead. DEFAULT GATEWAY FUNCTION A PMIDP IPsec can also advertise the default security policy when it is configured as the Default Gateway. The default policy advertisement is sent by the Default Gateway to all IPsecs for their default policies. When an IP packet arrives at the PT interface of an IPsec, the IPsec will find a match security policy to forward the packet on the CT interface encrypted. If no policy is found, the packet will be dropped unless there is a default policy. Figures 5 and 6 show an example of how default policy is used. In this example IPsec C and IPsec D are configured as the Default Gateway. In figure 5, IPsec A and IPsec B discover each other using PMIDP. Ship1 sends data to Ship2 using direct Security Policy that was created dynamically by the PMIDP.

Ipsec A
Red Network Prefix C

Red router

Ipsec C

Blk router

BLK NETWORK Ipsec B


Red Mobil Network Prefix X Red Network Prefix B

Advertise prefix C (encrypted)

Advertise prefix B,X (encrypted)

Figure 2: Mobile network Prefix X is moving away from IPsec B


Advertise prefix A,X (encrypted) Red Network Prefix A Red Mobil Network Prefix X

Ipsec A
Red Network Prefix C

Red router

Ipsec C

Blk router

BLK NETWORK Ipsec B

Advertise prefix C (encrypted)

Advertise prefix B (encrypted)

Red Network Prefix B

Figure 3: Mobile network Prefix X arrives at IPsec A When IPsec B detects that PT prefix X is no longer in its routing table (mobile network has moved), IPsec B stops advertising Prefix X. IPsec B also sends an update packet to IPsec A and C to remove all security policies that associate with Prefix X and IPsec B. When the Mobile Network Prefix X shows up in the routing table of IPsec A (mobile network has arrived), IPsec A starts advertising

SHIP 2
Ipsec A Ipsec C
Red Network Prefix C

Red Network Prefix A

BLK NETWORK Ipsec B


Red Network Prefix B

SHORE 1

Advertise Default Policy

Figure 7 shows the basic connection of a security gateway for scalability. Figure 8 shows one option how SG IPsec devices can be connected between three multicast groups in a large network for scalability.
Red Network Prefix D Red Network Prefix E Red Network Prefix F Red Network Prefix G Red Network Prefix H Red Network Prefix I

SHIP 1

Figure 5. Ship 1 sends data to Ship 2 using A-B Security policy In Figure 6, Ship 2 moved and was no longer on the same CT network with Ship 1. Ship 1 is no longer having security policy with Ship 2. However, Ship 1 will continue sending data to Ship 2 using Default policy to Shore.
SHIP 2
Advertise Default Policy Red Network Prefix A

MULTICAST GROUP X

MULTICAST GROUP Y

MULTICAST GROUP Z

COMMUNITY X

GIG NETWORK
COMMUNITY Y
Adv prefix ABCFGHI (encrypted) Adv prefix ABCDEHI (encrypted)

COMMUNITY Z

SHORE 2
Red Network Prefix D

Ipsec A BLK NETWORK

Red Network Prefix B

IPSEC GATEWAY

IPSEC GATEWAY

Adv prefix ABCDEFG (encrypted)

IPSEC GATEWAY

Red Network Prefix C

Ipsec D Ipsec C
Red Network Prefix C

Red Network Prefix A

BLK NETWORK Ipsec B


Red Network Prefix B

Figure 8. Scalable Option in GIG Network MULTICAST EXTENSION Overview: The IPsec Multicast Discovery Protocol (IMDP) is a simple protocol that enables an IPsec to dynamically discover multicast receivers in the PT networks so that PT multicast traffics can be encrypted and dynamically multicast routed in the CT network. This protocol is an extension of the PMIDP. When IMDP is configured to run with a multicast support IPsec, it provides multiple security enclave networks a capability to dynamically route multicast IP packets across security domains without compromising security requirements. For example, one security requirement is to prevent PT multicast address and PT prefixes to be seen in the CT network. A pre-place key is used for encryption and decryption of multicast data by the protocol throughout the multicast discovery process IPsec Multicast Discovery Protocol (IMDP) is a proactive protocol that periodically sends Multicast Advertisement Protocol Data Unit (MA-PDU). IMDP requires only the IPsec devices that have multicast sender to send the MAPDU. The MA-PDU is sent encrypted to protect data in the packet. MA-PDU data consists of the PT multicast IP address, the Mapping CT Multicast IP address and the prefix or the IP address of the PT multicast sender. When a MA-PDU is received at the IPsec, data is recorded and used to create all Multicast IPsec tunnels and inbound securities policies for encryption and decryption of multicast data. The IPsec devices that received MA-PDU

SHORE 1

Advertise Default Policy

SHIP 1

Figure 6. Ship1 sends data to Ship 2 using Default policy SCALABILITY The Security Gateway feature of the PMIDP can be used for scalability in a large network with a large number of IPsec devices. The scalability can be obtained by dividing number of IPsec devices in different multicast groups. Each IPsec is a member of one multicast group only. There will be a security gateway between two multicast groups such as group A and group B.
Group A IPsec
Red Network Prefix X Advertise Prefix X and Group B red prefixes (encrypted)

Blk router Red router Group B IPsec

BLK NETWORK

Advertise Prefix X and Group A red prefixes (encrypted)

Figure 7. Security Gateway between two multicast groups for scalability A typical security gateway consists of two IPsec devices running PMIDP protocol with their PT interfaces are connected to the same PT router. One IPsec is configured to run PMIDP protocol with group A and the other with group B.

also joins the Mapping CT IP address on the CT interface. After joining the multicast group, the IPsec devices are ready to receive and decrypt the CT multicast packet. An example of how PT multicast packets are sent and received is as followed.
Tx
Red IP Black IP multicast packet multicast packet Red IP packet Join blk IP

example, CT multicast routing protocol can be PIM-SM while PT multicast routing protocol can be PIM-DM.
Tx

IPsec
Black Host Red Multicast Router

Rx
Join red IP

Rx
Join red IP

PIM
RED MULTICAST ROUTING DOMAIN

PIM

PIM
PIM

IPsec PIM

PIM

IPsec
BLACK MULTICAST ROUTING DOMAIN

Join red IP

Rx

Join red IP Rx

Red IP packet

Join blk IP

Join blk IP

Rx
Red IP packet Join red IP

Figure 10. Multicast Routing Domains Figure 10 shows a network consists of a CT network and four separated PT networks. Each PT network and the CT network can be considered having separate multicast routing domain. Key Management: The IMDP requires a protocol key and a multicast data key. The protocol key is the same preshared key that is used by the PMIDP for encryption of PT prefixes advertised in the CT network. The multicast data key can be either static or dynamic key that is used for encryption and decryption of multicast data between PT networks. An interface between the IMDP and the Key management shall be defined when dynamic multicast data key is used for encryption of multicast data. OPTIMIZATION OF MULTICAST ROUTING IN THE CT NETWORK With dynamic multicast routing in the CT network, the multicast routing is optimized when the encrypted multicast packets are forwarding only to those IPsec devices that have multicast receivers in the PT network. The processes to optimize multicast routing in the CT network for PT multicast traffics are different depend on whether the PT multicast routing protocol is PIM-SM or PIM-DM. The following section describes how optimization process works in PIM-DM and PIM-SM. Optimization of CT multicast routing when PT multicast routing protocol is PIM-DM: The Optimization process is best described in an example as shown in Figure 11. The figure shows a network with 4 IPsec devices. IPsec 1 has a multicast sender. IPsec 2 and IPsec 3 have multicast receivers. And IPsec 4 has no multicast sender or receiver. All PT routers and IPsec devices in the networks run PIM-DM. The multicast routing in the CT network is optimized when the multicast packets are forwarded only to IPsec 2 and IPsec 3. In PIMDM, IPsecs 2, 3, and 4 do not know if they have multicast receivers in the PT network or downstream until the first

Rx

Figure 9. Multicast Routing in CT Core Network In Figure 9, a multicast source sends data to multicast receivers. When the multicast packet arrives at the PT interface of the sending IPsec, the packet is encapsulated and sent in an IPsec multicast tunnel. The destination IP address of the IPsec tunnel is a CT multicast IP address, which is derived by mapping from a PT multicast IP address to a CT multicast IP address. The mapping from PT to CT multicast IP address can be static or dynamic, linear or complex, depending on the security requirement to protect the PT multicast IP address and the sender address in the CT network. At the receiving IPsec, the packet is decrypted. The original PT multicast packet will be sent to the multicast PT router for forwarding to local multicast receivers in the PT network. MULTICAST REQUIREMENT Cipher Text Network: The IMDP requires CT network to support multicast routing with a dynamic multicast routing protocol such as PIM-SM (Protocol-Independent Multicast - Sparse Mode) or PIM-DM (Protocol-Independent Multicast - Dense Mode). From a CT router point of view, the IPsec functions as a multicast host sending and receiving multicast IP packets. There is no multicast routing protocol running on the CT interface of the IPsec. Plain Text Network: The IMDP requires PT network to support multicast routing with a dynamic multicast routing protocol such as PIM-SM or PIM-DM. From a PT router point of view, the IPsec functions as a PIM router in the PT network. Therefore, PIM is required to run on the PT interface of the IPsec. Multicast routing between the PT and the CT networks is not allowed to prevent PT prefixes and PT Multicast IP addresses to be seen in the CT network. Multicast routing protocols in the PT and CT networks can be different. For

multicast packet is forwarded in the downstream direction. This is the reason why all IPsec devices have to join the CT multicast group regardless they have multicast receivers or not in the PT network. As a result, the flooding and pruning processes are necessary to optimize multicast routing in the CT network as described in the following steps.
Tx
Multicast Sender

the PT multicast packets to the multicast receivers as shown in Figure 12. The packet was enable to be decrypted because the IPsec multicast and inbound SP have been setup during the Advertisement process. Step 4: Pruning. When the PIM-DM PT routers at IPsec 2 and IPsec 3 received the PT multicast packet, they forward the packet to multicast receivers who had joined the PT multicast group. On the other hand, the PT router at IPsec 4 drops the packet because it has no multicast member for the PT multicast group. After the packet is dropped, the PIM-DM multicast router also sends a PRUNE message to IPsec 4 who also is a PIM-DM multicast router. When IPsec 4 receives the PRUNE message, it disjoins the CT multicast group on the CT interface. As a result, all CT multicast routers do not have IPsec 4 as a member of the CT multicast group as shown in Figure 13.
Tx
Multicast Sender Black IP multicast Red IP multicast packet # 1 packet # 1

Rx

Advertise Ipsec 1 multicast group


Create outbound Tunnel & SP Join blk IP

Ipsec 2
Join blk IP

Multicast Receiver Join red IP

PIM-DM

PIM-DM

PIM
PIM-DM
Join blk IP

PIM-DM

Ipsec 4

Ipsec 3

Join red IP

Rx
PC Multicast Receiver

Figure 11 Initialization and Advertisement processes Step 1: PT to CT Forwarding. In this step, when the first multicast data packet is received at IPsec 1, the packet is encrypted and sent over the multicast IPsec tunnel whose destination is the CT multicast address. The multicast IPsec tunnel and outbound SP for the PT multicast packet were set up during the Initialization and Advertisement processes as shown in Figure 11. Step 2: Flooding Multicast Packet in the CT network. At the end of the Advertisement Process, all IPsec devices joined the CT Multicast Group regardless of if they have multicast receiver in the PT network. Therefore, when IPsec 1 sends the first multicast packet over the multicast IPsec tunnel, the packet is sent to all three IPsec devices in the network as shown in Figure 12. Step 3: CT to PT Forwarding.
Tx
Multicast Sender Black IP multicast Red IP multicast packet # 1 packet # 1

Rx

Ipsec
Join blk IP

Multicast receiver Join red IP 2Red IP # 1 packet

PIM

Ipsec 1 PIM

PIM

Red IP packet # 1 DROPPED

PIM

Ipsec 4
Dis-Join blk IP Prune Blk IP message

Ipsec 3
Join blk IP

PIM
Red IP packet # 1 Join red IP

Prune red IP message PC

Rx
Multicast Receiver

Figure 13. Pruning Step 5: Sending PT multicast data on optimized multicast tree in the CT network. After flooding and pruning steps completed for the PT multicast packets, all subsequence PT multicast packets are encrypted forwarded in the CT networks arriving only at IPsec 2 and 3 as shown in Figure 14.
Tx
Multicast Sender Black IP multicast Red IP multicast packet # 2,3,... packet # 2,3...

Rx

Ipsec
Join blk IP

Multicast receiver Join red IP 2Red IP # 2,3,... packet

Rx

Ipsec 2Red IP # 1 packet


Join blk IP

Multicast receiver Join red IP

PIM

Ipsec 1 PIM

PIM

PIM

Ipsec 1 PIM

PIM

PIM

Ipsec 4

Ipsec 3
Join blk IP

PIM
Red IP packet # 2,3,... Join red IP

Red IP packet # 1 DROPPED

PIM

Ipsec 4
Join blk IP

Ipsec 3
Join blk IP

PIM
PC
Red IP packet # 1 Join red IP

Rx

Multicast Receiver

Red IP packet PC

Figure 14. Pruned multicast tree Step 6: New members. When a new multicast receiver at IPsec 4 joins the PT multicast group, the PT multicast router sends a GRAFT message to IPsec 4. When the GRAFT message is received, the IPsec joins the CT multicast group as shown in Figure 15. When IPsec 4 becomes new member of the CT multicast group, all subsequence PT multicast packet

Rx
Multicast Receiver

Figure 12. Flooding CT network and CT to PT Forwarding When the CT multicast packet is received at IPsecs 2, 3, and 4, the packet is decrypted and the original PT multicast IP packet is forwarding on the PT interface with the PT routers. Finally, the PT multicast routers forward

will be forwarded to IPsecs 2, 3, and 4 as in Figure 16.


Tx
Multicast Sender Black IP multicast Red IP multicast packet # 2,3,... packet # 2,3...

Rx

Ipsec
Join blk IP

Multicast receiver Join red IP 2Red IP # 2,3,... packet

multicast advertisement process, the multicast routing in the CT network is optimized. When the first multicast packet is received at IPsec 1, the packet is encrypted and forwarded only to IPsec 2 and IPsec 3. One additional note about IPsec and PIM-SM, the sending IPsec (IPsec 1) must join the PT multicast group in order to receive the PT multicast packets. In this case, the sending IPsec functions as a multicast host to receive the PT multicast packet. Without joining the group by the IPsec, the PT PIM-SM router will drop the packet due to no group member in downstream. At the same time, the receiving IPsec (IPsec 2 and IPsec 3) functions as a PIMSM router to forward a PT multicast packet to the PT PIMSM router. If the IPsec is not a PIM-SM router, the PT PIM-SM router will drop the multicast packets because it expects a PIM-SM router to forward the packet. CONCLUSION

PIM

Ipsec 1 PIM

PIM

PIM

Ipsec 4
Join blk IP GRAFT Blk IP message

Ipsec 3
Join blk IP

PIM
Red IP packet # 2,3,... Join red IP

GRAFT red IP message

Rx

Multicast Receiver

Multicast Receiver

Figure 15. New PT member join the group


Tx
Multicast Sender Black IP multicast Red IP multicast packet packet

Rx

Ipsec
Join blk IP

Multicast receiver Join red IP Red IP 2multicast packet

PIM

Ipsec 1 PIM

PIM

PIM

Ipsec 4
Join blk IP

Ipsec 3
Join blk IP

PIM
Red IP multicast packet Join red IP

Join red IP

Red IP multicast packet

Rx

Multicast Receiver

Multicast Receiver

Figure 16. New CT multicast tree with new PT member Optimization of CT multicast routing when PT multicast routing protocol is PIM-SM When the PT multicast protocol is PIM-SM, the optimization of multicast routing in the CT network is different. In the example shown in Figure 11, IPsec 2 and IPsec 3 have the record of multicast receivers in the PT network because the PIM-SM PT routers periodically send JOIN toward the IPsec as shown in Figure 17.
Tx
Multicast Sender Join red IP

Rx

Advertise multicast group Ipsec 1 PIM

Create inbound Tunnel & SP

Ipsec 2

PIM-SM

Multicast Receiver Join red IP

The PMIDP is an IPsec Discovery Protocol that provides a comprehensive set of solutions for networks with multiple security enclaves in which the impacts of IPsec device on unicast and multicast routing between security enclaves are significant. Unlike other IPsec discovery protocols, the PMIDP is a proactive protocol that provides a simple mechanism to discover a new IPsec or to detect when an IPsec is down in the network. The PMIDP is a simple and scalable protocol with low protocol overheads whose capabilities include mobility support, dynamic routing between plaintext networks, security gateways between two separate CT networks, Default IPsec gateway. In addition, PMIDP multicast extension is the first protocol that provides dynamic multicast routing in the CT network for PT multicast traffics sent over CT network. Finally, the PMIDP has met the utmost important security requirement for an IDP that is to protect of PT prefixes and addresses in the CT network. ACKNOWLEDGEMENT The United States participation in the INSC project was sponsored jointly by the Office of Naval Research, and the Navy International Programs Office. REFERENCES [1] INSC2/Task2/DU/003, Secure Multicast Architecture. August 2004. [2] INSC II/Task1/D/002, Test and Demonstration Architecture, Feb. 2005. [3] RFC 2407, The Internet Security Association and Key Management Protocol, Nov. 1998

PIM-SM

Create outbound Tunnel & SP

Join blk IP Join red IP Create inbound Tunnel & SP

Ipsec 3 PIM-SM
PIM-SM

Ipsec 4

Join blk IP

Join red IP

Join red IP

Rx
PC Multicast Receiver

Figure 17. Advertisement and Optimization Processes To optimize the multicast routing in the CT network, when a multicast Advertisement PDU is received, the IPsec joins the CT multicast group only if it has a multicast receiver in the PT network. IPsec devices without multicast receivers will ignore the Multicast Advertisement PDU. In the previous example in Figure 11, only IPsec 2 and 3 join the CT group. IPsec 4 does not join the group because it has no multicast receiver in the PT network. At the end of the

S-ar putea să vă placă și