Dynamic Virtual Network Engine (DVNE) Framwork
draft-mrw-dvne-fw-00.txt

Abstract

This document discusses the management and configuration requirements for large Virtual Networks (VNs). VNs are private networks that employ tunneling technologies to overlay private network links over physical IP networks.

As VNs grow, the amount of administrative effort required to manually configure virtual nodes and to set up the required tunnels becomes prohibitive. The DVNE protocol automates this process, elminating much of the administrative work involved in setting up a virtual network.

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 21, 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.  Introduction
2.  Applicability
3.  Problem Statement
4.  Terminology
5.  DVNE Model
    5.1.  Mediator
    5.2.  VN Nodes
    5.3.  Using DVNE Service
    5.4.  VN Address Assignment
    5.5.  Tunnel Establishment
    5.6.  Next Hop Determination
    5.7.  Interaction Between DVNE Entities
6.  Security Considerations
7.  IANA Considerations
8.  Acknowledgements
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Authors' Addresses

1.  Introduction

This document discusses the management and configuration requirements for large Virtual Networks (VNs). VNs are private networks that employ tunneling technologies to overlay private network links over physical IP networks.

As VNs grow, the amount of administrative effort required to manually configure virtual nodes, and to set up the required tunnels, becomes prohibitive. The DVNE protocol automates this process, eliminating much of the administrative work involved in setting up a virtual network.

2.  Applicability

IPsec [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.) site-to-site VPNs [RFC3809] (Nagarajan, A., “Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN),” June 2004.) are widely deployed in enterprise networks. IPsec gateways located anywhere on the Internet are virtual network nodes which are responsible for initiating/terminating IPsec tunnels and encapsulating/decapsulating IPsec packets. Every IPsec gateway should be configured with the addresses of the gateway(s) to be tunneled to and the parameters pertaining to the tunnel. It might be configured with the routing protocol(s) to be used after the tunnel has been established and any other configuration needed for virtual network connectivity. As the number of such gateways increases, the scalability issues would arise. When an IPsec gateway join or leave, the configuration of each gateway would be updated.

Some people and companies have very dynamic networking needs. Small or medium size companies might find the IT costs of deploying a complete VPN infrastructure could not be justified. They may have their access device(s) connected to the Internet via xDSL or the ISP deploys CGN [I-D. nishitani-cgn] in its networks. It is challenging to manually configure these access devices as virtual network nodes to construct a virtual network, since they have dynamic addresses and imposed on some communication constraints (by CGN). Such dynamic nature might also apply to an individual person or a family. A person might like to access his home network which might locate behind NAT devices from anywhere over the Internet by auto-configuring his home gateway and handset for media sharing.

3.  Problem Statement

Constructing a virtual network traversing physical IP networks encounters 2 major problems:

• When the size of virtual networks grows, the configuration and management burden is overwhelming. For example, when a virtual network node joins a virtual network, the needed parameters should be provisioned to the new comer, and changes would be propagated to the existing virtual network nodes.
• The dynamic natural of virtual networks, such as addresses assigned dynamically to virtual network nodes for the Internet connection, would make static configuration and manual configuration impossible.

4.  Terminology

• Virtual Network (VN): an overlay network connecting VN nodes based on physical networks along with the edge networks to which VN nodes attach.
• DVNE: An approach to configure and manage virtual networks based on the provision of dedicated servers, called Mediators.
• Mediator: Functional element of DVNE. Servers for configuring and managing VNs. The administrator(s) can configure with the Mediator VN construction policy and the Mediator in turn configure with the designated or qualified VN nodes.
• VN node: Functional element of DVNE. The node connected to the Internet which is responsible for initialing/terminating tunnels or encapsulating/decapsulating encapsulated packets. All VN nodes belonging to the same VN form an overlay network. VN node can connect to edge networks to the overlay network.

5.  DVNE Model

DVNE Mediators are configuration managers that help configure virtual network connectivity to virtual network nodes already connected to the Internet. The Mediator may be a server or a cluster. For discovery purpose, the DNS names or addresses of the Mediator could be pre-configured, referenced on web pages, provisioned via DHCP [RFC2131] (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.)[RFC3315] (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) or DNS lookup.

The DVNE model is based on the set of functional elements depicted in figure 1.

                      +----------+
                      | Mediator |
                      +----------+
                        /      \
                       /        \
                      /          \
            +---------+          +---------+
            | VN Node |<========>| VN Node |
            +---------+          +---------+
                 |
            ------------
           /            \
          | Edge Network |
           \            /
            ------------

              Figure 1: Simple DVNE configuration

5.1.  Mediator

The Mediator is the place where the VN nodes connect to register and activate their presence in the virtual network. The mediator configures with VN nodes the necessary parameters for creating, modifying or deleting a virtual network either automatically or by request.

A Mediator must be IPv4 addressable. It must be reached by all VN nodes (i.e., without NAT traversal needed).

5.2.  VN Nodes

VN nodes function in the virtual network as routers or hosts. If a VN node is a VN router, it is followed by an edge network consisting of one or more physical hosts. After the configuration order is received from the Mediator, the VN node set up tunnels, exchange routing information and data forwarding, etc. accordingly.

5.3.  Using DVNE Service

Administrators configure parameters for VN construction with the Mediator instead of going to every single VN node. The configuration between the admin and the Mediator can be achieved by interactive commands, Web pages or any other alternative means. The configuration parameters may contain the topology of the overlay network (i.e., hub-and-spokes or hub), the function type of specific VN nodes (i.e., router or host), the tunneling method (e.g., IPsec), the routing protocols (e.g., OSPF) or routing lookup method (e.g., via DNS lookup), etc. The Mediator will configure each VN node accordingly when the VN node registers. We called this process as administrative configuration.

Approaching the Mediator, the VN node should be asked first of all to provide its identity and credentials so that proper user authentication, authorization and accounting can be carried out (e.g., relying on existing AAA facilities such as RADIUS). This means the VN node and the Mediator have to share a pre-configured or automatically established security association to be used to prevent unauthorized use of the service. With this respect the Mediator can be seen as an access-control server for VN nodes.

After successful authentication, the VN node may register further information with the Mediator such as the IP address to which it is attaching and/or request such as function type it would like (i.e., router or host), etc. In response, the Mediator configures the VN node according to administrative configuration and the request if exists. The configuration may contain the addresses of any other VN nodes (which might be registered by the corresponding VN nodes in advance), the tunneling method (e.g., IPsec), the routing protocols used upon established tunnels or routing lookup method (e.g., name service lookup) used for next-hop determination, etc.

5.4.  VN Address Assignment

IP address should be assigned to the VN nodes and any edge network they connect. Automatic addressing, e.g., DHCP is recommended in this case not only because it is automatic but also it helps avoid addressing conflict if used well. Besides, the address allocation record can be used for next-hop determination when routing protocol is not used.

The lifetime of these dynamically assigned VN addresses should be relatively long and potentially longer than the lifetime of the connection of the VN nodes to the Mediator. This is to allow the VN node to get semipermanent VN addresses even though it gets dynamically assigned IPv4 addresses through DHCP for access to the Internet.

5.5.  Tunnel Establishment

The Mediator configures a VN node with adequate information to create tunnels. E.g., it may provide a VN node the address of another VN node it attempts to tunnel to, the tunneling method (and encapsulation options). The Mediator may provide extra information in aid of tunnel setup authentication. E.g., it may relay fingerprint of certificates for each other [RFC4572] (Lennox, J., “Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP),” July 2006.).

DVNE at this stage only considers the case where all VN nodes attach to the same virtual link, i.e., a VN node can reach each other VN node in the virtual network in one-hop. There are two major topologies to consider for overlay networks. In the hub-and-spokes case, the spoke nodes should be configured with hub nodes’ address. In the mesh case, each node should be configured with other nodes’ address.

                      +-----------+
                      | Mediator  |
                      +-----------+
                       |    |    |
                  -----+    |    +-----
                 /          |          \
        +---------+    +---------+    +---------+
        | VN Node |<==>| VN Node |<==>| VN Node |
        +---------+    +---------+    +---------+
             |
       ------------
      /            \
     | Edge Network |
      \            /
       ------------

              Figure 2: Hub and Spoke Topology


                      +-----------+
                      | Mediator  |
                      +-----------+
                       |    |    |
                -------+    |    +-------
               /            |            \
              /        +---------+        \
             |    ===> | VN Node |<===     |
             |  //     +---------+    \\   |
             |  V                      V   |
       +---------+                    +---------+
       | VN Node |<==================>| VN Node |
       +---------+                    +---------+
             |
       ------------
      /            \
     | Edge Network |
      \            /
       ------------

              Figure 3: Mesh Topology

Things get complicated if one or both VN nodes are behind NAT devices. The registered address when a VN node logs in may be meaningless for other VN nodes if the VN node is behind NAT devices whatever the VN node wants to connect to or connected by another VN node. In that case, the Mediator may configure STUN and/or TURN servers’ addresses to a VN node and coordinate with ICE to work out the effective or efficient address pairs for connectivity. [I-D. saito-mmusic-sdp-ike] presents an alternative approach for IKE/IPsec tunnels establishment with NAT traversal using SIP/SDP model.

Tunneling configuration adjust to NAT traversal. E.g., when NAT devices comes in between, UDP encapsulation of IPsec tunneling [RFC3948] (Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, “UDP Encapsulation of IPsec ESP Packets,” January 2005.) is preferred whereas TLS tunneling is preferred without the presence of NAT.

5.6.  Next Hop Determination

Routing protocols could be used for the virtual network routing after tunnels have been established. When routing protocols are not available or too costly, other alternatives should be considered. In hub-and-spokes case, the Mediator would configure the spokes nodes with a default route to the hub node. In mesh case, the Mediator would configure each node with routes to other nodes and update the routes over time. Instead, VN nodes can request routes from the Mediator or DNS name servers when they are ready to forward VN packets (in which case, the address of these DNS servers should be configured in advance). The tunnels can be established as described above before or after the routes have been configured.

5.7.  Interaction Between DVNE Entities

The definition of a specific set of protocols and procedures to be used for the communication among the various entities in the DVNE architecture is outside of the scope of the present framework document. Nevertheless, in the reminder of this section some viable technical alternatives to support admin-Mediator, Mediator-node, and node-node interaction are briefly described in order to help future implementation efforts or standardization initiatives.

The administrator could configure parameters for VN construction with the Mediator via SSH, HTTP, SNMP, NETCONF or any other alternate methods. All the se methods are secure.

A VN node should register some information (e.g., its addresses) and/or request configuration to the Mediator. In response, the Mediator should configure the VN node with addressing, routing, tunneling, etc. The Mediator may configure the VN node with STUN/TURN server’s address if the VN node is behind NAT device(s). In that case, both VN nodes and the Mediator may be integrated with ICE mechanism to achieve NAT traversal. Other than the VN related configuration and policies, the Mediator may relay referrals to two VN nodes that are willing to setup tunnels with each other for better connectivity. [I-D. carpenter-behave-referral-object] tries to standardize a generic referral objects and GROBJ BoF at this writing time is undertaking related tasks.

When two VN nodes choose a pair of addresses for connectivity, one node can initiate a tunnel to the other node according to the administrative configuration or request. DVNE assumes the tunnel method is IPsec All the interaction between the functional elements of the proposed architecture need to be secured:

• The interaction between the Mediator and the administrator;
• The interaction between a VN node and the Mediator;
• The interaction between VN nodes.

The Mediator should impose a strong method to authenticate the administrator, for example, using X.509 certificate issued by a trusted Certification Authority. The configuration data between the Mediator and the administrator usually exchange in an interactive mode, SSH, TLS or any other alternative means can protect the integrity and confidentiality of the configuration data.

The Mediator should impose a strong or moderate method to authenticate the VN node and let the authorized VN node join the VN. A moderate method could be using TLS as secure tunnel and using username/password method to do actual authentication since X.509 certificate might be costly in some circumstances. The integrity and confidentiality can be achieved by using TLS or any other alternative means to protect the data.

The VN nodes use tunneling technologies which are out of the scope of this document should accommodate NAT traversal. For example, UDP encapsulation of ESP would be used for IPsec works in the presence of NAT. for tunneling authentication, the Mediator can act as a proxy to relay the authentication credentials or share pre-secret or distribute session key for tunneled data encap/decap. The security for tunneled data is dependent on which tunnel technology you used. Security issues for tunnels are addressed in specific tunneling specification or relevant documents and out of the scope of this doc.

Finally, the Mediator must implement protections against denial of service attacks which may occur whenever a malicious user exhausts all the resources available on the Mediator. A possible protection against this attack could be achieved by administratively limiting the VN scale and the number of VNs supported simultaneously.tunnel and IPsec tunnel over UDP (when NAT traversal is needed). Other alternatives like SSL, L2TP, GRE should be considered later.

6.  Security Considerations

All the interaction between the functional elements of the proposed architecture need to be secured:

• The interaction between the Mediator and the administrator;
• The interaction between a VN node and the Mediator;
• The interaction between VN nodes.

The Mediator should impose a strong method to authenticate the administrator, for example, using X.509 certificate issued by a trusted Certification Authority. The configuration data between the Mediator and the administrator usually exchange in an interactive mode, SSH, TLS or any other alternative means can protect the integrity and confidentiality of the configuration data.

The Mediator should impose a strong or moderate method to authenticate the VN node and let the authorized VN node join the VN. A moderate method could be using TLS as secure tunnel and using username/password method to do actual authentication since X.509 certificate might be costly in some circumstances. The integrity and confidentiality can be achieved by using TLS or any other alternative means to protect the data.

The VN nodes use tunneling technologies which are out of the scope of this document should accommodate NAT traversal. For example, UDP encapsulation of ESP would be used for IPsec works in the presence of NAT. for tunneling authentication, the Mediator can act as a proxy to relay the authentication credentials or share pre-secret or distribute session key for tunneled data encap/decap. The security for tunneled data is dependent on which tunnel technology you used. Security issues for tunnels are addressed in specific tunneling specification or relevant documents and out of the scope of this doc.

Finally, the Mediator must implement protections against denial of service attacks which may occur whenever a malicious user exhausts all the resources available on the Mediator. A possible protection against this attack could be achieved by administratively limiting the VN scale and the number of VNs supported simultaneously.

7.  IANA Considerations

There are no IANA considerations for this document.

8.  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.).

9.  References

9.1. Normative References

9.2. Informative References

Authors' Addresses