Network Working Group Michael Ko Internet Draft Edward Wang Intended status : Informational Huawei Symantec Expires : April 2012 October 14, 2011 Problem Statement for Dynamic Secure Interconnect draft-ko-dsi-problem-statement-00.txt Abstract This document examines the problems and challenges associated with the process of setting up secure interconnections between 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 [NAT]. Setting up a secure interconnection 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 in April 2012. Table of Contents 1 Introduction ................................................2 2 Problems in Establishing Secure Interconnections ............3 2.1 Connectivity Problems .......................................3 2.2 Security Problems ...........................................5 2.3 Management Problems .........................................6 Ko Expires April 2012 [Page 1] Internet-Draft DSI Problem Statement October 2011 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 interconnection 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 interconnection 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 reduce 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 interconnections 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, and periodically sets up a secure interconnection with the Ko Expires April, 2012 [Page 2] Internet-Draft DSI Problem Statement October 2011 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 interconnection 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 secure interconnections with authorized network nodes anywhere in the Internet for various reasons. 2 Problems in Establishing Secure Interconnections Establishing and maintaining a secure interconnection between two network nodes entails challenges related to connectivity, security, and management. 2.1 Connectivity Problems The first consideration in establishing a secure interconnection between two authorized network nodes 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 another 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, automated discovery is an important requirement for the user to set up a secure interconnection 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, the "directory agent" Ko Expires April, 2012 [Page 3] Internet-Draft DSI Problem Statement October 2011 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 for managing 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 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 secure interconnections 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 April, 2012 [Page 4] Internet-Draft DSI Problem Statement October 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 is ready for interconnections, either seeking to connect to other network nodes, or allowing others to connect to it, it contacts a central repository to login and register its presence in the network. After a 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 establishing a secure interconnection between two authorized network nodes is security. Ideally any node with the same security/application strategy can form a secure interconnection free of the restrictions of the physical network, and network Security Assurance solutions should not be dependent on network topology. The secure interconnection 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. (An enclave is 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 include firewalls, guards, Virtual Private Networks Ko Expires April, 2012 [Page 5] Internet-Draft DSI Problem Statement October 2011 [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 interconnection. 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 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. Existing standards such as Kerberos [KERBEROS] can be used to satisfy the authentication aspect of establishing a secure interconnection. Kerberos acts as a trusted third-party authentication service by using conventional (shared secret key) cryptography. Extensions to Kerberos can provide for the use of public key cryptography during certain phases of the authentication protocol. 2.3 Management Problems The third consideration in establishing a secure interconnection between two authorized network nodes is on management and control. The following is a list of some of the critical management tasks that are required for establishing a secure interconnection between two authorized network nodes: 1. Discover if the network nodes that a user is authorized to access are currently online and active. Ko Expires April, 2012 [Page 6] Internet-Draft DSI Problem Statement October 2011 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. 5. Determine the parameters needed to establish a secure interconnection 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 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, Ko Expires April, 2012 [Page 7] Internet-Draft DSI Problem Statement October 2011 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 secure interconnections. This protocol does not directly establish a secure interconnection between the two network nodes. It only conveys the information needed by the two network nodes to establish a secure interconnection. This enables all existing methods of secure interconnection establishment, 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 establishing a secure interconnection between 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 secure interconnection 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 Ko Expires April, 2012 [Page 8] Internet-Draft DSI Problem Statement October 2011 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 authorized network nodes in the network, a protocol is needed for the interaction between a central repository and a 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 [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 Ko Expires April, 2012 [Page 9] Internet-Draft DSI Problem Statement October 2011 [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 [KERBEROS] C. Neuman et al., "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005 [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 et al, "NETCONF Configuration Protocol (NETCONF)", RFC6241, June 2011 [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 Ko Expires April, 2012 [Page 10] Internet-Draft DSI Problem Statement October 2011 [TURN] R. Mahy et al., "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010 [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 [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 for his valuable advice and suggestion. 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 Ko Expires April, 2012 [Page 11] Internet-Draft DSI Problem Statement October 2011 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. 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 April, 2012 [Page 12]