View
39
Download
0
Category
Preview:
DESCRIPTION
Dynamic VPN Controller. Developed by NRNS Inc. July 2, 2003. 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. - PowerPoint PPT Presentation
Citation preview
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.
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
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
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.
Recommended