Internet Engineering Task Force C. Jacquenet INTERNET-DRAFT France Telecom R & D Document: draft-jacquenet-ip-vpn-needs-00.txt Category: informational Expires: January 2001 Functional requirements for the deployment of an IP VPN service offering <draft-jacquenet-ip-vpn-needs-00.txt> 1. Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 ([RFC-2026]). 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This document aims at identifying the requirements which should be taken into consideration by a service provider, when considering the deployment of an IP VPN service offering. From this perspective, this document does not specify any technical means which could be used to deploy an IP VPN service offering, unlike the [VPN-FRAME] document. This document tries to express a service provider perspective, according to its own experience of IP-based service offerings, and to its own perception of the (constantly) evolving needs of the customers of such services. To some extent, this document can be viewed as a complementary taxonomy effort of the [TAXONOMY] draft. 3. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 ([RFC- 2119]). 4. Glossary IP VPN requirements July 2000 CPE: Customer Premises Equipment. Customer: See " subscriber ". SLA: Service Level Agreement. A SLA is a contractual document which a subscriber and a service provider have agreed upon. SLS: Service Level Specification. A SLS is the technical and detailed specification of an SLA. SMFA: Specific Management Functional Area, such as configuration management, performance management, security management, alarm management and accounting management. SoHo: Small office Home office. Subscriber:A subscriber (or a customer) is a legal representative who has the (legal) ability to subscribe to a service offering. User: A user is an entity (a human being or a process, from a general perspective) who has been named by a subscriber and appropriately identified by a service provider, so that he might benefit from a service according to his associated rights and duties. VPN: Virtual Private Network. A collection of switching resources (namely routers) and transmission resources which will be used over an IP backbone to process the IP traffic which will reflect the data oriented- communication service of an enterprise (VPNs which are designed to support intranet-based applications) or a set of enterprises (VPNs which are designed to support extranet-based applications). An IP VPN may also provide an access to the Internet, from a service offering perspective. 5. Some basic definitions 5.1. What's an IP VPN ? An IP VPN is a set of IP switching and transmission resources which is dedicated to the use of a set of authorized users, and which is deployed over a public IP backbone. 5.2. What's an IP VPN service offering ? An IP VPN service offering is one of the services which may be provided by a service provider, and which consists in engineering, deploying and managing one or more IP VPN(s) for the corresponding subscriber, and according to the needs which have been expressed by this subscriber before the contractual agreement has been signed between the subscriber and the service provider, AND during the contractual lifetime of the above-mentioned agreement. 5.3. The customers of an IP VPN service offering An IP VPN service offering is designed to address some of the needs of the corporate enterprises. From that perspective, an IP VPN IP VPN requirements July 2000 service offering will have to consider the following categories of subscribers: - a single enterprise which may subscribe to the IP VPN service offering to exclusively address its internal data communication needs, within the context of running intranet applications; - a set of enterprises which may subscribe to the IP VPN service offering to exclusively address their data communication needs between themselves, within the context of running extranet applications. Some or all of these enterprises may also subscribe to the IP VPN service offering to address their own internal data communication needs, without any kind of interference. In any case, the subscriber of an IP VPN service offering is an administrative entity which has been granted to represent an enterprise or a set of enterprises, at least from a legal perspective. Subscribing to an IP VPN service offering also means that there will be at least one IP VPN which will be deployed for the subscriber. 5.4. The users of an IP VPN service offering The users of an IP VPN service offering are the human beings (or processes) which will communicate with other human beings (or processes) thanks to the use of workstations (PCs, Unix workstations, whatever) to exchange information between them by using the resources of the IP VPN service offering. From this perspective, the users can be classified into two categories: - static users, i.e. users who will communicate with the other users (or part of) by using the resources of the IP VPN service offering without moving from their office and by always using the same workstation. This office can be precisely identified, at least according to some basic geographical considerations; - mobile users, i.e. users who will communicate with the other users (or part of) by using the resources of the IP VPN service offering wherever they may be and, more precisely, one can distinguish: * the mobile users who may move within a single location among the various locations which will be used/granted by the IP VPN service offering subscriber (e.g. one of the sites of a given enterprise which will be interconnected by at least one IP VPN which is part of the contract the subscriber and the IP VPN service provider have agreed upon). That kind of mobile user may use a given set of workstations within the above-mentioned location and may make use of the IP VPN service offering resources only when moving within this location; * the mobile users who may move between the set of (or part of) locations which will be used/granted by the IP VPN service offering subscriber. That kind of mobile user may make use of the IP VPN service offering resources only when moving within this set of locations; IP VPN requirements July 2000 * the mobile users who may make use of the IP VPN service offering resources wherever they may be, including accessing these resources through the Internet network or from their home, within the context of SoHo workers. 6. Description of the requirements for an IP VPN service offering 6.1. Architectural considerations 6.1.1. The network components of an IP VPN service offering According to the definition which has been given in chapter 5.1, the network components of an IP VPN service offering will have to process the IP traffic that will be exchanged between the users of the IP VPN service offering, and that will reflect the use of an as widest as possible range of applications, ranging from electronic mail to video-conferencing applications. Moreover, since an IP VPN service offering will have to consider the connection of sites which may belong to an enterprise (or a set of enterprises), there should be no kind of limitation in terms of link-layer-based access technology (1), such as PSTN, ISDN, xDSL, leased line, ATM, Frame Relay, etc. If there is such a limitation, this will have to be clearly and precisely stated when defining the technical specifications of the IP VPN service offering. From this access perspective, it should be possible to provide a back-up capability (2) whenever the primary access link from a site to one of the IP VPN(s) which may have been deployed for the subscriber fails to be operational. As far as IP traffic is concerned, an IP VPN service offering will obviously make use of an IP forwarding and routing global resource which may be distributed among various locations, including customer and service provider premises. Nevertheless, since an IP VPN service offering belongs to the range of internetworking service offerings which are (to be) provided by a service provider, the limit of responsibility will have to be clearly identified between both parties - namely the customer and the IP VPN service provider. (1): considering the link layer technology which is used (or yet to be used) by the IP backbone which will support the IP VPNs that will be deployed within the context of an IP VPN service offering is, by definition, out of the scope of this document. Nevertheless, the engineering characteristics of such an IP backbone will have to be taken into account when specifying the IP VPN service offering. (2): this back-up capability should obviously be as dynamic as possible, i.e. the back-up link should be dynamically established as soon as the primary access link fails to be operational, and should become dynamically idle as soon as the primary access link comes back up. 6.1.1.1. Numerical considerations IP VPN requirements July 2000 The dimensioning considerations which may characterize an IP VPN service offering can be expressed as the number of expected customers, the number of expected users per customer, and/or the number of expected IP VPNs to be deployed. From that perspective, the technical specification of an IP VPN service offering should consider the following assumptions: - it should be possible to deploy more than one IP VPN per subscriber, especially when considering the IP layer as the multi- service layer of the subscriber; - the number of sites which may be interconnected by a given IP VPN is obviously a function of the size of the subscriber (in terms of turnover or number of employees, for example), and it may also reflect the organization of the subscriber (e.g. national banks which are composed of thousands of agencies which may have a permanent access to a central site, and a record manufacturing company, which may have a couple of production sites, an R and D location, and its headquarters). From that perspective, the number of sites may dramatically vary from one subscriber to another, typically ranging from 2 or 3 sites, up to several thousands of locations, both national and international. 6.1.1.2. Permanent access and temporary access The IP VPN service offering should allow both permanent and temporary access (to one or several IP VPNs) for its users, according to their very own rights (see the corresponding " security considerations " chapter). Once again, there should be no limitation in the type of access technology which may be used as the IP transportation technology. 6.1.1.3. IP traffics considerations The IP VPN service offering should handle any kind of IP traffic - namely broadcast, anycast, multicast and unicast, and may also have the ability to activate the appropriate filtering capabilities whenever required, and whatever the filter may be, upon request of the customer. An example of such a request would consist in optimizing as far as possible the time needed for an authorized user to become a member of a video-conferencing service according to some specific scheduling requirements which may have an impact on the processing functions of the corresponding IP multicast trafic (wherever these functions may be located), if the video-conferencing application has been built so that it may gracefully benefit from the activation of such multicast processing capabilities. 6.1.1.4. IP numbering schemes considerations The IP VPN service offering should gracefully take care of the following cases : IP VPN requirements July 2000 - the subscriber has deployed its own private numbering scheme on every location which may benefit from the IP VPN service offering, and this IP numbering scheme should never be changed in any case; - the subscriber has deployed a globally unique IP numbering scheme composed of public IP addresses which have been delivered by the IANA; - the subscriber has deployed NO IP numbering scheme, and has made no specific request either : in this case, the IP VPN service offering should be able to address this need, whatever the corresponding provisioning may be (i.e. private and/or public - including an IPv6-based numbering scheme, if appropriate). The IP VPN service offering should also provide the following capabilities: - a dynamic IP address allocation mechanism whenever requested by the user, and whatever the access may be, i.e. either permanent or temporary; - an IP numbering scheme outsourcing feature, which may consist for the service provider in managing the IP numbering scheme which has been deployed by or allocated to the subscriber, including the multicast addressing scheme. The appropriate DNS service which may be provided to the subscriber will have to be taken into consideration as well, whenever appropriate (e.g. when connecting a new location to one of the IP VPNs which have been deployed for the subscriber). 6.1.1.5. Accessing the Internet The IP VPN service offering may also provide an access to the Internet network for all the authorized users which have been declared by the subscriber(3). The IP VPN(s) which may be deployed for the subscriber may either process the corresponding IP traffic (i.e. the traffic which is destined to or comes from the Internet network) or reject the corresponding traffic thanks to the activation of the appropriate filtering capabilities (4). (3): the subscriber may also request that some of his " Web-based communication" servers which would be installed in one of the sites connected to one of his IP VPNs, might be accessed from the Internet network. This probably yields some security considerations which are detailed in paragraph 6.1.3. of the present document. (4): it's important to note that BOTH cases (at least one of the IP VPNs which have been deployed for the subscriber will process the "Internet" traffic, or none of these IP VPNs will process the "Internet" traffic) may very well correspond to the " Internet access " capability (or, more suitably, option) of the IP VPN service offering. IP VPN requirements July 2000 6.1.1.6. Migration considerations Subscribers of the IP VPN service offering who have already deployed their own private network (whatever the technology) should not suffer from migration considerations (whatever they are), when evolving from the above-mentioned network towards one or more IP VPNs. This migration should be as smooth as possible, both from an economical and technical perspectives. 6.1.2. Quality of service considerations 6.1.2.1. The basic nature of applications Applications that may be run over the IP VPN(s) which has(ve) been deployed for the subscriber can be classified into two categories (it is obviously the responsibility of the subscriber to decide whether an application is "critical" or "not that critical"): - there are applications which are critical either to delay, jitter, throughput or reliability (or a combination of the above-mentioned criteria). Real-time applications (such as voice over IP) are generally considered as sensitive applications, for example; - there are applications which are not that critical, i.e. they can accept an affordable degradation when being transmitted, even from a user perspective. For example, a transaction process thanks to the use of the Telnet protocol can accept some delay variations (which may even cause the loss of a given set of datagrams), because the integrity of the transaction is not that damaged, especially when considering the fact that the Telnet protocol relies upon the TCP layer. On the other hand, the loss of a single IP datagram during an FTP-based file transfer may have a dramatic impact on the integrity of the file, so that the user could simply be unable to use this file. This critical/not that critical kind of typology for the applications which are to be run over the IP VPN(s) which will be deployed for a given subscriber will have to be taken into account by the IP VPN service offering, at least from a quality of service perspective, so that it will have to consider the deployment of QOS- based IP VPNs. 6.1.2.2. Dealing with congestion Whenever a congestion is experienced in the IP backbone which will support the IP VPNs (and wherever this congestion may take place), it may affect the transmission of the IP datagrams. Some of these datagrams will reflect the activation of sensitive applications, others will reflect the activation of not-that-sensitive applications. It is therefore the responsibility of the IP VPN service provider to provide any means which may be appropriate so that: IP VPN requirements July 2000 - sensitive applications-based IP datagrams will never have to suffer from any kind of congestion, either in the IP VPN which processes such datagrams, or somewhere in the IP backbone, provided it has been clearly stated (by any means appropriate) that the responsibility of such a congestion is the IP VPN service provider's responsibility. This means that no such datagrams will be lost during their transmission over the IP VPN, which yields the notion of quality of service guarantees for such datagrams. Such guarantees will have to be expressed in terms of QOS indicators, and these indicators will have to be as precisely as possible defined and measured on a regular basis (e.g. one month), so that they might be used as part of the contract which will be signed between the subscriber and the service provider; - not-that-sensitive applications-based IP datagrams may occasionally suffer from any kind of congestion. This "suffering" might be expressed in terms of classes of service, which may allow the service provider to: * process (i.e. transmit) some datagrams more rapidly than others, according to a scheduling policy which may be part of the contract between the subscriber and the service provider; * discard some datagrams rather than others, according to a discarding policy which may be part of the contract between the subscriber and the service provider; * commit in providing a maximum loss rate (or some equivalent indicator), which may vary according to the number of classes of service that may be defined and activated by the service provider within the network resources he's responsible of (e.g. a one out of a thousand datagrams for the "economy" class of service, a one out of a million datagrams for the "business" class of service, and a one out of a billion datagrams for the "first" class of service). 6.1.2.3. Service guarantees According to what has been mentioned in the above chapter, the IP VPN service provider will have to commit in some specific service guarantees which will be part of the contract that will be signed between the subscriber and the service provider. This yields the notion of SLA both parties will have to agree upon, and the corresponding specification is the SLS. The IP VPN service offering should therefore have the ability to provide a range of SLAs/SLSes to address the needs of its subscribers. 6.1.3. Security considerations 6.1.3.1. Identifying and authenticating the users The IP VPN(s) to be deployed will be used by human beings (or processes) who will have to be precisely authorized and authenticated. In other words, the IP VPN service offering will have to provide any appropriate means which will help both parties in IP VPN requirements July 2000 being convinced that no unexpected/unauthorized user will access the IP VPN resources which might be deployed for the subscriber. Identifying the user means that the service provider will have to provide an as precise as possible answer to the following question: "who does the (requesting) user claim to be ?" Authenticating the user means that the service provider will have to provide an as precise as possible answer to the following question: "since the identity of the user has been (somewhat) confirmed (by answering to the previous question), who is the actual human being according to the identification information he has provided and what are his rights ?" 6.1.3.2. Protecting the resources of the subscriber When deploying one or several IP VPNs for the subscriber, the IP VPN service offering will have to provide the appropriate guarantees that the corresponding resources have the ability to deny any kind of malicious intrusion, especially by protecting the access to the locations (by " location ", the author means either a site which may have a permanent access to the IP VPN resources, or a site which may have a temporary access to the IP VPN resources, including mobile hosts) of the subscriber which might be interconnected by the IP VPN(s), and also by ensuring that the IP VPN resources will deny the access to the locations of the subscriber which are not even connected to the IP VPN(s). 6.1.3.3. Preserving the data confidentiality within the IP VPN(s) The IP VPN service offering will have to preserve the confidentiality of the information which is to be transmitted over the IP VPN resources. Moreover, if several IP VPNs are to be deployed for a given subscriber, the IP VPN service offering will have to preserve the confidentiality of the information which is to be transmitted through the various IP VPNs so that any kind of interference might never occur between these IP VPNs. 6.1.3.4. Identifying and authenticating the network resources The IP VPN service offering will have to guarantee that, for a given IP VPN (or a set of IP VPN(s)) which has (have) been deployed for a given subscriber, all of the network resources that will be used by this (these) IP VPNs have been appropriately identified and authenticated, so that they have the right to process (i.e. mainly forward and route) the corresponding IP traffic. As far as the security is concerned, the less the (network) resources involved in the processing of the IP traffic of a given IP VPN, the more secure this IP VPN will be. 6.1.4. Service management considerations The management of an IP VPN service offering will have to comply with the following requirements: IP VPN requirements July 2000 - engineer, deploy and manage the switching and transmission resources which will support the IP VPN service offering, from a network perspective. This features reflects the network element management part of the service management activity; - manage the IP VPNs which have been deployed over the above- mentioned resources. This feature reflects the network management part of the service management activity; - manage the IP VPN service offering itself (this reflects the service management part of the service management activity). From a general perspective, the service management should at least include the global activation of the five classical SMFAs which have been specified by ISO - namely alarm, security, configuration, performance and accounting management. This means in particular: * the specification and the establishment of SLAs between the service provider and the various subscribers, according to the corresponding SLSes; * the measurement of the indicators which have been defined within the context of the above-mentioned SLAs, on a regular basis (namely one day, one week, one month, one quarter, one year, or else); * the management of the users which have been identified and granted by the subscriber, so that they may benefit from the IP VPN(s) which have been deployed accordingly. This should also include the integration of the management of possible user/subscriber directories. - finally manage the IP VPN business, which mainly consists in provisioning administrative and accounting information related to the IP VPN service offering subscribers. This feature reflects the business management part of the service management activity. 7. Constraints and selection criteria of an IP VPN service offering 7.1. Functional constraints It is assumed the service provider already operates an IP backbone, which could support an IP VPN service offering. This implies that the technical choices must be taken in accordance to the technologies and equipment which are already in use in this backbone. Nevertheless, the technical solutions which will be considered must be supported by the Internet standardization process for compatibility, modularity and backward compatibility purposes. Furthermore, some security functions are needed to ensure that the IP VPN(s) which is (are) provided to the customer is (are) actually "private", and these specific requirements may have an impact on the functional features which are currently supported by the equipment of the IP backbone. 7.2. Selection criteria 7.2.1. Performances IP VPN requirements July 2000 As far as the performances are concerned, the IP VPN service offering should support the following characteristics : - the time to access the service from a user standpoint should be expressed in milliseconds. 7.2.2. Quality of service To be defined according to the SLAs which should be provided along with the provisioning of the IP VPN service offering itself, according to the " quality of service considerations " paragraph (6.1.2) of the present document. 8. References [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [VPN-FRAME]Gleeson, B., Heinanen, J., Armitage, G., Malis, A., "A Framework for IP Based Virtual Private Networks ", RFC 2764, February 2000 [TAXONOMY] Berkowitz, H., "Requirements Taxonomy for Virtual Private Networks",draft-berkowitz-vpn-tax-00.txt, work in progress, March 1999 9. Author's address Christian Jacquenet France Telecom Research and Development 42, rue des Coutures BP 6243 14066 Caen cedex 04 France Phone: + 33 2 31 75 94 28 Fax: + 33 2 31 73 56 26 Email: christian.jacquenet@francetelecom.fr 10. Full copyright statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be IP VPN requirements July 2000 followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.