idnits 2.17.1 draft-baker-nested-vpn-routing-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1228. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1241. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 461 has weird spacing: '...aintext domai...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 21, 2005) is 6761 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-ssm-arch' is defined on line 1063, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 1083, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rpsec-bgpsecrec' is defined on line 1094, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rpsec-generic-requirements' is defined on line 1099, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rpsec-ospf-vuln' is defined on line 1104, but no explicit reference was found in the text == Unused Reference: 'I-D.puig-rpsec-rqts-opened-questions' is defined on line 1114, but no explicit reference was found in the text == Unused Reference: 'RFC1924' is defined on line 1127, but no explicit reference was found in the text == Unused Reference: 'RFC2461' is defined on line 1136, but no explicit reference was found in the text == Unused Reference: 'RFC2547' is defined on line 1140, but no explicit reference was found in the text == Unused Reference: 'RFC2764' is defined on line 1147, but no explicit reference was found in the text == Unused Reference: 'RFC2917' is defined on line 1155, but no explicit reference was found in the text == Unused Reference: 'RFC3569' is defined on line 1158, but no explicit reference was found in the text == Unused Reference: 'RFC3849' is defined on line 1168, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) == Outdated reference: A later version (-10) exists of draft-ietf-rpsec-bgpsecrec-02 == Outdated reference: A later version (-02) exists of draft-ietf-rpsec-ospf-vuln-01 -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) Summary: 8 errors (**), 0 flaws (~~), 18 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Baker 3 Internet-Draft Cisco Systems 4 Expires: April 24, 2006 P. Bose 5 D. Voce 6 Lockheed Martin 7 October 21, 2005 9 Routing across Nested VPNs 10 draft-baker-nested-vpn-routing-02 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 24, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document discusses the general problem of routing in an IPv6 44 Nested Virtual Private Network. A solution is proposed based on one- 45 way hashes of IP Prefix values. The concepts extend to IPv4, but 46 with difficulty due to the number of bits in question. 48 Requirements Language 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC 2119 [RFC2119]. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Nested Virtual Private Networks . . . . . . . . . . . . . 5 57 1.2. Defining Terms . . . . . . . . . . . . . . . . . . . . . . 6 58 1.3. Fundamental Requirements for Routing . . . . . . . . . . . 7 59 1.4. Fundamental proposal: use of a one-way hash . . . . . . . 7 61 2. Unicast Routing Solution . . . . . . . . . . . . . . . . . . . 10 62 2.1. Inner domain routing . . . . . . . . . . . . . . . . . . . 11 63 2.2. Forming a ciphertext address from a plaintext prefix . . . 12 64 2.3. Routing to a remote address . . . . . . . . . . . . . . . 13 65 2.4. Routing between enclaves . . . . . . . . . . . . . . . . . 14 66 2.4.1. Routing between enclaves across a common 67 ciphertext domain . . . . . . . . . . . . . . . . . . 14 68 2.4.2. Routing between enclaves across a multiple 69 ciphertext domains . . . . . . . . . . . . . . . . . . 14 70 2.5. Proving recursiveness . . . . . . . . . . . . . . . . . . 15 71 2.6. Open Issues (Author's notes to self) . . . . . . . . . . . 16 73 3. Multicast Routing Solution - SSM . . . . . . . . . . . . . . . 17 74 3.1. Forming a ciphertext group address from a plaintext 75 address . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 3.2. Routing to a remote address . . . . . . . . . . . . . . . 19 77 3.3. Proving recursiveness . . . . . . . . . . . . . . . . . . 20 78 3.4. Issues (Author's notes to self) . . . . . . . . . . . . . 20 80 4. Key Management Procedures . . . . . . . . . . . . . . . . . . 21 81 4.1. Key Management Requirements . . . . . . . . . . . . . . . 21 82 4.2. Key Management Procedures . . . . . . . . . . . . . . . . 21 83 4.3. Pathological Cases . . . . . . . . . . . . . . . . . . . . 22 85 5. Operational Considerations . . . . . . . . . . . . . . . . . . 23 86 5.1. Scaling issues in host routing . . . . . . . . . . . . . . 23 87 5.2. The place of manual configuration and server-based 88 solutions . . . . . . . . . . . . . . . . . . . . . . . . 24 89 5.3. Use Case for Enterprise Network . . . . . . . . . . . . . 24 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 95 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 97 9.1. Normative References . . . . . . . . . . . . . . . . . . . 30 98 9.2. Informative References . . . . . . . . . . . . . . . . . . 30 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 101 Intellectual Property and Copyright Statements . . . . . . . . . . 34 103 1. Introduction 105 This document discusses the general problem of routing in an IPv6 106 Nested Virtual Private Network. A solution is proposed based on one- 107 way hashes of IP Prefix values, or equivalently, the use of encrypted 108 prefix values. The concepts extend to IPv4, but with difficulty due 109 to the number of bits available in the address. 111 1.1. Nested Virtual Private Networks 113 / \ 114 ( +--+ +--+ enclave ) ,---------. 115 .----------. \ |H2+---+R2| / ,-' ` 116 +--+ +--+`--.\ +--+ ++-+ / / +--+ +--+ 117 |H1+---+R1| \`. | ,' / |R3+---+H3| 118 +--+ +-++ ) '--. +----++ _.-' ( ++-+ +--+ 119 | / _.`---|VPN2||''-. \ | 120 enclave +----+-i.--'' +----++ `----.\ +----+ enclave 121 --------|VPN1|' | ``|VPN3| , 122 ,+----+ | +----+------' 123 ,' --+-------+----------+------------------+---`. 124 ,' ++-+ `. 125 ,' |R7+--------+ `. 126 / interface +--+ | \ 127 domain 1 +-+--+ \ 128 _.--------|VPN7|--------. 129 ,-----'' +--+-+ `------. . 130 `-. ,-' | `-. .-' 131 `-: inner domain +-++ `.' 132 ( |R9| ) 133 .'. ++-+ ;-. 134 .' `-. | ,-' `-. 135 ' `------. +-+--+ _.-----' ` 136 interface `---------|VPN8|-------'' 137 domain 2 +-+--+ / 138 \ | +--+ / 139 `. +----------+R8| ,' 140 `. ++-+ ,' 141 `. --+------------------+-----------+------+-- ,' 142 ,-----+----+ | +----+------. 143 ,' |VPN6|. | _.|VPN4| ` 144 +----+.`----. +----+ _.--'' ,+----+ 145 | \ `--=.-|VPN5|---:' / | 146 +--+ ++-+ : ,-'' +----+ `--. ; ++-+ +--+ 147 |H6+---+R6| | ,' | `.| |R4+---+H4| 148 +--+ +--+ ;/ +--+ ++-+ : +--+ +--+ 149 // |H5+---+R5| \ 150 enclave ,'( +--+ +--+ `. enclave 151 `. ,' \ enclave / '-. , 152 `-------' \ / `-------' 154 Figure 1: Nested Virtual Private Network 156 Figure 1 shows what the authors have described as a "Nested VPN". 157 Like normal VPNs, this is a network that has a variety of enclaves 158 that communicate across an encrypted cloud that is invisible to them 159 (apart from effects such as delay or jitter) and to which they are 160 invisible. It differs in that the construct is recursive - such 161 encrypted clouds may themselves appear to be enclaves to further 162 underlying VPN networks - and that little or no information is 163 permitted to cross the boundary and yet any enclave must be enabled 164 to communicate with any other enclave at the same nesting level. 166 Normal VPNs tend to be managed in one of two ways. One is that a 167 service provider offers the VPN, and provides an underlying circuit 168 network, often MPLS, that connects the underlying endpoints as 169 defined in a contract. These are referred to as "Provider- 170 Provisioned VPNs" [RFC3809]. The other, generally referred to as 171 "customer-provisioned", is that the edge routers themselves provide 172 tunnels over an underlying network using one of a variety of types of 173 IP tunnel technologies loose source routes as specified in DVMRP 174 [RFC1075], IP/IP [RFC2003], IPsec/ESP [RFC2401][RFC2406], L2TP 175 [RFC2661], GRE [RFC2784], and others. 177 In this context, a "Nested VPN" is an example of an IPsec or IPsec- 178 like VPN, and is therefore "customer-provisioned". Such networks 179 have in the past been built in a very ad hoc fashion, without 180 significant knowledge or concern for the underlying network 181 infrastructure. They have often consisted of either a haphazard 182 collection of tunnels, or a star or multi-star network in which a 183 large set of client sites maintain static or semi-static tunnels with 184 a much smaller set of service sites. Such networks support 185 telecommuters working from home offices, small distributed companies, 186 and so on. 188 1.2. Defining Terms 190 Plaintext Domain: A network domain in which datagrams are sent 191 without additional encryption. 193 Ciphertext Domain: A network domain in which datagrams that 194 originated in a plaintext domain are sent with additional 195 encryption. Note that if there is an additional layer of 196 encryption in the network beyond that provided by a given 197 ciphertext domain, a ciphertext domain will be treated by that 198 ciphertext domain as if it were a plaintext domain - traffic 199 entering it will be encrypted, and traffic leaving it will be 200 decrypted. 202 Domain: In the context of this document, the routing domain of 203 relevance. This will be either a ciphertext or a plaintext 204 domain. 206 Enclave: A plaintext Domain, as seen from the ciphertext domain 208 One Way Hash: One of a variety of approaches that scramble the bits 209 in a string or number to produce a different one, and from which 210 the original cannot be deduced. Examples, include CRCs, MD5, etc. 211 Encrypted addresses have also been suggested, and would work in 212 this context, but require management of the ability to decrypt the 213 address, via key management. 215 VPN Router: A special case of a router supporting IPsec or IPsec- 216 like tunnels over an IP network, and having the characteristic 217 that information leakage between plaintext and ciphertext parts of 218 the same router is absolutely minimal - ideally zero. 220 1.3. Fundamental Requirements for Routing 222 [I-D.ietf-rpsec-routing-threats] describes in general terms the 223 threats that one deals with in routing, and [I-D.ietf-rpsec-generic- 224 requirements] describes general security requirements for routing. 225 They might be summarized as relating to four basic attack vectors: 226 authenticity of the channel, privacy of the channel (both of which 227 might be adequately addressed by IPsec), correctness of the data, and 228 scalability to the network design in question. These issues apply to 229 any routing solution. 231 In addition, nested VPNs in this context require as close to zero 232 information leakage as possible between domains. Note that as a 233 practical matter this is not quite "zero"; the only proposal that the 234 authors are aware of that truly leaks no information across domains 235 has scalability issues in networks larger than a few tens or hundreds 236 of enclaves (i.e. broadcast a request to all domains asking the right 237 one to respond). All other known approaches require some level of 238 sharing of knowledge between domains - the CE router creates, whether 239 through configuration or some more dynamic process, a tunnel to a 240 router across the ciphertext domain by connecting to a specified 241 ciphertext domain address. 243 1.4. Fundamental proposal: use of a one-way hash 245 First, imagine that a VPN Router consists of two independent 246 functional elements, whether physical or logical, and information 247 crosses between them through a narrowly defined interconnection 248 function. These four functions are: 250 Plaintext Router: A router that is entirely within the plaintext 251 enclave network. 253 Ciphertext Router: A router that is entirely within the ciphertext 254 network. 256 Encrypt/Decrypt Unit: A functional element (either an interface card 257 or a separate device) with three interfaces: 259 * A local interface to the plaintext router, in which datagrams 260 are passed as IP datagrams associated with a plaintext network 261 next hop address. Such datagrams are encrypted using IPsec 262 ESP's [RFC2406] Tunnel Mode, and passed to the Ciphertext 263 Router. 265 * An interface to the ciphertext router, which is or is 266 functionally equivalent to a LAN interface. Messages received 267 on it are decrypted and handed to the Plaintext Router. 269 * A network management interface, which enables the programming 270 of security associations in the encrypt/decrypt process. 272 Network Manager A functional element (software or hardware) that is 273 capable of programming security associations and passes narrowly 274 defined communications between the plaintext and ciphertext 275 routers. These communciations might include configuration 276 information and commands to generate or forward QoS signaling. 278 Such a configuration is shown in Figure 2. 280 Plaintext Router Ciphertext Router 281 +------------------+ +------------------+ 282 |+----------------+| +--------+ |+----------------+| 283 ||Configuration || |Network | ||Configuration || 284 ||Management ++----+Manager +----++Management || 285 |+----------------+| +----+---+ |+----------------+| 286 | | | | | 287 |+----------------+| +----+---+ |+----------------+| 288 || IP +-----+Encrypt/+-----+ IP || 289 |+----------------+| |Decrypt | |+----------------+| 290 |+----------------+| +--------+ |+----------------+| 291 || Link || || Link || 292 |+----------------+| |+----------------+| 293 +------------------+ +------------------+ 295 Figure 2: VPN Router Functional Breakdown 297 Typically the relationship between the different functions in 298 Figure 2 does not change for a given operational configuration and a 299 unique mapping exists between Plaintext IP address to Ciphertext IP 300 address. The hash function accepts a number of 0 to 64 bits and 301 hashes it according to an externally specific (e.g., not intrinsic to 302 this specification) algorithm. Possible algorithms include CRCs, 303 SHA1, MD5 hashes, AES encryption, etc. 305 Coupled with Stateless Address Autoconfiguration [RFC2462] and 306 specifically its Privacy extensions [RFC3041], this enables us to 307 create a host part of an IPv6 address based on a randomized number 308 taken from the enclave and build an address based on it unknown on 309 the plaintext router (either within the enclave or in any remote 310 enclave) but in a certain sense predictable by it. 312 | 64 bit component | 64 bit component | 313 +----------------------+----------------------+ 314 | IPv6 Prefix | IPv6 host part | 315 +----------------------+----------------------+ 316 | | 317 | | 318 | | 319 ,-------. 320 ( Hash ) 321 `-------' 322 | | 323 | | 324 | | 64 bit result 325 +----------------------+ 326 | Hashed number | 327 +----------------------+ 329 Figure 3: One-way Hash 331 2. Unicast Routing Solution 332 +------+ +------+ +------+ 333 |Host 1| |Host 2| |Host 3| 334 +--+---+ +--+---+ +--+---+ 335 | | | 336 /--+-------------+-+--------------+---/ 337 | 338 +------+------+ 339 |+-----------+| 340 ||plaintext || 341 |+-----------+| VPN Router 1 342 | +--+ | 343 | +--+ | 344 |+-----------+| 345 ||ciphertext || 346 |+-----------+| 347 +------+------+ 348 | 349 ,-----------+-----------------. 350 ( IP Network ) 351 `-------------+---------------' 352 | 353 +----+--------+ 354 |+-----------+| 355 ||ciphertext || 356 |+-----------+| 357 | +--+ | 358 | +--+ | 359 VPN Router 2 |+-----------+| 360 ||plaintext || 361 |+-----------+| 362 +------+------+ 363 | 364 /---+--------------+-+-------------+--/ 365 | | | 366 +---+--+ +---+--+ +---+--+ 367 |Host 4| |Host 5| |Host 6| 368 +------+ +------+ +------+ 370 Figure 4: Unicast Example 372 Let us work through an example of unicast use. Figure 4 shows a 373 simple case of a VPN. The fundamental problems are: 375 o Given a prefix on the LAN in the upper enclave, how does one form 376 an address on the ciphertext router of the VPN Router? 378 o How does the plaintext prefix of the upper LAN or address of Host 379 1 relate to routing? 381 o How does the corresponding ciphertext prefix or address relate to 382 routing? 384 o How does a host in a remote enclave determine the address of Host 385 1? 387 o How does a host in a remote enclave direct a datagram to the 388 appropriate VPN Router to get it to Host 1? 390 o Presuming that the two VPN Routers are unknown to each other, how 391 do they form the appropriate security association? 393 2.1. Inner domain routing 395 IPSec or IPSec like routers currently support static configuration of 396 ciphertext addresses in security databases. These addresses are used 397 by the VPN router to initialize security associations to a set of 398 well-known ciphertext addresses. The mechanism to dynamically create 399 and discover new or changing ciphertext addresses as described in 400 this document complements the static configuration mechanism or other 401 legacy mechanisms (for example, directory servers could resolve 402 ciphertext address queries). Static configuration of a known set of 403 ciphertext addresses on a VPN router is useful in setting up default 404 security associations (for example to peer enterprise VPN routers or 405 to enterprise headquarters). 407 In the inner domain of Figure 1 , the authors consider it likely that 408 security associations between VPN8 and VPN7 are likely to be 409 statically configured, allowing routing protocols (e.g. IGP) to run 410 over them as through a tunnel. This connects the routing of the 411 interface domains, enabling the alogrithm described in Section 2.2 to 412 work properly. 414 In addition, other approaches exist to distribute routing information 415 in the core. For example, one could use Mobile IP to connect to a 416 central "Home Agent" within the ciphertext domain which would be able 417 to provide, through Optimized Routing, the address of the proper peer 418 as a Care-of Address. Having established that relationship, OSPF 419 with the Do-Not-Age flag could allow the domains to exchange routing 420 information but not have to maintain continuous routing relationships 421 thereafter. Another alternative would be a directory service similar 422 to LDAP or DNS that could associate the hashed nonce with the 423 ciphertext address located within the ciphertext domains. 425 2.2. Forming a ciphertext address from a plaintext prefix 427 First, a VPN Router (as shown in Figure 2) is in every sense a 428 router, as defined by the IPv6 Architecture [RFC2460], which defines 429 a router as any "node that forwards IPv6 packets not explicitly 430 addressed to itself. " As a router, it may advertise (using 431 theStateless Address Autoconfiguration [RFC2462] Router 432 Advertisement) a prefix into its plaintext domain, or it may pick up 433 similar advertisements from another router. It and the other hosts 434 in the enclave form addresses within the enclave's prefix as 435 specified in that procedure, and may subsequently advertise these 436 addresses in DNS in the plaintext domain or disseminate them in other 437 ways. 439 As shown in Figure 5, knowing the prefix for the enclave LAN, the 440 plaintext router of the VPN Router hashes the prefix (the /64 or the 441 appropriate subset of it) and communicates the hashed value to the 442 ciphertext router. That interface is similarly engaged in stateless 443 address autoconfiguration. It uses the prefix from that router 444 (whether configured or learned) with the hashed value to form an 445 address for the ciphertext router. 447 There are two approaches to placing multiple LANs within an enclave. 448 One is to have the VPN Router participate in routing within the 449 enclave, and form multiple such addresses on the ciphertext router. 450 Another is to use a shorter prefix in each enclave, such as perhaps a 451 /60. A /60 would permit every enclave to support 16 IPv6 LANs 452 without expanding routing. 454 The ciphertext-router address is now included in routing in the IP 455 network on the ciphertext router as a host route (/128), or may be 456 distributed in an OSPF Opaque LSA (if the routing domain is entirely 457 OSPF). 459 +----------------------+----------------------+ 460 | IPv6 Prefix of | Host part of | 461 | plaintext domain | IPv6 Address | 462 +----------------------+----------------------+ 463 \\ 464 \\ 465 ,---------------. 466 ( Hash Function ) 467 `---------------' 468 \\ 469 \\ 470 +----------------------+----------------------+ 471 | IPv6 Prefix of | Hashed plaintext | 472 | ciphertext domain | IPv6 Address | 473 +----------------------+----------------------+ 475 Figure 5: Forming a unicast ciphertext address from a plaintext 476 address 478 2.3. Routing to a remote address 480 Let us imagine that the two enclaves in Figure 4 have just performed 481 the procedure in Section 2.2 and at this point have no active 482 security association. Host 4 is able to determine the address of 483 Host 1 via DNS, and wishes to commune with it. 485 Host 4 is essentially unaware of the network connecting it to Host 1, 486 and unaware of the presence or absence of a VPN Router. Like any 487 IPv6 host, it encapsulates the datagram in an IPv6 datagram header 488 and ships it to its friendly neighborhood plaintext router, which 489 happens to be a VPN Router in this case. Processing in the VPN 490 router is a little different, however: 492 o The plaintext router first determines the next hop address (via 493 routing functions such as OSPF or BGP). 495 o It then determines whether there is an established security 496 association from the Network Management process 498 o if not, it lets the Network Management process establish such an 499 association (see [RFC2401]). Accomplishing this requires 501 * Identifying the remote ciphertext router. The Network manager 502 enquires of the local ciphertext router whether there is one or 503 more host routes (/128) whose host part equals the hash of the 504 remote plaintext prefix. 506 * If so, it establishes a security association to the specified 507 address. It may try them sequentially or in parallel, and it 508 may choose to leave all such associations open or to close the 509 ones that are not useful, per local policy. 511 o It then presents either the next hop address or the SPI that has 512 been associated with it, with the datagram, to the encrypt/decrypt 513 unit. 515 o The encrypt/decrypt unit derives the appropriate remote ciphertext 516 address from the security association information stored in it. 518 o Having encrypted the datagram and appropriately re-encapsulated 519 it, the encrypt/decrypt unit presents the ciphertext datagram to 520 the ciphertext router. 522 If at any point in this process the route lookup or the security 523 association fails, the datagram is dropped. 525 The receiving process follows standard IPsec tunnel-mode security 526 procedures. The ciphertext router presents the datagram to the 527 encrypt/decrypt unit, which decapsulates and decrypts it, and 528 presents the resulting datagram to the plaintext router. 530 2.4. Routing between enclaves 532 This system may obviously be used in two ways. It may be used across 533 a common ciphertext domain, or across multiple ciphertext domains 534 that route traffic through intermediate enclaves. 536 2.4.1. Routing between enclaves across a common ciphertext domain 538 Once the security association is set up between two VPN routers, the 539 respective enclaves can exchange routing information in the security 540 association. As an example, if the two disjoint enclaves learn 541 routes inside their respective enclaves via the use of an IGP 542 protocol like OSPF, OSPF route advertisements can be exchanged in the 543 security association which is set up using the procedure described 544 above. Hence hosts and routers within each enclave learn routes from 545 the remote enclave using the same protocol that is used within their 546 enclave via the invisible security association between the VPN 547 routers. 549 2.4.2. Routing between enclaves across a multiple ciphertext domains 551 By extension, if a router in an intermediate enclave establishes 552 relationships with multiple plaintext peers, it has the option to 553 advertise its capability as a transit path between them. In this 554 case, a network can be built across multiple plaintext domains. 556 2.5. Proving recursiveness 558 The proof of recursiveness is simple. Consider Figure 1 and presume 559 that H1 wishes to exchange files with H6. 561 When the networks come up, H1 derive its address from R1 and H6 562 derives its address from R6. VPN1's plaintext router participates in 563 the routing, and learns of the two LANs in the domain, or learns of 564 the shorter prefix encompassing them if that is the case in this 565 network. It forms a ciphertext-router address for each relevant 566 prefix. Similarly, VPN6 participates in the routing of its domain 567 and forms relevant addresses. So also the other peripheral enclaves. 568 Routing to those host addresses is injected into the routing of 569 interface domain 1 and interface domain 2. 571 This is also true of interface domain 1 and interface domain 2. VPN7 572 and VPN8 see the interface domains as enclaves and the inner domain 573 as a ciphertext domain. VPN7 and VPN8 form addresses in the inner 574 domain from the prefixes used in the interface domains, and advertise 575 corresponding host routes into the routing of the inner domain. 577 So: 579 o Host H1 sends a datagram to H6, passing it to R1. 581 o R1 passes it along its default route, to VPN1. 583 o VPN1 finds that the next hop towards H6 is VPN6, either by 584 inspection of the prefix or by knowledge from routing, and knows 585 that this is across the ciphertext domain. It hashes the /64 of 586 the datagram's source address and passes that to the ciphertext 587 router. There is no corresponding security association, but 588 VPN6's ciphertext-router address shows up in routing, with R7 as 589 the next hop. VPN1 now opens a security association with VPN6, 590 meaning that its ciphertext router must send a datagram to VPN6. 592 o The SA-Open datagram is handed to R7, which hands it to VPN7. 594 o VPN7 finds that the next hop towards VPN6 is VPN8, either by 595 inspection of the prefix or by knowledge from routing, and knows 596 that this is across the inner ciphertext domain. It hashes the 597 /64 of the datagram's source address and passes that to its 598 ciphertext router. There is no corresponding security 599 association, but VPN8's ciphertext-router address shows up in 600 routing, with R9 as the next hop. VPN7 now opens a security 601 association with VPN8, meaning that its ciphertext router must 602 send a datagram to VPN8. 604 o The IKE exchange happens between VPN7 and VPN8, and when the 605 relationship is accepted, the datagram initiating the IKE exchange 606 between VPN1 and VPN6 is encrypted and passed along. 608 o The IKE exchange happens between VPN1 and VPN6, and when the 609 relationship is accepted, the datagram initiating the datagram 610 from H1 to H6 is encrypted and passed along. 612 2.6. Open Issues (Author's notes to self) 614 Anycast: Does this preclude anycast applications? 616 Hash collisions: A good hash such as SHA should keep the collisions 617 to a minimum, but theoretically they can still happen. 619 Plaintext prefix collisions: If two enclaves chose the same prefix, 620 this would result in two VPN gateways advertising the same 621 address. This is a configuration error (two enclaves shouldn't do 622 that, not in an IP network) 624 Ciphertext host part collisions: A VPN router properly forms its 625 ciphertext address, and finds that its address collides with the 626 address of another device on its link. The autoconfiguration 627 process provides for arbitration, but the VPN router can't change 628 its address. Wouldn't that be a fatal problem? 630 3. Multicast Routing Solution - SSM 632 It has been aptly said that anyone who thinks he understands 633 something in routing should repeat his statement using the word 634 "multicast". This section proposes to do exactly that. Figure 4 635 shows a simple case of a VPN. Rather than attempting to solve the 636 most general case, which many have found difficult, use Single Source 637 Multicast [RFC3569]as the basic technology. The fundamental problems 638 are: 640 o Given a group prefix on the LAN in the upper enclave, how does one 641 form a corresponding address on the ciphertext router of the VPN 642 Router? 644 o How does the plaintext address Host 1 relate to routing of a 645 multicast group used by Host 1? 647 o How does the corresponding ciphertext group address relate to 648 routing? 650 o How does a host in a remote enclave determine the plaintext group 651 address and join it? 653 o How does a VPN Router in front of a remote enclave determine the 654 corresponding ciphertext group address and join it? 656 o Presuming that the two VPN Routers are unknown to each other, how 657 do they form the appropriate security association? 659 o How are keys exchanged? 661 3.1. Forming a ciphertext group address from a plaintext address 663 Single Source Multicast identifies a multicast channel using the 664 source address and group address as an {S,G} pair. Using IPv6 665 addresses, this has a natural breakdown: the Sender Address has a 666 prefix part (a /64 prefix) and a host part, and the group address 667 (defined in [I-D.ietf-ipv6-addr-arch-v4] and shown in Figure 6) 668 similarly has 16 bits of discriminator, flags, and scope, and 112 669 bits of Group ID. For the purposes of this document, we will 670 consider that Group ID to have 64 bits in its lower part and 48 bits 671 in its upper part, and that the upper part represents a prefix that 672 may be configured for a routing domain. In this game, we will create 673 the ciphertext router of the VPN router's "sender address" just as we 674 did in Section 2, and will additionally use the hash of the host part 675 of the plaintext group address. 677 | 8 | 4 | 4 | 112 bits | 678 +------ -+----+----+---------------------------------------------+ 679 |11111111|flgs|scop| group ID | 680 +--------+----+----+---------------------------------------------+ 682 Figure 6: IPv6 Multicast Address, from RFC 3513 684 As shown in Figure 7, when a host joins a multicast tree emanating 685 from a host in another enclave, the joins will migrate toward the 686 sender following SSM's algorithms, and crossing the intervening VPN 687 as through a tunnel. When such a route is created, the following 688 four elements are combined: 690 o a configured multicast group prefix used in the ciphertext domain 691 and unknown to the plaintext router 693 o The IPv6 prefix used for unicast addresses in the ciphertext 694 domain. 696 o The hashed prefix part of the plaintext router sender address 698 o The hashed "host part" of the plaintext router group address 700 +-----------+-----------+-----------+-----------+ 701 | Plaintext | Plaintext | Plaintext | Plaintext | 702 | Source | Source | Group and | Group Addr| 703 | Prefix | Host Part | Flags |"Host Part"| 704 +-----------+-----------+-----------+-----------+ 705 \\ || 706 \\ || 707 ,-------. ,-------. 708 ( Hash ) ( Hash ) 709 `-------' `-------' 710 \\ || 711 \\ || 712 +-----------+-----------+-----------+-----------+ 713 | Ciphertext| Ciphertext| Ciphertext| Ciphertext| 714 | Source | Source | Group and | Group Addr| 715 | Prefix | Host Part | Flags | LSB | 716 +-----------+-----------+-----------+-----------+ 718 Figure 7: Forming a ciphertext address pair from a plaintext address 719 pair 721 The ciphertext domain's prefix plus the hashed plaintext prefix form 722 the "sender address", identical to the ciphertext domain unicast 723 address. The ciphertext group address prefix plus the hashed host 724 part of the plaintext group address creates the ciphertext multicast 725 group. If a given host in the plaintext domain requires multiple 726 multicast groups, it creates multiple group addresses. 728 3.2. Routing to a remote address 730 A host in a remote enclave determines the SSM channel identifier, an 731 {S,G} address pair and joins it. The "join" heads toward the VPN 732 Router, which performs the same transformation as noted in 733 Section 3.1, and the ciphertext router of that system joins that 734 multicast group. As an example, assume that the enclaves in Figure 4 735 have established unicast connectivity across the ciphertext domain 736 via the procedure described in Section 2.2. Further assume that Host 737 4 is the source of a plaintext multicast group G. Host 1 learns of 738 the SSM channel {Host 4, Group G} out of band. It joins towards this 739 channel through normal MLDv2 [RFC3810] multicast listener report 740 messaging. The plaintext router of VPN Router 1 receives the report, 741 hashes the source prefix (Host 4) and the host part of the plaintext 742 group address G, and communicates the hashed values to the ciphertext 743 router. This triggers a join toward the ciphertext multicast channel 744 supporting the plaintext channel. The original join is also directed 745 across a unicast security association to the plaintext router of VPN 746 Router 2, and continues joining toward Host 4. 748 The ciphertext router joins towards the ciphertext domain connecting 749 the enclaves using the source address formed by the procedure 750 described in Section 2.2 and a ciphertext group address formed by 751 combining its configured ciphertext multicast group prefix with the 752 hashed host part of the plaintext group address G. A source-specific 753 tree is constructed through the domain and a join reaches the 754 ciphertext router of the source enclave's VPN router. The source VPN 755 router creates join state for the multicast channel on its ciphertext 756 router. When Host 4 transmits multicast packets on the channel, the 757 plaintext router of its VPN router passes the (encrypted) packet to 758 the ciphertext router along with a hash of the enclave unicast prefix 759 and a hash of the host part of the plaintext group address G. The 760 packet is forwarded down the source-specific tree within the 761 ciphertext domain towards the VPN router fronting Host 1. The VPN 762 router decrypts the packet and passes it to its plaintext router 763 which forwards it to Host 1 due to the join state previously created 764 via MLDv2. 766 If the VPN routers do not border the same ciphertext domain, they 767 must know of each other's configured ciphertext multicast prefixes 768 prior to establishing the source-specific tree. They may learn of 769 their respective ciphertext multicast prefixes through pre- 770 configuration, or they may inform each other following the 771 establishment of a unicast SA. 773 One approach to distribution of the encryption key used by the 774 multicast data stream and the multicast group's group address in the 775 ciphertext domain would be for VPN Router 1 to query VPN Router 2 in 776 the black domain to determine what 48 bit group address portion, 777 flags, and scope are in use and the key used for the channel. This 778 would occur using the ciphertext domain's unicast security 779 association. 781 3.3. Proving recursiveness 783 Since the components required in Section 3.1 are the same at both 784 levels, both levels work. 786 3.4. Issues (Author's notes to self) 788 We need to deal with the possibility that the hash function produces 789 collisions... 791 4. Key Management Procedures 793 4.1. Key Management Requirements 795 The various ways that one hashes bits are checksum generation or 796 cryptographic mechanisms. These generally use some initial data to 797 parameterise the algorithm; this may be included in the result or 798 used (such as in a CRC) to select feedback paths in the algorithm, or 799 other approaches. For generality, in this document such parameters 800 will be referred to as "keys". 802 It is strongly desirable that a hypothetical security breach in one 803 Internet protocol not automatically compromise other Internet 804 protocols. A key configured for use in this specification SHOULD NOT 805 be stored using protocols or algorithms that have known flaws. 807 Implementations MUST support the storage of more than one key at the 808 same time, although it is recognized that only one key will normally 809 be active on an interface. They MUST associate a specific lifetime 810 (i.e., date/time first valid and date/time no longer valid) and a key 811 identifier with each key, and MUST support manual key distribution 812 (e.g., the privileged user manually typing in the key, key lifetime, 813 and key identifier on the router console). The lifetime may be 814 infinite. If more than one algorithm is supported, then the 815 implementation MUST require that the algorithm be specified for each 816 key at the time the other key information is entered. Keys that are 817 out of date MAY be deleted at will by the implementation without 818 requiring human intervention. Manual deletion of active keys SHOULD 819 also be supported. 821 4.2. Key Management Procedures 823 As with all security methods using keys, it is necessary to change 824 the key on a regular basis. To maintain routing stability during 825 such changes, implementations MUST be able to store and use more than 826 one Key on a given interface at the same time. 828 Each key will have its own Key Identifier, which is stored locally. 829 The combination of the Key Identifier and the interface associated 830 with the datagram uniquely identifies the algorithm and key in use. 832 As noted above, the VPN Router will select a valid key from the set 833 of valid keys for that interface. The receiver will use the Key 834 Identifier and interface to determine which key to use for 835 authentication of the received datagram. More than one key may be 836 associated with an interface at the same time. 838 Hence it is possible to have fairly smooth Key rollovers without 839 losing legitimate traffic because the stored key is incorrect and 840 without requiring people to change all the keys at once. To ensure a 841 smooth rollover, each communicating VPN Router must be updated with 842 the new key several minutes before the current key will expire and 843 several minutes before the new key lifetime begins. The new key 844 should have a lifetime that starts several minutes before the old key 845 expires. This gives time for each VPN Router to learn of the new key 846 before that key will be used. It also ensures that the new key will 847 begin being used and the current key will go out of use before the 848 current key's lifetime expires. For the duration of the overlap in 849 key lifetimes, a system may receive datagrams using either key and 850 authenticate the datagram. The Key-ID in the received datagram is 851 used to select the appropriate key for authentication. 853 4.3. Pathological Cases 855 Two pathological cases exist which must be handled, which are 856 failures of the network manager. Both of these should be exceedingly 857 rare. 859 During key switchover, devices may exist which have not yet been 860 successfully configured with the new key. Therefore, routers SHOULD 861 implement (and would be well advised to implement) an algorithm that 862 detects the set of keys being used by its neighbors, and transmits 863 its datagrams using both the new and old keys until all of the 864 neighbors are using the new key or the lifetime of the old key 865 expires. Under normal circumstances, this elevated transmission rate 866 will exist for a single update interval. 868 In the event that the last key associated with an interface expires, 869 it is unacceptable to revert to an unauthenticated condition, and not 870 advisable to disrupt routing. Therefore, the router should send a 871 "last authentication key expiration" notification to the network 872 manager and treat the key as having an infinite lifetime until the 873 lifetime is extended, the key is deleted by network management, or a 874 new key is configured. 876 5. Operational Considerations 878 [RFC1958], in section 3, gives some general principles for making 879 Internet technology that works well. Key points include: 881 o Heterogeneity is inevitable and must be supported by design. 883 o All designs must scale readily to very many nodes per site and to 884 many millions of sites. 886 o Performance and cost must be considered as well as functionality. 888 o Keep it simple. When in doubt during design, choose the simplest 889 solution. 891 o Modularity is good. If you can keep things separate, do so. 893 From the viewpoint of constructing technology that scales to a large 894 network, this proposal obviously has some issues. One is that each 895 VPN Router ends up with a host route per VPN Router in the network, 896 which may have scaling issues and in any event makes route 897 aggregation difficult. Another is that other technologies, including 898 manual configuration and a form of database lookup, are already in 899 use and need to be integrated with - and may have long-term utility 900 in the network. This section attempts to address those issues. 902 5.1. Scaling issues in host routing 904 One of the principles that has improved Internet scaling is that of 905 information hiding: differing routing domains simple advertise a 906 prefix or set of prefixes to each other and hide internal structure. 907 Specifically, they don't advertise host addresses or LAN prefixes, 908 and in some cases prefixes belonging to multiple ISPs and edge 909 networks are aggregated to represent continental regions. 911 On the other hand, at this writing, the Internet backbone reportedly 912 carries about 150,000 routes in default-free routing. The conditions 913 under which this is true are that BGP routing is used between domains 914 and is essentially stable (a small percentage of routes are changing 915 at any given time, but the bulk of routes are stable), and some form 916 of link state routing is used within most non-edge domains. It seems 917 rational to expect that an IP-based network is capable of carrying on 918 the order of 50,000-75,000 host routes, 50-75K LAN routes within the 919 black domain, and some number of external routes, if the same 920 conditions apply. In general, given current technology, the matters 921 driving aggregation of routes are more related to information 922 assurance issues and administrative boundaries than the scaling of 923 routing. 925 Therefore, we initially recommend that in stable domains the number 926 of host routes within a single routing domain be engineered to not 927 exceed 50,000. This recommendation may change in operational 928 practice. 930 5.2. The place of manual configuration and server-based solutions 932 Currently, customer-provisioned VPNs (of which this is an example) 933 are generally configured manually. In certain cases, nested VPN 934 routing is being implemented using a database solution which may be 935 constructively compared to DNS: when an address or prefix must be 936 found dynamically, a query is sent to a server, which replies with 937 the necessary information. 939 We would suggest that these can be accommodated into this proposal if 940 the lookup for a Security Association follows this rule: 942 o If a security association exists, it should be used. This would 943 include any security association which had been set up dynamically 944 as a result of some previous exchange, or any manually configured 945 association. 947 o Failing that, the routing table may be inquired of using an 948 appropriate API. If a host route is found, the approach suggested 949 in this document applies. 951 o Failing that, the server should be queried. 953 o Failing that, the peer is unknown. 955 5.3. Use Case for Enterprise Network 957 The applicability of the rule described in Section Section 5.2 959 can be understood under the context of the use case shown in 960 Figure 8. 962 _.--------. 963 ,-'' `--. 964 ,' PT Enclave 1 `. 965 ,' +-----------+ `. 966 / R1.H1 |PT-Router-1| \ ,---. 967 ; |...........| : / \ 968 |--------|E/D :: Mgmt|--------| / CT \ 969 : |...........| ; B1.h(R1) ( Hub ) 970 \ |CT-Router-1|.........................\ B1.H0 / 971 `. +-----------+ ,' .-'\ / 972 `. CT Enclave 1 ,' .' `--+' 973 `--. _.-' .-' | 974 `--------'' .-' | 975 .-' | 976 B1.h(R3).' |B1.h(R3) 977 _.--------. .-' _.---+----. 978 ,-'' `--. .-' ,-'' | `--. 979 ,' CT Enclave 2 .'. ,' CT Enc|ave 3 `. 980 ,' +-----------.-' `. ,' +-----+-----+ `. 981 / |CT-Router 2| \ / |CT-Router-3| \ 982 ; |...........| : ; |...........| : 983 |--------|E/D :: Mgmt|--------| |--------|E/D :: Mgmt|--------| 984 : |...........| ; : |...........| ; 985 \ R2.H2 |PT-Router-2| / \ R3.H3 |PT-Router-3| / 986 `. +-----------+ ,' `. +-----------+ ,' 987 `. PT Enclave 2 ,' `. PT Enclave 3 ,' 988 `--. _.-' `--. _.-' 989 `--------'' `--------'' 991 Figure 8: Routing in a Hub & Spoke VPN 993 Figure 8 depicts a simple hub and spoke enterprise network employing 994 the VPN routing approach described in this draft. Three VPN enclave 995 sites are connected to each other via the ciphertext hub which also 996 serves the enterprise headquarters and connects to the Internet. 997 Multiple security associations between any two sites may be set up as 998 neccessary. A typical operational scenario employing the solution 999 described in this document would apply as follows: 1001 o The ciphertext address of VPN router (e.g. B1.h(H1)) at any given 1002 site is derived from the plaintext address of the VPN router (e.g. 1003 R1.H1) via the hash rule described in Section 1.4 1005 o In this scenario both manual configuration or host routes would 1006 serve as a simple mechanism to route to a remote ciphertext 1007 address. If the enclave sites are expected to setup on-demand 1008 security associations between sites due to traffic needs or 1009 mobility, then host routes would better serve this dynamic nature 1010 of the network. [Note: Scalability of host routes in such an 1011 enterprise network of even hundreds of enclaves is well within the 1012 limits of know network routing scalability]. 1014 6. IANA Considerations 1016 This memo adds no new IANA considerations. 1018 Note to RFC Editor: This section will have served its purpose if it 1019 correctly tells IANA that no new assignments or registries are 1020 required, or if those assignments or registries are created during 1021 the RFC publication process. From the author's perspective, it may 1022 therefore be removed upon publication as an RFC at the RFC Editor's 1023 discretion. 1025 7. Security Considerations 1027 The specification of a set of acceptable hash mechanisms is beyond 1028 the scope of this document. The choice of the exact hash 1029 algorithm(s) that may be employed is dependent on the security 1030 considerations of the customer provisioning the specific virtual 1031 private network. As described in Section 1.4, possible algorithm 1032 choices are defined in MD5 [RFC1321], FIPS PUB 180-1 (SHA1) and ITU-T 1033 Recommendation V.41, "Code-independent error-control system" 1034 (CRC-32). 1036 The appropriate choice of hash algorithm(s) can sufficiently secure 1037 the plaintext addresses which are hashed to derive ciphertext 1038 addresses. As an improvement to (static) configuration of ciphertext 1039 addresses within the plaintext databases of the VPN enclave, the 1040 automatic mechanism described in this document can easily complement 1041 other security procedures such as ciphertext address change on a 1042 pseudo-random or periodic basis without manual intervention. 1044 8. Acknowledgements 1046 Commentary from Brian Weis and Dave McGrew was very helpful. Some 1047 concepts and questions also came from Bharat Doshi and his associates 1048 of the US DoD GIG Routing Working Group. Comments by Eric Fleischman 1049 helped improve the document. 1051 The authors of RFC 2082, from which the initial text of section 4 was 1052 remorselessly stolen, deserve credit for that contribution. 1054 9. References 1056 9.1. Normative References 1058 [I-D.ietf-ipv6-addr-arch-v4] 1059 Hinden, R. and S. Deering, "IP Version 6 Addressing 1060 Architecture", draft-ietf-ipv6-addr-arch-v4-04 (work in 1061 progress), May 2005. 1063 [I-D.ietf-ssm-arch] 1064 Holbrook, H. and B. Cain, "Source-Specific Multicast for 1065 IP", draft-ietf-ssm-arch-07 (work in progress), 1066 October 2005. 1068 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1069 Requirement Levels", BCP 14, RFC 2119, March 1997. 1071 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1072 Internet Protocol", RFC 2401, November 1998. 1074 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 1075 Payload (ESP)", RFC 2406, November 1998. 1077 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1078 (IPv6) Specification", RFC 2460, December 1998. 1080 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1081 Autoconfiguration", RFC 2462, December 1998. 1083 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1084 "Definition of the Differentiated Services Field (DS 1085 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1086 December 1998. 1088 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 1089 Stateless Address Autoconfiguration in IPv6", RFC 3041, 1090 January 2001. 1092 9.2. Informative References 1094 [I-D.ietf-rpsec-bgpsecrec] 1095 Christian, B. and T. Tauber, "BGP Security Requirements", 1096 draft-ietf-rpsec-bgpsecrec-02 (work in progress), 1097 July 2005. 1099 [I-D.ietf-rpsec-generic-requirements] 1100 McPherson, D., "Generic Security Requirements for Routing 1101 Protocols", draft-ietf-rpsec-generic-requirements-01 (work 1102 in progress), January 2005. 1104 [I-D.ietf-rpsec-ospf-vuln] 1105 Jones, E. and O. Moigne, "OSPF Security Vulnerabilities 1106 Analysis", draft-ietf-rpsec-ospf-vuln-01 (work in 1107 progress), December 2004. 1109 [I-D.ietf-rpsec-routing-threats] 1110 Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 1111 Routing Protocols", draft-ietf-rpsec-routing-threats-07 1112 (work in progress), October 2004. 1114 [I-D.puig-rpsec-rqts-opened-questions] 1115 Puig, J., "Generic Security Requirements for Routing 1116 Protocols - Opened Questions", 1117 draft-puig-rpsec-rqts-opened-questions-01 (work in 1118 progress), January 2005. 1120 [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance 1121 Vector Multicast Routing Protocol", RFC 1075, 1122 November 1988. 1124 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1125 April 1992. 1127 [RFC1924] Elz, R., "A Compact Representation of IPv6 Addresses", 1128 RFC 1924, April 1996. 1130 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 1131 RFC 1958, June 1996. 1133 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1134 October 1996. 1136 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1137 Discovery for IP Version 6 (IPv6)", RFC 2461, 1138 December 1998. 1140 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, 1141 March 1999. 1143 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1144 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1145 RFC 2661, August 1999. 1147 [RFC2764] Gleeson, B., Heinanen, J., Lin, A., Armitage, G., and A. 1148 Malis, "A Framework for IP Based Virtual Private 1149 Networks", RFC 2764, February 2000. 1151 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1152 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1153 March 2000. 1155 [RFC2917] Muthukrishnan, K. and A. Malis, "A Core MPLS IP VPN 1156 Architecture", RFC 2917, September 2000. 1158 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 1159 Multicast (SSM)", RFC 3569, July 2003. 1161 [RFC3809] Nagarajan, A., "Generic Requirements for Provider 1162 Provisioned Virtual Private Networks (PPVPN)", RFC 3809, 1163 June 2004. 1165 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1166 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1168 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 1169 Reserved for Documentation", RFC 3849, July 2004. 1171 Authors' Addresses 1173 Fred Baker 1174 Cisco Systems 1175 1121 Via Del Rey 1176 Santa Barbara, California 93117 1177 USA 1179 Phone: +1-408-526-4257 1180 Fax: +1-413-473-2403 1181 Email: fred@cisco.com 1183 Pratik Bose 1184 Lockheed Martin 1185 700 North Frederick Ave 1186 Gaithersburg, Maryland 20871 1187 USA 1189 Phone: +1-301-240-7041 1190 Fax: +1-301-240-5748 1191 Email: pratik.bose@lmco.com 1193 Dan Voce 1194 Lockheed Martin 1195 3201 Jermantown Road 1196 Fairfax, Virginia 22030 1197 USA 1199 Phone: +1-703-293-5732 1200 Fax: +1-703-293-4460 1201 Email: daniel.voce@lmco.com 1203 Full Copyright Statement 1205 Copyright (C) The Internet Society (2005). 1207 This document is subject to the rights, licenses and restrictions 1208 contained in BCP 78, and except as set forth therein, the authors 1209 retain all their rights. 1211 This document and the information contained herein are provided on an 1212 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1213 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1214 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1215 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1216 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1217 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1219 Intellectual Property 1221 The IETF takes no position regarding the validity or scope of any 1222 Intellectual Property Rights or other rights that might be claimed to 1223 pertain to the implementation or use of the technology described in 1224 this document or the extent to which any license under such rights 1225 might or might not be available; nor does it represent that it has 1226 made any independent effort to identify any such rights. Information 1227 on the procedures with respect to rights in RFC documents can be 1228 found in BCP 78 and BCP 79. 1230 Copies of IPR disclosures made to the IETF Secretariat and any 1231 assurances of licenses to be made available, or the result of an 1232 attempt made to obtain a general license or permission for the use of 1233 such proprietary rights by implementers or users of this 1234 specification can be obtained from the IETF on-line IPR repository at 1235 http://www.ietf.org/ipr. 1237 The IETF invites any interested party to bring to its attention any 1238 copyrights, patents or patent applications, or other proprietary 1239 rights that may cover technology that may be required to implement 1240 this standard. Please address the information to the IETF at 1241 ietf-ipr@ietf.org. 1243 Acknowledgment 1245 Funding for the RFC Editor function is currently provided by the 1246 Internet Society.