Network Working Group F. Baker Internet-Draft Cisco Systems Expires: April 24, 2006 P. Bose D. Voce Lockheed Martin October 21, 2005 Routing across Nested VPNs draft-baker-nested-vpn-routing-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on April 24, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document discusses the general problem of routing in an IPv6 Nested Virtual Private Network. A solution is proposed based on one- way hashes of IP Prefix values. The concepts extend to IPv4, but with difficulty due to the number of bits in question. Requirements Language Baker, et al. Expires April 24, 2006 [Page 1] Internet-Draft Nested VPN Routing October 2005 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Nested Virtual Private Networks . . . . . . . . . . . . . 5 1.2. Defining Terms . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Fundamental Requirements for Routing . . . . . . . . . . . 7 1.4. Fundamental proposal: use of a one-way hash . . . . . . . 7 2. Unicast Routing Solution . . . . . . . . . . . . . . . . . . . 10 2.1. Inner domain routing . . . . . . . . . . . . . . . . . . . 11 2.2. Forming a ciphertext address from a plaintext prefix . . . 12 2.3. Routing to a remote address . . . . . . . . . . . . . . . 13 2.4. Routing between enclaves . . . . . . . . . . . . . . . . . 14 2.4.1. Routing between enclaves across a common ciphertext domain . . . . . . . . . . . . . . . . . . 14 2.4.2. Routing between enclaves across a multiple ciphertext domains . . . . . . . . . . . . . . . . . . 14 2.5. Proving recursiveness . . . . . . . . . . . . . . . . . . 15 2.6. Open Issues (Author's notes to self) . . . . . . . . . . . 16 3. Multicast Routing Solution - SSM . . . . . . . . . . . . . . . 17 3.1. Forming a ciphertext group address from a plaintext address . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Routing to a remote address . . . . . . . . . . . . . . . 19 3.3. Proving recursiveness . . . . . . . . . . . . . . . . . . 20 3.4. Issues (Author's notes to self) . . . . . . . . . . . . . 20 4. Key Management Procedures . . . . . . . . . . . . . . . . . . 21 4.1. Key Management Requirements . . . . . . . . . . . . . . . 21 4.2. Key Management Procedures . . . . . . . . . . . . . . . . 21 4.3. Pathological Cases . . . . . . . . . . . . . . . . . . . . 22 5. Operational Considerations . . . . . . . . . . . . . . . . . . 23 5.1. Scaling issues in host routing . . . . . . . . . . . . . . 23 5.2. The place of manual configuration and server-based solutions . . . . . . . . . . . . . . . . . . . . . . . . 24 5.3. Use Case for Enterprise Network . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 Baker, et al. Expires April 24, 2006 [Page 2] Internet-Draft Nested VPN Routing October 2005 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.1. Normative References . . . . . . . . . . . . . . . . . . . 30 9.2. Informative References . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . . 34 Baker, et al. Expires April 24, 2006 [Page 3] Internet-Draft Nested VPN Routing October 2005 1. Introduction This document discusses the general problem of routing in an IPv6 Nested Virtual Private Network. A solution is proposed based on one- way hashes of IP Prefix values, or equivalently, the use of encrypted prefix values. The concepts extend to IPv4, but with difficulty due to the number of bits available in the address. Baker, et al. Expires April 24, 2006 [Page 4] Internet-Draft Nested VPN Routing October 2005 1.1. Nested Virtual Private Networks / \ ( +--+ +--+ enclave ) ,---------. .----------. \ |H2+---+R2| / ,-' ` +--+ +--+`--.\ +--+ ++-+ / / +--+ +--+ |H1+---+R1| \`. | ,' / |R3+---+H3| +--+ +-++ ) '--. +----++ _.-' ( ++-+ +--+ | / _.`---|VPN2||''-. \ | enclave +----+-i.--'' +----++ `----.\ +----+ enclave --------|VPN1|' | ``|VPN3| , ,+----+ | +----+------' ,' --+-------+----------+------------------+---`. ,' ++-+ `. ,' |R7+--------+ `. / interface +--+ | \ domain 1 +-+--+ \ _.--------|VPN7|--------. ,-----'' +--+-+ `------. . `-. ,-' | `-. .-' `-: inner domain +-++ `.' ( |R9| ) .'. ++-+ ;-. .' `-. | ,-' `-. ' `------. +-+--+ _.-----' ` interface `---------|VPN8|-------'' domain 2 +-+--+ / \ | +--+ / `. +----------+R8| ,' `. ++-+ ,' `. --+------------------+-----------+------+-- ,' ,-----+----+ | +----+------. ,' |VPN6|. | _.|VPN4| ` +----+.`----. +----+ _.--'' ,+----+ | \ `--=.-|VPN5|---:' / | +--+ ++-+ : ,-'' +----+ `--. ; ++-+ +--+ |H6+---+R6| | ,' | `.| |R4+---+H4| +--+ +--+ ;/ +--+ ++-+ : +--+ +--+ // |H5+---+R5| \ enclave ,'( +--+ +--+ `. enclave `. ,' \ enclave / '-. , `-------' \ / `-------' Figure 1: Nested Virtual Private Network Figure 1 shows what the authors have described as a "Nested VPN". Like normal VPNs, this is a network that has a variety of enclaves that communicate across an encrypted cloud that is invisible to them Baker, et al. Expires April 24, 2006 [Page 5] Internet-Draft Nested VPN Routing October 2005 (apart from effects such as delay or jitter) and to which they are invisible. It differs in that the construct is recursive - such encrypted clouds may themselves appear to be enclaves to further underlying VPN networks - and that little or no information is permitted to cross the boundary and yet any enclave must be enabled to communicate with any other enclave at the same nesting level. Normal VPNs tend to be managed in one of two ways. One is that a service provider offers the VPN, and provides an underlying circuit network, often MPLS, that connects the underlying endpoints as defined in a contract. These are referred to as "Provider- Provisioned VPNs" [RFC3809]. The other, generally referred to as "customer-provisioned", is that the edge routers themselves provide tunnels over an underlying network using one of a variety of types of IP tunnel technologies loose source routes as specified in DVMRP [RFC1075], IP/IP [RFC2003], IPsec/ESP [RFC2401][RFC2406], L2TP [RFC2661], GRE [RFC2784], and others. In this context, a "Nested VPN" is an example of an IPsec or IPsec- like VPN, and is therefore "customer-provisioned". Such networks have in the past been built in a very ad hoc fashion, without significant knowledge or concern for the underlying network infrastructure. They have often consisted of either a haphazard collection of tunnels, or a star or multi-star network in which a large set of client sites maintain static or semi-static tunnels with a much smaller set of service sites. Such networks support telecommuters working from home offices, small distributed companies, and so on. 1.2. Defining Terms Plaintext Domain: A network domain in which datagrams are sent without additional encryption. Ciphertext Domain: A network domain in which datagrams that originated in a plaintext domain are sent with additional encryption. Note that if there is an additional layer of encryption in the network beyond that provided by a given ciphertext domain, a ciphertext domain will be treated by that ciphertext domain as if it were a plaintext domain - traffic entering it will be encrypted, and traffic leaving it will be decrypted. Domain: In the context of this document, the routing domain of relevance. This will be either a ciphertext or a plaintext domain. Baker, et al. Expires April 24, 2006 [Page 6] Internet-Draft Nested VPN Routing October 2005 Enclave: A plaintext Domain, as seen from the ciphertext domain One Way Hash: One of a variety of approaches that scramble the bits in a string or number to produce a different one, and from which the original cannot be deduced. Examples, include CRCs, MD5, etc. Encrypted addresses have also been suggested, and would work in this context, but require management of the ability to decrypt the address, via key management. VPN Router: A special case of a router supporting IPsec or IPsec- like tunnels over an IP network, and having the characteristic that information leakage between plaintext and ciphertext parts of the same router is absolutely minimal - ideally zero. 1.3. Fundamental Requirements for Routing [I-D.ietf-rpsec-routing-threats] describes in general terms the threats that one deals with in routing, and [I-D.ietf-rpsec-generic- requirements] describes general security requirements for routing. They might be summarized as relating to four basic attack vectors: authenticity of the channel, privacy of the channel (both of which might be adequately addressed by IPsec), correctness of the data, and scalability to the network design in question. These issues apply to any routing solution. In addition, nested VPNs in this context require as close to zero information leakage as possible between domains. Note that as a practical matter this is not quite "zero"; the only proposal that the authors are aware of that truly leaks no information across domains has scalability issues in networks larger than a few tens or hundreds of enclaves (i.e. broadcast a request to all domains asking the right one to respond). All other known approaches require some level of sharing of knowledge between domains - the CE router creates, whether through configuration or some more dynamic process, a tunnel to a router across the ciphertext domain by connecting to a specified ciphertext domain address. 1.4. Fundamental proposal: use of a one-way hash First, imagine that a VPN Router consists of two independent functional elements, whether physical or logical, and information crosses between them through a narrowly defined interconnection function. These four functions are: Plaintext Router: A router that is entirely within the plaintext enclave network. Baker, et al. Expires April 24, 2006 [Page 7] Internet-Draft Nested VPN Routing October 2005 Ciphertext Router: A router that is entirely within the ciphertext network. Encrypt/Decrypt Unit: A functional element (either an interface card or a separate device) with three interfaces: * A local interface to the plaintext router, in which datagrams are passed as IP datagrams associated with a plaintext network next hop address. Such datagrams are encrypted using IPsec ESP's [RFC2406] Tunnel Mode, and passed to the Ciphertext Router. * An interface to the ciphertext router, which is or is functionally equivalent to a LAN interface. Messages received on it are decrypted and handed to the Plaintext Router. * A network management interface, which enables the programming of security associations in the encrypt/decrypt process. Network Manager A functional element (software or hardware) that is capable of programming security associations and passes narrowly defined communications between the plaintext and ciphertext routers. These communciations might include configuration information and commands to generate or forward QoS signaling. Such a configuration is shown in Figure 2. Plaintext Router Ciphertext Router +------------------+ +------------------+ |+----------------+| +--------+ |+----------------+| ||Configuration || |Network | ||Configuration || ||Management ++----+Manager +----++Management || |+----------------+| +----+---+ |+----------------+| | | | | | |+----------------+| +----+---+ |+----------------+| || IP +-----+Encrypt/+-----+ IP || |+----------------+| |Decrypt | |+----------------+| |+----------------+| +--------+ |+----------------+| || Link || || Link || |+----------------+| |+----------------+| +------------------+ +------------------+ Figure 2: VPN Router Functional Breakdown Typically the relationship between the different functions in Figure 2 does not change for a given operational configuration and a unique mapping exists between Plaintext IP address to Ciphertext IP address. The hash function accepts a number of 0 to 64 bits and Baker, et al. Expires April 24, 2006 [Page 8] Internet-Draft Nested VPN Routing October 2005 hashes it according to an externally specific (e.g., not intrinsic to this specification) algorithm. Possible algorithms include CRCs, SHA1, MD5 hashes, AES encryption, etc. Coupled with Stateless Address Autoconfiguration [RFC2462] and specifically its Privacy extensions [RFC3041], this enables us to create a host part of an IPv6 address based on a randomized number taken from the enclave and build an address based on it unknown on the plaintext router (either within the enclave or in any remote enclave) but in a certain sense predictable by it. | 64 bit component | 64 bit component | +----------------------+----------------------+ | IPv6 Prefix | IPv6 host part | +----------------------+----------------------+ | | | | | | ,-------. ( Hash ) `-------' | | | | | | 64 bit result +----------------------+ | Hashed number | +----------------------+ Figure 3: One-way Hash Baker, et al. Expires April 24, 2006 [Page 9] Internet-Draft Nested VPN Routing October 2005 2. Unicast Routing Solution +------+ +------+ +------+ |Host 1| |Host 2| |Host 3| +--+---+ +--+---+ +--+---+ | | | /--+-------------+-+--------------+---/ | +------+------+ |+-----------+| ||plaintext || |+-----------+| VPN Router 1 | +--+ | | +--+ | |+-----------+| ||ciphertext || |+-----------+| +------+------+ | ,-----------+-----------------. ( IP Network ) `-------------+---------------' | +----+--------+ |+-----------+| ||ciphertext || |+-----------+| | +--+ | | +--+ | VPN Router 2 |+-----------+| ||plaintext || |+-----------+| +------+------+ | /---+--------------+-+-------------+--/ | | | +---+--+ +---+--+ +---+--+ |Host 4| |Host 5| |Host 6| +------+ +------+ +------+ Figure 4: Unicast Example Let us work through an example of unicast use. Figure 4 shows a simple case of a VPN. The fundamental problems are: o Given a prefix on the LAN in the upper enclave, how does one form an address on the ciphertext router of the VPN Router? Baker, et al. Expires April 24, 2006 [Page 10] Internet-Draft Nested VPN Routing October 2005 o How does the plaintext prefix of the upper LAN or address of Host 1 relate to routing? o How does the corresponding ciphertext prefix or address relate to routing? o How does a host in a remote enclave determine the address of Host 1? o How does a host in a remote enclave direct a datagram to the appropriate VPN Router to get it to Host 1? o Presuming that the two VPN Routers are unknown to each other, how do they form the appropriate security association? 2.1. Inner domain routing IPSec or IPSec like routers currently support static configuration of ciphertext addresses in security databases. These addresses are used by the VPN router to initialize security associations to a set of well-known ciphertext addresses. The mechanism to dynamically create and discover new or changing ciphertext addresses as described in this document complements the static configuration mechanism or other legacy mechanisms (for example, directory servers could resolve ciphertext address queries). Static configuration of a known set of ciphertext addresses on a VPN router is useful in setting up default security associations (for example to peer enterprise VPN routers or to enterprise headquarters). In the inner domain of Figure 1 , the authors consider it likely that security associations between VPN8 and VPN7 are likely to be statically configured, allowing routing protocols (e.g. IGP) to run over them as through a tunnel. This connects the routing of the interface domains, enabling the alogrithm described in Section 2.2 to work properly. In addition, other approaches exist to distribute routing information in the core. For example, one could use Mobile IP to connect to a central "Home Agent" within the ciphertext domain which would be able to provide, through Optimized Routing, the address of the proper peer as a Care-of Address. Having established that relationship, OSPF with the Do-Not-Age flag could allow the domains to exchange routing information but not have to maintain continuous routing relationships thereafter. Another alternative would be a directory service similar to LDAP or DNS that could associate the hashed nonce with the ciphertext address located within the ciphertext domains. Baker, et al. Expires April 24, 2006 [Page 11] Internet-Draft Nested VPN Routing October 2005 2.2. Forming a ciphertext address from a plaintext prefix First, a VPN Router (as shown in Figure 2) is in every sense a router, as defined by the IPv6 Architecture [RFC2460], which defines a router as any "node that forwards IPv6 packets not explicitly addressed to itself. " As a router, it may advertise (using theStateless Address Autoconfiguration [RFC2462] Router Advertisement) a prefix into its plaintext domain, or it may pick up similar advertisements from another router. It and the other hosts in the enclave form addresses within the enclave's prefix as specified in that procedure, and may subsequently advertise these addresses in DNS in the plaintext domain or disseminate them in other ways. As shown in Figure 5, knowing the prefix for the enclave LAN, the plaintext router of the VPN Router hashes the prefix (the /64 or the appropriate subset of it) and communicates the hashed value to the ciphertext router. That interface is similarly engaged in stateless address autoconfiguration. It uses the prefix from that router (whether configured or learned) with the hashed value to form an address for the ciphertext router. There are two approaches to placing multiple LANs within an enclave. One is to have the VPN Router participate in routing within the enclave, and form multiple such addresses on the ciphertext router. Another is to use a shorter prefix in each enclave, such as perhaps a /60. A /60 would permit every enclave to support 16 IPv6 LANs without expanding routing. The ciphertext-router address is now included in routing in the IP network on the ciphertext router as a host route (/128), or may be distributed in an OSPF Opaque LSA (if the routing domain is entirely OSPF). Baker, et al. Expires April 24, 2006 [Page 12] Internet-Draft Nested VPN Routing October 2005 +----------------------+----------------------+ | IPv6 Prefix of | Host part of | | plaintext domain | IPv6 Address | +----------------------+----------------------+ \\ \\ ,---------------. ( Hash Function ) `---------------' \\ \\ +----------------------+----------------------+ | IPv6 Prefix of | Hashed plaintext | | ciphertext domain | IPv6 Address | +----------------------+----------------------+ Figure 5: Forming a unicast ciphertext address from a plaintext address 2.3. Routing to a remote address Let us imagine that the two enclaves in Figure 4 have just performed the procedure in Section 2.2 and at this point have no active security association. Host 4 is able to determine the address of Host 1 via DNS, and wishes to commune with it. Host 4 is essentially unaware of the network connecting it to Host 1, and unaware of the presence or absence of a VPN Router. Like any IPv6 host, it encapsulates the datagram in an IPv6 datagram header and ships it to its friendly neighborhood plaintext router, which happens to be a VPN Router in this case. Processing in the VPN router is a little different, however: o The plaintext router first determines the next hop address (via routing functions such as OSPF or BGP). o It then determines whether there is an established security association from the Network Management process o if not, it lets the Network Management process establish such an association (see [RFC2401]). Accomplishing this requires * Identifying the remote ciphertext router. The Network manager enquires of the local ciphertext router whether there is one or more host routes (/128) whose host part equals the hash of the remote plaintext prefix. Baker, et al. Expires April 24, 2006 [Page 13] Internet-Draft Nested VPN Routing October 2005 * If so, it establishes a security association to the specified address. It may try them sequentially or in parallel, and it may choose to leave all such associations open or to close the ones that are not useful, per local policy. o It then presents either the next hop address or the SPI that has been associated with it, with the datagram, to the encrypt/decrypt unit. o The encrypt/decrypt unit derives the appropriate remote ciphertext address from the security association information stored in it. o Having encrypted the datagram and appropriately re-encapsulated it, the encrypt/decrypt unit presents the ciphertext datagram to the ciphertext router. If at any point in this process the route lookup or the security association fails, the datagram is dropped. The receiving process follows standard IPsec tunnel-mode security procedures. The ciphertext router presents the datagram to the encrypt/decrypt unit, which decapsulates and decrypts it, and presents the resulting datagram to the plaintext router. 2.4. Routing between enclaves This system may obviously be used in two ways. It may be used across a common ciphertext domain, or across multiple ciphertext domains that route traffic through intermediate enclaves. 2.4.1. Routing between enclaves across a common ciphertext domain Once the security association is set up between two VPN routers, the respective enclaves can exchange routing information in the security association. As an example, if the two disjoint enclaves learn routes inside their respective enclaves via the use of an IGP protocol like OSPF, OSPF route advertisements can be exchanged in the security association which is set up using the procedure described above. Hence hosts and routers within each enclave learn routes from the remote enclave using the same protocol that is used within their enclave via the invisible security association between the VPN routers. 2.4.2. Routing between enclaves across a multiple ciphertext domains By extension, if a router in an intermediate enclave establishes relationships with multiple plaintext peers, it has the option to advertise its capability as a transit path between them. In this Baker, et al. Expires April 24, 2006 [Page 14] Internet-Draft Nested VPN Routing October 2005 case, a network can be built across multiple plaintext domains. 2.5. Proving recursiveness The proof of recursiveness is simple. Consider Figure 1 and presume that H1 wishes to exchange files with H6. When the networks come up, H1 derive its address from R1 and H6 derives its address from R6. VPN1's plaintext router participates in the routing, and learns of the two LANs in the domain, or learns of the shorter prefix encompassing them if that is the case in this network. It forms a ciphertext-router address for each relevant prefix. Similarly, VPN6 participates in the routing of its domain and forms relevant addresses. So also the other peripheral enclaves. Routing to those host addresses is injected into the routing of interface domain 1 and interface domain 2. This is also true of interface domain 1 and interface domain 2. VPN7 and VPN8 see the interface domains as enclaves and the inner domain as a ciphertext domain. VPN7 and VPN8 form addresses in the inner domain from the prefixes used in the interface domains, and advertise corresponding host routes into the routing of the inner domain. So: o Host H1 sends a datagram to H6, passing it to R1. o R1 passes it along its default route, to VPN1. o VPN1 finds that the next hop towards H6 is VPN6, either by inspection of the prefix or by knowledge from routing, and knows that this is across the ciphertext domain. It hashes the /64 of the datagram's source address and passes that to the ciphertext router. There is no corresponding security association, but VPN6's ciphertext-router address shows up in routing, with R7 as the next hop. VPN1 now opens a security association with VPN6, meaning that its ciphertext router must send a datagram to VPN6. o The SA-Open datagram is handed to R7, which hands it to VPN7. o VPN7 finds that the next hop towards VPN6 is VPN8, either by inspection of the prefix or by knowledge from routing, and knows that this is across the inner ciphertext domain. It hashes the /64 of the datagram's source address and passes that to its ciphertext router. There is no corresponding security association, but VPN8's ciphertext-router address shows up in routing, with R9 as the next hop. VPN7 now opens a security association with VPN8, meaning that its ciphertext router must Baker, et al. Expires April 24, 2006 [Page 15] Internet-Draft Nested VPN Routing October 2005 send a datagram to VPN8. o The IKE exchange happens between VPN7 and VPN8, and when the relationship is accepted, the datagram initiating the IKE exchange between VPN1 and VPN6 is encrypted and passed along. o The IKE exchange happens between VPN1 and VPN6, and when the relationship is accepted, the datagram initiating the datagram from H1 to H6 is encrypted and passed along. 2.6. Open Issues (Author's notes to self) Anycast: Does this preclude anycast applications? Hash collisions: A good hash such as SHA should keep the collisions to a minimum, but theoretically they can still happen. Plaintext prefix collisions: If two enclaves chose the same prefix, this would result in two VPN gateways advertising the same address. This is a configuration error (two enclaves shouldn't do that, not in an IP network) Ciphertext host part collisions: A VPN router properly forms its ciphertext address, and finds that its address collides with the address of another device on its link. The autoconfiguration process provides for arbitration, but the VPN router can't change its address. Wouldn't that be a fatal problem? Baker, et al. Expires April 24, 2006 [Page 16] Internet-Draft Nested VPN Routing October 2005 3. Multicast Routing Solution - SSM It has been aptly said that anyone who thinks he understands something in routing should repeat his statement using the word "multicast". This section proposes to do exactly that. Figure 4 shows a simple case of a VPN. Rather than attempting to solve the most general case, which many have found difficult, use Single Source Multicast [RFC3569]as the basic technology. The fundamental problems are: o Given a group prefix on the LAN in the upper enclave, how does one form a corresponding address on the ciphertext router of the VPN Router? o How does the plaintext address Host 1 relate to routing of a multicast group used by Host 1? o How does the corresponding ciphertext group address relate to routing? o How does a host in a remote enclave determine the plaintext group address and join it? o How does a VPN Router in front of a remote enclave determine the corresponding ciphertext group address and join it? o Presuming that the two VPN Routers are unknown to each other, how do they form the appropriate security association? o How are keys exchanged? 3.1. Forming a ciphertext group address from a plaintext address Single Source Multicast identifies a multicast channel using the source address and group address as an {S,G} pair. Using IPv6 addresses, this has a natural breakdown: the Sender Address has a prefix part (a /64 prefix) and a host part, and the group address (defined in [I-D.ietf-ipv6-addr-arch-v4] and shown in Figure 6) similarly has 16 bits of discriminator, flags, and scope, and 112 bits of Group ID. For the purposes of this document, we will consider that Group ID to have 64 bits in its lower part and 48 bits in its upper part, and that the upper part represents a prefix that may be configured for a routing domain. In this game, we will create the ciphertext router of the VPN router's "sender address" just as we did in Section 2, and will additionally use the hash of the host part of the plaintext group address. Baker, et al. Expires April 24, 2006 [Page 17] Internet-Draft Nested VPN Routing October 2005 | 8 | 4 | 4 | 112 bits | +------ -+----+----+---------------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+---------------------------------------------+ Figure 6: IPv6 Multicast Address, from RFC 3513 As shown in Figure 7, when a host joins a multicast tree emanating from a host in another enclave, the joins will migrate toward the sender following SSM's algorithms, and crossing the intervening VPN as through a tunnel. When such a route is created, the following four elements are combined: o a configured multicast group prefix used in the ciphertext domain and unknown to the plaintext router o The IPv6 prefix used for unicast addresses in the ciphertext domain. o The hashed prefix part of the plaintext router sender address o The hashed "host part" of the plaintext router group address +-----------+-----------+-----------+-----------+ | Plaintext | Plaintext | Plaintext | Plaintext | | Source | Source | Group and | Group Addr| | Prefix | Host Part | Flags |"Host Part"| +-----------+-----------+-----------+-----------+ \\ || \\ || ,-------. ,-------. ( Hash ) ( Hash ) `-------' `-------' \\ || \\ || +-----------+-----------+-----------+-----------+ | Ciphertext| Ciphertext| Ciphertext| Ciphertext| | Source | Source | Group and | Group Addr| | Prefix | Host Part | Flags | LSB | +-----------+-----------+-----------+-----------+ Figure 7: Forming a ciphertext address pair from a plaintext address pair The ciphertext domain's prefix plus the hashed plaintext prefix form the "sender address", identical to the ciphertext domain unicast address. The ciphertext group address prefix plus the hashed host part of the plaintext group address creates the ciphertext multicast Baker, et al. Expires April 24, 2006 [Page 18] Internet-Draft Nested VPN Routing October 2005 group. If a given host in the plaintext domain requires multiple multicast groups, it creates multiple group addresses. 3.2. Routing to a remote address A host in a remote enclave determines the SSM channel identifier, an {S,G} address pair and joins it. The "join" heads toward the VPN Router, which performs the same transformation as noted in Section 3.1, and the ciphertext router of that system joins that multicast group. As an example, assume that the enclaves in Figure 4 have established unicast connectivity across the ciphertext domain via the procedure described in Section 2.2. Further assume that Host 4 is the source of a plaintext multicast group G. Host 1 learns of the SSM channel {Host 4, Group G} out of band. It joins towards this channel through normal MLDv2 [RFC3810] multicast listener report messaging. The plaintext router of VPN Router 1 receives the report, hashes the source prefix (Host 4) and the host part of the plaintext group address G, and communicates the hashed values to the ciphertext router. This triggers a join toward the ciphertext multicast channel supporting the plaintext channel. The original join is also directed across a unicast security association to the plaintext router of VPN Router 2, and continues joining toward Host 4. The ciphertext router joins towards the ciphertext domain connecting the enclaves using the source address formed by the procedure described in Section 2.2 and a ciphertext group address formed by combining its configured ciphertext multicast group prefix with the hashed host part of the plaintext group address G. A source-specific tree is constructed through the domain and a join reaches the ciphertext router of the source enclave's VPN router. The source VPN router creates join state for the multicast channel on its ciphertext router. When Host 4 transmits multicast packets on the channel, the plaintext router of its VPN router passes the (encrypted) packet to the ciphertext router along with a hash of the enclave unicast prefix and a hash of the host part of the plaintext group address G. The packet is forwarded down the source-specific tree within the ciphertext domain towards the VPN router fronting Host 1. The VPN router decrypts the packet and passes it to its plaintext router which forwards it to Host 1 due to the join state previously created via MLDv2. If the VPN routers do not border the same ciphertext domain, they must know of each other's configured ciphertext multicast prefixes prior to establishing the source-specific tree. They may learn of their respective ciphertext multicast prefixes through pre- configuration, or they may inform each other following the establishment of a unicast SA. Baker, et al. Expires April 24, 2006 [Page 19] Internet-Draft Nested VPN Routing October 2005 One approach to distribution of the encryption key used by the multicast data stream and the multicast group's group address in the ciphertext domain would be for VPN Router 1 to query VPN Router 2 in the black domain to determine what 48 bit group address portion, flags, and scope are in use and the key used for the channel. This would occur using the ciphertext domain's unicast security association. 3.3. Proving recursiveness Since the components required in Section 3.1 are the same at both levels, both levels work. 3.4. Issues (Author's notes to self) We need to deal with the possibility that the hash function produces collisions... Baker, et al. Expires April 24, 2006 [Page 20] Internet-Draft Nested VPN Routing October 2005 4. Key Management Procedures 4.1. Key Management Requirements The various ways that one hashes bits are checksum generation or cryptographic mechanisms. These generally use some initial data to parameterise the algorithm; this may be included in the result or used (such as in a CRC) to select feedback paths in the algorithm, or other approaches. For generality, in this document such parameters will be referred to as "keys". It is strongly desirable that a hypothetical security breach in one Internet protocol not automatically compromise other Internet protocols. A key configured for use in this specification SHOULD NOT be stored using protocols or algorithms that have known flaws. Implementations MUST support the storage of more than one key at the same time, although it is recognized that only one key will normally be active on an interface. They MUST associate a specific lifetime (i.e., date/time first valid and date/time no longer valid) and a key identifier with each key, and MUST support manual key distribution (e.g., the privileged user manually typing in the key, key lifetime, and key identifier on the router console). The lifetime may be infinite. If more than one algorithm is supported, then the implementation MUST require that the algorithm be specified for each key at the time the other key information is entered. Keys that are out of date MAY be deleted at will by the implementation without requiring human intervention. Manual deletion of active keys SHOULD also be supported. 4.2. Key Management Procedures As with all security methods using keys, it is necessary to change the key on a regular basis. To maintain routing stability during such changes, implementations MUST be able to store and use more than one Key on a given interface at the same time. Each key will have its own Key Identifier, which is stored locally. The combination of the Key Identifier and the interface associated with the datagram uniquely identifies the algorithm and key in use. As noted above, the VPN Router will select a valid key from the set of valid keys for that interface. The receiver will use the Key Identifier and interface to determine which key to use for authentication of the received datagram. More than one key may be associated with an interface at the same time. Hence it is possible to have fairly smooth Key rollovers without Baker, et al. Expires April 24, 2006 [Page 21] Internet-Draft Nested VPN Routing October 2005 losing legitimate traffic because the stored key is incorrect and without requiring people to change all the keys at once. To ensure a smooth rollover, each communicating VPN Router must be updated with the new key several minutes before the current key will expire and several minutes before the new key lifetime begins. The new key should have a lifetime that starts several minutes before the old key expires. This gives time for each VPN Router to learn of the new key before that key will be used. It also ensures that the new key will begin being used and the current key will go out of use before the current key's lifetime expires. For the duration of the overlap in key lifetimes, a system may receive datagrams using either key and authenticate the datagram. The Key-ID in the received datagram is used to select the appropriate key for authentication. 4.3. Pathological Cases Two pathological cases exist which must be handled, which are failures of the network manager. Both of these should be exceedingly rare. During key switchover, devices may exist which have not yet been successfully configured with the new key. Therefore, routers SHOULD implement (and would be well advised to implement) an algorithm that detects the set of keys being used by its neighbors, and transmits its datagrams using both the new and old keys until all of the neighbors are using the new key or the lifetime of the old key expires. Under normal circumstances, this elevated transmission rate will exist for a single update interval. In the event that the last key associated with an interface expires, it is unacceptable to revert to an unauthenticated condition, and not advisable to disrupt routing. Therefore, the router should send a "last authentication key expiration" notification to the network manager and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured. Baker, et al. Expires April 24, 2006 [Page 22] Internet-Draft Nested VPN Routing October 2005 5. Operational Considerations [RFC1958], in section 3, gives some general principles for making Internet technology that works well. Key points include: o Heterogeneity is inevitable and must be supported by design. o All designs must scale readily to very many nodes per site and to many millions of sites. o Performance and cost must be considered as well as functionality. o Keep it simple. When in doubt during design, choose the simplest solution. o Modularity is good. If you can keep things separate, do so. From the viewpoint of constructing technology that scales to a large network, this proposal obviously has some issues. One is that each VPN Router ends up with a host route per VPN Router in the network, which may have scaling issues and in any event makes route aggregation difficult. Another is that other technologies, including manual configuration and a form of database lookup, are already in use and need to be integrated with - and may have long-term utility in the network. This section attempts to address those issues. 5.1. Scaling issues in host routing One of the principles that has improved Internet scaling is that of information hiding: differing routing domains simple advertise a prefix or set of prefixes to each other and hide internal structure. Specifically, they don't advertise host addresses or LAN prefixes, and in some cases prefixes belonging to multiple ISPs and edge networks are aggregated to represent continental regions. On the other hand, at this writing, the Internet backbone reportedly carries about 150,000 routes in default-free routing. The conditions under which this is true are that BGP routing is used between domains and is essentially stable (a small percentage of routes are changing at any given time, but the bulk of routes are stable), and some form of link state routing is used within most non-edge domains. It seems rational to expect that an IP-based network is capable of carrying on the order of 50,000-75,000 host routes, 50-75K LAN routes within the black domain, and some number of external routes, if the same conditions apply. In general, given current technology, the matters driving aggregation of routes are more related to information assurance issues and administrative boundaries than the scaling of routing. Baker, et al. Expires April 24, 2006 [Page 23] Internet-Draft Nested VPN Routing October 2005 Therefore, we initially recommend that in stable domains the number of host routes within a single routing domain be engineered to not exceed 50,000. This recommendation may change in operational practice. 5.2. The place of manual configuration and server-based solutions Currently, customer-provisioned VPNs (of which this is an example) are generally configured manually. In certain cases, nested VPN routing is being implemented using a database solution which may be constructively compared to DNS: when an address or prefix must be found dynamically, a query is sent to a server, which replies with the necessary information. We would suggest that these can be accommodated into this proposal if the lookup for a Security Association follows this rule: o If a security association exists, it should be used. This would include any security association which had been set up dynamically as a result of some previous exchange, or any manually configured association. o Failing that, the routing table may be inquired of using an appropriate API. If a host route is found, the approach suggested in this document applies. o Failing that, the server should be queried. o Failing that, the peer is unknown. 5.3. Use Case for Enterprise Network The applicability of the rule described in Section Section 5.2 can be understood under the context of the use case shown in Figure 8. Baker, et al. Expires April 24, 2006 [Page 24] Internet-Draft Nested VPN Routing October 2005 _.--------. ,-'' `--. ,' PT Enclave 1 `. ,' +-----------+ `. / R1.H1 |PT-Router-1| \ ,---. ; |...........| : / \ |--------|E/D :: Mgmt|--------| / CT \ : |...........| ; B1.h(R1) ( Hub ) \ |CT-Router-1|.........................\ B1.H0 / `. +-----------+ ,' .-'\ / `. CT Enclave 1 ,' .' `--+' `--. _.-' .-' | `--------'' .-' | .-' | B1.h(R3).' |B1.h(R3) _.--------. .-' _.---+----. ,-'' `--. .-' ,-'' | `--. ,' CT Enclave 2 .'. ,' CT Enc|ave 3 `. ,' +-----------.-' `. ,' +-----+-----+ `. / |CT-Router 2| \ / |CT-Router-3| \ ; |...........| : ; |...........| : |--------|E/D :: Mgmt|--------| |--------|E/D :: Mgmt|--------| : |...........| ; : |...........| ; \ R2.H2 |PT-Router-2| / \ R3.H3 |PT-Router-3| / `. +-----------+ ,' `. +-----------+ ,' `. PT Enclave 2 ,' `. PT Enclave 3 ,' `--. _.-' `--. _.-' `--------'' `--------'' Figure 8: Routing in a Hub & Spoke VPN Figure 8 depicts a simple hub and spoke enterprise network employing the VPN routing approach described in this draft. Three VPN enclave sites are connected to each other via the ciphertext hub which also serves the enterprise headquarters and connects to the Internet. Multiple security associations between any two sites may be set up as neccessary. A typical operational scenario employing the solution described in this document would apply as follows: o The ciphertext address of VPN router (e.g. B1.h(H1)) at any given site is derived from the plaintext address of the VPN router (e.g. R1.H1) via the hash rule described in Section 1.4 o In this scenario both manual configuration or host routes would serve as a simple mechanism to route to a remote ciphertext address. If the enclave sites are expected to setup on-demand security associations between sites due to traffic needs or mobility, then host routes would better serve this dynamic nature Baker, et al. Expires April 24, 2006 [Page 25] Internet-Draft Nested VPN Routing October 2005 of the network. [Note: Scalability of host routes in such an enterprise network of even hundreds of enclaves is well within the limits of know network routing scalability]. Baker, et al. Expires April 24, 2006 [Page 26] Internet-Draft Nested VPN Routing October 2005 6. IANA Considerations This memo adds no new IANA considerations. Note to RFC Editor: This section will have served its purpose if it correctly tells IANA that no new assignments or registries are required, or if those assignments or registries are created during the RFC publication process. From the author's perspective, it may therefore be removed upon publication as an RFC at the RFC Editor's discretion. Baker, et al. Expires April 24, 2006 [Page 27] Internet-Draft Nested VPN Routing October 2005 7. Security Considerations The specification of a set of acceptable hash mechanisms is beyond the scope of this document. The choice of the exact hash algorithm(s) that may be employed is dependent on the security considerations of the customer provisioning the specific virtual private network. As described in Section 1.4, possible algorithm choices are defined in MD5 [RFC1321], FIPS PUB 180-1 (SHA1) and ITU-T Recommendation V.41, "Code-independent error-control system" (CRC-32). The appropriate choice of hash algorithm(s) can sufficiently secure the plaintext addresses which are hashed to derive ciphertext addresses. As an improvement to (static) configuration of ciphertext addresses within the plaintext databases of the VPN enclave, the automatic mechanism described in this document can easily complement other security procedures such as ciphertext address change on a pseudo-random or periodic basis without manual intervention. Baker, et al. Expires April 24, 2006 [Page 28] Internet-Draft Nested VPN Routing October 2005 8. Acknowledgements Commentary from Brian Weis and Dave McGrew was very helpful. Some concepts and questions also came from Bharat Doshi and his associates of the US DoD GIG Routing Working Group. Comments by Eric Fleischman helped improve the document. The authors of RFC 2082, from which the initial text of section 4 was remorselessly stolen, deserve credit for that contribution. Baker, et al. Expires April 24, 2006 [Page 29] Internet-Draft Nested VPN Routing October 2005 9. References 9.1. Normative References [I-D.ietf-ipv6-addr-arch-v4] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", draft-ietf-ipv6-addr-arch-v4-04 (work in progress), May 2005. [I-D.ietf-ssm-arch] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", draft-ietf-ssm-arch-07 (work in progress), October 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. 9.2. Informative References [I-D.ietf-rpsec-bgpsecrec] Christian, B. and T. Tauber, "BGP Security Requirements", draft-ietf-rpsec-bgpsecrec-02 (work in progress), July 2005. [I-D.ietf-rpsec-generic-requirements] McPherson, D., "Generic Security Requirements for Routing Protocols", draft-ietf-rpsec-generic-requirements-01 (work Baker, et al. Expires April 24, 2006 [Page 30] Internet-Draft Nested VPN Routing October 2005 in progress), January 2005. [I-D.ietf-rpsec-ospf-vuln] Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Analysis", draft-ietf-rpsec-ospf-vuln-01 (work in progress), December 2004. [I-D.ietf-rpsec-routing-threats] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", draft-ietf-rpsec-routing-threats-07 (work in progress), October 2004. [I-D.puig-rpsec-rqts-opened-questions] Puig, J., "Generic Security Requirements for Routing Protocols - Opened Questions", draft-puig-rpsec-rqts-opened-questions-01 (work in progress), January 2005. [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC1924] Elz, R., "A Compact Representation of IPv6 Addresses", RFC 1924, April 1996. [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC2764] Gleeson, B., Heinanen, J., Lin, A., Armitage, G., and A. Malis, "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000. Baker, et al. Expires April 24, 2006 [Page 31] Internet-Draft Nested VPN Routing October 2005 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC2917] Muthukrishnan, K. and A. Malis, "A Core MPLS IP VPN Architecture", RFC 2917, September 2000. [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003. [RFC3809] Nagarajan, A., "Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004. Baker, et al. Expires April 24, 2006 [Page 32] Internet-Draft Nested VPN Routing October 2005 Authors' Addresses Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, California 93117 USA Phone: +1-408-526-4257 Fax: +1-413-473-2403 Email: fred@cisco.com Pratik Bose Lockheed Martin 700 North Frederick Ave Gaithersburg, Maryland 20871 USA Phone: +1-301-240-7041 Fax: +1-301-240-5748 Email: pratik.bose@lmco.com Dan Voce Lockheed Martin 3201 Jermantown Road Fairfax, Virginia 22030 USA Phone: +1-703-293-5732 Fax: +1-703-293-4460 Email: daniel.voce@lmco.com Baker, et al. Expires April 24, 2006 [Page 33] Internet-Draft Nested VPN Routing October 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Baker, et al. Expires April 24, 2006 [Page 34]