Network Working Group F. Baker Internet-Draft Cisco Systems Intended status: Informational June 29, 2007 Expires: December 31, 2007 Business to Business Private Routing draft-baker-v6ops-b2b-private-routing-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 31, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This note describes a network architecture for business-to-business private networking. It actually describes two: one for IPv4 and one for IPv6. Baker Expires December 31, 2007 [Page 1] Internet-Draft Business to Business Private Routing June 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Implementing business to business private networks in IPv4 . . 4 3. Implementing business to business private networks in IPv6 . . 5 3.1. IPv6 addresses for business to business private networks . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. IPv6 names for business to business private networks . . . 6 3.3. Issues in IPv6 business to business private networks . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. Informative References . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Baker Expires December 31, 2007 [Page 2] Internet-Draft Business to Business Private Routing June 2007 1. Introduction This note describes a network architecture for business-to-business private networking. It actually describes two: one for IPv4 and one for IPv6. As shown in Figure 1, this is direct communications over a physical or virtual link between companies that is distinct from their normal communications over the Internet. In its present form, the note describes a model that Cisco uses for IPv4 internetworking with its business partners, and which many of them use with each other. The IPv6 proposal could be described as a use case for ULA addressing, whether as described in [RFC4193] or using centralized allocation of them. Along the lines of [RFC4864], it suggests a way to accomplish the same results in a manner that preserves the end to end model and therefore preserves the ability for hosts to authenticate each other. _ public communication _. `-._ _,-' `-.._ / The Internet \ _,,-' /'---..._________...--+'' / \ ,-------/ \-------. ,' DMZ `. ,' DMZ `. ,' `. ,' `. / \ / \ / ,-----. \ / ,-----. \ ; / \ : ; / \ : | ( Data =========================Data ) | : \Center / ; private : \ Center/ ; \ `-----' /communication\ `-----' / \ / \ / `. example1.com,' `. example2.com,' `. ,' `. ,' `-------' `-------' Figure 1: Private business-to-business network The primary use of this kind of network at Cisco is to communicate with suppliers in out-sourcing relationships. Cisco buys services from a number of companies, which it then operationally treats as very close relationships, almost as if the two companies were business units of the same company. This has a number of issues that have to be handled delicately, both because they are in fact different companies, and because the suppliers may also be or may offer services to Cisco's competitors. The supplier companies have essentially the same set of issues. They cooperate in multiple out-sourcing relationships and may themselves Baker Expires December 31, 2007 [Page 3] Internet-Draft Business to Business Private Routing June 2007 have similar relationships with other companies or among each other. What is necessary, then, is a routing technology that enables enterprise resource planning (ERP) systems and other engineering support systems to interface directly in a manner that is auditable and reveals as little irrelevant information or connectivity to either party as necessary. Specifically, it must provide security within the relationships of companies in the context of an arbitrary number of similar relationships with other companies. 1.1. Glossary Router: [RFC2460] defines a router as any system that forwards packets not directed to itself. In this document, the term is used with the same basic meaning, but more generally. A router may be a single physical or virtual system that forwards packets, but is more likely a network (at minimum a pair, for operational reasons) of physical and virtual systems that forwards packets and may modify them as described in [RFC3022] in transit. Data Center: A physical or virtual location operated by a company where it keeps operational computing resources. 2. Implementing business to business private networks in IPv4 In present IPv4 business to business private networks, Cisco modifies the picture in Figure 1 as show in Figure 2. _ public communication _. `-._ _,-' `-.._ / The Internet \ _,,-' /'---..._________...--+'' / \ ,-------/ \-------. ,' DMZ `. ,' DMZ `. ,' `. ,' `. / \ / \ / ,-----. \ RFC 1918 / ,-----. \ ; / \ +--+Addresses+--+ / \ : | ( Data ====|R1|=========|R2|====Data ) | : \Center / +--+ +--+ \ Center/ ; \ `-----' / \ `-----' / \ / private \ / `. example1.com,' communication `. example2.com,' `. ,' `. ,' `-------' `-------' Baker Expires December 31, 2007 [Page 4] Internet-Draft Business to Business Private Routing June 2007 Figure 2: IPv4 business to business networks In this model, the corporate networks are divided into three addressing domains. The routers between them use what [RFC3489] calls a "full-cone NAT"; all requests from the same internal IP address and port are mapped to the same external IP address and port. They also use what [RFC2663] calls "Twice NAT", in that both the source and destination addresses are modified as a datagram crosses address realms. By means of the double translation, the addresses actually used in each network are hidden from the other, as is the topology that supports them. However, communication between them is assured by the consistency of the translation. The translation also works as an access control list of sorts; any source or destination address for which a translation is not configured is prevented from communicating. Names are not actually necessary for the implementation of this approach; only the addresses are required. That said, the Internet community long ago found that names were more convenient than raw addresses for management purposes. The use of addresses rather than names is called out in [RFC4192] as one of the main issues in renumbering networks. As such, it is advisable for the company example1.com to assign names to the addresses it uses in company example2.com of a general form like name.example2.b2b.example1.com that resolves to the address used on the corporate side of the NAT. This enables the company to refer to the systems it communications with in a manageable fashion, using the DNS. 3. Implementing business to business private networks in IPv6 Numerous problems have been observed in the Internet surrounding NAT, mostly as a result of the separation of the network into routing realms that may appear in higher layer protocols to overlap. In the spirit of [RFC4864], it would be nice to find a way to achieve the same essential result when using IPv6 in a manner that preserves end- to-end transparency and does not use NAT. In other words, it would be nice to be able to treat this as a routing problem rather than a security problem. 3.1. IPv6 addresses for business to business private networks I propose using Unique Local IPv6 Unicast Addresses [RFC4193]. ULAs are intended to be a form of local address that can be used within a confined domain and not advertised generally to the net. Like Baker Expires December 31, 2007 [Page 5] Internet-Draft Business to Business Private Routing June 2007 [RFC1918] addresses, however, a ULA is generally understood to not be announced in BGP and not accepted if it inadvertently is. Unlike [RFC1918] addresses, however, it is intended to be usable across administrative boundaries among consenting adults. If there is a desire to enable a specified set of systems in company example1.com's data center to communicate with a similar set of systems in company example2.com's data center, the two companies should be able to choose ULAs that do not conflict and advertise them to each other in routing, or configure them in their own static routing. If only the narrow ULAs are exchanged, routing will not find a transit path (company example2.com will not discover a route to company example3.com through example1.com), and will not find a path to the peer company's unadvertised networks. This is shown in Figure 3. _ public communication _. `-._ _,-' `-.._ / The Internet \ _,,-' /'---..._________...--+'' / \ ,-------/ \-------. ,' DMZ `. ,' DMZ `. ,' `. ,' `. / \ / \ / ,-----. \ / ,-----. \ ; / ULA1 \ +--+ULA2-> +--+ / ULA2\ : | ( Data ====|R1|=========|R2|====Data ) | : \Center / +--+ <-ULA1+--+ \ Center/ ; \ `-----' / \ `-----' / \ / private \ / `. example1.com,' communication `. example2.com,' `. ,' `. ,' `-------' `-------' Figure 3: IPv6 business to business networks 3.2. IPv6 names for business to business private networks Names are again not actually necessary for the implementation of this approach; only the addresses are required. That said, the Internet community long ago found that names were more convenient than raw addresses for management purposes, and in IPv6 this is a more important point due to the length and complexity of the address. The use of addresses rather than names is called out in [RFC4192] as one of the main issues in renumbering networks. In this case, though, it is advisable for the company administering the systems to advertise its own names, as is done with other DNS names. Thus, if company example2.com is providing systems for access Baker Expires December 31, 2007 [Page 6] Internet-Draft Business to Business Private Routing June 2007 by company example1.com, example2.com should offer names of a general form like name.example1.b2b.example2.com that resolves to the address that the company administering the system wants it to be, and puts that company in control of any changes it may wish to make. 3.3. Issues in IPv6 business to business private networks There is a potential security weakness in this approach. If example1.com advertises its ULA to example2.com and example2.com also configures a static route to example1.com's internal network or the ULA used by some third party, it can overcome the configuration of routing. There are several obvious approaches to solving this including the use of unicast RPF or access lists in the receiving network to limit incoming traffic to that which is intended. Since routing here is very simple, the filter required should be similarly simple. This is consistent with BCP 38 [RFC2827] There is also a potential scaling issue. Cisco prefers to keep its internal routing tables very simple, with perhaps a default route to the relevant service provider DMZ, routes to remote campuses, and routes within the local campus. The simplest solution to this would be to provide a semi-default route matching all ULAs for which there is not a more specific route advertised by router R1 within the data center. R1 has the necessary routes to route to all of the business partners, but the routing network is not burdened with this information, and since the prefixes are not advertised throughout company example1.com, the link is not exposed to unauthorized usage. The approach does require the correct configuration of ULA addresses on the various hosts and [RFC3484] source address selection tables. Only those systems that are accessible via this approach should have addresses in the exchange ULA, even if other systems that are intended to be inaccessible using it exist on the same LAN. These systems should be configured to use the exchange ULA when communicating with business partners using the private network. 4. IANA Considerations This memo adds no new IANA considerations, as it assigns no numbers. Note to RFC Editor: This section will have served its purpose if it correctly tells IANA that no new assignments or registries are required, or if those assignments or registries are created during Baker Expires December 31, 2007 [Page 7] Internet-Draft Business to Business Private Routing June 2007 the RFC publication process. From the author's perspective, it may therefore be removed upon publication as an RFC at the RFC Editor's discretion. 5. Security Considerations Whatever routing protocols are used, their security considerations apply. The issues in Section 3.3 are also important. 6. Acknowledgements 7. Informative References [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Baker Expires December 31, 2007 [Page 8] Internet-Draft Business to Business Private Routing June 2007 Addresses", RFC 4193, October 2005. [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007. Author's Address Fred Baker Cisco Systems Email: fred@cisco.com Baker Expires December 31, 2007 [Page 9] Internet-Draft Business to Business Private Routing June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Baker Expires December 31, 2007 [Page 10]