Network Working Group Internet Draft J.Halpern Expires: July 2007 Self Huaiyuan Ma Huawei Technologies Co., Ltd January 16, 2007 A VPN Library for use with the ForCES Protocol and Model draft-halpern-forces-lfblibrary-vpn--00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may only be posted in an Internet-Draft. 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 This Internet-Draft will expire on July 16, 2007. Abstract The forwarding and Control Element Separation (ForCES) protocol defines a standard communication and control mechanism through which a Control Element (CE) can control the behavior of a Forwarding Element (FE). That control is accomplished through manipulating Halpern,Ma Expires July 16, 2007 [Page 1] Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt January 2007 attributes of Logical Function Blocks (LFBs), whose structure is defined in a model RFC produced by the working group. In order to build an actual solution based on this protocol, defining a set of Logical Function Block definitions that can be instantiated by FEs and controlled by CEs is welcome. A base library definition of LFBs is already given in library [5]. VPN (Virtual Private Network) services, as a kind of important services widely employed in Internet, will certainly be implemented in routers using this protocol. This document provides an initial set of VPN LFB definitions in particular, a set of tunnel encapsulator and decapsulator LFBs. It is anticipated that additional VPN-related LFB definitions like L2VPN, L3VPN can be defined over time. 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. Table of Contents 1. Introduction................................................3 2. Tunnel Definitions..........................................3 2.1. GRE Tunnel Definitions.................................3 3. Security Considerations.....................................11 4. Acknowledgments.............................................11 5. References..................................................11 5.1. Normative References...................................11 5.2. Informative References.................................12 Author's Addresses.............................................12 Intellectual Property Statement................................12 Disclaimer of Validity.........................................13 Copyright Statement............................................13 Acknowledgment.................................................13 Halpern,Ma Expires July 16, 2007 [Page 2] Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt January 2007 1. Introduction In a solution using ForCES protocol, Control Elements (CEs) can control the behavior of Forwarding Elements (FEs) through manipulating attributes of Logical Function Blocks (LFBs). LFB's structure and abstract semantics is defined in Model [6]. That document also defines a single LFB Class for gaining access to FE properties including the set of LFBs and their interconnection. A LFB class is defined to manipulate the protocol properties of the FE in the protocol [4]. In I-D draft [5], a set of LFBs which are necessary to implement basic forwarding process are defined. This draft is intended to define an initial set of LFBs for a kind of important Internet service, Virtual Private Network (VPN). It is expected that other VPN-related definitions will be developed over time. 2. Tunnel Definitions 2.1. GRE Tunnel Definitions GRE tunnel specification and its extension are described in RFC 2784 and RFC 2890 respectively. A GRE tunnel is composed of three parts: outer delivery header, followed by a GRE header which is followed by a payload packet. The format of outer delivery header is determined by the corresponding delivery protocol, IPv4 or IPv6. In GRE header, there are two important optional fields: one is called GRE key which is intended to be used for identifying an individual traffic flow within a tunnel; the other is called Sequence Number, the Sequence Number MUST be used by the receiver to establish the order in which packets have been transmitted from the encapsulator to the receiver. The intended use of the Sequence Field is to provide unreliable but in-order delivery. The payload packet would be IPv4, IPv6 etc. When forwarding an IP packet in a next-hop applicator LFB, the matched FIB entry indicates the packet should be transmitted over a GRE tunnel and a correct tunnel index can be found out in the FIB entry. The original packet will be fed to GRE tunnel encapsulator with tunnel index as meta-data together in the downstream forwarding process. Tunnel index points to the correct tunnel entry in tunnel configuration table which stores the information of each tunnel. Each Halpern,Ma Expires July 16, 2007 [Page 3] Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt January 2007 tunnel entry maintains a management flag called "TunnelState" indicating whether the current tunnel is administratively up. GRE tunnel maintains a fragmentation permitted flag. Before encapsulating a payload packet GRE tunnel encapsulator will check the size of that payload packet against MTU. If the size of tunnelled packet is larger than MTU and at this moment that fragmentation permitted flag should be checked, if that flag is set, then chop the original packet into small packets with appropriate size, otherwise, send ICMP message to notify the appropriate receiver of some error. If the delivery protocol is IPv4, then the format of outer delivery header would be IPv4, otherwise, it would be IPv6. Once a IP packet with GRE is produced from an output port from GRE tunnel encapsulator, a meta-data called "NextHopReference" which points to the index of correct FIB entry is accompanied at the same time, that is, an alias entry pointing to the next-hop table so that it can use the predetermined route to the tunnel end-point. When a classifier LFB identifies the incoming packet is an IP packet with GRE at the GRE tunnel exit point, it will feed that packet to the GRE tunnel decapsulator, which will find out the correct tunnel index which maintains a local VPN ID field, the GRE tunnel decapsulator then strips off the outer delivery header and GRE header and feed it to the forwarding-related LFB with local index ID as meta-data indicating which VPN that payload packet belongs to. The actual GRE tunnel LFB class is defined as below. NextHopIndex An index used by the next hop table. Typically stored in and generated as metadata by the longest-prefix-match LFB int32 Halpern,Ma Expires July 16, 2007 [Page 4] Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt January 2007 VPNID An ID used to provide context for VPN specific Packet processing. int32 GRETunnelTableType GRE tunnel configuration table Each table entry describes a single GRE tunnel. The table Index is input meta-data for the encapsulator. TunnelValid It is enabled or disabled by FIB indicating whether the current tunnel is permitted to be used in forwarding process. boolean FragmentationPermitted it indicates whether it permits fragmentation when the size of a packet exceeds the tunnel's MTU. boolean ChecksumNeeded it indicates whether a checksum is needed. boolean Halpern,Ma Expires July 16, 2007 [Page 5] Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt January 2007 PacketType ...needs definition ... ... probably for decapsulator error checking? ... SrcAddr IP Address for local end of tunnel IPAddress DstAddr Address for remote End of Tunnel IPAddress GREKey Key for this specific GRE Tunnel The presence of this element indicate this tunnel uses keyed GRE format. int32 NextHopReference Reference to the correct NextHopIndex This points to a LPM where the next hop is maintained. The information is put in the encapsulator meta-data. NextHopIndex MTU Maximum Transmit Unit Used in conjunction with the flags to decide if large packets should be encapsulated, fragmented, or errored. uint32 Halpern,Ma Expires July 16, 2007 [Page 6] Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt January 2007 LocalVPNID VPN ID used by decapsulator as generated meta-data VPNID TunnelState It indicates whether the current tunnel is administratively up or down. Boolean SequencingNeeded it indicates whether a sequence field to differentiate different traffic flows in a tunnel is needed. boolean SequenceNumber a sequence field to differentiate different traffic flows in a tunnel. int32 Checksum The Checksum field contains the IP (one's complement) checksum sum of the all the 16 bit words in the GRE header and the payload packet. int16 Halpern,Ma Expires July 16, 2007 [Page 7] Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt January 2007 GRE_Encapsulator It specifies how to encapsulate an IP packet so that it can be transmitted over GRE tunnel. 0.0 PacketIn Normal packet in. IPv4 IPv6 Tunnel_Index PacketOut IP packet with GRE GREFrame NextHopReference FailOutput error prompt information to indicate whether some operations like fragmentation are Halpern,Ma Expires July 16, 2007 [Page 8] Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt January 2007 permitted. taggedFrame errorid GRETunnelTable Table of GRE Tunnels supported by this encapsulator GRETunnelTableType when fowarding a IP packet, a matching FIB entry has a GRE tunnel flag which indicates it should be transmitted over a GRE tunnel, then according to the constrains, TTL, MTU, fragmentation flag etc in the GRE tunnel entry to encapsulate a IP packet in its payload part. GRE_Decapsulator It specifies the procedure how to decapsulate a tunnelled packet. 0.0 PacketIn A IP packet with GRE. Halpern,Ma Expires July 16, 2007 [Page 9] Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt January 2007 GREFrame PacketOut original packet output IPv4 IPv6 LocalVPNID FailOutput error prompt information generated when a GRE packet cannot match a GRE tunnel state taggedFrame errorid GRETunnelTable Reference to the GRE Tunnel Table this decapsulator uses Halpern,Ma Expires July 16, 2007 [Page 10] Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt January 2007 which is stored in the corresponding encapsulator. GRETunelTableType Once the classifier has determined the content of an incoming packet is GRE, it will be fed to a GRE decapsulator, which can achieve the local VPN ID to which the packet belongs and strip off the outer IP header and GRE shim, at the same time, treat local VPN ID as meta- data and then feed it and original packet to the down-stream LFBs. 3. Security Considerations These definitions if used by an FE to support ForCES create manipulable entities on the FE, Manipulation of such objects can produce almost unlimited effects on the FE. FEs should ensure that only properly authenticated ForCES protocol participants are performing such manipulations. Thus, largely, the security issues with this protocol are defined in Protocol [2]. 4. Acknowledgments Thanks Zengjie,Kou for providing some comments. 5. References 5.1. Normative References [1] Khosravi, et al. Requirements for Separation of IP Control and Forwarding, RFC 3654, November 2003. [2] L. Yang, et al. ForCES Architectural Framework, RFC 3746, April 2004. Halpern,Ma Expires July 16, 2007 [Page 11] Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt January 2007 [3] Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., and S. Blake, "ForCES Forwarding Element Model", Feb. 2005. [4] A. Doria, et al. ForCES Protocol Specification, draft-ietf- forces- protocol-06.txt, December 2005. [5] Joel M.Halpern, A base Library for use with the ForCES Protocol and Model, draft-halpern-forces-lfblibrary-base-01.txt, March, 2006 [6] L.Yang, et al. ForCES Forwarding Element Model, draft-ietf- forces-model-06.txt 5.2. Informative References Author's Addresses Joel M. Halpern Self P. O. Box 6049 Leesburg, VA 20178 US Huanyuan Ma Huawei Technologies Co., Ltd mahuaiyuan@huawei.com Zengjie Kou Huawei Technologies Co., Ltd kouzengjie@huawei.com Intellectual Property Statement The IETF 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 this 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. Information Halpern,Ma Expires July 16, 2007 [Page 12] Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt January 2007 on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR 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 this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Halpern,Ma Expires July 16, 2007 [Page 13]