PPVPN Working Group Tissa Senevirathne Internet Draft Document: draft-tsenevir-app-vpn-test-00.txt Category: Informational July 2002 Application Level Operations and Maintenance (Testability) for Virtual Private Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract In this document we define the scope of Application level VPN testability. Requirements and Solutions for application level VPN testability are presented in the document. Senevirathne Informational - Expiration December 2002 1 draft-tsenevir-app-vpn-test-00.txt July 2002 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 [2]. 1. Introduction Current VPN testability methods depend on the underlying tunneling method used. As a result different tunneling protocols MAY provide different methods or degree of testability, or sometimes may totally lacks such capabilities. However, what is more important is to monitor and test the operation of the VPN and VPN services. In this document we attempt to provide Application level VPN testability or generic VPN testability that is independent of the underlying tunneling implementation. 2. Scope of VPN testability VPN testability is divided into two broad areas. Namely General VPN liveliness at a specific PE device and Specific VPN liveliness at a Specific PE device. 2.1 General VPN liveliness General VPN liveliness is defined as liveliness of a specific class of VPN at a specific PE device. A class of VPN is defined as any one of the following VPN solutions; L3 VPN (VPRN), VPLS, VPWS or any other future class of VPN. General VPN liveliness indicate . Availability of the requested VPN class at a specific PE device . Health and Liveliness of that VPN class at that PE device . General PE to PE reachability for that VPN class Liveliness of one VPN class MUST not be used to deduce the liveliness of any other class of VPN or a specific VPN. 2.2 Specific VPN liveliness Specific VPN liveliness indicates liveliness of a specific VPN of a specific VPN class at a specific PE devices. Specific VPN liveliness indicate Senevirathne Informational - Expiration December 2002 2 draft-tsenevir-app-vpn-test-00.txt July 2002 . Availability of the specific VPN of a specific VPN class at a specific PE device . Health and Liveliness of that VPN at that PE device . General PE to PE reachability for that VPN. . Health and operational status of forwarding process (VFI) at the peer PE. Liveliness of one Specific VPN MUST not be used to deduce the liveliness any other class of VPN or any other VPN. 3. Application Level VPN testability 3.1 Use of Reserved VPN id for General VPN liveliness We propose to reserve a set of specific VPN ids from the VPN addressing method used. The reserved VPN id represents the loop back VPN id for identified VPN class. As an example if integer based numbering is used for VPN addresses, one may choose VPN id 0 to represent loopback VPN id for L3 VPN, VPN id 1 (one) for VPLS and so on. PE devices that comply with the methods presented in this document MUST setup reachability between loopback VPN of all supported VPN classes. The reachability methods setup for the loopback VPN id MUST be exactly the same method as used for other VPN of the same class. Any PE device may request VPN liveliness from any other PE. A PE device MUST only respond the General liveliness request if and only if . The requested VPN class is operational A successful General VPN liveliness response MAY indicates . General PE to PE reachability for that VPN class . The health of the peer PE device . Health of the VPN class at the peer PE. 3.2 Implementation of specific VPN liveliness Senevirathne Informational - Expiration December 2002 3 draft-tsenevir-app-vpn-test-00.txt July 2002 We propose to use a reserved address from each VPN class for the purpose of specific VPN liveliness. As an example; for VPLS a specific MAC address may be reserved. (The actual MAC address to be determined). The implementation that comply to Application level VPN liveliness MUST identify such MAC address at Forwarding plane and process as explained in this document. For Layer 3 VPN it is possible to reserve one of the 127.0.0.x addresses for the purpose. (This require further discussion). Implementations that comply to Application level VPN liveliness MUST identify Layer 2 VPN loopback address at Forwarding plane and process as explained in this document. 4. Discussion Application level test query/responses are created using similar template as data packets. As an example if VPN testability is performed on L3 VPN, the testability packet is IP packet. This similarity allows Application level VPN tests to test wider range of properties. Application level VPN test MAY include testability for varied packet sizes. A local PE may generate a "liveliness" request to a remote PE with specified packet size. Specific packet size is implied by the size of the actual liveliness query packet. The responding PE MUST respond only if above specified criteria are satisfied and there are no packet size violations. Successful response to a "liveliness" query of a specific packet size MAY be used to deduce the support for data packet of that size along the path. Application level VPN test MAY include testability for Quality of service. Quality of Service tested MUST be encoded exactly the same manner as data packets encode quality of service. As an example queried Quality of service for IP packets may encoded as a Type of Service (or Differential Service Code Point (DSCP)). In VPLS, this may be encoded as 802.1Q Priority bits. Trace of reachability (commonly known as trace route) is considered out of scope for application level testability. 5. Advantages - Independent of tunneling methods used. - Ability to test operation and health of actual forwarding process (VFI) at remote PE. Senevirathne Informational - Expiration December 2002 4 draft-tsenevir-app-vpn-test-00.txt July 2002 - Ability to test application level properties such as Quality of Service, Packet size. TTL processing etc. - No extra burden/modification on tunneling methods. As an example in MPLS based testability methods proposed, a special label is used or label depth is increased. Such variations impact the validity of testability. - Ability to test VPN service across mixed mode tunnel configurations. - Provides a generic VPN testability method. Absence of such generic method requires vendors to implement scores of testability methods and service providers MAY require using combination of such methods. Hence generic VPN testability provide ease of implementation and deployment. 6. Security Considerations The methods presented in this document do not introduce any additional security risk on PE to PE side. It is recommended that implementation provide optional policy for handling data packets arriving from access ports with a destination address as the reserved address used for specific VPN liveliness test. Absence of such policy may lead to undefined behavior of reserved address handling and may lead to exploitation of security infrastructure. 7. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 8. Acknowledgments 9. Author's Addresses Tissa Senevirathne 1567 Belleville Way Senevirathne Informational - Expiration December 2002 5 draft-tsenevir-app-vpn-test-00.txt July 2002 Sunnyvale CA 94087 Phone: 408-245-5897 Email: tsenevir@hotmail.com Senevirathne Informational - Expiration December 2002 6 draft-tsenevir-app-vpn-test-00.txt July 2002 Full Copyright Statement "Copyright (C) The Internet Society (2002). 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 in 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 followed, or as required to translate it into Senevirathne Informational - Expiration December 2002 7