dvc vpn workshop july 2003

8/8/2019 Dvc VPN Workshop July 2003

1/18


2/18


3/18

Defence R&D Canada - Ottawa Centre de recherches pour la dfense Ottawa

Rationale

Initial experimentation with VPN technology among ICB membersdetermined that VPN solutions were difficult to configure and manage.

Each partner needed to configure explicit network and security policyinformation about all other members.

Proper VPN operation was also dependent on firewall, routing andname 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/18


Dynamic VPN Principles

Each partner owns resources that will be utilized in the VPN.These resources may range from a single service to a completenetwork.

Each DVC exchanges policies identifying available resources witheach other DVC.

Policies must be agreed upon by both partners before a DVCestablishes 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 avoidspoofing. X.509 certificates authenticate both SSL control sessions

and possibly IPSec based VPN tunnels.


5/18


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


6/18


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 ownkey 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 forthe project - need cross-certification to overcome this.

The CSR and signed public certificate are exchanged via Internet e-mail.


7/18


DVC Operator Authentication

HTTPS/SSL is used to secure the connection between the Operatorsbrowser and the DVC system.

HTTPS/SSL connections between the browser and the DVC systemare authenticated with X.509 certificates.

Each DVC system operates its own distinct OpenSSL CA to issueoperator certificates.

This ensures that only operators recognized by the local DVCsystem can operate the local DVC system.

The Operator key pairs are generated on the DVC system andprovided to the Operator in password protected PKCS #12 files.


8/18


9/18


DVC Operator Interface


10/18


Local Policy Database

Policies are compiled for each partner and are stored in a local PolicyDatabase. These policies define:

Which local networks require access to the remote partner sitevia 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.


11/18


Policy Exchange

DVC systems exchange policies to configure all aspects of VPN.

DVC A provides to DVC B the list of As local networks thatrequire access to Bs services. DVC B provides similar information

to DVC A.

DVC A provides to DVC B the list of services that A is willing tomake available to B. DVC B provides similar information to DVC

A.

The remote partners offered services are compared and validated againstthe locally configured expected services.

The exchanged information is used by each DVC in configuring thelocal side of the VPN, which includes the Firewall, Routing and DNS

subsystems.


12/18


Policy Validation

The DVC software is being enhanced to automatically determine thesuitability of policies presented by a remote DVC peer.

DVC will validate proposed policies with additional configuration itemssuch as Must Contain, May Contain and Must Not Contain:

Must Contain TCP/80


13/18


Subsystems

The DVC software controls four subsystems:

IPSec (KAME with manual keying). Establishes secure/authenticatedtunnels to trusted remote peers.

Firewall (IPFilter). Enforces both local and remote access policies.

Routing (Zebra). Advertizes routes for remote networks within localrouting domain.

DNS (Bind). Advertizes name binding necessary to access remoteservices from within local domain.

DVC Subsystems implemented as perl packages with well-definedinterfaces.

Will facilitate the development of subsystems on different platformssuch as Cisco and Linux.


14/18


Health & Status Monitoring

A DVC monitors the health (round-trip-time, packet loss) of the VPNto 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?


15/18


No Central Authority

A DVC maintains all configuration information in its Local PolicyDatabase.

A DVC does not rely on any central authority for configurationinformation.

All members of VPN are equal partners.

Each DVC maintains its own notion of its partners.


16/18


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 intransit.


17/18


Current Enhancements

Introduction of locally defined expect policies to assist invalidating policies proposed by remote partner.

Introduction of XML as the encoding mechanism for DVC controlmessages and security policies.

A Policy Editor will be added to the DVC GUI.

Currently the policy must be edited on the DVC system usinga Unix text-based editor.

Policy Editor is likely to be implemented in Java.


18/18


Future Enhancements?

Multi-platform support - Linux

Porting DVC system to IPv6 including the integration of IPv6support within the IPSec, Firewall, Routing and DNS subsystems.

Migrate the IPsec, Firewall, Routing and DNS subsystems ontoseparate systems. IPSec, firewall and routing could reside on the

boundary enforcement point - Cisco.

The development of an active GUI to shift most of the operatorupdate responsibility to the client workstation. Real-Time

pushed updates instead of periodic pulled updates wouldconsiderably speed up the feedback to the DVC Operator.

dvc vpn workshop july 2003

Documents