idnits 2.17.1 draft-baker-v6ops-b2b-private-routing-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 390. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 396. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (June 29, 2007) is 6118 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 10 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 Intended status: Informational June 29, 2007 5 Expires: December 31, 2007 7 Business to Business Private Routing 8 draft-baker-v6ops-b2b-private-routing-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 31, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This note describes a network architecture for business-to-business 42 private networking. It actually describes two: one for IPv4 and one 43 for IPv6. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 2. Implementing business to business private networks in IPv4 . . 4 50 3. Implementing business to business private networks in IPv6 . . 5 51 3.1. IPv6 addresses for business to business private 52 networks . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.2. IPv6 names for business to business private networks . . . 6 54 3.3. Issues in IPv6 business to business private networks . . . 7 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 57 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 58 7. Informative References . . . . . . . . . . . . . . . . . . . . 8 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 Intellectual Property and Copyright Statements . . . . . . . . . . 10 62 1. Introduction 64 This note describes a network architecture for business-to-business 65 private networking. It actually describes two: one for IPv4 and one 66 for IPv6. As shown in Figure 1, this is direct communications over a 67 physical or virtual link between companies that is distinct from 68 their normal communications over the Internet. In its present form, 69 the note describes a model that Cisco uses for IPv4 internetworking 70 with its business partners, and which many of them use with each 71 other. The IPv6 proposal could be described as a use case for ULA 72 addressing, whether as described in [RFC4193] or using centralized 73 allocation of them. Along the lines of [RFC4864], it suggests a way 74 to accomplish the same results in a manner that preserves the end to 75 end model and therefore preserves the ability for hosts to 76 authenticate each other. 78 _ public communication _. 79 `-._ _,-' 80 `-.._ / The Internet \ _,,-' 81 /'---..._________...--+'' 82 / \ 83 ,-------/ \-------. 84 ,' DMZ `. ,' DMZ `. 85 ,' `. ,' `. 86 / \ / \ 87 / ,-----. \ / ,-----. \ 88 ; / \ : ; / \ : 89 | ( Data =========================Data ) | 90 : \Center / ; private : \ Center/ ; 91 \ `-----' /communication\ `-----' / 92 \ / \ / 93 `. example1.com,' `. example2.com,' 94 `. ,' `. ,' 95 `-------' `-------' 97 Figure 1: Private business-to-business network 99 The primary use of this kind of network at Cisco is to communicate 100 with suppliers in out-sourcing relationships. Cisco buys services 101 from a number of companies, which it then operationally treats as 102 very close relationships, almost as if the two companies were 103 business units of the same company. This has a number of issues that 104 have to be handled delicately, both because they are in fact 105 different companies, and because the suppliers may also be or may 106 offer services to Cisco's competitors. 108 The supplier companies have essentially the same set of issues. They 109 cooperate in multiple out-sourcing relationships and may themselves 110 have similar relationships with other companies or among each other. 112 What is necessary, then, is a routing technology that enables 113 enterprise resource planning (ERP) systems and other engineering 114 support systems to interface directly in a manner that is auditable 115 and reveals as little irrelevant information or connectivity to 116 either party as necessary. Specifically, it must provide security 117 within the relationships of companies in the context of an arbitrary 118 number of similar relationships with other companies. 120 1.1. Glossary 122 Router: [RFC2460] defines a router as any system that forwards 123 packets not directed to itself. In this document, the term is 124 used with the same basic meaning, but more generally. A router 125 may be a single physical or virtual system that forwards packets, 126 but is more likely a network (at minimum a pair, for operational 127 reasons) of physical and virtual systems that forwards packets and 128 may modify them as described in [RFC3022] in transit. 130 Data Center: A physical or virtual location operated by a company 131 where it keeps operational computing resources. 133 2. Implementing business to business private networks in IPv4 135 In present IPv4 business to business private networks, Cisco modifies 136 the picture in Figure 1 as show in Figure 2. 138 _ public communication _. 139 `-._ _,-' 140 `-.._ / The Internet \ _,,-' 141 /'---..._________...--+'' 142 / \ 143 ,-------/ \-------. 144 ,' DMZ `. ,' DMZ `. 145 ,' `. ,' `. 146 / \ / \ 147 / ,-----. \ RFC 1918 / ,-----. \ 148 ; / \ +--+Addresses+--+ / \ : 149 | ( Data ====|R1|=========|R2|====Data ) | 150 : \Center / +--+ +--+ \ Center/ ; 151 \ `-----' / \ `-----' / 152 \ / private \ / 153 `. example1.com,' communication `. example2.com,' 154 `. ,' `. ,' 155 `-------' `-------' 157 Figure 2: IPv4 business to business networks 159 In this model, the corporate networks are divided into three 160 addressing domains. The routers between them use what [RFC3489] 161 calls a "full-cone NAT"; all requests from the same internal IP 162 address and port are mapped to the same external IP address and port. 163 They also use what [RFC2663] calls "Twice NAT", in that both the 164 source and destination addresses are modified as a datagram crosses 165 address realms. By means of the double translation, the addresses 166 actually used in each network are hidden from the other, as is the 167 topology that supports them. However, communication between them is 168 assured by the consistency of the translation. The translation also 169 works as an access control list of sorts; any source or destination 170 address for which a translation is not configured is prevented from 171 communicating. 173 Names are not actually necessary for the implementation of this 174 approach; only the addresses are required. That said, the Internet 175 community long ago found that names were more convenient than raw 176 addresses for management purposes. The use of addresses rather than 177 names is called out in [RFC4192] as one of the main issues in 178 renumbering networks. As such, it is advisable for the company 179 example1.com to assign names to the addresses it uses in company 180 example2.com of a general form like 182 name.example2.b2b.example1.com 184 that resolves to the address used on the corporate side of the NAT. 185 This enables the company to refer to the systems it communications 186 with in a manageable fashion, using the DNS. 188 3. Implementing business to business private networks in IPv6 190 Numerous problems have been observed in the Internet surrounding NAT, 191 mostly as a result of the separation of the network into routing 192 realms that may appear in higher layer protocols to overlap. In the 193 spirit of [RFC4864], it would be nice to find a way to achieve the 194 same essential result when using IPv6 in a manner that preserves end- 195 to-end transparency and does not use NAT. In other words, it would 196 be nice to be able to treat this as a routing problem rather than a 197 security problem. 199 3.1. IPv6 addresses for business to business private networks 201 I propose using Unique Local IPv6 Unicast Addresses [RFC4193]. ULAs 202 are intended to be a form of local address that can be used within a 203 confined domain and not advertised generally to the net. Like 205 [RFC1918] addresses, however, a ULA is generally understood to not be 206 announced in BGP and not accepted if it inadvertently is. Unlike 207 [RFC1918] addresses, however, it is intended to be usable across 208 administrative boundaries among consenting adults. If there is a 209 desire to enable a specified set of systems in company example1.com's 210 data center to communicate with a similar set of systems in company 211 example2.com's data center, the two companies should be able to 212 choose ULAs that do not conflict and advertise them to each other in 213 routing, or configure them in their own static routing. If only the 214 narrow ULAs are exchanged, routing will not find a transit path 215 (company example2.com will not discover a route to company 216 example3.com through example1.com), and will not find a path to the 217 peer company's unadvertised networks. This is shown in Figure 3. 219 _ public communication _. 220 `-._ _,-' 221 `-.._ / The Internet \ _,,-' 222 /'---..._________...--+'' 223 / \ 224 ,-------/ \-------. 225 ,' DMZ `. ,' DMZ `. 226 ,' `. ,' `. 227 / \ / \ 228 / ,-----. \ / ,-----. \ 229 ; / ULA1 \ +--+ULA2-> +--+ / ULA2\ : 230 | ( Data ====|R1|=========|R2|====Data ) | 231 : \Center / +--+ <-ULA1+--+ \ Center/ ; 232 \ `-----' / \ `-----' / 233 \ / private \ / 234 `. example1.com,' communication `. example2.com,' 235 `. ,' `. ,' 236 `-------' `-------' 238 Figure 3: IPv6 business to business networks 240 3.2. IPv6 names for business to business private networks 242 Names are again not actually necessary for the implementation of this 243 approach; only the addresses are required. That said, the Internet 244 community long ago found that names were more convenient than raw 245 addresses for management purposes, and in IPv6 this is a more 246 important point due to the length and complexity of the address. The 247 use of addresses rather than names is called out in [RFC4192] as one 248 of the main issues in renumbering networks. 250 In this case, though, it is advisable for the company administering 251 the systems to advertise its own names, as is done with other DNS 252 names. Thus, if company example2.com is providing systems for access 253 by company example1.com, example2.com should offer names of a general 254 form like 256 name.example1.b2b.example2.com 258 that resolves to the address that the company administering the 259 system wants it to be, and puts that company in control of any 260 changes it may wish to make. 262 3.3. Issues in IPv6 business to business private networks 264 There is a potential security weakness in this approach. If 265 example1.com advertises its ULA to example2.com and example2.com also 266 configures a static route to example1.com's internal network or the 267 ULA used by some third party, it can overcome the configuration of 268 routing. There are several obvious approaches to solving this 269 including the use of unicast RPF or access lists in the receiving 270 network to limit incoming traffic to that which is intended. Since 271 routing here is very simple, the filter required should be similarly 272 simple. This is consistent with BCP 38 [RFC2827] 274 There is also a potential scaling issue. Cisco prefers to keep its 275 internal routing tables very simple, with perhaps a default route to 276 the relevant service provider DMZ, routes to remote campuses, and 277 routes within the local campus. The simplest solution to this would 278 be to provide a semi-default route matching all ULAs for which there 279 is not a more specific route advertised by router R1 within the data 280 center. R1 has the necessary routes to route to all of the business 281 partners, but the routing network is not burdened with this 282 information, and since the prefixes are not advertised throughout 283 company example1.com, the link is not exposed to unauthorized usage. 285 The approach does require the correct configuration of ULA addresses 286 on the various hosts and [RFC3484] source address selection tables. 287 Only those systems that are accessible via this approach should have 288 addresses in the exchange ULA, even if other systems that are 289 intended to be inaccessible using it exist on the same LAN. These 290 systems should be configured to use the exchange ULA when 291 communicating with business partners using the private network. 293 4. IANA Considerations 295 This memo adds no new IANA considerations, as it assigns no numbers. 297 Note to RFC Editor: This section will have served its purpose if it 298 correctly tells IANA that no new assignments or registries are 299 required, or if those assignments or registries are created during 300 the RFC publication process. From the author's perspective, it may 301 therefore be removed upon publication as an RFC at the RFC Editor's 302 discretion. 304 5. Security Considerations 306 Whatever routing protocols are used, their security considerations 307 apply. The issues in Section 3.3 are also important. 309 6. Acknowledgements 311 7. Informative References 313 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 314 E. Lear, "Address Allocation for Private Internets", 315 BCP 5, RFC 1918, February 1996. 317 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 318 (IPv6) Specification", RFC 2460, December 1998. 320 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 321 Translator (NAT) Terminology and Considerations", 322 RFC 2663, August 1999. 324 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 325 Defeating Denial of Service Attacks which employ IP Source 326 Address Spoofing", BCP 38, RFC 2827, May 2000. 328 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 329 Address Translator (Traditional NAT)", RFC 3022, 330 January 2001. 332 [RFC3484] Draves, R., "Default Address Selection for Internet 333 Protocol version 6 (IPv6)", RFC 3484, February 2003. 335 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 336 "STUN - Simple Traversal of User Datagram Protocol (UDP) 337 Through Network Address Translators (NATs)", RFC 3489, 338 March 2003. 340 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 341 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 342 September 2005. 344 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 345 Addresses", RFC 4193, October 2005. 347 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 348 E. Klein, "Local Network Protection for IPv6", RFC 4864, 349 May 2007. 351 Author's Address 353 Fred Baker 354 Cisco Systems 356 Email: fred@cisco.com 358 Full Copyright Statement 360 Copyright (C) The IETF Trust (2007). 362 This document is subject to the rights, licenses and restrictions 363 contained in BCP 78, and except as set forth therein, the authors 364 retain all their rights. 366 This document and the information contained herein are provided on an 367 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 368 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 369 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 370 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 371 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 372 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 374 Intellectual Property 376 The IETF takes no position regarding the validity or scope of any 377 Intellectual Property Rights or other rights that might be claimed to 378 pertain to the implementation or use of the technology described in 379 this document or the extent to which any license under such rights 380 might or might not be available; nor does it represent that it has 381 made any independent effort to identify any such rights. Information 382 on the procedures with respect to rights in RFC documents can be 383 found in BCP 78 and BCP 79. 385 Copies of IPR disclosures made to the IETF Secretariat and any 386 assurances of licenses to be made available, or the result of an 387 attempt made to obtain a general license or permission for the use of 388 such proprietary rights by implementers or users of this 389 specification can be obtained from the IETF on-line IPR repository at 390 http://www.ietf.org/ipr. 392 The IETF invites any interested party to bring to its attention any 393 copyrights, patents or patent applications, or other proprietary 394 rights that may cover technology that may be required to implement 395 this standard. Please address the information to the IETF at 396 ietf-ipr@ietf.org. 398 Acknowledgment 400 Funding for the RFC Editor function is provided by the IETF 401 Administrative Support Activity (IASA).