idnits 2.17.1 draft-pegrum-vmmt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 40 has weird spacing: '...t draft is in...' == Line 189 has weird spacing: '...itation and a...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9378 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '2' is mentioned on line 466, but not defined == Unused Reference: '1' is defined on line 465, but no explicit reference was found in the text Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Pegrum 3 Internet Draft D. Jamieson 4 Expiration Date: February 1999 M. Yuen 5 A. Celer 6 Nortel (Northern Telecom) Ltd. 7 August 1998 9 VPN Point to Multipoint Tunnel Protocol (VPMT) 10 draft-pegrum-vmmt-01.txt 12 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast) 29 This draft obsoletes draft-pegrum-vmmt-00.txt 31 Abstract 33 For many carrier's, the implementation of Virtual Private Network 34 (VPN) services using current IP Tunneling technology is problematic 35 because of onerous configuration requirements. The VPMT is an 36 protocol for the dynammic distribution of VPN information throughout 37 a shared network, which in turn allows the automatic formation of 38 point to multi-point tunnels between VPN routers. 40 The method described in this internet draft is intended for single 41 AS where the AS administrator is a trusted third party. Traffic 42 seperation is maintained between VPNs. 44 Table of Contents 46 1 Introduction ............................................ 2 47 1.1 Terminology ............................................. 2 48 2 Address Assignment ...................................... 2 49 3 Routing Updates ......................................... 3 50 4 VPN Peer Discovery....................................... 51 4.1 VPN Peer Discovery Algorithm............................. 53 RFC NNNN VPMT Protocol August 1998 55 4.2 Multicast Enabled Shared Networks........................ 56 4.3 Non-Multicast Enabled Shared Networks.................... 57 5 Peer Connectivity........................................ 58 6 Peer Discovery Using ICMP Messages....................... 59 6.1 Message Formats ......................................... 4 60 6.2 IPv6 Compliance.......................................... 6 61 7 Summary ................................................. 62 8 Security Considerations ................................. 63 9 References .............................................. 64 10 Author's Address ........................................ 66 1. Introduction 68 For the purposes of this document, a VPN shall be considered to 69 consist of a grouping of private routers that use a shared tunneled 70 backbone. It is assumed that multiple VPNs use the shared backbone. 72 Private routers that are members of the same VPN form a peer group. 73 The members of the peer group communicate with each other over a 74 logical shared broadcast medium which is actually the tunnelled 75 backbone simulating a shared broadcast medium for each VPN peer 76 group. 78 In common tunnel implementations, tunnels are point to point 79 connections where the endpoints are statically configured by the 80 network operator. The VPMT protocol dynamically distributes 81 connection information (tunnel endpoints) between VPN peers 82 throughout a shared network, to allow dynamic establishment of a 83 point to multi-point tunnels. The VPN connection information could 84 include multi-cast information allowing the establishment of 85 multi-point to multi-point tunnels. 87 Each VPN is identified by a 32 bit VPN identifier (VPNID) that is 88 unique in the shared network, but common to all the routers which 89 belong to the same VPN. Suggested format of the VPNID is 16 bits of 90 AS number and 16 bits VPN number. It is assumed that VPN does not 91 cross boundaries of the AS. 93 Each VPN peer (router) belonging to a VPN is identified by a 32 bit 94 peer VPN identifier (PEERID) that is unique in the private network, 95 but does not have to be unique in the shared network. This 96 information is not propagated in the network. 98 The VPN peer connectivity is achieved in two steps: 99 * discovering the peers in the shared network 100 * establishment of communication channels between peers 102 RFC NNNN VPMT Protocol August 1998 104 This protocol deals with the dynamic VPN peer discovery in shared 105 network. Suggestions on how to establish the communication channels 106 between peers are given in Section 5. 108 1.1 Terminology 110 There is no new terminology introduced by this draft. 112 2. Address Assignment 114 Each VPN peer would have assigned a number of addresses as following: 116 * IP address in shared network - 117 In case of non-multicast enabled shared network 118 this address is to be used as a source or destination 119 address in all VPN peer discovery messages. 120 In case of the multicast enabled network 121 it is the group multicast address to which the VPN 122 peer belongs. 123 This address can also be used to establish VPN 124 peer to peer communication channels, if it is 125 not-multicast address. 127 * IP address in shared network - (optional) 128 This address is being used to establish communication 129 channels between VPN peers, if the VPMT messaging is 130 isolated from the VPN data traffic. 132 * multiple private IP addresses - 133 These addresses are used to establish configuration 134 of the private address space (network). 135 The tunnel is not established between two end-points 136 if advertised private interfaces do not belong to the 137 same sub-net. 138 There has to be at least one private address assigned 139 to the VPN peer. 141 3. Routing Updates 143 No routing information is exchanged between the shared and private 144 networks. Routing updates from the shared network are blocked and 145 not transmitted into the private networks. Conversely, private 146 network updates, even though they are tunnelled across the shared 147 network, are not transmitted into the shared network routing domain. 149 RFC NNNN VPMT Protocol August 1998 151 The VPN peer processes only routing information received from the 152 peer which belong to the same VPNID. 154 4. VPN Peer Discovery 156 The VPMT protocol allows VPN peer discovery to run in multicast 157 and non-multicast enabled networks. 159 New VPN peers joining the VPN immediately issues a VPN Peer 160 Solicitation message to trigger advertisements from other routers 161 on the VPN. In addition, each VPN router periodically issues a 162 VPN Advertisement Message to ensure that VPN integrity is maintained 163 Advertisements are not meant to provide blackhole detection. 164 The Layer 2 tunnel protocol and the VPN routing protocol provide 165 blackhole detection. 167 After discovering VPN peers connectivity between them is established. 168 The VPN peer configuration information is used by the implemented 169 Layer 2 Tunneling protocol to establish connectivity between VPN 170 peers. The Layer 2 tunneling protocol carries full responsiblity of 171 management of setting-up and tearing down peer connectivity. 173 ARP entries on VPN peers are refreshed when processing the VPN 174 Advertisement messages received from VPN peers. 176 4.1 VPN Peer Discovery Algorithm 178 The algorithm for discovering peers in the shared network for both 179 multicast and non-multicast enabled networks is the same. 181 Step 1. 182 Provision set of addresses specified in Section 2 for the VPN peer, 183 and unique VPNID for the VPN . 185 Provision the following: 186 1) for multicast enabled networks - multicast address where 187 solicitation and advertisement message are sent 188 2) for non-multicast enabled networks - provision set of known 189 addresses where the solicitation and advertisement message 190 are sent. 192 This draft does not deal with the automatic discovery of carrier 193 network configuration for non-multicast enabled networks. 195 RFC NNNN VPMT Protocol August 1998 197 Step 2. 198 When VPN peer joins the shared network it issues the VPN 199 Solicitation Message which includes the full information about the 200 peer. This message is sent to known address(es). 201 The acknowledgement to that message comes in the form of a VPN 202 Advertisement Message which contains remote VPN peer configuration 203 data. 205 Step 3. 206 On receiving of the VPN Advertisement Message, the following checks 207 are performed: 208 1) VPNID is checked; in case that the VPNID of the remote peer 209 does not match VPNID of the receiver, the message is not 210 processed 211 2) each private (address, mask) pair is compared with own 212 private (address, mask) pair; for private interfaces 213 that belong to the same sub-net, the connectivity 214 can be eastablished . The method of setting up-the 215 connectivity depends on the Layer 2 tunneling implementation 216 3) in case that the peer connectivity is to be established, 217 the shared address of the peer is stored 219 It is an implementation detail if the shared address of the 220 peer should be stored in case that the private interfaces 221 do not belong to the same sub-net. 223 Step 4. 224 If the VPN peer does not receive any responses for its VPN 225 Solicitation Message, the message is periodically re-sent. 226 The value of the period is provisionable and set by the network 227 administrator. 229 If peer connectivity is established, the VPN Solicitation message 230 will not be resent. 232 Step 5. 233 VPN Advertisement message is sent in two scenarios: 234 1) as a reply to the peer VPN Solicitation Message 235 2) periodically sent to known multicast address or set of 236 known destinations 238 An algorithm to change the advertisement frequency can be 239 implemented in order to lower the requirements on the bandwidth 240 for the messages in stable carier network. The frequency of updates 241 is indicated in the advertisement message generated by the VPN 242 peer. 244 RFC NNNN VPMT Protocol August 1998 246 Step 6. 247 If the VPN peer disconnects from the network, no action 248 is performed. It is up to Layer 2 tunneling protocol to tear 249 down the connection. 251 4.2 Multicast Enabled Shared Networks 253 In multicast enabled shared networks, each VPN peer is required to 254 join the multicast group that is provisioned for its associated VPN. 256 After joining the multicast group, the VPN peer executes a VPN Peer 257 Router Discovery protocol described in Section 4.1 on that multicast 258 group. 260 The messages are a combination of VPN discovery and address 261 resolution. The VPN discovery is meant to be a security measure to 262 ensure that all routers that belong to this multi-cast group belong 263 to the same VPN (have the same VPNID). This is intended to guard 264 against configuration errors only. It is assumed that the shared 265 network is secure. 267 After discovering a VPN peer, the connectivity between them is 268 established by the layer 2 tunneling protocol. 270 4.3 Non-Multicast Enabled Shared Networks 272 In non-multicast enabled shared networks, the VPN peer discovery 273 algorithm descibed in Section 4.1 is used. 274 The destination address to send the VPN Solicitation and 275 Advertisement Message can be one of the following: 276 * broadcast address instead of a multicast group address 277 * set of known unicast addresses 279 If the broadcast address is being used, the limit on the number of 280 broadcast addresses in the network may impose additional VPN peer 281 discovery message processing in order to separate peer configuration 282 data. In this case it is advisable to use separate IP address to 283 establish communication channels between VPN peers. 285 If the set of unicast addresses is being used, the originating 286 VPN peer would push VPN Solicitation and Advertisement messages to 287 all known destinations. The further refinement of the protocol is an 288 implementation concern. 290 To propagate peer discovery information in the network the following 291 methods can be used: 292 1. ICMP messages 294 RFC NNNN VPMT Protocol August 1998 296 2. OPAQUE LSAs 297 3. TCP connection established between known destinations 298 4. use of multicast addresses in the network 300 In Section 6, an example using the ICMP message implementation is 301 given. 303 5. Peer Conectivity 305 Peer connectivity phase is responsible for the following: 306 1) in case that connectivity between peers can be established 307 (same VPNID and interface(s) belong to the same sub-net(s), it 308 handles all actions necessary to create tunnel via carrier 309 backbone (network) 310 2) in case that connectivity between peers cannot exist anymore, 311 it carries all actions necessary to remove the tunnel via 312 carrier backbone (network) 313 3) based on the layer 2 media used to esatblish peer connectivity, 314 there can be periodical verification of the tunnel state. This 315 functionality is separate from VPN Peer Discovery phase. 317 The communication of data between VPN peers througout carrier network 318 can be carried using separate layer 2 media. The following methods 319 of encapsulating VPN data can be used: 320 1. IP in IP tunnel 321 2. MPLS 322 4. IPSec 323 5. Frame Relay SVCs 325 This draft does not discuss the options of the peer connectivity 326 establishement and maintenance. 328 6. Peer Discovery Using ICMP Messages 330 In this section, the example is given on the use of the ICMP Peer 331 Discovery message to identify VPN peers in order to set-up the 332 connections between them. A new message type is being proposed, 333 which includes all necessary data to identify the peer and set-up the 334 connection. 336 6.1 Message Formats 338 The message formats follow standard ICMP type messages. The IP 339 Header is not shown in the diagrams below. 341 The VPMT protocol proposes to define new ICMP message type VPN Peer 343 RFC NNNN VPMT Protocol August 1998 345 Discovery for messages to dynamically discover VPN peers. 346 For the VPN ICPM Peer Discovery message the following codes are 347 assigned: 348 * 1 - VPN solicitation message; this message will invoke the 349 VPN Adverisement message to be sent by the receiving 350 router 351 * 2 - VPN advertisement message; this message is not acknowledged 352 in any way by the receiving router 354 The VPN ICMP Peer Discovery message format includes VPN configuration 355 information. 357 The diagram below illustrates the message format for IPv4 only 358 addresses. 360 VPN ICMP Peer Discovery Message 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Type | Code | Checksum | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 |S|P| Num Interfaces | Addr Entry Size | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | VPN Identifier | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Refresh Time | Reserved | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Shared Address | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Private Address | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Private Address Mask | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 + + 381 IP Header Addresses: 382 Destination Address: Shared Network IP Address of the VPN peer; 383 in case of the multicast enabled network 384 it is the group multicast address to which 385 the VPN peer belongs 386 Source Address: Shared Network IP Address of the VPN peer 388 ICMP Fields: 389 Type: VPN ICMP Peer Discovery 390 Code: value {1, 2}; where: 391 1 - VPN Solicitation Message 393 RFC NNNN VPMT Protocol August 1998 395 2 - VPN Advertisement Message 396 Checksum: 16 bit one's complement of entire message 397 S (shared) 1 bit format of the shared address: 398 0 - complies with IPv4 399 1 - complies with IPv6 400 P (private) 1 bit format of the private (address,mask) 401 pair: 402 0 - complies with IPv4 403 1 - complies with IPv6 404 Num Interfaces: 14 bit containing number of VPN private 405 interfaces included in this message; 406 interface is desfined by (address, mask) 407 pair 409 Addr Entry: Size of (address,mask) pair in 32 bit words 410 VPN Identifier: 32 bits containing VPNID shared between 411 VPN peers 412 Refresh Time: 2 bytes of refresh time interval in seconds 413 Reserved: 2 bytes 414 Shared address: VPN peer address in the shared network 415 this address may differ from the source 416 address in IP header. This address specifies 417 communication channel end-point on the source 418 VPN peer. 419 Private Address: IP address of the interface to the private 420 network 421 Private Address Mask: mask associated with the IP address of the 422 interface to the private network 424 6.2 IPv6 Compliance 426 The VPMT protocol can be used in IPv6 . The message format remains 427 the same with respect to fields, however the size of the following 428 fields will, optionally, expand from 32 bits to 128 bits: 429 * Shared address 430 * Private address 431 * Prefix length for the private address mask 433 The following fields in the ICMP Peer Discovery message will be used 434 to specify the format of the address and appropriate mask: 435 * shared : 436 0 - IPv4 format 437 1 - IPv6 format 438 * private : 439 0 - IPv4 format 440 1 - IPv6 format 442 The behaviour of the protocol remains unchanged. 444 RFC NNNN VPMT Protocol August 1998 446 7. Summary 448 VPMT addresses several problems: 449 - Dynamic VPN endpoint configuration 450 - Support of Multi-point to Multi-point tunnels 451 - Security against network operator misconfiguration 452 - Ensures private network isolation 454 The VPMT protocol allows for scalable VPN solutions using a common 455 shared infrastructure. 457 8. Security Considerations 459 This protocol requires the shared network to be secure and trusted. 461 The method is intended for a single AS where the AS administrator 462 is a trusted third party. 464 9. References 465 [1] S. Deering, Editor, "ICMP Router Discovery Messages", RFC 1256, 466 Xerox PARC, September 1991 [2] S. Hanks et al., "Generic Router 467 Encapsulation", RFC 1701, NetSmiths Ltd & Cisco Systems, October 468 1994 470 9. Author's Address 472 Scott Pegrum 473 Nortel (Northern Telecom), Ltd. 474 PO Box 3511 Station C 475 Ottawa ON K1Y 4H7 476 Canada 478 EMail: spegrum@Nortel.ca 480 Dwieght Jamieson 481 Nortel (Northern Telecom), Ltd. 482 PO Box 3511 Station C 483 Ottawa ON K1Y 4H7 484 Canada 486 EMail: djamies@Nortel.ca 488 RFC NNNN VPMT Protocol August 1998 490 Matthew Yuen 491 Nortel (Northern Telecom), Ltd. 492 PO Box 3511 Station C 493 Ottawa ON K1Y 4H7 494 Canada 496 EMail: myuen@Nortel.ca 498 Alicja B. Celer 499 Nortel (Northern Telecom), Ltd. 500 PO Box 3511 Station C 501 Ottawa ON K1Y 4H7 502 Canada 504 EMail: aceler@nortel.ca