Dynamic Virtual Network Engine (DVNE) Protocol
draft-mrw-dvne-prot-00.txt

Abstract

This document describes the Dynamic Virtual Network Engine (DVNE) protocol. The DVNE protocol is a signaling protocol between a virtual network node (the DVNE Client) and a configuration server (the DVNE Mediator). The DVNE protocol is used to authenticate the nodes in a Virtual Network and assist them to setup and release VPN connections directly among themselves.

A DVNE clients can be located anywhere in a private or public network, directly connected or behind one or more levels of NAT. The DVNE protocol performs client authentication, peer discovery, virtual network address management, and provides all parameters necessary to enable the clients setup a secure VPN connection. The protocol does not explicitly setup the VPN connection itself. It only enables the clients to be able to directly setup the VPN connection themselves.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on April 22, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Requirements Terminology
2.  Introduction
3.  Definitions
4.  DVNE Protocol Functional Overview
5.  Description of DVNE Protocol Operation
    5.1.  Overview
    5.2.  Client Startup or Installation
    5.3.  Login
    5.4.  Identification
    5.5.  Authentication
        5.5.1.  TLS Certificate-based authentication
        5.5.2.  TLS Username/Password-based Authentication
        5.5.3.  Fallback Authentication
    5.6.  DVNE Authentication
    5.7.  Addressing in Virtual Network
    5.8.  Connection Setup
    5.9.  VPN Connection
6.  Message authentication
7.  DVNE Protocol Details
8.  Security Considerations
9.  IANA Considerations
10.  Acknowledgements
11.  References
    11.1.  Normative References
    11.2.  Informative References
§  Authors' Addresses

1.  Requirements Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Introduction

This document describes the Dynamic Virtual Network Engine (DVNE) protocol. The DVNE protocol is a signaling protocol between a virtual network node (the DVNE Client) and a configuration server (the DVNE Mediator). The DVNE protocol is used to authenticate the nodes in a Virtual Network and assist them to setup and release VPN connections directly among themselves.

A DVNE clients can be located anywhere in a private or public network, directly connected or behind one or more levels of NAT. The DVNE protocol performs client authentication, peer discovery, virtual network address management, and provides all parameters necessary to enable the clients setup a secure VPN connection. The protocol does not explicitly setup the VPN connection itself. It only enables the clients to be able to directly setup the VPN connection themselves.

The DVNE protocol is used by the DVNE framework to setup a virtual or overlay networks among hosts which is independent of the underlying physical network.

This document provides an overview of DVNE protocol functionality, including detailed flows, message layouts, and parameters of the DVNE protocol. The main functional components of the DVNE Protocol are the DVNE Client (a node on a virtual network) and the DVNE Mediator (a server that provides authentiction and configuration information). An architectural framework for the DVNE protocol is described in draft-mrw-dvne-fw-00.txt (replace with reference, when available).

3.  Definitions

• DVNE Client: Client software running on a host or a network node (e.g., router) that communicates with the DVNE Mediator.
• DVNE Mediator: A server that implemnets DVNE and provides configuration information and parameters to DVNE clients.
• DVNE Session: A secure session between a DVNE Client and DVNE Mediator.

4.  DVNE Protocol Functional Overview

DVNE Protocol (DVNEP) is a signaling protocol between a DVNE Client and DVNE Mediator to essentially perform the following functions:

• Authentication of clients
• Peer discovery (locate the peer)
• Address assignment to the DVNE client
• Provide all parameters necessary for the two endpoints to setup a secure VPN connection.

DVNEP transparently supports all types of NAT traversals for the end points. DVNEP does not directly setup a secure VPN connection between the end points. It does provide all parameters necessary for the end points so that they can setup the VPN connection directly. The main advantage of this approach is that all existing methods of VPN connection setup can be supported without changes.

The DVNE Client software runs on a host machine and is responsible for communicating with the DVNE Mediator. Among other functions, the DVNE Client software performs the following generic functions:

• Client startup or installation. Upon client startup, the client should be able to reach one or more DVNE Mediator.
• Client cache to store data provided by the Mediator

The following is a list functions described in this document:

• Client identification:To uniquely identify a client in a specific domain. A domain represents a specific virtual network or overlay network.
• Client authentication:In the first phase, the clients are authenticated using username/password mechanism.
• Client Location:The clients can be located behind any type of multiple NAT traversals
  • Use standards compliant protocols like STUN, TURN and ICE to identify and locate a client behind one or more NATs.
• Addressing:Each domain or virtual network in DVNE has its own independent addressing. Each client is provided with an address in the private address space in the virtual network as long as it is connected to the DVNE network. The following are supported as a part of addressing functions:
  • Private address space in the virtual network
  • Static address or dynamic address via the DHCP server (NOT supported in phase 1)
• Secure session between the client and the DVNE Mediator:Using secure credentials a session is established between a client and the DVNE Mediator. All the communication is encrypted and standard security algorithms are supported.
• Peer discovery:The DVNE Mediator assists a client in locating and discovering a desired client in the same virtual network.
  • Dynamic translation of client id to end points:used for determining the destination end point location or a next-hop determination
  • Provide a list of Virtual Network members to every client
• Connection setup and release requests
  • The relay of the client transport addresses and other information between the clients.
  • If the clients request to establish a manual IPSEC connection, for example, then provide the security parameters (e.g., keys, SPI) to the clients.

5.  Description of DVNE Protocol Operation

This section describes the operation of the DVNE protocol at a conceptual level.

5.1.  Overview

An example topology view of the DVNE and its components are shown in the Figure below. This is used to illustrate various functions like login, connection setup etc., in subsequent sections.

FIGURE TBD: Figure 1. DVNE and its components

5.2.  Client Startup or Installation

The DVNE Client software upon installation should at a minimum be programmed to reach one of the DVNE Mediators. The DVNE Mediator server name or IP address/Port# must be made available in the Client Cache. In future, after successful connection to this DVNE Mediator, the list of all other possible DVNE Mediators that this client can reach is downloaded to the client.

The DVNE Mediator is expected to be globally addressable via public internet. In future, we can add the capability of DVNE Mediators also being behind firewalls or NAT.

5.3.  Login

All clients of DVNE are required to first login to one of the DVNE Mediators. After successful login a session is open between the DVNE client and the mediator. The session between DVNE client and mediator is kept active as long as the client wants to have a connection to any other client in the virtual network. The process of login involves the following:

• Identify and authenticate the clients.The client and the mediator perform mutual authentication
• Determine the virtual network that the client belongs to
• Provide the client with the latest list of VN Members that are ‘online’ in the virtual network
• Provide the client with Virtual Network global data (e.g., TURN, STUN server addresses)

5.4.  Identification

The client identity in DVNE uniquely identifies both the client and the virtual network that the client belongs to. The client identity is explicitly provided by the client during login to the DVNE. The client id for example can take the form client-id@vn-id.dvne.com where “vn-id” identifies a specific virtual network and the “client-id” identifies a specific client. Both the client-id and vn-id are a combination of alphanumeric characters.

5.5.  Authentication

Each client is authenticated by the DVNE mediator. In addition, the clients initially use TLS protocol to communicate with the DVNE Mediator and only upon successful authentication at TLS level, a secure session is established between the client and the DVNE Mediator. The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications. The TLS protocol is layered on top of a reliable transport protocol TCP/IP. All DVNE Protocol messages are encrypted by the TLS layer.

The following types of client authentication are supported:

• Client certificates (e.g., X.509) using PKI infrastructure (third party trust relationship). Self signed certificates are also supported, but the clients are authenticated via the username/password mechanism.
• Username/Password mechanism using Secure Remote Password (SRP-6) via TLS protocol

5.5.1.  TLS Certificate-based authentication

The message flow for client certificate based authentication is shown below. This is the same standard TLS message flow without any changes.

FIGURE TBD: Figure 2. TLS certificate authentication

5.5.2.  TLS Username/Password-based Authentication

The client can also initiate username/password based authentication via TLS protocol using Secure Remote Password mechanism (SRP-6). The client supplies the username parameter in the client hello message. This indicates to the MEDIATOR that the client wishes to perform username password authentication. The message flow for SRP mechanism is shown below. Both sides exchange the SRP parameters (random numbers, generator g etc.,) using the TLS:server key exchange and TLS:client key exchange messages. The two sides then derive the same secret key K and encrypt the TLS:finished messages using this secret key. If the other side can decrypt the TLS:finished successfully, it implies that both sides are in possession of the same secret. For details of SRP mechanism, please refer to RFC 5054.

FIGURE TBD: Figure 3. TLS username/password authentication

5.5.3.  Fallback Authentication

It is also possible that the MEDIATOR always initiate a client certificate based authentication and use username/password as a fallback mechanism. The MEDIATOR will reject the first TLS attempt with an error code of unknown-psk-identity and in such cases, the client can re-initiate a new TLS session using the username/password mechanism. A typical message flow for this case is shown below.

FIGURE TBD: Figure 4. Certificate auth failure with fallback to username/password authentication

5.6.  DVNE Authentication

DVNE client authentication is performed during LOGIN. This is in addition to the TLS authentication. The DVNE authentication is a mutual authentication between the Client and the Mediator. This is based on Username/password mechanism. The client password is not sent to the Mediator. Instead, each side performs a challenge-response method of authentication. Each side computes a response for a given nonce and challenges the other side to the do the same by sending the same nonce value. When the computed response and the received response match, the authentication is deemed successful.

The DVNE Authentication will use the MD5 hash algorithm as follows:

• Inputs:
  • Username/Password
  • Nonce (16 Bytes)
• Output:
  • Response (16 Bytes)
• Algorithms:
  • HA1 = MD5(username:dvne authentication:password);
  • Response = MD5(nonce:HA1);

5.7.  Addressing in Virtual Network

Each virtual network has an independent range of IP addresses that it can use. This address range does not collide with addresses assigned to other virtual networks. In future, a DVNE client can only join more than one virtual network and hence it is suggested not to use overlapping addresses across virtual networks.

The client is assigned a Virtual Network IP address by the mediator during the LOGIN phase.

5.8.  Connection Setup

Once logged in, the DVNE clients can establish connections to other clients. To do this, the DVNE client has to send ‘Connection setup’ message to the Mediator. The Mediator will then perform the following functions:

• Validate the identifier of the destination client,
• relay the transport addresses between the two clients
• provide manual security association parameters (e.g., session key, SPI) to both clients. The SPI value has to be unique for a specific end node.

The clients can use all these information to setup the direct VPN connection themselves.

5.9.  VPN Connection

The two end clients can select the type of VPN connection they wish to setup. These connections can be typically:

• IPSEC
  • With IKE:In this case, the end hosts can use IKE protocol to authenticate security credentials and then setup an IPSEC connection.
  • Manual IPSEC:Setup IPSEC using manual security association parameters provided by the mediator
• DTLS

6.  Message authentication

It is possible that a client can impersonate another client in the messages that a client sends to a mediator. For example, a Client-A can specify a different “FROM” field in the messages. In order to prevent this, the client should include a “msg-auth-value” field in the first message of every transaction initiated by the client to the mediator. The “msg-auth-value” is computed using the username/password of the client as specified in the “FROM” field of the request message.

The msg-auth-value is especially useful, if in future, we have to implement “Mediator Proxy” which then forwards all the messages to a “mediator”.

The “msg-auth-value” computation will use the MD5 hash algorithm as follows:

• Inputs:
  • Username/Password for the username specified in the “FROM” field;
• Output:
  • msg-auth-value (16 Bytes)
• Algorithm:
  • HA1 = MD5(username:”dvne message authentication”:password);
  • msg-auth-value = MD5(“0123456789abcdeffedcba9876543210”:HA1);

7.  DVNE Protocol Details

TBD.

8.  Security Considerations

TBD.

9.  IANA Considerations

TBD.

10.  Acknowledgements

This document was written using the xml2rfc tool described in RFC 2629 [RFC2629] (Rose, M., “Writing I-Ds and RFCs using XML,” June 1999.).

11.  References

11.1. Normative References

11.2. Informative References

Authors' Addresses