[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
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