PPVPN Working Group Internet Draft Paul Knight Document: draft-knight-ppvpn-vr-protocol-00.txt Nortel Networks Expires: April 2003 October 2002 Protocol Actions for Virtual Router VPNs Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. 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. Abstract This document identifies elements of the protocols used by the ôVirtual Routerö Provider Provisioned VPN architecture which may need to be coordinated with IETF Working Groups other than the PPVPN WG. The primary focus of coordination identified in this document is with the IPSEC WG. This document is for temporary administrative purposes. 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 [RFC2119]. Knight Expires - April 2003 [Page 1] Internet Draft draft-knight-ppvpn-vr-protocol-00.txt October 2002 Table of Contents 1. Introduction...................................................2 2. Auto-discovery Protocol Requirements...........................2 3. Signaling VPN-ID within Tunneling Protocol.....................3 3.1 New Identification Type....................................3 3.2 New ISAKMP Payload Type....................................3 3.3 Additional Traffic Selector TS Type........................3 3.4 New Notification Message...................................4 3.5 Vendor ID Payload..........................................4 3.6 Other Suggestions..........................................4 3.7 Cross-WG Coordination Requirement..........................4 Security Considerations...........................................4 References........................................................5 Acknowledgments...................................................5 Author's Address..................................................5 1. Introduction The Virtual Router Architecture is described in ôNetwork based IP VPN Architecture using Virtual Routersö [VR]. There are two currently identified areas where the VR Architecture depends on other protocol specifications. Both of these areas relate to the interchange of a VPN-ID among Virtual Routers (VRs). The first area is in auto- discovery of VPN member sites. The second is in signaling the VPN-ID within a tunneling protocol between VRs. These two areas are discussed below. The term "VPN-ID" may be either the VPN-ID in RFC 2685 [RFC2685] or another similar VPN identifier which is shared among VPN member sites. 2. Auto-discovery Protocol Requirements Auto-discovery is an option which may be used to simplify VR VPN configuration, as discussed in Section 6 of the [VR] draft. When auto-discovery is used, the auto-discovery mechanism needs to support the exchange of VPN-ID. This is not specifically a protocol issue for VR, but a requirement for auto-discovery mechanisms. The mechanisms for VR BGP-based auto-discovery already use standards- based BGP extensions (MP-BGP). If the auto-discovery mechanism is BGP, as in draft-ietf-ppvpn-auto-03.txt [VPN-AUTO], then it includes the necessary support for the VPN-ID, so this is satisfied. If a different auto-discovery protocol is specified, then it should employ a BGP-based mechanism as an option to support the VR model. Knight Expires - April 2003 [Page 2] Internet Draft draft-knight-ppvpn-vr-protocol-00.txt October 2002 Since current work with auto-discovery is ongoing in the PPVPN WG, there is no cross-WG coordination identified for this requirement. 3. Signaling VPN-ID within Tunneling Protocol The second protocol dependency may involve some significant coordination effort beyond the PPVPN WG, if the preferred method of accomplishing the desired function requires a change to IPsec. This is the need for a capability to signal the VPN-ID within the tunneling protocol between VRs. Although the VR model can work without this, the scalability and security of VPN services may be enhanced by the ability to exchange a VPN-ID. When the VRs use MPLS tunnels, there is already a mechanism for signaling the VPN-ID. However as discussed in section 5.3.1 and 5.3.1.2 of [VR], if IPsec is used as the tunneling protocol, there is a need to signal the VPN-ID within IPsec. This may require a message within ISAKMP/IKE, or some other mechanism. We have a strong preference for identifying a method of signaling the VPN-ID without modifying IPsec, but we have not yet identified a clear way to do this. Specific possibilities (most of which appear to require changes to IPsec) that we have currently identified for carrying the VPN-ID are described in the following sections. 3.1 New Identification Type A new Identification Type within the ISAKMP Identification Payload. As specified in Section 6.9 of RFC 2407, this would require the development of an RFC which describes how to use the identification type with IPsec. 3.2 New ISAKMP Payload Type A new ISAKMP Payload type. This may be more flexible than the approach suggested in 3.1, but . 3.3 Additional Traffic Selector TS Type The Traffic Selector (TS) payload proposed in [IKE-V2] may be suitable for this purpose. The TS Payload specifies address ranges, and thus does not appear to be a clear fit for specifying a single VPN-ID, but it may be possible to define an additional TS Type with semantics suitable for the VPN-ID. Knight Expires - April 2003 [Page 3] Internet Draft draft-knight-ppvpn-vr-protocol-00.txt October 2002 3.4 New Notification Message A new Notification Message type could potentially carry the VPN-ID. However, the Notificatin Message is typically used for error messages, so it may not be appropriate. This does not appear desirable. 3.5 Vendor ID Payload A specific Vendor ID payload might also be able to carry the VPN-ID, but this may result in limited interoperability, and is probably not desirable. It may be possible to use the ID Type 11 (ID_KEY_ID) defined in RFC 2407 (Section 4.6.2.12) for this purpose, along with a defined Vendor-ID Payload to signal that the value of the ID_KEY_ID is a VPN-ID. 3.6 Other Suggestions In addition, it appears that a recently-published Internet-Draft, ôFramework for IPsec Protected Virtual Links for PPVPNs,ö [VLINK] may have useful suggestions for this application. There is some discussion of passing the VPN-ID in section 5.3 of this I-D, and section 6 discusses a number of possible approaches. However, it appears that a specific method of carrying the VPN-ID is not clearly defined in this I-D. 3.7 Cross-WG Coordination Requirement We think this will need to be coordinated with the IPsec WG, so that we can clearly define the requirements and usage scenarios, and evaluate the best approach. Security Considerations As an administrative document, this document does not specify a protocol, so no specific security considerations are identified at this time. Security considerations which may pertain to any solution arising from this document should be addressed along with that solution. Knight Expires - April 2003 [Page 4] Internet Draft draft-knight-ppvpn-vr-protocol-00.txt October 2002 References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [VR] Knight, P. (editor) and Ould-Brahim, H. et al, ôNetwork based IP-VPN Architecture Using Virtual Routersö, work in progress, draft-ietf-ppvpn-vpn-vr-03.txt, July, 2002. [RFC2685] Fox, B., et al, "Virtual Private Networks Identifier", RFC 2685, September 1999. [VPN-AUTO] Ould-Brahim, H., et al., "Using BGP as an Auto-Discovery Mechanism for Network-based VPNs", draft-ietf-ppvpn-bgpvpn-auto- 03.txt, work in progress, September 2002. [IKE-V2] Kaufman, C. (editor), et al, ôInternet Key Exchange (IKEv2) Protocolö, draft-ietf-ipsec-ikev2-03.txt, work in progress, October 2002. [VLINK] Duffy, M., ôFramework for IPsec Protected Virtual Links for PPVPNsö, draft-duffy-ppvpn-ipsec-vlink-00.txt, work in progress, October 2002. Acknowledgments Many thanks to Benson Schliesser, as well as to the co-authors of ôNetwork based IP-VPN Architecture Using Virtual Routers,ö who reviewed and commented on this subject. Author's Address Paul Knight Nortel Networks 600 Technology Park Drive Billerica, Massachusetts 01821 USA Phone: +1 978 288 6414 Email: paul.knight@nortelnetworks.com Knight Expires - April 2003 [Page 5]