Dynamic VPN Controller

1. Dynamic VPN Controller Developed by NRNS Inc. July 2, 2003

2. Dynamic VPN Controller (DVC) • Concept originated by DRDC Ottawa, fertilized by the DARPA X-Bone project at ISI. • Developed from open-source software plus portions of the X-Bone software.

3. Rationale • Initial experimentation with VPN technology among ICB members determined that VPN solutions were difficult to configure and manage. • Each partner needed to configure explicit network and security policy information about all other members. • Proper VPN operation was also dependent on firewall, routing and name binding (DNS) configurations. • A system was needed that could: • Effectively establish and manage VPNs without requiring advance detailed knowledge of other partners’ network infrastructures and security policies. • Dynamically reconfigure firewall, routing and DNS subsystems.

4. Dynamic VPN Principles • Each partner owns resources that will be utilized in the VPN. These resources may range from a single service to a complete network. • Each DVC exchanges policies identifying available resources with each other DVC. • Policies must be agreed upon by both partners before a DVC establishes a VPN link between them. • Policies may be different between different partner pairs. • The exchange must remain private. • Each DVC must authenticate itself to each other DVC to avoid spoofing. X.509 certificates authenticate both SSL control sessions and possibly IPSec based VPN tunnels.

5. Dynamic VPN Principles (cont.) • VPN links are established as peer-to-peer links, resulting in a fully meshed VPN topology. • The DVC ensures that only traffic permitted by mutually agreed policies uses the VPN - Firewall subsystem. • The DVC ensures that traffic for remote partner networks is directed at the DVC - Routing subsystem. • The DVC ensures that name bindings needed to access remote services are locally accessible - DNS Subsystem. • The health of the VPN is monitored and reported to all partners.

6. DVC System Components • Currently runs on FreeBSD-4.6 • System is written in perl. • Main DVC process: 4000 lines • DVC GUI (cgi script): 1300 lines • Subsystems: 1800 lines • System also employs: • OpenSSL: Certificate issuance, authenticated/secure sessions • KAME: IPSec subsystem • IPFilter: Firewall subsystem • Bind: DNS subsystem • Zebra: Routing subsystem • Apache, mod-ssl: Graphical User Interface

7. DVC System Authentication • SSL is used to secure control connections between DVCs. • SSL control connections between DVCs are authenticated with X.509 certificates. • Same X.509 certificates are used to authenticate ISAKMP security associations - if dynamic keying is used. • Each DVC system uses the OpenSSL software to generate its own key pair and certificate signing request (CSR). Private keys generated for the local DVC never leave the system. • DVC certificates are currently signed by a common OpenSSL CA for the project - need cross-certification to overcome this. • The CSR and signed public certificate are exchanged via Internet e-mail.

8. DVC Operator Authentication • HTTPS/SSL is used to secure the connection between the Operator’s browser and the DVC system. • HTTPS/SSL connections between the browser and the DVC system are authenticated with X.509 certificates. • Each DVC system operates its own distinct OpenSSL CA to issue operator certificates. • This ensures that only operators recognized by the local DVC system can operate the local DVC system. • The Operator key pairs are generated on the DVC system and provided to the Operator in password protected PKCS #12 files.

9. DVC Use of Certificates

10. DVC Operator Interface

11. Local Policy Database • Policies are compiled for each partner and are stored in a local Policy Database. These policies define: • Which local networks require access to the remote partner site via the VPN. • Which local services are available to a remote partner site. • Which name bindings are needed by the remote partner site to make use of the services offered via the local DVC system. • What type of services are expected from the remote partner site. • The Policies may be different for each partner.

12. Policy Exchange • DVC systems exchange policies to configure all aspects of VPN. • DVC “A” provides to DVC “B” the list of “A’s” local networks that require access to “B’s” services. DVC “B” provides similar information to DVC “A”. • DVC “A” provides to DVC “B” the list of services that “A” is willing to make available to “B”. DVC “B” provides similar information to DVC “A”. • The remote partner’s offered services are compared and validated against the locally configured “expected” services. • The exchanged information is used by each DVC in configuring the local side of the VPN, which includes the Firewall, Routing and DNS subsystems.

13. Policy Validation • The DVC software is being enhanced to automatically determine the suitability of policies presented by a remote DVC peer. • DVC will validate proposed policies with additional configuration items such as “Must Contain”, “May Contain” and “Must Not Contain”: • Must Contain TCP/80 <-- Web is a must • May Contain TCP/22 <-- SSH is OK • Must Not Contain TCP/23 <-- No TELNET • New configuration items simply identify the types of services expected from the remote partner, not how the services will be provided.

14. Subsystems • The DVC software controls four subsystems: • IPSec (KAME with manual keying). Establishes secure/authenticated tunnels to trusted remote peers. • Firewall (IPFilter). Enforces both local and remote access policies. • Routing (Zebra). Advertizes routes for remote networks within local routing domain. • DNS (Bind). Advertizes name binding necessary to access remote services from within local domain. • DVC Subsystems implemented as perl packages with well-defined interfaces. • Will facilitate the development of subsystems on different platforms such as Cisco and Linux.

15. Health & Status Monitoring • A DVC monitors the health (round-trip-time, packet loss) of the VPN to all remote DVCs. • A DVC also reports status information (# of packets, # of bytes). • Health and Status are periodically reported to DVC Operator. • Health is also communicated to other partner DVCs . • Each DVC can determine the current topology of the entire VPN. • Who is connected to who? • What is the health of their connections?

16. No Central Authority • A DVC maintains all configuration information in its Local Policy Database. • A DVC does not rely on any central authority for configuration information. • All members of VPN are equal partners. • Each DVC maintains its own notion of its partners.

17. Scaling Issues • The system establishes a fully-meshed topology. • The system will not scale to hundreds of sites. • A SSL connection is needed between each pair of DVCs. • An IPSec tunnel is needed between each pair of DVCs. • Partial meshing requires that intermediate DVCs can decrypt data in transit.

18. Current Enhancements • Introduction of locally defined “expect” policies to assist in validating policies proposed by remote partner. • Introduction of XML as the encoding mechanism for DVC control messages and security policies. • A “Policy Editor” will be added to the DVC GUI. • Currently the policy must be edited on the DVC system using a Unix text-based editor. • Policy Editor is likely to be implemented in Java.

19. Future Enhancements? • Multi-platform support - Linux • Porting DVC system to IPv6 including the integration of IPv6 support within the IPSec, Firewall, Routing and DNS subsystems. • Migrate the IPsec, Firewall, Routing and DNS subsystems onto separate systems. IPSec, firewall and routing could reside on the boundary enforcement point - Cisco. • The development of an active GUI to shift most of the operator update responsibility to the client workstation. Real-Time “pushed” updates instead of periodic “pulled” updates would considerably speed up the feedback to the DVC Operator.