INTERNET DRAFT Marcel Wiget Simon Bryden Geoff Mattson Nortel Networks December 1999 draft-wiget-dynamic-vpls-00.txt Dynamic VPLS solution over multicast enabled IP backbone Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an individual submission to the Internet Engineering Task Force (IETF). Comments should be submitted to the authors. Distribution of this memo is unlimited. 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.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes an experimental serverless solution to build Virtual Private LAN Segments (VPLS) for TCP/IP over a multicast enabled IP backbone. IP traffic is encapsulated in IPsec [RFC2401] tunnel mode. IP broadcast and multicast traffic is sent, after encapsulation in IPSec tunnel mode, to the VPN assigned IP multicast address. IP unicast traffic, after encapsulation, is sent directly to the dynamically learned IP tunnel endpoint address. Multicast Enabled ARP (ME-ARP) as defined in this document is used to dynamically build the mapping between IP addresses and remote tunnel endpoints. The tunnel endpoint information is hidden in the hardware address given to IP devices in the ARP reply. Therefore IP devices participating in a VPLS keep track of the remote locations of other VPLS members through their own ARP table without "knowledge". Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Wiget, et al Expires: June 2000 [Page 1] INTERNET DRAFT draft-wiget-dynamic-vpls-00.txt 1 December 1999 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Dynamic VPLS Overview . . . . . . . . . . . . . . . . . . . . . 4 2.1. Multicast IP backbone Requirements . . . . . . . . . . . . . . 4 2.2. VPLS Identifier (Multicast IP Address) . . . . . . . . . . . . 4 2.3. VPLS Interfaces . . . . . . . . . . . . . . . . . . . . . . . 4 3. Multicast Enabled ARP (ME-ARP) . . . . . . . . . . . . . . . . . 4 3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. ME-ARP operations . . . . . . . . . . . . . . . . . . . . . . 6 3.3.1. ARP request intercepted from the PLS . . . . . . . . . . . . 6 3.3.2. Tunneled ME-ARP requests received from VPLS gateways . . . . 7 3.3.3. ARP replies intercepted from the PLS . . . . . . . . . . . . 7 3.3.4. Tunneled ME-ARP replies received from VPLS gateways . . . . 7 3.4. Hardware address calculation algorithm . . . . . . . . . . . . 7 4. IP Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Multicast and broadcast IP packets received from the . . . . . 9 4.2. Unicast IP packets intercepted from the PLS . . . . . . . . . 9 4.3. Tunneled IP packets received from VPLS gateways . . . . . . . 10 5. VPLS examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. CLE based Virtual Private LAN Segment (VPLS) . . . . . . . . . 10 5.2. Network based Virtual Private LAN Segment (VPLS) . . . . . . . 11 5.2.1. Functional Overview . . . . . . . . . . . . . . . . . . . . 12 5.3. Interoperability between different types of PLS . . . . . . . 13 6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Intellectual Property Considerations . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction 1.1. Goals The popularity of the Internet is driving requirements for secure and segregated IP interconnection of remote sites. One solution is to use an underlying network supporting virtual connections ie Frame Relay or ATM. These virtual connections can be separated by provisioning to form a Virtual Private Network which is Layer 3 protocol transparent. However if the underlying network is IP itself, as is the case with the Internet then IP tunnels can be used to interconnect two or more sites. The solution outlined in this document describes the following goals: ¸ Separation of IP address space between VPNs. ¸ To provide support for IPv4 based applications. Support for IPv6 is outside the scope of this document. Ipv6 encapsulation in Ipv4 will be supported by this solution as long as the encapsulation occurs before the VPN boundary. Wiget, et al Expires: June 2000 [Page 2] INTERNET DRAFT draft-wiget-dynamic-vpls-00.txt 1 December 1999 ¸ Transparent CLE (Customer Leased Equipment) or network based VPN's can be constructed independently or combined with this architecture. ¸ The use of IP multicast capabilities rather than address or broadcast servers. ¸ VPN traffic forwarding is achieved via tunnels which may option¡ ally be secure. Traffic forwarded over these tunnels are opti¡ mally routed using the underlying IP network backbone routing architecture. The document is split into four parts: Overview, protocol description of ME-ARP (multicast enabled ARP), IP encapsulation and VPLS examples over different lower layer technologies. 1.2. Terminology The term virtual private networks (VPN) is widely used as a common description for any kind of network built over another network with limited scope. The terminology used in this document is based on the definitions found in [gleeson]: A Virtual Private LAN Segment (VPLS) is the emulation of a LAN seg¡ ment using Internet facilities. A VPLS can be used to provide what is sometimes known as a transparent LAN service (TLS), which can be used to interconnect multiple physical LAN Segments (PLS). It can be seen as a pure layer 2 bridged VPN solution. The term "Physical LAN Segment" (PLS) is used in this document to describe a broadcast domain, like a shared or switched ethernet seg¡ ment, connecting hosts, servers and routers at each site. Without the use of a VPN technology, the scope of these PLS is limited per site. The term is also used for segments simulating a broadcast domain like a WAN link configured for bridging or simulating an ethernet segment using SMDS or ethernet over HDLC. The term "Client Address" (CA) space or network ranges is used to describe the IP address space used by each VPN customer. It is abso¡ lutely legal and very common for CA's from different VPN to overlap. The term "Provider Address" (PA) space or network ranges is used to describe the provider allocated IP addresses in his IP backbone. Tun¡ nel endpoints e.g. must have an address assigned out of the PA range. The term "Customer Leased Equipment" (CLE) defines an edge device (router), fully managed by the provider, connecting a customers PLS to its VPN. The term "Customer Premises Equipment" (CPE) defines an edge device Wiget, et al Expires: June 2000 [Page 3] INTERNET DRAFT draft-wiget-dynamic-vpls-00.txt 1 December 1999 (router), either managed by the customer or provider, connected to a provider's VPN concentrator. The term "VPN Concentrator" is used to describe a provider managed network device interconnecting many Frame Relay attached customer managed network devices to build network based VPN's. Wiget, et al Expires: June 2000 [Page 4] INTERNET DRAFT draft-wiget-dynamic-vpls-00.txt 1 December 1999 2. Dynamic VPLS Overview 2.1. Multicast IP backbone Requirements The providers IP backbone must be IP multicast capable. VPLS config¡ ured devices must be able to join a multicast group using IGMP. It is not a requirement that all routers in the backbone must have multi¡ cast capabilities. It is possible to interconnect the devices via a partially meshed or "star-like" multicast backbone, built using a mix of multicast routing protocols and tunnels to interconnect multicast islands. IP multicast is used to forward broadcast and multicast traffic and for IP address resolution, but not for forwarding of uni¡ cast traffic. 2.2. VPLS Identifier (Multicast IP Address) Each VPLS has a provider unique multicast IP address assigned. This address is used to send IP multicast, broadcast and special address resolution traffic to all participating VPLS gateways. If the VPLS consists only of 2 gateways, then an IP unicast address could be used instead as the VPLS identifier. 2.3. VPLS Interfaces The following minimal configuration parameters are needed per VPLS interface: ¸ VPLS Identifier = multicast IP address assigned to each VPLS. ¸ Customer assigned IP subnet network address and mask. This is used to detect IP subnet broadcast packets. ¸ Pair of Security Associations (SA) (one for each direction). ¸ Hardware address calculation algorithm. Due to the limited size of hardware address length it is possible to use different algo¡ rithm per VPLS interface. The algorithm has only interface local significance. The VPLS interface doesn't have to be identical to the IPSec interface. It is possible to share the same IPSec interface with more than one VPLS interface in the same device. A bidirectional mapping between the IPSec and VPLS interface based on SA's is enough to forward VPLS packets. It is not recommended to assign an IP address out of the client address (CA) network range. Doing so will allow the client to access the VPLS gateway from the provider. It is however possible to assign an IP address out of the provider address (PA) network range in order to man¡ age the interface from the providers' backbone. Wiget, et al Expires: June 2000 [Page 5] INTERNET DRAFT draft-wiget-dynamic-vpls-00.txt 1 December 1999 3. Multicast Enabled ARP (ME-ARP) 3.1. Protocol Overview The Address Resolution Protocol, ARP [RFC826], allows a host to find the physical address of a target host on the same physical network, given only the targets IP address. The goal of ME-ARP defined here is the expansion of ARP to work for Virtual Private LAN Segments (VPLS) connecting 2 or more Physical LAN Segments (PLS). The physical address for remote hosts is replaced by a pseudo-physical address containing the remote gateway identifier. It is important to note that these pseudo-physical addresses only have significance within of a PLS. All ARP requests sent by hosts connected to a VPLS are translated into ME-ARP requests and forwarded to the VPN assigned IP multicast address. These ME-ARP requests are then translated back into stan¡ dard ARP requests with remote gateway or tunnel endpoint information encoded in the pseudo-physical address. The request is sent out the local PLS. ARP replies are treated similarly but forwarded as uni¡ cast packets using the remote gateway or tunnel endpoint information encoded in the destination physical address. A new IP protocol type is assigned to ME-ARP and used in IPSec proto¡ col type field. 3.2. Packet Format Request and reply packet have the same format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | ProtoLength | Operation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Protocol Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target Protocol Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version This 8 bit field must be set to 1 for the packet format described in this RFC. It can be used for future expansion. ProtoLength This 8 bit field defines the byte length of the protocol address and is copied from the ARP packet field ar$pln (byte length of each protocol address) as defined in [RFC826]. Wiget, et al Expires: June 2000 [Page 6] INTERNET DRAFT draft-wiget-dynamic-vpls-00.txt 1 December 1999 Operation This 16 bit field is copied from the ARP packet field ar$op and defines the ARP operation (REQUEST or REPLY). Sender Protocol Address This variable length field contains the protocol address of the sender and is copied from the ARP packet field ar$spa. Sender Protocol Address This variable length field contains the protocol address of the sender and is copied from the ARP packet field ar$spa. Target Protocol Address This variable length field contains the protocol address of the target and is copied from the ARP packet field ar$tpa. A checksum is not needed as IPSec guarantees unmodified delivery of packets and discards them otherwise. There is no need to transfer hardware addresses as they have only local significance inside a PLS. The hardware addresses are created by ME-ARP based on the source IP address from the outer IPsec tunnel header (equals to the remote tunnel endpoint). 3.3. ME-ARP operations In all operations below there is no need to keep state of pending requests or replies as this is done by the hosts originating the ARP requests. ME-ARP simply tunnels modified ARP packets to remote loca¡ tions and process them as described below. This greatly simplifies the solution. Each VPLS interface must maintain a host table with the hardware address of local attached IP devices (no remote devices!). This table is identical to the ARP table needed for proxy ARP implementations. 3.3.1. ARP request intercepted from the PLS Each ARP request sent by IP devices connected to a PLS are inter¡ cepted by the VPLS interface. The tuple source hardware and protocol address are stored in an interface local host table. This table is accessed when VPLS traffic is received from remote VPLS gateways. The receiver uses table entry to map the protocol address in the header of incoming IP packets to the hardware address of a locally connected host. A ME-ARP packet is created using data from the ARP request and sent over a tunnel-mode IPsec connection to the VPLS assigned multi¡ cast IP address. Wiget, et al Expires: June 2000 [Page 7] INTERNET DRAFT draft-wiget-dynamic-vpls-00.txt 1 December 1999 3.3.2. Tunneled ME-ARP requests received from VPLS gateways IPSec encapsulated ME-ARP packets are sent to the VPLS interface based on the SPI index matching an incoming SA. The data of the ME- ARP request is used to build an ordinary ARP request packet and sent to the hardware broadcast address on the local PLS. The sender hard¡ ware address is calculated based on the source outer IPSec tunnel IP header address. The algorithm used for the hardware address calcula¡ tion can be found in a separate chapter further down. 3.3.3. ARP replies intercepted from the PLS ARP replies are sent by IP device to the target hardware address. The VPLS interface must check each of these target hardware address if it is a constructed address created by this VPLS interface. The detec¡ tion algorithm is directly related to the hardware address calcula¡ tion algorithm defined below. If the destination hardware address originated from this VPLS inter¡ face (created by the calculation algorithm) then it is translated into a ME-ARP reply packet, encapsulated in IPsec and sent to the destination gateway. The destination gateway IP address is extracted from the hardware address using the hardware address calculation algorithm as described in section 3.4. 3.3.4. Tunneled ME-ARP replies received from VPLS gateways IPSec encapsulated ME-ARP reply packets are sent to the VPLS inter¡ face based on the SPI index matching an incoming SA. The data of the ME-ARP reply is used to build a conventional ARP reply packet. The hardware destination address look-up is performed on the local host table maintained for this VPLS interface. If an entry is not found, then the packet is discarded, otherwise it is sent to the hardware address associated with the IP sender address. The source hardware address and target hardware address are calculated based on the source outer IPsec tunnel IP header address. The algorithm used for the hardware address calculation is described in section 3.4. [If the local host table doesn't contain an entry to forward the ARP reply, then it is ok to discard the packet because it might have reached this gateway as a result of an error (e.g. ARP request didn't come from this gateway) or the table was cleared between the request and the reply. However the requesting IP device will resend another ARP request if needed.] 3.4. Hardware address calculation algorithm Data to pack into the hardware address are: Wiget, et al Expires: June 2000 [Page 8] INTERNET DRAFT draft-wiget-dynamic-vpls-00.txt 1 December 1999 Unicast Tunnel Endpoint IP address (4 Bytes) This IP address is used to forward unicast IP packets directly to the correct VPN tunnel endpoint. Ideally, the complete IP address is stored, however in some cases it might be possible to reduce it to the host address if all gateway devices share the same network (ie. network address is the same for all CLE devices). This IP address is typically the address of the IPSec interface of the VPLS gateway. Interface local unique VPN Id This is used in case of IP multi-netted interfaces to distin¡ guish the different VPN's configured on the same physical interface. It's enough to store an index for all configured VPN's per interface instead of the real VPN multicast Id. Therefore 4 bits might be enough (-> 16 VPN's per interface). Local gateway identification In case of CLE redundancy (2 or more CLE devices connected to the same physical shared media serving the same VPN), a shared media wide unique identifier must be present. This gives an easy solution to add redundancy: ARP request coming from a local connected client will be for¡ warded by both CLE devices, as well as the ARP reply packet returning to the client. The client (host) however will store only one MAC address in its ARP table (whichever packet came last) A solution to this could be to use a 2 bit identifier to dis¡ tinguish up to 4 CLE devices per VPN segment. Summary: 32 Bit IP destination Gateway address 4 Bit VPN Id index (16 VPN's max) 2 Bit Gateway index (4 Gateways) ------------------------------------- 38 bits in use, leaving 10 Bits to identify a valid Ethernet address prefix. or, in case of using only the host portion of the gateway address (assuming class B), then we end up with 16 bit IP destination Gateway host address 4 Bit VPN Id Index 2 Bit Gateway index ----- 22 Bit, leaving 26 Bits as ethernet prefix (24 bit needed) so use e.g. the IANA prefix 00005E plus 2 bits. The algorithm used to pack the information into the calculated MAC address is only relevant for the local attached VPN network. A dif¡ ferent algorithm can be used on other CLE devices. Wiget, et al Expires: June 2000 [Page 9] INTERNET DRAFT draft-wiget-dynamic-vpls-00.txt 1 December 1999 It must be determined, if it would be possible to use a prefix of 04......, as this isn't assigned according to IEEE [Enet], it breaks however the rule, which identifies the vendor by the high-order 3 octets. 4. IP Encapsulation IP traffic between Physical LAN Segments (PLS) is encapsulated in IP using IPSec tunnel mode [RFC401]. ARP traffic is intercepted from the PLS, translated in ME-ARP packet, and encapsulated in IPSec with the protocol Id of ME-ARP. Therefore all VPLS traffic is authenticated and optionally secured using IPSec. There must be one Security Association (SA) created per VPLS in each gateway (see chapter 'VPN Security Association') to link the SPI to a particular VPN. This indirection is used to fully map tunneled pack¡ ets to their VPN. IPsec offers different levels of authentication, security and reply protection by using Authentication Header (AH) [RFC2402] and Encapsu¡ lating Security Payload (ESP) [RFC2406]. If encryption is not needed or prevented by legal issues, then IPSec with NULL encryption algo¡ rithm [RFC2410] can be used. IPSec must be able to forward IP and ME-ARP traffic (different proto¡ col id) as well as support wildcard Security Associations (SA). A pair of SA's are defined per VPLS for bidirectional traffic inside a VPLS. A table linking VPLS Id and SA's in each gateway provides the binding between the VPLS IP multicast address and the current SPI used in each IPSec packet. Therefore there is no need to further encapsulate each VPLS packet to store the VPLS Id. 4.1. Multicast and broadcast IP packets received from the Multicast and broadcast IP packets received by a VPLS interface must be sent to all members of the VPLS by sending them as IPSec tunneled packets to the multicast IP address assigned to the VPLS (VPLS Id). It is required to update the interface host table with the hardware and protocol source address of the packet. This ensures the proper delivery of reply traffic to the originating host, especially if the sending host used static host entries. 4.2. Unicast IP packets intercepted from the PLS The VPLS interface must check each unicast packet for a constructed destination hardware address (originally created by this VPLS inter¡ face). The detection algorithm is directly related to the hardware address calculation algorithm defined below. If the destination hardware address originated from this VPLS Wiget, et al Expires: June 2000 [Page 10] INTERNET DRAFT draft-wiget-dynamic-vpls-00.txt 1 December 1999 interface (created by the calculation algorithm) then it is sent as an IPSec tunnel packet to the remote gateway IP address reconstructed from the destination hardware address using the configured calcula¡ tion algorithm. It is required to update the interface host table with the hardware and protocol source address of the packet. This ensures the proper delivery of reply traffic to the originating host, especially if the sending host used static host entries. 4.3. Tunneled IP packets received from VPLS gateways IPSec encapsulated IP packets are sent to the local VPLS interface based on the SPI index matching an incoming SA. The IPSec tunnel source IP address is used to calculate the source hardware address of the packet. The destination hardware address must be looked up in the interface host table. If no entry is found, then the packet is either discarded (not recommended) or handled according to the dis¡ cussion below. The source hardware address is calculated based on the source outer IPsec tunnel IP header address. The algorithm used for the hardware address calculation can be found further below. Discussion: Contrary to the discard behavior of ARP replies, there might be a connectivity problem if the source IP device has a valid ARP entry for the destination protocol address but the host table of the remote VPLS interface got cleared. To recover from here there are basically two solutions: Local ARP for destination hardware address This would need a proper ARP handling by the VPLS interface and queue the packet until the hardware address is resolved. Send the packet to the broadcast hardware address This would ensure the delivery of the packet to the IP device (as well as all other devices which will discard the packet). This approach does increase the broadcast traffic but only until the local IP device sends any IP packet (broadcast, mul¡ ticast or unicast) back to the originating host (connected to a remote PLS). Any of these packet will result in an update of the interfaces host table with the missing entry. 5. VPLS examples 5.1. CLE based Virtual Private LAN Segment (VPLS) Physical (Provider) View: PLS 1 PLS 2 Wiget, et al Expires: June 2000 [Page 11] INTERNET DRAFT draft-wiget-dynamic-vpls-00.txt 1 December 1999 |--------+---------| |---------+---------| | ....... | +---+---+ .' `. +---+---+ | CLE A +--------. .-------+ CLE B | +-------+ . . +-------+ . IP Backbone . +-------+ . . +-------+ | CLE C +----------. .---------+ CLE D | +---+---+ `.......' +---+---+ | | |--------+---------| |---------+---------| PLS 3 PLS 4 The IP backbone and CLE devices A..D are managed (and typically owned) by the service provider. The PLS 1..4 are managed (and typically owned) by the customer. Logical (Customer) View: PLS 1 + PLS 2 + PLS 3 + PLS 4 => VPLS |---------------------------------------------------------| 1 flat IP subnetwork A layer 2 virtual private LAN segment can span two or more sites, with all IP devices do share the same IP subnet. The IP address and mask are chosen by the customer without any restrictions in relation to the provider or other customers. The CLE devices, managed by the provider, are completely transparent to the customer. This type of layer 2 VPN solution possesses the following benefits for the cus¡ tomer: ¸ Transparency. No IP addresses must be given to the provider ¸ Flat IP subnet. The VPN can be seen as a VLAN, with transparent support for broadcast protocols like DHCP/BOOTP, Netbios/IP etc. ¸ Broadcast and Multicast support. The customer can extend the VPN with their own routers and run any routing protocol over the VPN without any coordination with the provider. There are however also some drawbacks: ¸ Scalability. The number of IP devices participating in the VPN is limited, primarily by the percentage of broadcast and multicast traffic. 5.2. Network based Virtual Private LAN Segment (VPLS) Wiget, et al Expires: June 2000 [Page 12] INTERNET DRAFT draft-wiget-dynamic-vpls-00.txt 1 December 1999 5.2.1. Functional Overview Physical (Provider) View: +-----+ +-----+ |CPE A|-. ,-|CPE B| +-----+ \ +------------+ +------------+ / +-----+ `--+ VPN |........| VPN +-' ,-+Concentrator| |Concentrator+-. +-----+ / +------------+ +------------+ \ +-----+ |CPE 1|--' . IP . `-|CPE C| +-----+ . Backbone . +-----+ . . . +------------+ . ...| VPN |... |Concentrator| +-+---+----+-+ | | | +-----+ / | \ +-----+ |CPE D|--' +--+--+ `--|CPE 3| +-----+ |CPE 2| +-----+ +-----+ Logical (Customer) View: +-----+ +-----+ +-----+ +-----+ |CPE A| |CPE B| |CPE 1| |CPE 2| +-----+ +-----+ +-----+ +-----+ \ / \ / Frame Relay Frame Relay Network Network / \ | +-----+ +-----+ +--+--+ |CPE C| |CPE D| |CPE 3| +-----+ +-----+ +-----+ Customer ABCD Customer 123 A typical VPN topology with Frame Relay edge connectivity is as fol¡ lows: The provider network consists of an IP core with VPN concentrators on the edge. Customers have access routers on their premises which con¡ nect to these edge routers using Frame Relay. Within a given VPN, CPE interfaces have configured IP addresses in the same subnet. CPE's are directly connected to the VPN concentrators (no Frame Relay switches in between). Therefore the VPN concentrator is providing DCE function in the data link management protocol (LMI, Q.933 Annex A/D, ...). Wiget, et al Expires: June 2000 [Page 13] INTERNET DRAFT draft-wiget-dynamic-vpls-00.txt 1 December 1999 The VPN concentrator use ME-ARP as discussed in the previous chapter to resolve IP addresses in each VPLS on behalf of the connected CPE's. The Frame Relay interface of the CPE's are configured using IP addresses from the Client Address (CA) space. The VPN concentrator will learn these addresses using ARP as discussed in [RFC2427]. The CPE will see the resulting VPN as a traditional Frame Relay net¡ work and will be configured with multiple virtual circuits under each IP address per interface. The CPE device must be able to resolve IP addresses using ARP as described in [RFC2427]. 5.3. Interoperability between different types of PLS As ME-ARP doesn't transfer any hardware addresses to remote VPLS gateways and therefore hardware addresses do have only local signifi¡ cance, it is absolutely possible to interconnect different types of PLS (ethernet, FR, SMDS, ...) into one VPLS and IP subnet. 6. Security There are two distinct types of packet which are required to be pro¡ tected; the ME-ARP requests and responses and the unicast tunnel data traffic. The ME-ARP messages are multicast, and so a manual SA should be configured with a wildcard destination address corresponding to the range of provider-side CLE addresses. If it is required to encrypt the ME-ARP messages, then the cipher key must be manually specified as part of the SA configuration. The key must be shared between all VPLS gateways. This does not provide a high level of security because of the long key lifetime, but in practice the data in these packets may be considered not to be particularly sensitive, the only potential issue being revealing the ip address of the pri¡ vate destination device. For data traffic, which is generally much more sensitive, IKE [RFC2409] can be used to automate the creation of SAs. It defines two possibilities for authentication of tunnel endpoints, using either pre-shared keys or public key techniques. It is recommended that one of the public key mechanisms is used as this does not require shared keys to be distributed to all CLE devices, although note that even using pre-shared keys, it is inherently more secure than using a man¡ ual SA because session keys are dynamically generated and rekeying takes place automatically. In addition to the above, user data security is further enhanced as VPLS interfaces can't be reached by a customer due to the lack of an assigned IP address. They don't respond to any IP traffic sent to them. Special considerations must be taken into account in cases where an Wiget, et al Expires: June 2000 [Page 14] INTERNET DRAFT draft-wiget-dynamic-vpls-00.txt 1 December 1999 intruder can join a multicast group in the providers IP backbone. This is possible in networks where the provider gives native access to the IP backbone and IP multicast itself. Unfortunately IGMP [RFC2236] doesn't has security features defined, so either traffic or multicast policy filters SHOULD be used to prevent unauthorized joins to VPN multicast Id's. 7. Scalability It is assumed, that VPLS networks will scale up to the size of single class C network, or, if only customer routers are interconnected which produce minimal broadcast traffic (routing protocol), it might scale even further. The scaling property is expected better for net¡ work based VPLS as ME-ARP traffic is limited between the connected VPN concentrators on behalf of attached CPE's, which are most likely to be of static nature (compared to network devices attached to a physical LAN segment). 8. Discussion An implementation might allow the usage of a list of unicast instead of a multicast IP address of the tunnel endpoints of a VPN (with one address chosen as VPN Id). This would reduce the number of assigned IP multicast addresses, especially for VPN's with only a few sites (2..5). The same IP unicast list must be maintained on all VPN joined CLE devices. 9. Intellectual Property Considerations Nortel Networks may seek patent or other intellectual property pro¡ tection for some of all of the technologies disclosed in this docu¡ ment. If any standards arising from this document are or become pro¡ tected by one or more patents assigned to Nortel, Nortel intends to disclose those patents and license them on reasonable and non-dis¡ criminatory terms. 10. Acknowledgments Many thanks for feedback and contributions from Mike Tate and Robert Pluim . 11. References [Gleeson] Bryan Gleeson, Arthur Lin, Juha Heinanen, G. Armitage, A. Malis - "A Framework for IP Based Virtual Private Networks", draft- gleeson-vpn-framework-03.txt [Heinanen] Heinanen J., et al, "MPLS Mappings of generic VPN Wiget, et al Expires: June 2000 [Page 15] INTERNET DRAFT draft-wiget-dynamic-vpls-00.txt 1 December 1999 mechanisms", draft-heinanen-generic-vpn-mpls-00.txt. [Meyer] Meyer D., "Administratively Scoped IP Multicast". RFC 2365. [RFC826] David C. Plummer, "An Ethernet Address Resolution Protocol", RFC 826, November 1982. [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998 [RFC2410] R. Glenn, S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998. [RFC2427] C. Brown, A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 2427, September 1998 Author's Addresses Marcel Wiget Nortel Networks EMEA, S.A. 25, Allee Pierre Ziller 06560 Valbonne - France EMail: mwiget@nortelnetworks.com Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Wiget, et al Expires: June 2000 [Page 16] INTERNET DRAFT draft-wiget-dynamic-vpls-00.txt 1 December 1999 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Wiget, et al Expires: June 2000 [Page 17]