Network Working Group S. Pegrum Internet Draft D. Jamieson Expiration Date: September 1998 M. Yuen Nortel (Northern Telecom) Ltd. March 1998 VPN Multipoint to Multipoint Tunnel Protocol (VMMT) draft-pegrum-vmmt-00.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) 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 VMMT is an protocol for the dynammic distribution of VPN information throughout a shared network, and the automatic formation of multi-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 Message Formats ......................................... 4 5 VPN Configuration Information Distribution .............. 6 Pegrum, et. al. Internet Draft [Page 1] RFC NNNN VMMT Protocol March 1998 5.1 Multicast Enabled Shared Networks ....................... 6 5.2 Non-Multicast Enabled Shared Networks ................... 6 6 Summary ................................................. 6 7 Security Considerations ................................. 7 8 Referneces .............................................. 7 9 Author's Address ........................................ 7 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. 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 VMMT protocol dynamically distributes connection information (tunnel endpoints) between VPN peers throughout a shared network, to allow dynamic establishment of a tunnel. The VPN connection information could include multi-cast information allowing the establishment of multi-point to multi-point tunnels. Each VPN peer (router) belonging to a VPN is identified by a 32 bit VPN identifier (VPNID) that is unique in the shared network, but common to all routers belonging to the VPN. 2. Address Assignment Each VPN peer would have assigned to it one shared IP address and multiple private IP addresses. The shared IP address is used as the source address in all tunnel IP headers. There is also, optionally, a shared IP multi-cast group address which is used to send VPN multicast or broadcast packets to VPN peers . It also has one private address for each interface into the private network, and one for the interface into the shared network. The private IP address for the interface into the shared network will have the same IP subnet value as all VPN peers. 3. Routing Updates Pegrum, et. al. Internet Draft [Page 2] RFC NNNN VMMT Protocol March 1998 No routing information is exchange 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. Pegrum, et. al. Internet Draft [Page 3] RFC NNNN VMMT Protocol March 1998 4. Message Formats The message formats follow standard ICMP type messages. The IP Header is not shown in the diagrams below. VPN ICMP Solicitation 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Addrs | Addr Entry Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Private Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | IP Header Addresses: Destination Address: Shared Network IP Address Source Address: Shared Network IP Address ICMP Fields: Type: VPN Solicitation Type Code: 0 Checksum: 16 bit one's complement of entire message Num VPNs: Number of VPNs contained in this message Addr Entry: Size of message in 32 bit words Pegrum, et. al. Internet Draft [Page 4] RFC NNNN VMMT Protocol March 1998 VPN ICMP Advertisement 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Addrs | Addr Entry Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Private Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Shared Network IP Fields: Destination Address: Shared Network IP Address Source Address: Shared Network IP Address ICMP Fields: Type: VPN Solicitation Type Code: 0 Checksum: 16 bit one's complement of entire message Num VPNs: Number of VPNs contained in this message Addr Entry: Size of message in 32 bit words Pegrum, et. al. Internet Draft [Page 5] RFC NNNN VMMT Protocol March 1998 5. VPN Configuration Information Distribution 5.1 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 then executes an ICMP Router Discovery [1] like protocol on that multicast group. These 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 belonging to this multi-cast group belong to the same VPN. This is intended to guard against configuration errors only. It is assumed that the shared network is secure. New VPN peers joining the multi-cast group immediately issue a VPN ICMP Router Solicitation message to trigger advertisements from other routers on the VPN. This provides immediate configuration feedback to the network operator upon switch reconfiguration, by allowing the VPN peer to compare the VPNID advertised with it's own. In addition, each switch periodically issues a VPN Router Advertisement Message to ensure that the VPN integrity is maintained. The default period for Advertisement Messages is every 10 minutes but the network operator can configure the advertisement rate as appropriate for the network. The VPN peers are now able to communicate with one another through standard routing protocols. VPN broadcast messages traverse shared network as a multicast address so that only entities belonging to that VPN see those messages. ARP entries on VPN peers are refreshed when processing the VPN ICMP Advertisement messages received from other peers. The private address resolves into a shared network unicast address. Unicast VPN messages traverse the shared network as unicast tunnelled messages. 5.2 Non-Multicast Enabled Shared Networks The VMMT distribution mechanism is the same as in the multi-cast enabled case except that the shared destination address is a broadcast address instead of a multicast group address. 6. Summary VMMT addresses several problems: - Dynamic VPN endpoint configuration - Multi-point to Multi-point tunnels. - Security against network operator misconfiguration - Ensures network isolation Pegrum, et. al. Internet Draft [Page 6] RFC NNNN VMMT Protocol March 1998 The VMMT protocol allows for scalable VPN solutions using a common shared infrastructure. 7. Security Considerations This protocol requires the shared network to be secure and trusted. 8. 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 Matthew Yuen Nortel (Northern Telecom), Ltd. PO Box 3511 Station C Ottawa ON K1Y 4H7 Canada EMail: myuen@Nortel.ca Pegrum, et. al. Internet Draft [Page 7] -------------------------------------------------------------------------- Scott Pegrum Nortel Enterprise Networks Phone: (613) 763-2693 Fax: (613) 765-2186 email: spegrum@nortel.ca