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]