One document matched: draft-knight-ppvpn-vr-protocol-00.txt

   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]