Internet Draft Network Working Group S. Pegrum Internet Draft D. Jamieson Expiration Date: February 1999 M. Yuen A. Celer Nortel (Northern Telecom) Ltd. August 1998 VPN Point to Multipoint Tunnel Protocol (VPMT) draft-pegrum-vmmt-01.txt Status of this Memo This document is 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'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast) This draft obsoletes draft-pegrum-vmmt-00.txt Abstract For many carrier's, the implementation of Virtual Private Network (VPN) services using current IP Tunneling technology is problematic because of onerous configuration requirements. The VPMT is an protocol for the dynammic distribution of VPN information throughout a shared network, which in turn allows the automatic formation of point to multi-point tunnels between VPN routers. The method described in this internet draft is intended for single AS where the AS administrator is a trusted third party. Traffic seperation is maintained between VPNs. Table of Contents 1 Introduction ............................................ 2 1.1 Terminology ............................................. 2 2 Address Assignment ...................................... 2 3 Routing Updates ......................................... 3 4 VPN Peer Discovery....................................... 4.1 VPN Peer Discovery Algorithm............................. Pegrum, et. al. Internet Draft [Page 1] RFC NNNN VPMT Protocol August 1998 4.2 Multicast Enabled Shared Networks........................ 4.3 Non-Multicast Enabled Shared Networks.................... 5 Peer Connectivity........................................ 6 Peer Discovery Using ICMP Messages....................... 6.1 Message Formats ......................................... 4 6.2 IPv6 Compliance.......................................... 6 7 Summary ................................................. 8 Security Considerations ................................. 9 References .............................................. 10 Author's Address ........................................ 1. Introduction For the purposes of this document, a VPN shall be considered to consist of a grouping of private routers that use a shared tunneled backbone. It is assumed that multiple VPNs use the shared backbone. Private routers that are members of the same VPN form a peer group. The members of the peer group communicate with each other over a logical shared broadcast medium which is actually the tunnelled backbone simulating a shared broadcast medium for each VPN peer group. In common tunnel implementations, tunnels are point to point connections where the endpoints are statically configured by the network operator. The VPMT protocol dynamically distributes connection information (tunnel endpoints) between VPN peers throughout a shared network, to allow dynamic establishment of a point to multi-point tunnels. The VPN connection information could include multi-cast information allowing the establishment of multi-point to multi-point tunnels. Each VPN is identified by a 32 bit VPN identifier (VPNID) that is unique in the shared network, but common to all the routers which belong to the same VPN. Suggested format of the VPNID is 16 bits of AS number and 16 bits VPN number. It is assumed that VPN does not cross boundaries of the AS. Each VPN peer (router) belonging to a VPN is identified by a 32 bit peer VPN identifier (PEERID) that is unique in the private network, but does not have to be unique in the shared network. This information is not propagated in the network. The VPN peer connectivity is achieved in two steps: * discovering the peers in the shared network * establishment of communication channels between peers Pegrum, et. al. Internet Draft [Page 2] RFC NNNN VPMT Protocol August 1998 This protocol deals with the dynamic VPN peer discovery in shared network. Suggestions on how to establish the communication channels between peers are given in Section 5. 1.1 Terminology There is no new terminology introduced by this draft. 2. Address Assignment Each VPN peer would have assigned a number of addresses as following: * IP address in shared network - In case of non-multicast enabled shared network this address is to be used as a source or destination address in all VPN peer discovery messages. In case of the multicast enabled network it is the group multicast address to which the VPN peer belongs. This address can also be used to establish VPN peer to peer communication channels, if it is not-multicast address. * IP address in shared network - (optional) This address is being used to establish communication channels between VPN peers, if the VPMT messaging is isolated from the VPN data traffic. * multiple private IP addresses - These addresses are used to establish configuration of the private address space (network). The tunnel is not established between two end-points if advertised private interfaces do not belong to the same sub-net. There has to be at least one private address assigned to the VPN peer. 3. Routing Updates No routing information is exchanged between the shared and private networks. Routing updates from the shared network are blocked and not transmitted into the private networks. Conversely, private network updates, even though they are tunnelled across the shared network, are not transmitted into the shared network routing domain. Pegrum, et. al. Internet Draft [Page 3] RFC NNNN VPMT Protocol August 1998 The VPN peer processes only routing information received from the peer which belong to the same VPNID. 4. VPN Peer Discovery The VPMT protocol allows VPN peer discovery to run in multicast and non-multicast enabled networks. New VPN peers joining the VPN immediately issues a VPN Peer Solicitation message to trigger advertisements from other routers on the VPN. In addition, each VPN router periodically issues a VPN Advertisement Message to ensure that VPN integrity is maintained Advertisements are not meant to provide blackhole detection. The Layer 2 tunnel protocol and the VPN routing protocol provide blackhole detection. After discovering VPN peers connectivity between them is established. The VPN peer configuration information is used by the implemented Layer 2 Tunneling protocol to establish connectivity between VPN peers. The Layer 2 tunneling protocol carries full responsiblity of management of setting-up and tearing down peer connectivity. ARP entries on VPN peers are refreshed when processing the VPN Advertisement messages received from VPN peers. 4.1 VPN Peer Discovery Algorithm The algorithm for discovering peers in the shared network for both multicast and non-multicast enabled networks is the same. Step 1. Provision set of addresses specified in Section 2 for the VPN peer, and unique VPNID for the VPN . Provision the following: 1) for multicast enabled networks - multicast address where solicitation and advertisement message are sent 2) for non-multicast enabled networks - provision set of known addresses where the solicitation and advertisement message are sent. This draft does not deal with the automatic discovery of carrier network configuration for non-multicast enabled networks. Pegrum, et. al. Internet Draft [Page 4] RFC NNNN VPMT Protocol August 1998 Step 2. When VPN peer joins the shared network it issues the VPN Solicitation Message which includes the full information about the peer. This message is sent to known address(es). The acknowledgement to that message comes in the form of a VPN Advertisement Message which contains remote VPN peer configuration data. Step 3. On receiving of the VPN Advertisement Message, the following checks are performed: 1) VPNID is checked; in case that the VPNID of the remote peer does not match VPNID of the receiver, the message is not processed 2) each private (address, mask) pair is compared with own private (address, mask) pair; for private interfaces that belong to the same sub-net, the connectivity can be eastablished . The method of setting up-the connectivity depends on the Layer 2 tunneling implementation 3) in case that the peer connectivity is to be established, the shared address of the peer is stored It is an implementation detail if the shared address of the peer should be stored in case that the private interfaces do not belong to the same sub-net. Step 4. If the VPN peer does not receive any responses for its VPN Solicitation Message, the message is periodically re-sent. The value of the period is provisionable and set by the network administrator. If peer connectivity is established, the VPN Solicitation message will not be resent. Step 5. VPN Advertisement message is sent in two scenarios: 1) as a reply to the peer VPN Solicitation Message 2) periodically sent to known multicast address or set of known destinations An algorithm to change the advertisement frequency can be implemented in order to lower the requirements on the bandwidth for the messages in stable carier network. The frequency of updates is indicated in the advertisement message generated by the VPN peer. Pegrum, et. al. Internet Draft [Page 5] RFC NNNN VPMT Protocol August 1998 Step 6. If the VPN peer disconnects from the network, no action is performed. It is up to Layer 2 tunneling protocol to tear down the connection. 4.2 Multicast Enabled Shared Networks In multicast enabled shared networks, each VPN peer is required to join the multicast group that is provisioned for its associated VPN. After joining the multicast group, the VPN peer executes a VPN Peer Router Discovery protocol described in Section 4.1 on that multicast group. The messages are a combination of VPN discovery and address resolution. The VPN discovery is meant to be a security measure to ensure that all routers that belong to this multi-cast group belong to the same VPN (have the same VPNID). This is intended to guard against configuration errors only. It is assumed that the shared network is secure. After discovering a VPN peer, the connectivity between them is established by the layer 2 tunneling protocol. 4.3 Non-Multicast Enabled Shared Networks In non-multicast enabled shared networks, the VPN peer discovery algorithm descibed in Section 4.1 is used. The destination address to send the VPN Solicitation and Advertisement Message can be one of the following: * broadcast address instead of a multicast group address * set of known unicast addresses If the broadcast address is being used, the limit on the number of broadcast addresses in the network may impose additional VPN peer discovery message processing in order to separate peer configuration data. In this case it is advisable to use separate IP address to establish communication channels between VPN peers. If the set of unicast addresses is being used, the originating VPN peer would push VPN Solicitation and Advertisement messages to all known destinations. The further refinement of the protocol is an implementation concern. To propagate peer discovery information in the network the following methods can be used: 1. ICMP messages Pegrum, et. al. Internet Draft [Page 6] RFC NNNN VPMT Protocol August 1998 2. OPAQUE LSAs 3. TCP connection established between known destinations 4. use of multicast addresses in the network In Section 6, an example using the ICMP message implementation is given. 5. Peer Conectivity Peer connectivity phase is responsible for the following: 1) in case that connectivity between peers can be established (same VPNID and interface(s) belong to the same sub-net(s), it handles all actions necessary to create tunnel via carrier backbone (network) 2) in case that connectivity between peers cannot exist anymore, it carries all actions necessary to remove the tunnel via carrier backbone (network) 3) based on the layer 2 media used to esatblish peer connectivity, there can be periodical verification of the tunnel state. This functionality is separate from VPN Peer Discovery phase. The communication of data between VPN peers througout carrier network can be carried using separate layer 2 media. The following methods of encapsulating VPN data can be used: 1. IP in IP tunnel 2. MPLS 4. IPSec 5. Frame Relay SVCs This draft does not discuss the options of the peer connectivity establishement and maintenance. 6. Peer Discovery Using ICMP Messages In this section, the example is given on the use of the ICMP Peer Discovery message to identify VPN peers in order to set-up the connections between them. A new message type is being proposed, which includes all necessary data to identify the peer and set-up the connection. 6.1 Message Formats The message formats follow standard ICMP type messages. The IP Header is not shown in the diagrams below. The VPMT protocol proposes to define new ICMP message type VPN Peer Pegrum, et. al. Internet Draft [Page 7] RFC NNNN VPMT Protocol August 1998 Discovery for messages to dynamically discover VPN peers. For the VPN ICPM Peer Discovery message the following codes are assigned: * 1 - VPN solicitation message; this message will invoke the VPN Adverisement message to be sent by the receiving router * 2 - VPN advertisement message; this message is not acknowledged in any way by the receiving router The VPN ICMP Peer Discovery message format includes VPN configuration information. The diagram below illustrates the message format for IPv4 only addresses. VPN ICMP Peer Discovery Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|P| Num Interfaces | Addr Entry Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh Time | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Private Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Private Address Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + IP Header Addresses: Destination Address: Shared Network IP Address of the VPN peer; in case of the multicast enabled network it is the group multicast address to which the VPN peer belongs Source Address: Shared Network IP Address of the VPN peer ICMP Fields: Type: VPN ICMP Peer Discovery Code: value {1, 2}; where: 1 - VPN Solicitation Message Pegrum, et. al. Internet Draft [Page 8] RFC NNNN VPMT Protocol August 1998 2 - VPN Advertisement Message Checksum: 16 bit one's complement of entire message S (shared) 1 bit format of the shared address: 0 - complies with IPv4 1 - complies with IPv6 P (private) 1 bit format of the private (address,mask) pair: 0 - complies with IPv4 1 - complies with IPv6 Num Interfaces: 14 bit containing number of VPN private interfaces included in this message; interface is desfined by (address, mask) pair Addr Entry: Size of (address,mask) pair in 32 bit words VPN Identifier: 32 bits containing VPNID shared between VPN peers Refresh Time: 2 bytes of refresh time interval in seconds Reserved: 2 bytes Shared address: VPN peer address in the shared network this address may differ from the source address in IP header. This address specifies communication channel end-point on the source VPN peer. Private Address: IP address of the interface to the private network Private Address Mask: mask associated with the IP address of the interface to the private network 6.2 IPv6 Compliance The VPMT protocol can be used in IPv6 . The message format remains the same with respect to fields, however the size of the following fields will, optionally, expand from 32 bits to 128 bits: * Shared address * Private address * Prefix length for the private address mask The following fields in the ICMP Peer Discovery message will be used to specify the format of the address and appropriate mask: * shared : 0 - IPv4 format 1 - IPv6 format * private : 0 - IPv4 format 1 - IPv6 format The behaviour of the protocol remains unchanged. Pegrum, et. al. Internet Draft [Page 9] RFC NNNN VPMT Protocol August 1998 7. Summary VPMT addresses several problems: - Dynamic VPN endpoint configuration - Support of Multi-point to Multi-point tunnels - Security against network operator misconfiguration - Ensures private network isolation The VPMT protocol allows for scalable VPN solutions using a common shared infrastructure. 8. Security Considerations This protocol requires the shared network to be secure and trusted. The method is intended for a single AS where the AS administrator is a trusted third party. 9. References [1] S. Deering, Editor, "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991 [2] S. Hanks et al., "Generic Router Encapsulation", RFC 1701, NetSmiths Ltd & Cisco Systems, October 1994 9. Author's Address Scott Pegrum Nortel (Northern Telecom), Ltd. PO Box 3511 Station C Ottawa ON K1Y 4H7 Canada EMail: spegrum@Nortel.ca Dwieght Jamieson Nortel (Northern Telecom), Ltd. PO Box 3511 Station C Ottawa ON K1Y 4H7 Canada EMail: djamies@Nortel.ca Pegrum, et. al. Internet Draft [Page 10] RFC NNNN VPMT Protocol August 1998 Matthew Yuen Nortel (Northern Telecom), Ltd. PO Box 3511 Station C Ottawa ON K1Y 4H7 Canada EMail: myuen@Nortel.ca Alicja B. Celer Nortel (Northern Telecom), Ltd. PO Box 3511 Station C Ottawa ON K1Y 4H7 Canada EMail: aceler@nortel.ca Pegrum, et. al. Internet Draft [Page 11]