One document matched: draft-mrw-dvne-fw-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc4301 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml'>
<!ENTITY rfc3809 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3809.xml'>
<!ENTITY rfc2131 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml'>
<!ENTITY rfc3315 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
<!ENTITY rfc4572 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4572.xml'>
<!ENTITY rfc3948 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3948.xml'>
<!ENTITY rfc2629 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
]/>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" ipr="trust200902" docName="draft-mrw-dvne-fw-00.txt">
<front>
<title abbrev="DVNE Framework">Dynamic Virtual Network Engine
(DVNE) Framwork</title>
<author initials="M." surname="Wasserman" fullname="Margaret Wasserman">
<organization>Painless Security</organization>
<address>
<postal>
<street>356 Abbott Street</street>
<city>North Andover</city> <region>MA</region>
<code>01845</code>
<country>USA</country>
</postal>
<phone>+1 781 405 7464</phone>
<email>mrw@painless-security.com</email>
<uri>http://www.painless-security.com</uri>
</address>
</author>
<author fullname="Padmanabha Nallur" initials="P."
surname="Nallur">
<organization>Futurewei Technologies</organization>
<address>
<postal>
<street>3255-4, Scott Blvd</street>
<city>Santa Clara</city>
<region>California</region>
<country>USA</country>
</postal>
<email>pnallur@huawei.com</email>
</address>
</author>
<date month="October" year="2010" />
<area>Transport</area>
<abstract>
<t>
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.
</t>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Applicability">
<t>
IPsec <xref target="RFC4301"/> site-to-site VPNs
<xref target="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.
</t>
<t>
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.
</t>
</section>
<section title="Problem Statement">
<t>
Constructing a virtual network traversing physical IP networks
encounters 2 major problems:
<list style="symbols">
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section title="Terminology">
<t>
<list style="symbols">
<t>
Virtual Network (VN): an overlay network connecting VN nodes based on
physical networks along with the edge networks to which VN nodes
attach.
</t>
<t>
DVNE: An approach to configure and manage virtual networks
based on the provision of dedicated servers, called Mediators.
</t>
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section title="DVNE Model">
<t>
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
<xref target="RFC2131"/><xref target="RFC3315"/> or DNS lookup.
</t>
<t>
The DVNE model is based on the set of functional elements depicted in
figure 1.
</t>
<figure>
<artwork>
<![CDATA[
+----------+
| Mediator |
+----------+
/ \
/ \
/ \
+---------+ +---------+
| VN Node |<========>| VN Node |
+---------+ +---------+
|
------------
/ \
| Edge Network |
\ /
------------
Figure 1: Simple DVNE configuration
]]>
</artwork>
</figure>
<section title="Mediator">
<t>
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.
</t>
<t>
A Mediator must be IPv4 addressable. It must be reached by all VN
nodes (i.e., without NAT traversal needed).
</t>
</section>
<section title="VN Nodes">
<t>
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.
</t>
</section>
<section title="Using DVNE Service">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="VN Address Assignment">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Tunnel Establishment">
<t>
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 <xref target="RFC4572"/>.
</t>
<t>
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.
</t>
<figure>
<artwork>
<![CDATA[
+-----------+
| 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
]]>
</artwork>
</figure>
<t>
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.
</t>
<t>
Tunneling configuration adjust to NAT traversal. E.g., when NAT
devices comes in between, UDP encapsulation of IPsec tunneling
<xref target="RFC3948"/> is preferred whereas TLS tunneling is
preferred without the presence of NAT.
</t>
</section>
<section title="Next Hop Determination">
<t>
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.
</t>
</section>
<section title="Interaction Between DVNE Entities">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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:
<list style="symbols">
<t>
The interaction between the Mediator and the administrator;
</t>
<t>
The interaction between a VN node and the Mediator;
</t>
<t>
The interaction between VN nodes.
</t>
</list>
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
All the interaction between the functional elements of the proposed architecture need to be secured:
<list style="symbols">
<t>
The interaction between the Mediator and the administrator;
</t>
<t>
The interaction between a VN node and the Mediator;
</t>
<t>
The interaction between VN nodes.
</t>
</list>
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="IANA Considerations">
<t>
There are no IANA considerations for this document.
</t>
</section>
<section title="Acknowledgements">
<t>
This document was written using the xml2rfc tool described in RFC 2629
<xref target="RFC2629"/>.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc4301;
&rfc3809;
&rfc2131;
&rfc3315;
&rfc4572;
&rfc3948;
</references>
<references title="Informative References">
&rfc2629;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:27:18 |