Subject: [GROW] Private IP in SP cores

From: Tony Kirkham <[email-masked]>
Date: Sat, 27 Feb 2010 16:09:25 +1000

Hi again,

As previously requested I have converted my draft over to XML and text 
formats.

A few points. I had several fights with the RFC XML to txt converter. It 
forced the inclusion of 'security considerations' and 'normative 
references'. I'm not sure these were part of the natural flow but are 
included because I basically 'had no choice'.

I realise some of the formating will need some extra work. I'm no expert 
in XML, so it was a learn on the fly type experience. In particular, I 
know the references need some more work. However, before I put any more 
time into this, I wanted to be confident that the material is useful and 
has some chance of being published. So a review would be greatly 
appreciated.

Thanks very much, hope this is useful.

Tony K

-- 

*Anthony Kirkham*
*Solution Architect

***World Wide Security
Service Practice
**
[email-masked] <mailto:[email-masked]>
Phone: *+61 (0)7 3238 8203*
Mobile: *+61 (0)401 890 494*

CISSP, CCIE# - 1378

**

Level 12, 300 Adelaide Street
Brisbane, Qld, 4000
Australia
Cisco home page <http://www.cisco.com/global/AU/>

Network Working Group                                         A. Kirkham
Internet-Draft                                             Cisco Systems
Obsoletes:  None                                           March 1, 2010
(if approved)
Intended status:  Informational
Expires:  September 2, 2010

           Issues with Private IP Addressing in the Internet
                    draft-kirkham-private-ip-core-00

Abstract

   The purpose of this document is to provide a discussion of the
   potential problems of using private, RFC1918, or non-globally-
   routable addressing within the core of an SP network.  The discussion
   focuses on link addresses and to a small extent loopback addresses.
   While many of the issues are well recognised within the ISP
   community, there appears to be no document that collectively
   describes the issues.

Legal

   This documents and the information contained therein 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 THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

Status of this Memo

   This document is an Internet-Draft and is NOT offered in accordance
   with Section 10 of RFC 2026, and the author does not provide the IETF
   with any rights other than to publish as an Internet-Draft.

   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."

Kirkham                 Expires September 2, 2010               [Page 1]

Internet-Draft             IP-Core-Private-IP                 March 2010

   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 September 2, 2010.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conservation of Address Space  . . . . . . . . . . . . . . . .  3
   3.  Breaks Traceroute  . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Breaks Path MTU Discovery  . . . . . . . . . . . . . . . . . .  5
   5.  Unexpected interactions with some NAT implementations  . . . .  6
   6.  Issues with edge anti-spoofing techniques  . . . . . . . . . .  7
   7.  Peering using loopbacks  . . . . . . . . . . . . . . . . . . .  7
   8.  DNS Interaction  . . . . . . . . . . . . . . . . . . . . . . .  8
   9.  Operational and Troubleshooting issues . . . . . . . . . . . .  8
   10. Security Arguments . . . . . . . . . . . . . . . . . . . . . .  8
   11. Issues with core network security  . . . . . . . . . . . . . .  9
   12. Alternate approaches to core network security  . . . . . . . . 10
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   14. Normative References . . . . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11

Kirkham                 Expires September 2, 2010               [Page 2]

Internet-Draft             IP-Core-Private-IP                 March 2010

1.  Introduction

   In the mid to late 90's, some Internet Service Providers (ISPs)
   adopted the practice of utilising private IP (i.e.  RFC1918)
   addresses for the infrastructure links and in some cases the loopback
   interfaces within their networks.  The reasons for this approach
   centered on conservation of address space (i.e. scarcity of routeable
   IPv4 address space), and security of the core network (also known as
   core hiding).

   However, a number of technical and operational issues occurred as a
   result of using non-routable IP addresses, and as a result, virtually
   all these ISPs moved away from the practice.  Tier 1 ISPs are
   considered the benchmark of the industry and today there is no known
   tier 1 ISP that utilises the practice of private addressing within
   their core network.

   The following sections will discuss the various issues (and potential
   issues) associated with deploying private IP (i.e.  RFC1918)
   addresses within ISP core networks.

   Note:  The practice of ISPs using 'stolen' address space has many of
   the same issues as that of using private IP address space within core
   networks.  The term "stolen IP address space" refers to the practice
   of an ISP using address space for its own infrastructure/core network
   addressing that has been officially allocated by IANA (or an RIR) to
   another provider but that that provider is not currently using or
   advertising within the Internet.  Stolen addressing is not discussed
   further in this document.  It is simply noted as an associated issue.

2.  Conservation of Address Space

   One of the original intents for the use of private IP addressing
   within an ISP core was the conservation of routeable IP address
   space.  When an ISP is allocated a block of routeable IP addresses
   (from IANA or an RIR), this address block was traditionally split in
   order to dedicate some portion for infrastructure use (i.e. for the
   core network), and the other portion for customer (subscriber) or
   other address pool use.  Typically, the number of infrastructure
   addresses needed is relatively small in comparison to the total
   address count.  So unless the ISP was only granted a small routable
   block, dedicating some portion to infrastructure links and loopback
   addresses (/32) is rarely a large enough issue to outweigh the
   problems that are potentially caused when the private address space
   is used as being discussed.

   Additionally, specifications and equipment capability improvements

Kirkham                 Expires September 2, 2010               [Page 3]

Internet-Draft             IP-Core-Private-IP                 March 2010

   now allow for the use of /31s [RFC3021] for link addresses in place
   of the original /30s - further minimises the impact of dedicating
   routeable addresses to infrastructure links by only using two (2) ip
   address per point to point link versus four (4) respectively.

   The use of private or RFC1918 addressing as a conservation technique
   within an Internet Service Provider (ISP) core can cause a number of
   technical and operational issues.  The main issues are described
   next.

3.  Breaks Traceroute

   The single biggest issue with the use of private (RFC1918) addressing
   within an Internet core is the fact that it can disrupt the operation
   of traceroute in some situations.  This section provides some
   examples of the issues that can occur.

   Firstly, the example below shows a traceroute across a network that
   uses privately numbered links.  In this example the string of " * * *
   " in hop number 12 indicates that private addresses for which there
   is no route are being attempted in the traceroute.  For example:

   10   120 ms   131 ms   120 ms  xxx.xxx.67.97
   11   130 ms   130 ms   131 ms  xxx.xxx.21.1
   12     *        *        *     Request timed out.
   13   130 ms   130 ms   140 ms  xxx.xxx.21.185

   Of more relevance is the situation where the traceroute crosses an AS
   boundary and one of the networks has utilised private addressing.
   The following simple network is used for illustrative purposes.

              AS100                 EBGP                AS200
                    IBGP Mesh <--------------->  IBGP Mesh
  Pool -                                                       Pool -
1.1.2.0/24                                                   2.1.2.0/24
                                 2.1.1.8/30

    10.1.1.0/30  10.1.1.4/30   .9          .10  2.1.1.4/30  2.1.1.0/30
    .1       .2  .5       .6    ------------    .6      .5  .2      .1
  R1-----------R2-----------R3--|          |--R4----------R5----------R6

10.1.1.1    10.1.1.2     10.1.1.3           2.1.1.3    2.1.1.2   2.1.1.1

   Using this example, performing the traceroute from AS200 to AS100, we
   can see the private addresses of the infrastructure links in AS100
   are returned.

Kirkham                 Expires September 2, 2010               [Page 4]

Internet-Draft             IP-Core-Private-IP                 March 2010

   R6#traceroute 1.1.2.1
   Type escape sequence to abort.
   Tracing the route to 1.1.2.1

     1 2.1.1.2 40 msec 20 msec 32 msec
     2 2.1.1.6 16 msec 20 msec 20 msec
     3 2.1.1.9 20 msec 20 msec 32 msec
     4 10.1.1.5 20 msec 20 msec 20 msec
     5 10.1.1.1 20 msec 20 msec *
   R6#

   While the previous example may not present a major problem, a
   potentially more severe case exists if the source IP address of the
   traceroute is within a privately numbered part of the network (AS100)
   and the destination is outside of the ISPs AS (AS200).  In this
   situation the traceroute will fail completely beyond the AS boundary.

   R1# traceroute 2.1.2.1
   Type escape sequence to abort.
   Tracing the route to 2.1.2.1

     1 10.1.1.2 20 msec 20 msec 20 msec
     2 10.1.1.6 52 msec 24 msec 40 msec
     3  *  *  *
     4  *  *  *
     5  *  *  *
     6  *  *  *
   R1#

   In a complex topology, with multiple paths and exit points from the
   AS, the provider will loose their ability to trace paths through the
   network to other ASs.  Such a situation could be a severe
   troubleshooting impediment.

   It should be noted that some solutions to this problem have been
   proposed.  They may utilise extensions to ICMP to allow the return of
   some "single public address" on the device, along with an interface
   identifier, possibly the SNMP ID of the interface.  However at the
   time of writing, such a solution was not available.

4.  Breaks Path MTU Discovery

   The Path MTU Discovery (PMTUD) process was designed to allow hosts to
   make an accurate assessment of the maximum size packets that can be
   sent across a path without fragmentation.  Path MTU Discovery is
   supported for TCP (and other protocols that support PMTUD such as GRE
   and IPsec) and works as follows:

Kirkham                 Expires September 2, 2010               [Page 5]

Internet-Draft             IP-Core-Private-IP                 March 2010

   o When a router attempts to forward an IP datagram with the Do Not
   Fragment (DF) bit set out a link that has a lower MTU than the size
   of the packet, the router MUST drop the packet and return an Internet
   Control Message Protocol (ICMP) 'destination unreachable -
   fragmentation needed and DF set (type 3, code 4)' message to the
   source of the IP datagram.  This message includes the MTU of that
   next-hop network.  As a result, the source station which receives the
   ICMP message, will lower the send Maximum Segment Size (MSS).

   It is obviously desirable that packets be sent between two
   communicating hosts without fragmentation as this process imposes
   extra load on the fragmenting router (process of fragmentation),
   intermediate routers (forwarding additional packets), as well as the
   receiving host (reassembly of the fragmented packets).  Additionally,
   many applications, including some web servers, set the DF (do not
   fragment) bit causing undesirable interactions if the path MTU is
   insufficient.  Other TCP implementations may set an MTU size of 576
   bytes if PMTUD is unavailable.  In addition, IPsec and other
   tunneling protocols will often require MTUs greater than 1500 bytes
   and often rely on PMTUD.  While it is uncommon these days for SP
   networks not to support a path MTUs in excess of 1500 bytes (with
   4470 being common), the situation of 1500 byte path MTUs may still
   exist in some networks.

   The issue is as follows:

   o When an ICMP Type 3 Code 4 message is issued from an infrastructure
   link that uses a private (RFC1918) address, it must be routed back to
   the originating host.  As the originating host will typically be a
   globally routable IP address, its source address is used as the
   destination address of the returned ICMP Type 3 packet.  At this
   point there are normally no problems.

   o As the returned packet will have an RFC1918 source address,
   problems can occur when the returned packet passes through an anti-
   spoofing security control (such as Unicast RPF (uRPF)), other anti-
   spoofing ACLs, or virtually any perimeter firewall.  These devices
   will typically drop packets with an RFC1918 source address, breaking
   the successful operation of PMTUD.

   As a result, the potential for application level issues is created.

5.  Unexpected interactions with some NAT implementations

   Private addressing is legitimately used within many enterprise or
   corporate networks for internal network addressing.  When users on
   the inside of the network require Internet access, they will

Kirkham                 Expires September 2, 2010               [Page 6]

Internet-Draft             IP-Core-Private-IP                 March 2010

   typically connect through a perimeter router or firewall that
   provides Network Address Translation (NAT) services.  Typical NAT
   deployments assume that the internal private address ranges will not
   exist outside of the internal environment.

   However unpredictable interactions could occur if traffic such as
   traceroute and PMTUD was launched from the NAT IPv4 'inside address'
   and it passed over the same address range in the public IP core.

   The discussion may be further complicated with the transition to
   IPv6.  Current discussions around the use of NAT444 and LSN (Large
   Scale NAT) would make use of a double NAT process.  Within this
   scheme, another private address block (at the time of writing) is
   being requested for ISP NAT 444 so that ISP private backbone space
   would not conflict with customer private backbone space.  Again,
   unpredictable interactions could occur if these address ranges
   conflicted with the ranges assigned in an Internet core.

6.  Issues with edge anti-spoofing techniques

   Denial of service attacks and distributed denial of attacks often
   make use of spoofed source IP addresses in an attempt to obfuscate
   the source of an attack.  RFC2827 (Network Ingress Filtering)
   strongly recommends that providers of Internet connectivity implement
   filtering to prevent packets using source addresses outside of their
   legitimately assigned and advertised prefix ranges.  Such filtering
   should also prevent packets with private source addresses from
   egressing the AS.

   Best security practices for ISPs also strongly recommend that packets
   with illegitimate source addresses should be dropped at the AS
   perimeter.  Illegitimate source addresses include private IP
   (RFC1918) addresses, addresses within the providers assigned prefix
   ranges, bogons (legitimate but unassigned IP addresses).
   Additionally, packets with private IP destinations addresses should
   also dropped at the AS perimeter.

   If such filtering is properly deployed, then traffic either sourced
   from, or destined for privately addressed portions of the network
   should be dropped.  Hence the negative consequences on traceroute,
   PMTUD and regular ping type traffic.

7.  Peering using loopbacks

   Although not a common technique, some ISPs use loopback addresses of
   border routers (ASBRs) for peering, in particular where multiple

Kirkham                 Expires September 2, 2010               [Page 7]

Internet-Draft             IP-Core-Private-IP                 March 2010

   connections or exchange points exist between the two ISPs.  Such a
   technique can be used as the foundation of fine grained traffic
   engineering and load balancing through the combination of IGP metrics
   and multi-hop BGP (as opposed to the more common technique of local
   preference).  When private or non-globally reachable addresses are
   used as loopback addresses, this technique is not possible.
   Additionally, private or non-globally reachable addresses, mandates
   the use of next-hop-self which can provide far less control than the
   technique above.

8.  DNS Interaction

   Many ISPs utilise their DNS to perform both forward and reverse
   resolution for the infrastructure devices and infrastructure
   addresses.  With a privately numbered core, the ISP itself will still
   have the capability to perform name resolution of their own
   infrastructure.  However others outside of the autonomous system will
   not have this capability.  At best, they will get a number of
   unidentified RFC1918 IP addresses returned from a traceroute.

   Such a situation can lead to complaints from parties or customers
   outside of the ISP.

9.  Operational and Troubleshooting issues

   Previous sections of the document have noted issues relating to
   network operations and troubleshooting.  In particular when private
   IP addressing within an ISP core is used, the ability to easily
   troubleshoot across the AS boundary is severely limited.  For less
   experienced personnel or first tier operations staff this may be an
   operational impediment.

   For users outside of the AS, the loss of the ability to use a
   traceroute for troubleshooting is very often a serious issue.  As
   soon as many of these people see a row of "* * *" in a traceroute
   they often incorrectly assume that a large part of the network is
   down or inaccessible (e.g. behind a firewall).  Operational
   experience in many large providers has shown that significant
   confusion results.  This translates directly into difficult (and
   potentially long and emotional) conversations with these users.

10.  Security Arguments

   One of the arguments often put forward for the use of private
   addressing within an ISP is an improvement in the network security.

Kirkham                 Expires September 2, 2010               [Page 8]

Internet-Draft             IP-Core-Private-IP                 March 2010

   It has been argued that if private addressing is used within the
   core, the network infrastructure becomes unreachable from outside the
   providers autonomous system, hence protecting the infrastructure.
   There is an element of legitimacy to this argument.  Certainly if the
   core is privately numbered and unreachable, it potentially provides a
   level of isolation in addition to what can be achieved with other
   techniques such as infrastructure ACLs on their own.  This is
   especially true in the event of an ACL misconfiguration, something
   that does commonly occur as the result of human error.

11.  Issues with core network security

   There are a number of flaws to the argument of using private
   addressing for security.

      o Private addressing may not protect against attacks originating
      from hosts within the AS or subscribers directly attached to the
      providers AS.  Depending on the routing design, subscribers may be
      able to route traffic to the core infrastructure devices.

      o Private addressing may not protect against attacks originating
      from hosts within the AS or subscribers directly attached to the
      providers AS.  Depending on the routing design, subscribers may be
      able to route traffic to the core infrastructure devices.

      Even if anti-spoofing is deployed at the AS boundary, the border
      routers will potentially carry routing information for the
      privately addressed network infrastructure.  This can mean that
      packets with spoofed addresses, corresponding to the private
      infrastructure addressing, may be considered legitimate by the
      anti-spoofing feature and forwarded.  To avoid this situation, the
      anti-spoofing algorithm would need to consider the ingress
      interface of the spoofed trraffic as part of its forward/drop
      decision process.  However, such an approach can be problematic in
      an environment where asymmetric traffic paths exist.

      o Additionally, distributed denial of service attacks which make
      use of spoofed source addresses typically produce large amounts of
      backscatter traffic.  Backscatter traffic is returned from hosts,
      etc when the received packet contained a spoofed source address.
      That traffic, or an ICMP destination unreachable messages are sent
      to an incorrect party as it was assumed to be the legitimate
      source address, which it wasn't.

   If the core network is privately numbered, then that backscatter
   traffic may be received by infrastructure devices.  As backscatter
   traffic is very common on the Internet, the amount of backscatter

Kirkham                 Expires September 2, 2010               [Page 9]

Internet-Draft             IP-Core-Private-IP                 March 2010

   traffic received by the control and management planes of the network
   infrastructure devices could be significant.  Figures in the order of
   hundreds of MBits/s have occurred in some networks.  Without suitable
   protection, the network infrastructure devices could be negatively
   impacted in such a situation, in particular if the spoofed address
   range corresponded with the private address range used to number the
   core.  Again, a publicly numbered core does not protect from this
   issue.

12.  Alternate approaches to core network security

   Today, hardware-based ACLs, which have minimal to no performance
   impact, are now widespread.  Applying an ACL at the AS perimeter to
   prevent access to the network core may be a far simpler approach and
   provide comparable protection to using private addressing, Such a
   technique is known as an infrastructure ACL (iACL).

   In concept, iACLs provide filtering at the edge network which allows
   traffic to cross the network core, but not to terminate on
   infrastructure addresses within the core.  Proper iACL deployment
   will normally allow required network management traffic to be passed,
   such that traceroutes and PMTUD can still operate successfully.  For
   an iACL deployment to be practical, the core network needs to have
   been addressed with a relatively small number of contiguous address
   blocks.

   The other approach to preventing external access to the core is IS-IS
   core hiding.  This technique makes use of a fundamental property of
   the IS-IS protocol which allows link addresses to be removed from the
   routing table while still allowing loopback addresses to be resolved
   as next hops for BGP.  The technique prevents parties outside the AS
   from being able to route to infrastructure addresses, while still
   allowing traceroutes to operate successfully.  IS-IS core hiding does
   not have the same practical requirement for the core to be addressed
   from a small number of contiguous address blocks as with iACLs.

   These techniques may not be suitable for every network, however,
   there are many circumstances where they can be used successfully
   without the associated issues of privately addressing the core.

13.  Security Considerations

   None

Kirkham                 Expires September 2, 2010              [Page 10]

Internet-Draft             IP-Core-Private-IP                 March 2010

14.  Normative References

   [NANOG]    Various, "Various Nanog mail archives".

   [RFC1918]  Rekhter , Y., Moskowitz, R., Karrenberg, D., Jan de Groot,
              G., and E. Lear , "RFC1918 Address Allocation for Private
              Internets, BCP 5", Febuary  1996.

   [RFC2728]  Ferguson, P. and D. Senie , "RFC 2827 Network Ingress
              Filtering, BCP 38", May 2000.

Appendix A.  Acknowledgments

   The author would like to thank the following people for their input
   and review - Dan Wing (Cisco Systems), Roland Dobbins (Arbor
   Networks), Philip Smith (Cisco Systems), Barry Greene (Juniper
   Networks), Anton Ivanov (kot-begemot.co.uk), Ryan Mcdowell (Cisco
   Systems), Russ White (Cisco Systems), Gregg Schudel (Cisco Systems).

Author's Address

   Anthony Kirkham
   Cisco Systems
   Level 12
   300 Adeliade St
   Brisbane, Queensland  4000
   Australia

   Phone:  +61 7 32388203
   Email:  [email-masked]

Kirkham                 Expires September 2, 2010              [Page 11]


<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629-fixed.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY ADDARCH SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3513.xml">
<!ENTITY GLOBAL SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3587.xml">
<!ENTITY ICMPv6 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY IPv6 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY NTP SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1305.xml">
<!ENTITY RANDOM SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml">
<!ENTITY SHA1 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3174.xml">
<!ENTITY ULA SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY FIPS SYSTEM "http://xml.resource.org/public/rfc/bibxml2/reference.FIPS.180-1.1995.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc subcompact="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes"?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<rfc category="info" docName="draft-kirkham-private-ip-core-00" ipr="none"
     obsoletes="None" submissionType="IETF" updates="" xml:lang="en">
  <front>
    <title abbrev="IP-Core-Private-IP">Issues with Private IP Addressing in
    the Internet</title>

    <author fullname="Anthony Kirkham" initials="A." surname="Kirkham">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>Level 12</street>

          <street>300 Adeliade St</street>

          <city>Brisbane</city>

          <region>Queensland</region>

          <code>4000</code>

          <country>Australia</country>
        </postal>

        <phone>+61 7 32388203</phone>

        <email>[email-masked]</email>
      </address>
    </author>

    <date day="1" month="March" year="2010" />

    <abstract>
      <t>The purpose of this document is to provide a discussion of the
      potential problems of using private, RFC1918, or non-globally-routable
      addressing within the core of an SP network. The discussion focuses on
      link addresses and to a small extent loopback addresses. While many of
      the issues are well recognised within the ISP community, there appears
      to be no document that collectively describes the issues.</t>
    </abstract>

    <note title="Legal">
      <t>This documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
      WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction" toc="default">
      <t>In the mid to late 90's, some Internet Service Providers (ISPs)
      adopted the practice of utilising private IP (i.e. RFC1918) addresses
      for the infrastructure links and in some cases the loopback interfaces
      within their networks. The reasons for this approach centered on
      conservation of address space (i.e. scarcity of routeable IPv4 address
      space), and security of the core network (also known as core
      hiding).</t>

      <t>However, a number of technical and operational issues occurred as a
      result of using non-routable IP addresses, and as a result, virtually
      all these ISPs moved away from the practice. Tier 1 ISPs are considered
      the benchmark of the industry and today there is no known tier 1 ISP
      that utilises the practice of private addressing within their core
      network.</t>

      <t>The following sections will discuss the various issues (and potential
      issues) associated with deploying private IP (i.e. RFC1918) addresses
      within ISP core networks.</t>

      <t>Note: The practice of ISPs using ‘stolen’ address space has many of
      the same issues as that of using private IP address space within core
      networks. The term “stolen IP address space” refers to the practice of
      an ISP using address space for its own infrastructure/core network
      addressing that has been officially allocated by IANA (or an RIR) to
      another provider but that that provider is not currently using or
      advertising within the Internet. Stolen addressing is not discussed
      further in this document. It is simply noted as an associated issue.</t>
    </section>

    <section title="Conservation of Address Space">
      <t>One of the original intents for the use of private IP addressing
      within an ISP core was the conservation of routeable IP address space.
      When an ISP is allocated a block of routeable IP addresses (from IANA or
      an RIR), this address block was traditionally split in order to dedicate
      some portion for infrastructure use (i.e. for the core network), and the
      other portion for customer (subscriber) or other address pool use.
      Typically, the number of infrastructure addresses needed is relatively
      small in comparison to the total address count. So unless the ISP was
      only granted a small routable block, dedicating some portion to
      infrastructure links and loopback addresses (/32) is rarely a large
      enough issue to outweigh the problems that are potentially caused when
      the private address space is used as being discussed.</t>

      <t>Additionally, specifications and equipment capability improvements
      now allow for the use of /31s [RFC3021] for link addresses in place of
      the original /30s – further minimises the impact of dedicating routeable
      addresses to infrastructure links by only using two (2) ip address per
      point to point link versus four (4) respectively.</t>

      <t>The use of private or RFC1918 addressing as a conservation technique
      within an Internet Service Provider (ISP) core can cause a number of
      technical and operational issues. The main issues are described
      next.</t>
    </section>

    <section title="Breaks Traceroute">
      <t>The single biggest issue with the use of private (RFC1918) addressing
      within an Internet core is the fact that it can disrupt the operation of
      traceroute in some situations. This section provides some examples of
      the issues that can occur.</t>

      <t>Firstly, the example below shows a traceroute across a network that
      uses privately numbered links. In this example the string of " * * * "
      in hop number 12 indicates that private addresses for which there is no
      route are being attempted in the traceroute. For example:</t>

      <figure>
        <artwork>
10   120 ms   131 ms   120 ms  xxx.xxx.67.97
11   130 ms   130 ms   131 ms  xxx.xxx.21.1
12     *        *        *     Request timed out.
13   130 ms   130 ms   140 ms  xxx.xxx.21.185
</artwork>
      </figure>

      <t>Of more relevance is the situation where the traceroute crosses an AS
      boundary and one of the networks has utilised private addressing. The
      following simple network is used for illustrative purposes.</t>

      <figure>
        <artwork>

              AS100                 EBGP                AS200
                    IBGP Mesh &lt;---------------&gt;  IBGP Mesh
  Pool -                                                       Pool -
1.1.2.0/24                                                   2.1.2.0/24
                                 2.1.1.8/30

    10.1.1.0/30  10.1.1.4/30   .9          .10  2.1.1.4/30  2.1.1.0/30
    .1       .2  .5       .6    ------------    .6      .5  .2      .1
  R1-----------R2-----------R3--|          |--R4----------R5----------R6

10.1.1.1    10.1.1.2     10.1.1.3           2.1.1.3    2.1.1.2   2.1.1.1
</artwork>
      </figure>

      <t>Using this example, performing the traceroute from AS200 to AS100, we
      can see the private addresses of the infrastructure links in AS100 are
      returned.</t>

      <figure>
        <artwork>
R6#traceroute 1.1.2.1
Type escape sequence to abort.
Tracing the route to 1.1.2.1

  1 2.1.1.2 40 msec 20 msec 32 msec
  2 2.1.1.6 16 msec 20 msec 20 msec
  3 2.1.1.9 20 msec 20 msec 32 msec
  4 10.1.1.5 20 msec 20 msec 20 msec
  5 10.1.1.1 20 msec 20 msec * 
R6#
</artwork>
      </figure>

      <t>While the previous example may not present a major problem, a
      potentially more severe case exists if the source IP address of the
      traceroute is within a privately numbered part of the network (AS100)
      and the destination is outside of the ISPs AS (AS200). In this situation
      the traceroute will fail completely beyond the AS boundary.</t>

      <figure>
        <artwork>
R1# traceroute 2.1.2.1
Type escape sequence to abort.
Tracing the route to 2.1.2.1

  1 10.1.1.2 20 msec 20 msec 20 msec
  2 10.1.1.6 52 msec 24 msec 40 msec
  3  *  *  * 
  4  *  *  * 
  5  *  *  * 
  6  *  *  *
R1#  
</artwork>
      </figure>

      <t>In a complex topology, with multiple paths and exit points from the
      AS, the provider will loose their ability to trace paths through the
      network to other ASs. Such a situation could be a severe troubleshooting
      impediment.</t>

      <t>It should be noted that some solutions to this problem have been
      proposed. They may utilise extensions to ICMP to allow the return of
      some "single public address" on the device, along with an interface
      identifier, possibly the SNMP ID of the interface. However at the time
      of writing, such a solution was not available.</t>
    </section>

    <section title="Breaks Path MTU Discovery">
      <t>The Path MTU Discovery (PMTUD) process was designed to allow hosts to
      make an accurate assessment of the maximum size packets that can be sent
      across a path without fragmentation. Path MTU Discovery is supported for
      TCP (and other protocols that support PMTUD such as GRE and IPsec) and
      works as follows:</t>

      <t>• When a router attempts to forward an IP datagram with the Do Not
      Fragment (DF) bit set out a link that has a lower MTU than the size of
      the packet, the router MUST drop the packet and return an Internet
      Control Message Protocol (ICMP) 'destination unreachable - fragmentation
      needed and DF set (type 3, code 4)’ message to the source of the IP
      datagram. This message includes the MTU of that next-hop network. As a
      result, the source station which receives the ICMP message, will lower
      the send Maximum Segment Size (MSS).</t>

      <t>It is obviously desirable that packets be sent between two
      communicating hosts without fragmentation as this process imposes extra
      load on the fragmenting router (process of fragmentation), intermediate
      routers (forwarding additional packets), as well as the receiving host
      (reassembly of the fragmented packets). Additionally, many applications,
      including some web servers, set the DF (do not fragment) bit causing
      undesirable interactions if the path MTU is insufficient. Other TCP
      implementations may set an MTU size of 576 bytes if PMTUD is
      unavailable. In addition, IPsec and other tunneling protocols will often
      require MTUs greater than 1500 bytes and often rely on PMTUD. While it
      is uncommon these days for SP networks not to support a path MTUs in
      excess of 1500 bytes (with 4470 being common), the situation of 1500
      byte path MTUs may still exist in some networks.</t>

      <t>The issue is as follows:</t>

      <t>• When an ICMP Type 3 Code 4 message is issued from an infrastructure
      link that uses a private (RFC1918) address, it must be routed back to
      the originating host. As the originating host will typically be a
      globally routable IP address, its source address is used as the
      destination address of the returned ICMP Type 3 packet. At this point
      there are normally no problems.</t>

      <t>• As the returned packet will have an RFC1918 source address,
      problems can occur when the returned packet passes through an
      anti-spoofing security control (such as Unicast RPF (uRPF)), other
      anti-spoofing ACLs, or virtually any perimeter firewall. These devices
      will typically drop packets with an RFC1918 source address, breaking the
      successful operation of PMTUD.</t>

      <t>As a result, the potential for application level issues is
      created.</t>
    </section>

    <section title="Unexpected interactions with some NAT implementations">
      <t>Private addressing is legitimately used within many enterprise or
      corporate networks for internal network addressing. When users on the
      inside of the network require Internet access, they will typically
      connect through a perimeter router or firewall that provides Network
      Address Translation (NAT) services. Typical NAT deployments assume that
      the internal private address ranges will not exist outside of the
      internal environment.</t>

      <t>However unpredictable interactions could occur if traffic such as
      traceroute and PMTUD was launched from the NAT IPv4 ‘inside address’ and
      it passed over the same address range in the public IP core.</t>

      <t>The discussion may be further complicated with the transition to
      IPv6. Current discussions around the use of NAT444 and LSN (Large Scale
      NAT) would make use of a double NAT process. Within this scheme, another
      private address block (at the time of writing) is being requested for
      ISP NAT 444 so that ISP private backbone space would not conflict with
      customer private backbone space. Again, unpredictable interactions could
      occur if these address ranges conflicted with the ranges assigned in an
      Internet core.</t>
    </section>

    <section title="Issues with edge anti-spoofing techniques">
      <t>Denial of service attacks and distributed denial of attacks often
      make use of spoofed source IP addresses in an attempt to obfuscate the
      source of an attack. RFC2827 (Network Ingress Filtering) strongly
      recommends that providers of Internet connectivity implement filtering
      to prevent packets using source addresses outside of their legitimately
      assigned and advertised prefix ranges. Such filtering should also
      prevent packets with private source addresses from egressing the AS.</t>

      <t>Best security practices for ISPs also strongly recommend that packets
      with illegitimate source addresses should be dropped at the AS
      perimeter. Illegitimate source addresses include private IP (RFC1918)
      addresses, addresses within the providers assigned prefix ranges, bogons
      (legitimate but unassigned IP addresses). Additionally, packets with
      private IP destinations addresses should also dropped at the AS
      perimeter.</t>

      <t>If such filtering is properly deployed, then traffic either sourced
      from, or destined for privately addressed portions of the network should
      be dropped. Hence the negative consequences on traceroute, PMTUD and
      regular ping type traffic.</t>
    </section>

    <section title="Peering using loopbacks">
      <t>Although not a common technique, some ISPs use loopback addresses of
      border routers (ASBRs) for peering, in particular where multiple
      connections or exchange points exist between the two ISPs. Such a
      technique can be used as the foundation of fine grained traffic
      engineering and load balancing through the combination of IGP metrics
      and multi-hop BGP (as opposed to the more common technique of local
      preference). When private or non-globally reachable addresses are used
      as loopback addresses, this technique is not possible. Additionally,
      private or non-globally reachable addresses, mandates the use of
      next-hop-self which can provide far less control than the technique
      above.</t>
    </section>

    <section title="DNS Interaction">
      <t>Many ISPs utilise their DNS to perform both forward and reverse
      resolution for the infrastructure devices and infrastructure addresses.
      With a privately numbered core, the ISP itself will still have the
      capability to perform name resolution of their own infrastructure.
      However others outside of the autonomous system will not have this
      capability. At best, they will get a number of unidentified RFC1918 IP
      addresses returned from a traceroute.</t>

      <t>Such a situation can lead to complaints from parties or customers
      outside of the ISP.</t>
    </section>

    <section title="Operational and Troubleshooting issues">
      <t>Previous sections of the document have noted issues relating to
      network operations and troubleshooting. In particular when private IP
      addressing within an ISP core is used, the ability to easily
      troubleshoot across the AS boundary is severely limited. For less
      experienced personnel or first tier operations staff this may be an
      operational impediment.</t>

      <t>For users outside of the AS, the loss of the ability to use a
      traceroute for troubleshooting is very often a serious issue. As soon as
      many of these people see a row of "* * *" in a traceroute they often
      incorrectly assume that a large part of the network is down or
      inaccessible (e.g. behind a firewall). Operational experience in many
      large providers has shown that significant confusion results. This
      translates directly into difficult (and potentially long and emotional)
      conversations with these users.</t>
    </section>

    <section title="Security Arguments">
      <t>One of the arguments often put forward for the use of private
      addressing within an ISP is an improvement in the network security. It
      has been argued that if private addressing is used within the core, the
      network infrastructure becomes unreachable from outside the providers
      autonomous system, hence protecting the infrastructure. There is an
      element of legitimacy to this argument. Certainly if the core is
      privately numbered and unreachable, it potentially provides a level of
      isolation in addition to what can be achieved with other techniques such
      as infrastructure ACLs on their own. This is especially true in the
      event of an ACL misconfiguration, something that does commonly occur as
      the result of human error.</t>
    </section>

    <section title="Issues with core network security">
      <t>There are a number of flaws to the argument of using private
      addressing for security.<list>
          <t>• Private addressing may not protect against attacks originating
          from hosts within the AS or subscribers directly attached to the
          providers AS. Depending on the routing design, subscribers may be
          able to route traffic to the core infrastructure devices.</t>

          <t>• Private addressing may not protect against attacks originating
          from hosts within the AS or subscribers directly attached to the
          providers AS. Depending on the routing design, subscribers may be
          able to route traffic to the core infrastructure devices.</t>

          <t>Even if anti-spoofing is deployed at the AS boundary, the border
          routers will potentially carry routing information for the privately
          addressed network infrastructure. This can mean that packets with
          spoofed addresses, corresponding to the private infrastructure
          addressing, may be considered legitimate by the anti-spoofing
          feature and forwarded. To avoid this situation, the anti-spoofing
          algorithm would need to consider the ingress interface of the
          spoofed trraffic as part of its forward/drop decision process.
          However, such an approach can be problematic in an environment where
          asymmetric traffic paths exist.</t>

          <t>• Additionally, distributed denial of service attacks which make
          use of spoofed source addresses typically produce large amounts of
          backscatter traffic. Backscatter traffic is returned from hosts, etc
          when the received packet contained a spoofed source address. That
          traffic, or an ICMP destination unreachable messages are sent to an
          incorrect party as it was assumed to be the legitimate source
          address, which it wasn’t.</t>
        </list></t>

      <t>If the core network is privately numbered, then that backscatter
      traffic may be received by infrastructure devices. As backscatter
      traffic is very common on the Internet, the amount of backscatter
      traffic received by the control and management planes of the network
      infrastructure devices could be significant. Figures in the order of
      hundreds of MBits/s have occurred in some networks. Without suitable
      protection, the network infrastructure devices could be negatively
      impacted in such a situation, in particular if the spoofed address range
      corresponded with the private address range used to number the core.
      Again, a publicly numbered core does not protect from this issue.</t>
    </section>

    <section title="Alternate approaches to core network security">
      <t>Today, hardware-based ACLs, which have minimal to no performance
      impact, are now widespread. Applying an ACL at the AS perimeter to
      prevent access to the network core may be a far simpler approach and
      provide comparable protection to using private addressing, Such a
      technique is known as an infrastructure ACL (iACL).</t>

      <t>In concept, iACLs provide filtering at the edge network which allows
      traffic to cross the network core, but not to terminate on
      infrastructure addresses within the core. Proper iACL deployment will
      normally allow required network management traffic to be passed, such
      that traceroutes and PMTUD can still operate successfully. For an iACL
      deployment to be practical, the core network needs to have been
      addressed with a relatively small number of contiguous address
      blocks.</t>

      <t>The other approach to preventing external access to the core is IS-IS
      core hiding. This technique makes use of a fundamental property of the
      IS-IS protocol which allows link addresses to be removed from the
      routing table while still allowing loopback addresses to be resolved as
      next hops for BGP. The technique prevents parties outside the AS from
      being able to route to infrastructure addresses, while still allowing
      traceroutes to operate successfully. IS-IS core hiding does not have the
      same practical requirement for the core to be addressed from a small
      number of contiguous address blocks as with iACLs.</t>

      <t>These techniques may not be suitable for every network, however,
      there are many circumstances where they can be used successfully without
      the associated issues of privately addressing the core.</t>
    </section>

    <section title="Security Considerations">
      <t>None</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC1918">
        <front>
          <title>RFC1918 Address Allocation for Private Internets, BCP
          5</title>

          <author initials="Y" surname="Rekhter ">
            <organization>Cisco Systems</organization>
          </author>

          <author initials="R" surname="Moskowitz">
            <organization>Chrysler Corporation</organization>
          </author>

          <author initials="D" surname="Karrenberg">
            <organization>RIPE Network Coordination Centre</organization>
          </author>

          <author initials="G" surname="Jan de Groot">
            <organization>RIPE Network Coordination Centre</organization>
          </author>

          <author initials="E" surname="Lear ">
            <organization>Silicon Graphics, Inc.</organization>
          </author>

          <date month="Febuary " year="1996" />
        </front>
      </reference>

      <reference anchor="RFC2728">
        <front>
          <title>RFC 2827 Network Ingress Filtering, BCP 38</title>

          <author initials="P" surname="Ferguson">
            <organization>Cisco Systems, Inc.</organization>
          </author>

          <author initials="D" surname="Senie ">
            <organization>Amaranth Networks Inc.</organization>
          </author>

          <date month="May" year="2000" />
        </front>
      </reference>

      <reference anchor="NANOG">
        <front>
          <title>Various Nanog mail archives</title>

          <author>
            <organization>Various</organization>
          </author>

          <date />
        </front>
      </reference>
    </references>

    <section title="Acknowledgments">
      <t>The author would like to thank the following people for their input
      and review – Dan Wing (Cisco Systems), Roland Dobbins (Arbor Networks),
      Philip Smith (Cisco Systems), Barry Greene (Juniper Networks), Anton
      Ivanov (kot-begemot.co.uk), Ryan Mcdowell (Cisco Systems), Russ White
      (Cisco Systems), Gregg Schudel (Cisco Systems).</t>
    </section>
  </back>
</rfc>

---

From: Jens Brey <[email-masked]>
Date: Sat, 27 Feb 2010 12:48:14 +0100

Hi Tony,

thanks for the effort. I think this is a very usefull document, describe 
the pros and cons and I would like to see this as a informational RFC.

BR,
Jens

Am 27.02.2010 07:09, schrieb Tony Kirkham:
> A few points. I had several fights with the RFC XML to txt converter. 
> It forced the inclusion of 'security considerations' and 'normative 
> I realise some of the formating will need some extra work. I'm no 
> expert in XML, so it was a learn on the fly type experience. In 
> particular, I know the references need some more work. However, before 
> I put any more time into this, I wanted to be confident that the 
> material is useful and has some chance of being published. So a review 
> would be greatly appreciated.
>
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: Anton Ivanov <[email-masked]>
Date: Sat, 27 Feb 2010 13:43:31 +0000

Looks good. 

Brgds,

On Sat, 2010-02-27 at 16:09 +1000, Tony Kirkham wrote:
> Solution Architect
> World Wide Security
> [email-masked] 
> Phone: +61 (0)7 3238
> 8203
> Mobile: +61 (0)401 890
> 494
> Cisco home page
> plain text document attachment (draft-tkirkham-private-ip_0-14.txt)
> 
> 
-- 
   Understanding is a three-edged sword:
            your side, their side, and the truth. --Kosh Naranek

A. R. Ivanov
E-mail:  [email-masked]
WWW:     http://www.sigsegv.cx/
pub 1024D/DDE5E715 2002-03-03 Anton R. Ivanov <[email-masked]>
    Fingerprint: C824 CBD7 EE4B D7F8 5331  89D5 FCDA 572E DDE5 E715