[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/