dynamic vpn controller

Defence R&DCanada

R et D pour la défenseCanada 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.


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.


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.


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.


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


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.


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.


DVC Use of Certificates

DVC “A” DVC “B”

DVC Operator “A”Netscape Browser

DVC Operator “B”Netscape Browser

DVC Process DVC Process .

ISAKMPD ISAKMPD

Apache Web Server Apache Web Server

HTTPS/SSL HTTPS/SSL

ISAKMP

SSL

DVC Project CA

DVC “A”Private CA

DVC “B”Private CA


DVC Operator Interface


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.


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.


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.


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.


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?


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.


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.


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.


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.

dynamic vpn controller

Documents