Network Working Group Michael Ko
Internet Draft Edward Wang
Intended status : Informational Huawei Symantec
Expires : December 15, 2011 June 15, 2011
Problem Statement for Setting Up Dynamic Virtual Network
draft-ko-dvn-problem-statement-00.txt
Abstract
This document examines the problems and challenges associated with
the process of setting up secure virtual network connections among
authorized network nodes. The network nodes can be located anywhere
in a private or public network, directly connected or behind one or
more levels of NAT. Setting up a secure virtual network in this
environment entails the resolution of various issues such as
authentication, peer discovery, virtual network address management,
and connection parameters determination.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 15, 2011.
Table of Contents
1 Introduction................................................2
2 Problems in Establishing Network Connections................3
2.1 Connectivity Problems.......................................3
Ko Expires December 15, 2011 [Page 1]
Internet-Draft DVN Problem Statement June 2011
2.2 Security Problems...........................................5
2.3 Management Problems.........................................6
3 Conclusions.................................................8
4 Security Considerations.....................................9
5 IANA Considerations.........................................9
6 Informative References......................................9
7 Acknowledgments............................................11
1 Introduction
The pervasiveness and the ubiquity of the Internet have empowered
mobile users, bringing it closer to reality for anyone to achieve
the goal of being able to work anywhere, anytime, and using any
device. The user's computer may only contain just a minimal
operating system with a web browser to serve as little more than a
display terminal for processes occurring on a network of computers
far away. Therefore, being able to setup a connection with any
authorized network nodes containing the needed resources on demand
will further increase the flexibility for the user, allowing him/her
to pick and choose the appropriate resources based on different
criteria for the task at hand. These network nodes containing the
needed resources may reside inside the local network, or externally
at an internet connected datacenter.
A user may need to set up a secure connection with an authorized
network node for data backup and archiving purposes. This allows a
user that stores his/her data at one facility (such as a cloud
storage facility) to backup and archive his/her data at a different
facility (such as a different cloud storage facility) in order to
avoid suffering irrecoverable data loss in a catastrophic situation.
A user may want to set up a secure connection with a remote
authorized network node for data mirroring purposes. This allows a
mobile user to maintain remote copies of the data at different
locations. Then depending on his/her current location, he/she can
select the nearest network node containing a replica of his/her data
in order to lower the access latency.
In some anti-DDoS (distributed denial of service) solutions, the
network node running the operation of the anti-DDoS solution is
responsible for formulating the detection and cleaning policies
based on user defined requirements. The network node needs to set
up secure connections with the network nodes responsible for DDoS
detection and the network nodes responsible for cleaning in order to
deliver the policies for execution. In turn, each network node
containing the DDoS detectors identifies and detects DDoS traffic,
Ko Expires December 15, 2011 [Page 2]
Internet-Draft DVN Problem Statement June 2011
and periodically sets up a secure connection with the network node
running the operation to return the detection results in order for
the cleaning policies to be updated based on the detection results.
Similarly, each network node acting as a cleaning agent filters DDoS
traffic and isolates threats, and periodically sets up a secure
connection with the network node running the anti-DDoS solution in
order to receive updated cleaning policies.
These and other examples point to the need for setting up virtual
network connections with authorized network nodes anywhere in the
Internet in a secure manner for various reasons.
2 Problems in Establishing Network Connections
Setting up a network connection with authorized network nodes
entails challenges related to connectivity, security, and management
in the process of establishing and maintaining a virtual network
connecting the two network nodes.
2.1 Connectivity Problems
The first consideration for a user in setting up a connection with
an authorized network node is the ability to create an end-to-end
connection between the two nodes. Ideally any node connected to the
Internet should be able to establish addressing and create direct
end-to-end connection with the other network node regardless of its
topological location and Internet Protocol technology (IPv4/v6). In
reality, a network node can be located anywhere in a private or
public network, directly connected or behind one or more levels of
NAT. In addition, it is not uncommon for a node to have a dynamic
IP address on its physical or virtual interfaces. Furthermore, the
status of a node being online or offline is dynamic. For a mobile
user, even the physical location of a node is also dynamic.
Due to the dynamic nature of these virtual networks, automated
discovery is an important requirement for the user to set up a
secure network connection with an authorized network node. The IETF
standard known as the Service Location Protocol [SLP] allows
computers and other devices to find services in a local area
network. In larger networks, one or more "directory agents" are
used in SLP. Service agents send register messages containing all
the services they advertise to the "directory agents". User agents
issue service requests to the "directory agent", specifying the
characteristics of the services they require. To provision services
to users, a network administrator can assign a scope string to each
and every user agent in order to limit the user agent to discover
only that particular grouping of services. As currently defined,
Ko Expires December 15, 2011 [Page 3]
Internet-Draft DVN Problem Statement June 2011
the "directory agent" merely functions as a cache and does not have
the authority to set the scopes for the user agents.
In some cases it is not possible to establish a direct end-to-end
connection especially when both parties are located behind NATs.
The IETF standard known as Traversal Using Relays around NAT [TURN]
allows a host behind a NAT to use the services of an intermediate
node that acts as a communication relay in order to exchange packets
with its peers. A client using TURN must have some way to
communicate the relayed transport address to its peers, and to learn
each peer's IP address and port (more precisely, each peer's server-
reflexive transport address). This can be done using a special-
purpose "introduction" or "rendezvous" protocol (see [RFC5128]), but
it does require the use of a publicly addressable "rendezvous
server".
The Internet Storage Name Service [iSNS] protocol facilitates the
automated discovery, management, and scalable configuration of
Internet Small Computer Systems Interface [iSCSI] devices on a
TCP/IP network. iSNS allows the administrator to go beyond a simple
device-by-device management model, where each storage device is
manually and individually configured with its own list of known
initiators and targets. Using iSNS, each storage device
subordinates its discovery and management responsibilities to an
"iSNS server". The "iSNS server" serves as the consolidated
configuration point through which management stations can configure
and manage the entire storage network. With the iSNS protocol
supporting the interaction between "iSNS servers" and iSNS clients,
iSNS provides the intelligent storage discovery and management
services needed. However, iSNS is intended to emulate Fibre Channel
fabric services and to manage both iSCSI and Fibre Channel devices,
and is therefore not suitable for use outside of the storage area
network.
The iSNS model points to the desirability of subordinating the
network nodes to a consolidated configuration point for scalability
reasons. This allows the network administrator to use the
consolidated configuration point through which management stations
can configure and manage the virtual network, instead of the simple
node-by-node management model, where each network node is manually
and individually configured with its own list of authorized network
nodes. The consolidated configuration point, acting as a central
repository, can facilitate the automated discovery problem since it
contains the necessary parameters for network nodes to discover and
construct virtual networks with other authorized network nodes.
Certain parameters can be pre-configured by the network
administrator while others can be dynamically provided by the
Ko Expires December 15, 2011 [Page 4]
Internet-Draft DVN Problem Statement June 2011
network nodes. The parameters may contain the topology of the
overlay network (e.g., hub-and-spokes or hub), the function type of
specific network nodes (e.g., router or host), the tunneling method
(e.g., IPsec), the routing protocols (e.g., OSPF), or routing lookup
method (e.g., DNS lookup), the dynamic physical and virtual IP
addresses of the network nodes, etc. For NAT traversal, the central
repository can also serve as the rendezvous server. Existing
standards that use central repositories such as the SLP "directory
agent", the "iSNS server", etc., provide some but not all of the
functionalities needed.
Existing methodologies can be used by network nodes to discover the
central repository, such as pre-configuring the domain name or
address of the central repository in the network nodes, or
provisioning via Dynamic Host Configuration Protocol [DHCP] or
Domain Name System [DNS] lookup, etc. When a network node wishes to
join the virtual network, either seeking to connect to other network
nodes, or allowing others to connect to it, it contacts a central
repository to login to the virtual network in order to register and
activate its presence in the virtual network. After successful
login, a network node may register additional information (e.g., its
dynamic IP address) with the central repository so that the
information can be shared with other authorized network nodes. The
central repository in turn provides the network node with the
necessary information needed to establish a connection with other
network nodes. Through the central repository, a network node
should be able to determine other network nodes that it is
authorized to access, the online status of other network nodes,
parameters needed to establish a connection, etc.
2.2 Security Problems
The second consideration in setting up a connection with authorized
network nodes is security. Ideally any node with the same
security/application strategy can form a dynamic virtual network
free of the restrictions of the physical network, and network
Security Assurance solutions should not be dependent on network
topology. The dynamic virtual network should provide unified
security services for trusted network construction, authentication
and access control, data confidentiality and data integrity, and
non-repudiation.
In a datacenter, there are identifiable boundaries to an enclave
(the collection of local computing devices that are governed by a
single security policy). This facilitates the defense of the
enclave boundary by focusing on effective control and monitoring of
data flow into and out of the enclave. Effective control measures
Ko Expires December 15, 2011 [Page 5]
Internet-Draft DVN Problem Statement June 2011
include firewalls, guards, Virtual Private Networks [VPN], and
identification and authentication /access control for remote users.
Effective monitoring mechanisms include network-based Intrusion
Detection System (IDS), vulnerability scanners, and virus detectors
located on the LAN (see [IATF].)
On the Internet, critical systems are exposed, and physical
isolation can no longer be relied upon to enforce security.
Instead, each network node must be treated as a separate enclave and
be protected as such. There is a need for client authentication,
peer discovery, virtual network address management, etc. in order to
enable a user to setup a secure connection.
Various IETF standards on security such as IP Security [IPSEC],
Transport Layer Security [TLS], Secure Shell [SSH], Public-Key
Cryptography Standards [PKCS], etc, provide the needed framework for
network nodes to create security tunnels to satisfy the security
requirement. But to create a security tunnel during connection
establishment, a network node may need to have access to certificate
fingerprint (see [RFC4572]), generated keys and security strategy,
etc. These can be facilitated by having a central repository in the
virtual network responsible for disseminating the required
information. A central repository is also needed to handle the
authentication, authorization and accounting for a network node
after the network node presents its identity and credentials to the
central repository upon login. This means that the network node and
the central repository may share a pre-configured or automatically
established security association to prevent unauthorized access.
2.3 Management Problems
The third consideration in setting up a connection with authorized
network nodes is on management and control. The following is a list
of some of the critical management tasks that are required for
setting up a connection with an authorized network node:
1. Discover the network nodes that a user is authorized to access
are currently online and active.
2. Discover the functional attributes associated with these
authorized network nodes.
3. Discover the location of the authorized network nodes.
4. Determine if accessing the network node requires going through a
relay (e.g., TURN). Discover the location of the relay if it is
needed.
Ko Expires December 15, 2011 [Page 6]
Internet-Draft DVN Problem Statement June 2011
5. Determine the parameters needed to set up a secure connection
between the two network nodes.
6. Discover, via inquiry or advertisement, other authorized network
nodes as they become active and available.
One popular protocol for managing networked devices is the Simple
Network Management Protocol [SNMP]. The current standard version,
SNMPv3, defines the full security framework including User-based
Security Model [USM] and View-based Access Control Model [VACM].
SNMP was designed to facilitate the exchange of management
information between networked devices. Even though it was
originally intended to configure network equipment, SNMP is mainly
being used for network monitoring due to several reasons. Firstly,
network operators prefer the text-based Command Line Interfaces
(CLI) to configure their boxes, instead of the BER-encoded SNMP (see
[BER]). Secondly, many equipment vendors did not provide the option
to completely configure their devices via SNMP (see [RFC3535].)
The Network Configuration Protocol [NETCONF] uses an Extensible
Markup Language (XML) based data encoding for the configuration data
and the protocol messages to provide mechanisms to install,
manipulate, and delete the configuration of network devices. The
Secure Shell [SSH] protocol is mandatory to support for
confidentiality and authentication. NETCONF uses a simple RPC-based
mechanism to facilitate communication between a client and a server.
A client is typically a network administrator, while a server is
typically a network device. Accordingly, a device may optionally
support multiple NETCONF sessions but is only required to support
one session. After all, "the NETCONF protocol is focused on the
information required to get the device into its desired running
state" by the network administrator.
Due to the dynamic nature of the virtual network, existing protocols
that are geared towards static or manual configuration or monitoring
purposes would be difficult, if not impossible, to allow a user to
discover important information about the authorized network nodes
available. Furthermore, as the number of network nodes increases,
the amount of effort required becomes prohibitive for manual
configuration.
A protocol to facilitate the automated discovery, management, and
configuration of network nodes will be useful in establishing a
dynamic virtual network. This protocol does not directly setup a
secure connection between the two network nodes. It only conveys
the information needed by the two network nodes to setup a secure
connection. This enables all existing methods of secure connection
Ko Expires December 15, 2011 [Page 7]
Internet-Draft DVN Problem Statement June 2011
setup, such as VPN, to be supported without any changes.
Furthermore, with the desirability of having a central repository
for scalability reasons to satisfy the connection and security
requirements, the management protocol should support the following
interactions between a network node and the central repository:
1. Mutual authentication between a network node and the central
repository
2. Virtual address assignment for the network node
3. Responding to inquiries from each network node regarding the
online status and other pertinent information related to peer
discovery for other network nodes that it is authorized to access
4. Providing all necessary parameters for setting up a secure
connection between the two network nodes
5. Initiating State Change Notifications from the network nodes
Multiple central repositories are desirable for redundancy. If the
[LDAP] information base is used to support the central repository,
then the information can be transferred using the [LDAP] protocol.
Otherwise a protocol is needed for distributing the information
between central repositories.
3 Conclusions
This Problem Statement concludes that to handle the connectivity and
security problems related to the task of establishing a virtual
network in a dynamic environment between two authorized network
nodes, it would be desirable to have a central repository to
coordinate the connection process for scalability reasons. Having a
central repository facilitates the task of the network administrator
by allowing him/her to go beyond a simple node-by-node management
model, where each network node is manually and individually
configured. Instead, each network node subordinates its discovery
and management responsibilities to the central repository. Each
network node, having retrieved the information from the central
repository regarding the other network nodes that it is authorized
to access, can proceed with the connection process using supported
standards.
With the central repository being the consolidated configuration
point for all the network nodes in the virtual network, a protocol
is needed for the interaction between a central repository and a
Ko Expires December 15, 2011 [Page 8]
Internet-Draft DVN Problem Statement June 2011
network node. Where redundancy is required, the protocol also needs
to handle the interaction among central repositories.
4 Security Considerations
If a new protocol is deployed, the interaction between a central
repository and a network node and the interaction between two
central repositories is subject to various security threats. As a
result, the protocol messages may need to be authenticated. In
addition, to protect against snooping of the protocol messages,
confidentiality support is desirable and is required when certain
functions of the central repository are utilized.
5 IANA Considerations
This document has no actions for IANA.
6 Informative References
[BER] "Information technology - ASN.1 encoding rules: Specification
of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
and Distinguished Encoding Rules (DER)", ITU-T X.690, July 2002
[DHCP] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,
March 1997
[DNS] P. Mockapetris, "Domain Names - Implementation and
Specification", RFC 1035, November 1987
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[IATF] Technical Directors, National Security Agency Information
Assurance Solutions, "Information Assurance Technical
Framework", Release 3.1, September 2002
[IPSEC] S. Kent et al., "Security Architecture for the Internet
Protocol", RFC 4301, December 2005
[ISCSI] J. Satran et al., "Internet Small Computer Systems Interface
(iSCSI)", RFC 3720, April 2004
[ISNS] J. Tseng et al., "Internet Storage Name Service (iSNS)", RFC
4171, September 2005
Ko Expires December 15, 2011 [Page 9]
Internet-Draft DVN Problem Statement June 2011
[LDAP] K. Zeilenga, "Lightweight Directory Access Protocol (LDAP):
Technical Specification Road Map", RFC 4510, June 2006
[NAT] P. Srisuresh et al., "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001
[NETCONF] R. Enns, "NETCONF Configuration Protocol", RFC4741,
December 2006
[PKCS] J. Jonsson et al., "Public-Key Cryptography Standards (PKCS)
#1: RSA Cryptography Specifications Version 2.1", RFC 3447,
February 2003
[RFC3535] J. Schoenwaelder, "Overview of the 2002 IAB Network
Management Workshop", RFC 3535, May 2003
[RFC4572] J. Lennox, "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006
[RFC5128] P. Srisuresh et al., "State of Peer-to-Peer (P2P)
Communication across Network Address Translators (NATs)", RFC
5128, March 2008
[SLP] E. Guttman et al., "Service Location Protocol, Version 2", RFC
2608, June 1999
[SNMP] R. Presuhn et al., "Version 2 of the Protocol Operations for
the Simple Network Management Protocol (SNMP)", STD 62, RFC
3416, December 2002
[SSH] T. Ylonen et al., "The Secure Shell (SSH) Protocol
Architecture", RFC 4251, January 2006
[TLS] T. Dierks et al., "The Transport Layer Security (TLS) Protocol
Version 1.2", RFC 5246, August 2008
[TURN] R. Mahy et al., "Traversal Using Relays around NAT (TURN):
Relay Extensions to Session Traversal Utilities for NAT (STUN)",
RFC 5766, April 2010
[UDP] J. Postel, "User Datagram Protocol", STD 6, RFC 768, August
1980
[USM] U. Blumenthal et al., "User-based Security Model (USM) for
version 3 of the Simple Network Management Protocol (SNMPv3)",
STD 62, RFC 3414, December 2002
Ko Expires December 15, 2011 [Page 10]
Internet-Draft DVN Problem Statement June 2011
[VACM] B. Wijnen et al., "View-based Access Control Model (VACM) for
the Simple Network Management Protocol (SNMP)", STD 62, RFC
3415, December 2002
[VPN] A. Nagarajan, "Generic Requirements for Provider Provisioned
Virtual Private Networks (PPVPN)", RFC 3809, June 2004
7 Acknowledgments
The authors would like to thank David Harrington and Linda Dunbar
for their valuable advice and suggestion. The authors would also
like to thank Margaret Wasserman and Padmanabha Nallur for laying
out the groundwork in the earlier submitted IETF drafts related to
the subject.
Author's Address
Michael Ko
Huawei Symantec Technologies Co., Ltd.
20245 Stevens Creek Blvd.
Cupertino, CA 95014, USA
Phone: +1-408-510-7465
Email: michael@huaweisymantec.com
Edward Wang
Huawei Symantec Technologies Co., Ltd.
3rd Floor, Section D, Keshi Building
No. 28A, Xinxi Rd., Shangdi, Haidian Dist.
Beijing 100085 P.R. China
Phone: +86-10-6272-1288
Email: wangyc@huaweisymantec.com
Copyright Notice
Copyright (c) 2011 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.
Ko Expires December 15, 2011 [Page 11]
Internet-Draft DVN Problem Statement June 2011
Intellectual Property Statement
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line
IPR repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
All IETF Documents and the information contained therein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Ko Expires December 15, 2011 [Page 12]