| 

|
 | 
        
  
 | |

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

|
 | 
        
  
 

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

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

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

|
 | 
        
  
|  
 
 

|
 | 
        
  
| ! 


|
 | 
        
  
 "|#

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

|
 | 
        
  
 $%&

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

|
 | 
        
  
  

‡ 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,    '  # ' .

|
 | 
        
  
 # 

‡ 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.
|
 | 
        
  
 ( )&

‡ 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?

|
 | 
        
  
  

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

|
 | 
        
  
 &! 

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

|
 | 
        
  
  $  

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

|
 | 
        
  
 * $  +

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

|
 |