Network Working Group F. Baker Internet-Draft Cisco Systems Expires: August 17, 2005 P. Bose D. Voce Lockheed Martin February 13, 2005 Routing in a Nested VPN draft-baker-nested-vpn-routing-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 August 17, 2005. 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. Baker, et al. Expires August 17, 2005 [Page 1] Internet-Draft Routing in a Nested VPN February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Nested Virtual Private Networks . . . . . . . . . . . . . 3 1.2 Defining Terms . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Fundamental Requirements for Routing . . . . . . . . . . . 5 1.4 Fundamental proposal: use of a one-way hash . . . . . . . 5 2. Unicast Routing Solution . . . . . . . . . . . . . . . . . . . 8 2.1 Static configuration . . . . . . . . . . . . . . . . . . . 9 2.2 Forming a ciphertext address from a plaintext prefix . . . 9 2.3 Routing between enclaves . . . . . . . . . . . . . . . . . 10 2.4 Routing to a remote address . . . . . . . . . . . . . . . 10 2.5 Proving recursiveness . . . . . . . . . . . . . . . . . . 11 2.6 Open Issues (Author's notes to self) . . . . . . . . . . . 12 3. Multicast Routing Solution - SSM . . . . . . . . . . . . . . . 14 3.1 Forming a ciphertext group address from a plaintext address . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2 Routing to a remote address . . . . . . . . . . . . . . . 16 3.3 Proving recursiveness . . . . . . . . . . . . . . . . . . 17 3.4 Issues (Author's notes to self) . . . . . . . . . . . . . 17 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1 Normative References . . . . . . . . . . . . . . . . . . . 21 7.2 Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 A. Additional stuff . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . 25 Baker, et al. Expires August 17, 2005 [Page 2] Internet-Draft Routing in a Nested VPN February 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. The concepts extend to IPv4, but with difficulty due to the number of bits available in the address. 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 / '-. , Baker, et al. Expires August 17, 2005 [Page 3] Internet-Draft Routing in a Nested VPN February 2005 `-------' \ / `-------' 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 (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 messages are sent without additional encryption. Cipher Text: A domain in which messages 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. Baker, et al. Expires August 17, 2005 [Page 4] Internet-Draft Routing in a Nested VPN February 2005 Domain: In the context of this document, the routing domain of relevance. This will be either a Cipher text or a Plain text domain. 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. 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. This is shown in Figure 2. Baker, et al. Expires August 17, 2005 [Page 5] Internet-Draft Routing in a Nested VPN February 2005 Plain text Unit Cipher text Unit +------------------+ +------------------+ |+----------------+| |+----------------+| ||Security Assoc. || +--------+ ||Security Assoc. || ||Management ++----+ Hash +----++Management || |+----------------+| +--------+ |+----------------+| |+----------------+| +--------+ |+----------------+| || IP +-----+Encrypt/+-----+ IP || |+----------------+| |Decrypt | |+----------------+| |+----------------+| +--------+ |+----------------+| || Link || || Link || |+----------------+| |+----------------+| +------------------+ +------------------+ Figure 2: VPN Router Functional Breakdown The interconnection function performs three basic functions: it o permits internal messages to cross between the plain text and cipher text units in specified cases, o encrypts or decrypts datagrams and passes them with a few specified parameters to the far side o hashes numbers and sends them to the far side. These hashes may be parameters of internal messages or of datagrams. The hash function accepts a number of 0 to 64 bits and hashes it according to an externally specific (e.g., not intrinsic to this specification) algorithm. Possible algorithms include CRCs, SHA1, MD5 hashes, etc. An important characteristic of such a one-way hash is that it lose information - that there not be a "one-to-one and onto" relationship between the input and the output. 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. Baker, et al. Expires August 17, 2005 [Page 6] Internet-Draft Routing in a Nested VPN February 2005 | 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 August 17, 2005 [Page 7] Internet-Draft Routing in a Nested VPN February 2005 2. Unicast Routing Solution +------+ +------+ +------+ |Host 1| |Host 1| |Host 1| +--+---+ +--+---+ +--+---+ | | | /--+-------------+-+--------------+---/ | +------+------+ |+-----------+| ||Plain text || |+-----------+| VPN Router | +--+ | | +--+ | |+-----------+| ||Cipher text || |+-----------+| +------+------+ | ,-----------+-----------------. ( IP Network ) `-------------+---------------' | +----+--------+ |+-----------+| ||Cipher text || |+-----------+| | +--+ | | +--+ | VPN Router |+-----------+| ||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? o How does the plain text prefix of the upper LAN or address of Host Baker, et al. Expires August 17, 2005 [Page 8] Internet-Draft Routing in a Nested VPN February 2005 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 Static configuration 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 ex. plaintext directory servers who 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 ex. to peer enterprise VPN routers or to enterprise headquarters). 2.2 Forming a ciphertext address from a plaintext prefix First, a VPN Router 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 Baker, et al. Expires August 17, 2005 [Page 9] Internet-Draft Routing in a Nested VPN February 2005 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 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). +----------------------+----------------------+ | 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 between enclaves 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 Routing to a remote address Let us imagine that the two enclaves in Figure 4 have just performed Baker, et al. Expires August 17, 2005 [Page 10] Internet-Draft Routing in a Nested VPN February 2005 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 message in an IPv6 datagram header and ships it to its friendly neighborhood router, which happens to be a VPN Router in this case. The VPN Router performs its defined encryption transformation, and in addition hashes the destination address /64 prefix and passes both to the cipher text side. The cipher text side first determines whether it has an active security association with any router whose address contains the hashed value as its host part. If so, it simply forwards the message using that security association. Failing such, however, it o searches its route table for any host route having that hashed value as the host part of the /128 address o If it finds one, uses the IKE procedure to open a security association and exchange keys, and o now sends the message using the new security association. If the route lookup or the security association fails, the message is dropped. The receiving unit follows standard IPsec tunnel-mode security procedures. Its cipher text side decrypts the message and hands it to the plain text side, which in turn directs it to its target. 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 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 Baker, et al. Expires August 17, 2005 [Page 11] Internet-Draft Routing in a Nested VPN February 2005 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 message 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 from H1 to H6 is encrypted and passed along. 2.6 Open Issues (Author's notes to self) How interface domain 1 and interface domain 2 find each other to exchange routing? We are assuming that there is an overarching routing domain at this level. Need to work out the details of this. Does this preclude anycast applications? Baker, et al. Expires August 17, 2005 [Page 12] Internet-Draft Routing in a Nested VPN February 2005 We need to deal with the possibility that the hash function produces collisions... These would include 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 August 17, 2005 [Page 13] Internet-Draft Routing in a Nested VPN February 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 group 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 [RFC3513] 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 August 17, 2005 [Page 14] Internet-Draft Routing in a Nested VPN February 2005 | 8 | 4 | 4 | 112 bits | +------ -+----+----+---------------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+---------------------------------------------+ Figure 6: IPv6 Multicast Address, from RFC 3513 As shown in Figure 7, the VPN Router's plain text side will join every multicast route in the enclave that might leave it. 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 +-----------+-----------+-----------+-----------+ | 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 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 groups for each the plain text domain. If a given host in the plain text domain requires multiple multicast groups, it creates multiple Baker, et al. Expires August 17, 2005 [Page 15] Internet-Draft Routing in a Nested VPN February 2005 group addresses. 3.2 Routing to a remote address A host in a remote enclave determines the SSM {S,G} address pair out of band (in a manner, often application-specific, not specified here), and joins it. The "join" heads toward the VPN Router, which performs the same transformation as noted in Section 3.1, and the ciphertext side of that system joins that multicast group. A host in a remote enclave determines the SSM {S,G} address pair out of band (in a manner, often application-specific, not specified here), and joins it. The "join" heads toward the VPN Router, which performs the same transformation as noted in Section 3.1, and the ciphertext side of that system joins that multicast group. As an example, assume that the enclaves in Figure 4 have established unicast connectivity across the cyphertext domain via the procedure described in Section 2.2. Further assume that Host 4 is the source of an plaintext multicast group G and the plaintext side of its VPN router has been configured to join towards this group. Host 1 learns of the SSM channel defined by Host 4 and Group G out of band. It joins towards this channel through normal MLDv2 [rfc3810] multicast listener report messaging. The plaintext side of its VPN router 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 side. The ciphertext side 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 side of the source enclave‚ÇÖs VPN router. The source VPN router creates join state for the multicast channel on its ciphertext side. When Host 4 transmits multicast packets on the channel, the plaintext side of its VPN router passes the (encrypted) packet to the cyphertext side 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 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 ciphertext domain, they must know of each other‚ÇÖs configured ciphertext multicast prefixes prior to establishing the source-specific tree. They may learn of Baker, et al. Expires August 17, 2005 [Page 16] Internet-Draft Routing in a Nested VPN February 2005 their respective ciphertext multicast prefixes through pre-configuration, or they may inform each other following the establishment of a unicast SA. 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 August 17, 2005 [Page 17] Internet-Draft Routing in a Nested VPN February 2005 4. IANA Considerations This document makes no request of the IANA. Note to RFC Editor: in the process assigning numbers and building IANA registries prior to publication, this section will have served its purpose. It may therefore be removed upon publication as an RFC. Baker, et al. Expires August 17, 2005 [Page 18] Internet-Draft Routing in a Nested VPN February 2005 5. 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 pseudorandom or periodic basis without manual intervention. Baker, et al. Expires August 17, 2005 [Page 19] Internet-Draft Routing in a Nested VPN February 2005 6. Acknowledgements Initial comment from Brian Weis and Dave McGrew was very helpful. Baker, et al. Expires August 17, 2005 [Page 20] Internet-Draft Routing in a Nested VPN February 2005 7. References 7.1 Normative References [I-D.ietf-ssm-arch] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", Internet-Draft draft-ietf-ssm-arch-06, September 2004. [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. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. 7.2 Informative References [I-D.ietf-rpsec-bgpsecrec] Christian, B., "BGP Security Requirements", Internet-Draft draft-ietf-rpsec-bgpsecrec-00, December 2004. [I-D.ietf-rpsec-generic-requirements] McPherson, D., "Generic Security Requirements for Routing Protocols", Internet-Draft draft-ietf-rpsec-generic-requirements-01, January 2005. [I-D.ietf-rpsec-ospf-vuln] Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Analysis", Internet-Draft draft-ietf-rpsec-ospf-vuln-01, December 2004. [I-D.ietf-rpsec-routing-threats] Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to Routing Protocols", Baker, et al. Expires August 17, 2005 [Page 21] Internet-Draft Routing in a Nested VPN February 2005 Internet-Draft draft-ietf-rpsec-routing-threats-07, October 2004. [I-D.puig-rpsec-rqts-opened-questions] Puig, J., "Generic Security Requirements for Routing Protocols - Opened Questions", Internet-Draft draft-puig-rpsec-rqts-opened-questions-01, 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. [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. [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, March 2000. [RFC2917] Muthukrishnan, K. and A. Malis, "A Core MPLS IP VPN Baker, et al. Expires August 17, 2005 [Page 22] Internet-Draft Routing in a Nested VPN February 2005 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. [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.baker@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 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 August 17, 2005 [Page 23] Internet-Draft Routing in a Nested VPN February 2005 Appendix A. Additional stuff Baker, et al. Expires August 17, 2005 [Page 24] Internet-Draft Routing in a Nested VPN February 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 August 17, 2005 [Page 25]