Network Working Group F. Baker Internet-Draft Cisco Systems Expires: January 18, 2006 P. Bose D. Voce Lockheed Martin July 17, 2005 Routing across Nested VPNs draft-baker-nested-vpn-routing-01 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 January 18, 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 January 18, 2006 [Page 1] Internet-Draft Nested VPN Routing July 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 between enclaves . . . . . . . . . . . . . . . . . 13 2.3.1 Routing between enclaves across a common ciphertext domain . . . . . . . . . . . . . . . . . . 13 2.3.2 Routing between enclaves across a multiple ciphertext domains . . . . . . . . . . . . . . . . . . 13 2.4 Routing to a remote address . . . . . . . . . . . . . . . 14 2.5 Proving recursiveness . . . . . . . . . . . . . . . . . . 14 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.1 Normative References . . . . . . . . . . . . . . . . . . . 26 8.2 Informative References . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 Baker, et al. Expires January 18, 2006 [Page 2] Internet-Draft Nested VPN Routing July 2005 A. Additional stuff . . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . 31 Baker, et al. Expires January 18, 2006 [Page 3] Internet-Draft Nested VPN Routing July 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 January 18, 2006 [Page 4] Internet-Draft Nested VPN Routing July 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 January 18, 2006 [Page 5] Internet-Draft Nested VPN Routing July 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 Plain Text: A domain in which datagrams are sent without additional encryption. Cipher Text: A domain in which datagrams are sent with additional encryption. Note that if there is an additional layer of encryption in the network beyond that provided by a given cipher text domain, a cipher text domain will be treated by that cipher text domain as if it were a plain text 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 Cipher text or a Plain text domain. Baker, et al. Expires January 18, 2006 [Page 6] Internet-Draft Nested VPN Routing July 2005 Enclave: A Plain text Domain, as seen from the Cipher text 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 plain text and cipher text 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 approach that has been suggested to date that truly leaks no information across domains (broadcast a request to all domains asking the right one to respond) has scalability issues in networks larger than a few tens or hundreds of enclaves. All other known approaches require some level of sharing of knowledge between domains - the CPE router creates, whether through configuration or some more dynamic process, a tunnel to a router across the cipher text domain by connecting to a specified cipher text 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: Baker, et al. Expires January 18, 2006 [Page 7] Internet-Draft Nested VPN Routing July 2005 Plain Text Router: A router that is entirely within the plaintext enclave network. Cipher Text 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 Cipher Text 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 Plain Text 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. Plain Text Router Cipher Text Router +------------------+ +------------------+ |+----------------+| +--------+ |+----------------+| ||Configuration || |Network | ||Configuration || ||Management ++----+Manager +----++Management || |+----------------+| +----+---+ |+----------------+| | | | | | |+----------------+| +----+---+ |+----------------+| || IP +-----+Encrypt/+-----+ IP || |+----------------+| |Decrypt | |+----------------+| |+----------------+| +--------+ |+----------------+| || Link || || Link || |+----------------+| |+----------------+| +------------------+ +------------------+ Figure 2: VPN Router Functional Breakdown The hash function accepts a number of 0 to 64 bits and hashes it Baker, et al. Expires January 18, 2006 [Page 8] Internet-Draft Nested VPN Routing July 2005 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 plain text side (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 January 18, 2006 [Page 9] Internet-Draft Nested VPN Routing July 2005 2. Unicast Routing Solution +------+ +------+ +------+ |Host 1| |Host 2| |Host 3| +--+---+ +--+---+ +--+---+ | | | /--+-------------+-+--------------+---/ | +------+------+ |+-----------+| ||Plain text || |+-----------+| VPN Router 1 | +--+ | | +--+ | |+-----------+| ||Cipher text|| |+-----------+| +------+------+ | ,-----------+-----------------. ( IP Network ) `-------------+---------------' | +----+--------+ |+-----------+| ||Cipher text|| |+-----------+| | +--+ | | +--+ | VPN Router 2 |+-----------+| ||Plain text || |+-----------+| +------+------+ | /---+--------------+-+-------------+--/ | | | +---+--+ +---+--+ +---+--+ |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 cipher text side of the VPN Router? Baker, et al. Expires January 18, 2006 [Page 10] Internet-Draft Nested VPN Routing July 2005 o How does the plain text prefix of the upper LAN or address of Host 1 relate to routing? o How does the corresponding cipher text 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 cipher text 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 IGP routing 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 January 18, 2006 [Page 11] Internet-Draft Nested VPN Routing July 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 plain text 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 plain text domain or disseminate them in other ways. As shown in Figure 5, knowing the prefix for the enclave LAN, the plain text side of the VPN Router hashes the prefix (the /64 or the appropriate subset of it) and communicates the hashed value to the cipher text side. That interface is similarly engaged in stateless address autoconfiguration. It uses the prefix from that side (whether configured or learned) with the hashed value to form an address for the cipher text side. 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 cipher text side. 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 cipher text-side address is now included in routing in the IP network on the cipher text side 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 January 18, 2006 [Page 12] Internet-Draft Nested VPN Routing July 2005 +----------------------+----------------------+ | IPv6 Prefix of | Host part of | | Plain text domain | IPv6 Address | +----------------------+----------------------+ \\ \\ ,---------------. ( Hash Function ) `---------------' \\ \\ +----------------------+----------------------+ | IPv6 Prefix of | Hashed Plain text | | Cipher text domain | IPv6 Address | +----------------------+----------------------+ Figure 5: Forming a unicast ciphertext address from a plaintext address 2.3 Routing between enclaves This system may obviously be used in two ways. It may be used across a common ciphertext domain, or across mulpitple ciphertext domains that route traffic through intermediate enclaves. 2.3.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.3.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 case, a network can be built across multiple plaintext domains. Baker, et al. Expires January 18, 2006 [Page 13] Internet-Draft Nested VPN Routing July 2005 2.4 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 plain text router, which happens to be a VPN Router in this case. Processing in the VPN router is a little different, however: o The plain 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]). 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 cipher text 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 cipher text datagram to the cipher text 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 cipher text router presents the datagram to the encrypt/decrypt unit, which decapsulates and decrypts it, and presents the resulting datagram to the plain text router. 2.5 Proving recursiveness The proof of recursiveness is simple. Consider Figure 1 and presume that H1 wishes to exchange files with H6. Baker, et al. Expires January 18, 2006 [Page 14] Internet-Draft Nested VPN Routing July 2005 When the networks come up, H1 derive its address from R1 and H6 derives its address from R6. VPN1's plain text side 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 cipher text-side 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 cipher text 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 cipher text domain. It hashes the /64 of the datagram's source address and passes that to the cipher text side. There is no corresponding security association, but VPN6's cipher text-side address shows up in routing, with R7 as the next hop. VPN1 now opens a security association with VPN6, meaning that its cipher text side 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 cipher text domain. It hashes the /64 of the datagram's source address and passes that to its cipher text side. There is no corresponding security association, but VPN8's cipher text-side address shows up in routing, with R9 as the next hop. VPN7 now opens a security association with VPN8, meaning that its cipher text side must 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 Baker, et al. Expires January 18, 2006 [Page 15] Internet-Draft Nested VPN Routing July 2005 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 cipher text 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 January 18, 2006 [Page 16] Internet-Draft Nested VPN Routing July 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 cipher text side of the VPN Router? o How does the plain text address Host 1 relate to routing of a multicast group used by Host 1? o How does the corresponding cipher text group address relate to routing? o How does a host in a remote enclave determine the plain text group address and join it? o How does a VPN Router in front of a remote enclave determine the corresponding cipher text 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 cipher text side 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 plain text group address. Baker, et al. Expires January 18, 2006 [Page 17] Internet-Draft Nested VPN Routing July 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 cipher text domain and unknown to the plain text side o The IPv6 prefix used for unicast addresses in the cipher text domain. o The hashed prefix part of the plain text side sender address o The hashed "host part" of the plain text side group address +-----------+-----------+-----------+-----------+ | Plain text| Plain text| Plain text| Plain text| | Source | Source | Group and | Group Addr| | Prefix | Host Part | Flags |"Host Part"| +-----------+-----------+-----------+-----------+ \\ || \\ || ,-------. ,-------. ( Hash ) ( Hash ) `-------' `-------' \\ || \\ || +-----------+-----------+-----------+-----------+ |Cipher text|Cipher text|Cipher text|Cipher text| | Source | Source | Group and | Group Addr| | Prefix | Host Part | Flags | LSB | +-----------+-----------+-----------+-----------+ Figure 7: Forming a ciphertext address pair from a plaintext address pair The cipher text domain's prefix plus the hashed plain text prefix form the "sender address", identical to the cipher text domain unicast address. The cipher text group address prefix plus the hashed host part of the sender address creates multiple multicast Baker, et al. Expires January 18, 2006 [Page 18] Internet-Draft Nested VPN Routing July 2005 groups for each the plain text domain. If a given host in the plain text 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 cipher text side of that system joins that multicast group. As an example, assume that the enclaves in Figure 4 have established unicast connectivity across the cipher text domain via the procedure described in Section 2.2. Further assume that Host 4 is the source of a plain text 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 plain text side of VPN Router 1 receives the report, hashes the source prefix (Host 4) and the host part of the plain text group address G, and communicates the hashed values to the cipher text side. This triggers a join toward the cipher text multicast channel supporting the plain text channel. The original join is also directed across a unicast security association to the plain text side of VPN Router 2, and continues joining toward Host 4. The cipher text side joins towards the cipher text domain connecting the enclaves using the source address formed by the procedure described in Section 2.2 and a cipher text group address formed by combining its configured cipher text multicast group prefix with the hashed host part of the plain text group address G. A source-specific tree is constructed through the domain and a join reaches the cipher text side of the source enclave's VPN router. The source VPN router creates join state for the multicast channel on its cipher text side. When Host 4 transmits multicast packets on the channel, the plain text side of its VPN router passes the (encrypted) packet to the cipher text side along with a hash of the enclave unicast prefix and a hash of the host part of the plain text group address G. The packet is forwarded down the source-specific tree within the cipher text domain towards the VPN router fronting Host 1. The VPN router decrypts the packet and passes it to its plain text side which forwards it to Host 1 due to the join state previously created via MLDv2. If the VPN routers do not border the same cipher text domain, they must know of each other's configured cipher text multicast prefixes prior to establishing the source-specific tree. They may learn of their respective cipher text multicast prefixes through pre- configuration, or they may inform each other following the Baker, et al. Expires January 18, 2006 [Page 19] Internet-Draft Nested VPN Routing July 2005 establishment of a unicast SA. One approach to distribution of the encryption key used by the multicast data stream and the multicast group's group address in the cipher text 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 cipher text 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 January 18, 2006 [Page 20] Internet-Draft Nested VPN Routing July 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 January 18, 2006 [Page 21] Internet-Draft Nested VPN Routing July 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 January 18, 2006 [Page 22] Internet-Draft Nested VPN Routing July 2005 5. IANA Considerations This memo adds no new IANA considerations. The presence of this template text indicates that the author/editor has not actually reviewed 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 January 18, 2006 [Page 23] Internet-Draft Nested VPN Routing July 2005 6. 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 plain text addresses which are hashed to derive cipher text addresses. As an improvement to (static) configuration of cipher text addresses within the plain text databases of the VPN enclave, the automatic mechanism described in this document can easily complement other security procedures such as cipher text address change on a pseudo-random or periodic basis without manual intervention. Baker, et al. Expires January 18, 2006 [Page 24] Internet-Draft Nested VPN Routing July 2005 7. Acknowledgements Commentary from Brian Weis and Dave McGrew was very helpful. 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 January 18, 2006 [Page 25] Internet-Draft Nested VPN Routing July 2005 8. References 8.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-06 (work in progress), September 2004. [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. 8.2 Informative References [I-D.ietf-rpsec-bgpsecrec] Christian, B., "BGP Security Requirements", draft-ietf-rpsec-bgpsecrec-01 (work in progress), February 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 January 18, 2006 [Page 26] Internet-Draft Nested VPN Routing July 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. [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. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Baker, et al. Expires January 18, 2006 [Page 27] Internet-Draft Nested VPN Routing July 2005 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. 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 22300 Comsat Drive Clarksburg, Maryland 20871 USA Phone: +1-301-428-4215 Fax: +1-301-428-5414 Email: pratik.bose@lmco.com Baker, et al. Expires January 18, 2006 [Page 28] Internet-Draft Nested VPN Routing July 2005 Dan Voce Lockheed Martin 22300 Comsat Drive Clarksburg, Maryland 20871 USA Phone: +1-301-428-? Fax: +1-301-428-? Email: daniel.voce@lmco.com Baker, et al. Expires January 18, 2006 [Page 29] Internet-Draft Nested VPN Routing July 2005 Appendix A. Additional stuff Baker, et al. Expires January 18, 2006 [Page 30] Internet-Draft Nested VPN Routing July 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Baker, et al. Expires January 18, 2006 [Page 31]