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]