Defence R&D Canada R et D pour la défense Canada Dynamic VPN Controller Developed by NRNS Inc. July 2, 2003

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa 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.

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa 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.

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa 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.

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa 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.

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa 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

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa 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.

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa 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.

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa DVC Use of Certificates

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa DVC Operator Interface

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa 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.

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa 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.

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa 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.

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa 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.

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa 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?

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa 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.

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa 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.

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa 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.

Defence R&D Canada - Ottawa Centre de recherches pour la défense Ottawa 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.