Offering a Multicast Delivery Service in a Programmable Secure IP VPN Environment

1. Offering a Multicast Delivery Service in a Programmable Secure IP VPN Environment Lina ALCHAALNetcelo S.A., EchirollesINRIA Rhône-Alpes, Planète project, Francelina.alchaal@inrialpes.fr Michel HABERTNetcelo S.A., Echirolles, Francemichel.habert@netcelo.com Vincent ROCAINRIA Rhône-Alpes, Planète Project, Francevincent.roca@inrialpes.fr

2. Request of Configuration Policies Request of Configuration Policies Configuration Policies Configuration Policies Introduction: a centralized environment Virtual Network Operation Center (VNOC) (e.g. Netcelo) VPN User Internet VPN Secure Tunnel VPN edge devices include: IPSec, Firewall, Policy configuration and group communication services

3. Goal of the work: offer a group communication service in this fully secure VPN environment Different from work at IETF MSEC opposite approach… in our case the environment is already secure! Different from work at IETF PPVPN (provider provisioned VPN) in our case we target a VPN service provider who doesn’t master the core IP network Introduction

4. Experiments with Multicast Routing Protocols in a VPN Environment IVGMP in a VPN environment Conclusions Outline

5. 1- PIM-SM in an IP VPN environment We tried to deploy PIM-SM on VPN edge devices pimd (University of Southern California/Information Sciences Institute) Free/SWAN IPSec implementation Linux / Lanner FW500-ME embedded PC Internet VPN edge devices with PIM-SM support

6. Problems: PIM-SM and IPSec ignore each other… multicast flag not set for IPSec interfaces two independent routing tables PIM doesn’t register itself to IPSec and vice-versa Free/SWAN IPSec implementation doesn’t support a security association (SA) with a multicast destination address PIM is very complex compared to the simplicity of a VPN environment PIM within IP VPN Environment… cont’

7. IVGMP benefits from the centralized VPN architecture around the VNOC close integration of group communication & VPN management Avoids the complexity of Multicast Routing Protocols a VPN topology is much simpler than the Internet mbone shares some similarities with overlay multicast solutions ! Internet VNOC 2. IVGMP in a VPN environment VPN edge devices

8. IVGMP features IVGMP functions: • dynamic discovery of group members/sources located in local subnets • use IGMP queries / traffic listening • more or less easy, depending on the site configuration (single LAN vs. • add/remove a site dynamically to a group VPN • … with the help of the VNOC • depends on the presence or not of receivers/sources • send multicast packets to other sites belonging to the same group via IPSec tunnels

9. (8) Send info of group G (4) Send info of group G (7) Join group G (3) Join group G IVGMP (6) Mcast traffic (1) IGMP Query Multicast application sending traffic for group G Group G Sender (2) IGMP Report for group G Multicast application awaiting traffic for group G Group G Receiver An example… VNOC (9) Create VPN entry for group G Internet IVGMP VPN edge device (5) Create VPN entry for group G

10. 2. Capture Mcast packet (with headers) for group G & check for group G entry UDP UDP 3. Encapsulate Mcast packet in a UDP packet 4. Decapsulate the UDP packet 5. Inject Mcast packet for group G 1. Mcast packet for group G The implementation VPN edge devices IVGMP IVGMP Libpcap Sock Raw IP IPSec IPSec IP Eth Ifr. IPSec Ifr. IPSec Ifr. Eth Ifr.

11. IVGMP goes beyond these simple examples… IVGMP advanced features

12. VPN group with Mcast @ 1 VPN group with Mcast @ 2 VPN group with Mcast @ 3 Mcast G1 Mcast G1 Mcast G2 Mcast G2 Mcast G1 Handling multiple groups IVGMP can handle multiple groups simultaneously VPN groups entries are updated by IVGMP with the help of IGMP and VNOC Classify according to Mcast @ IP Mcast Packet

13. VPRN distribution tree level Meshed VPN level Physical network level Internet Scalability Improvement Scalability problem can be addressed by provisioning some sites (or dedicated servers) as VPRN nodes that perform traffic forwarding

14. When a site is composed of several subnets supporting a multicast routing protocol… Receiver problem Sender problem IVGMP IVGMP PIM router PIM router IGMP Query Group G Receiver PIM router doesn’t forward IGMP queries to inner subnets IVGMP doesn’t know the address of the new Mcast group  IVGMP can’t send IGMP report IGMP Query Group G Sender IVGMP and Mcast routing Protocols Interoperability

15. Possible solutions… Use IGMP-proxying on inner subnets routers: Solves only the « receiver problem » Requires some administration work on clients sites  Predefine a small number of multicast groups Solves only the « source problem » Might be used with the first solution , but increases IGMP signaling Use a dedicated application to inform the local IVGMP of new multicast groups Doesn’t require any modification to the internal site It’s the responsibility of users to announce new groups IVGMP and Mcast routing Protocols Interoperability… cont’

16. 3. Conclusions This approach : • gets out with a simple way to manage a communicating group sparsed over the Internet • offers a secure multicast delivery service over the Internet • is fully dynamic • is fully transparent to the end users/applications  No configuration burdens on group members

17. Many thanks for your attention!

19. A VPRN consists of a mesh of IP tunnels between ISP routers, together with the routing capabilities needed to forward traffic received at each VPRN node to the appropriate destination site VPRN Definition