Network Working Group M. Wasserman
Internet-Draft Painless Security
Intended status: Standards Track P. Nallur
Expires: April 21, 2011 Futurewei Technologies
October 18, 2010
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
Wasserman & Nallur Expires April 21, 2011 [Page 1]
Internet-Draft DVNE Framework October 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. DVNE Model . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Mediator . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. VN Nodes . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Using DVNE Service . . . . . . . . . . . . . . . . . . . . 5
5.4. VN Address Assignment . . . . . . . . . . . . . . . . . . 6
5.5. Tunnel Establishment . . . . . . . . . . . . . . . . . . . 6
5.6. Next Hop Determination . . . . . . . . . . . . . . . . . . 9
5.7. Interaction Between DVNE Entities . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Wasserman & Nallur Expires April 21, 2011 [Page 2]
Internet-Draft DVNE Framework October 2010
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] site-to-site VPNs [RFC3809] 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:
Wasserman & Nallur Expires April 21, 2011 [Page 3]
Internet-Draft DVNE Framework October 2010
o 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.
o 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
o Virtual Network (VN): an overlay network connecting VN nodes based
on physical networks along with the edge networks to which VN
nodes attach.
o DVNE: An approach to configure and manage virtual networks based
on the provision of dedicated servers, called Mediators.
o 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.
o 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][RFC3315] or DNS lookup.
The DVNE model is based on the set of functional elements depicted in
figure 1.
Wasserman & Nallur Expires April 21, 2011 [Page 4]
Internet-Draft DVNE Framework October 2010
+----------+
| 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),
Wasserman & Nallur Expires April 21, 2011 [Page 5]
Internet-Draft DVNE Framework October 2010
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
Wasserman & Nallur Expires April 21, 2011 [Page 6]
Internet-Draft DVNE Framework October 2010
fingerprint of certificates for each other [RFC4572].
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.
Wasserman & Nallur Expires April 21, 2011 [Page 7]
Internet-Draft DVNE Framework October 2010
+-----------+
| 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
Wasserman & Nallur Expires April 21, 2011 [Page 8]
Internet-Draft DVNE Framework October 2010
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] 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
Wasserman & Nallur Expires April 21, 2011 [Page 9]
Internet-Draft DVNE Framework October 2010
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:
o The interaction between the Mediator and the administrator;
o The interaction between a VN node and the Mediator;
o 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.
Wasserman & Nallur Expires April 21, 2011 [Page 10]
Internet-Draft DVNE Framework October 2010
6. Security Considerations
All the interaction between the functional elements of the proposed
architecture need to be secured:
o The interaction between the Mediator and the administrator;
o The interaction between a VN node and the Mediator;
o 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.
Wasserman & Nallur Expires April 21, 2011 [Page 11]
Internet-Draft DVNE Framework October 2010
8. Acknowledgements
This document was written using the xml2rfc tool described in RFC
2629 [RFC2629].
9. References
9.1. Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3809] Nagarajan, A., "Generic Requirements for Provider
Provisioned Virtual Private Networks (PPVPN)", RFC 3809,
June 2004.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006.
9.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
Wasserman & Nallur Expires April 21, 2011 [Page 12]
Internet-Draft DVNE Framework October 2010
Authors' Addresses
Margaret Wasserman
Painless Security
356 Abbott Street
North Andover, MA 01845
USA
Phone: +1 781 405 7464
Email: mrw@painless-security.com
URI: http://www.painless-security.com
Padmanabha Nallur
Futurewei Technologies
3255-4, Scott Blvd
Santa Clara, California
USA
Email: pnallur@huawei.com
Wasserman & Nallur Expires April 21, 2011 [Page 13]