<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
                                 otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a 
                                 string such as <29> printed in the blank line at the 
                                 beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.  
         Note the ToC may be omitted for very short documents,but idnits insists on a ToC 
         if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references. 
         Some like symbolic tags in the references (and citations) and others prefer 
         numbers. The RFC Editor always uses symbolic tags.
         The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
                                 This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each 
         main section on a new page but does not omit the blank lines between list items. 
         If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="std" docName="draft-baker-opsec-passive-ip-address-01"
     ipr="trust200902" updates="792, 4443">
  <front>
    <title abbrev="">Passive IP Addresses</title>

    <author fullname="Fred Baker" initials="F.J." surname="Baker">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street></street>

          <city>Santa Barbara</city>

          <code>93117</code>

          <region>California</region>

          <country>USA</country>
        </postal>

        <email>fred@cisco.com</email>
      </address>
    </author>

    <author fullname="Gunter Van de Velde" initials="G."
            surname="Van de Velde">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>De Kleetlaan 6a</street>

          <city>Diegem</city>

          <country>Belgium</country>

          <code>1831</code>
        </postal>

        <phone>+32 2704 5473</phone>

        <email>gvandeve@cisco.com</email>
      </address>
    </author>

    <date year="2012" />

    <area>Operations and Management</area>

    <workgroup>Operational Security</workgroup>

    <abstract>
      <t>This note suggests an approach to minimizing the attack surface of
      the network elements - routers, switches, and middleware - of a
      network.</t>
    </abstract>

    <!--		
		<note title="Foreword">
		</note>
		-->

    <!--
      <?rfc needLines="10" ?>
      <texttable anchor="table_example" title="A Very Simple Table">
      <preamble>Tables use ttcol to define column headers and widths.
      Every cell then has a &quot;c&quot; element for its content.</preamble>
          <ttcol align="center">ttcol #1</ttcol>
                                    <ttcol align="center">ttcol #2</ttcol>
                      <c>c #1</c>		<c>c #2</c>
                      <c>c #3</c>		<c>c #4</c>
                      <c>c #5</c>		<c>c #6</c>
      <postamble>which is a very simple example.</postamble>
      </texttable>
    -->
  </front>

  <middle>
    <!--		
      <t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
      <t>
	<list style="symbols">
	    <t>First bullet</t>
	    <t>Second bullet</t>
	</list>
     </t>
-->

    <!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
	ASCII artwork goes here... 
]]>
</artwork>
</figure>
-->

    <section anchor="intro" title="Introduction">
      <t>This note suggests an approach to minimizing the attack surface of
      the network elements - routers, switches, and middleware - of a
      network.</t>

      <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref
        target="RFC2119"></xref>.</t>
      </section>

      <section title="Problem Statement">
        <t>The problem, at least in its first instance, is a side effect of
        diagnostics used in the Internet. Tools such as mtr, traceroute, and
        pingplotter operate by sending streams of packets to a remote address
        with varying hop limit values in <xref target="RFC2460">IPv6</xref> or
        Time to Live in <xref target="RFC0791">IPv4</xref>, and receiving
        <xref target="RFC0792">ICMP</xref> or <xref
        target="RFC4443">ICMPv6</xref> messages that indicate which interfaces
        the packet stream traversed in the forward direction. <xref
        target="RFC1191">Path MTU</xref> <xref target="RFC1981"></xref>
        discovery depends on ICMP/ICMPv6 Packet Too Big. Various ICMP/ICMPv6
        "unreachable" messages respond when routing fails, which are intended
        to trigger applications to try other peer addresses <xref
        target="I-D.ietf-v6ops-happy-eyeballs"></xref>, and so on. The IP
        addresses of these responders can be looked up in <xref
        target="RFC1033">Reverse DNS</xref><xref target="RFC1912"></xref> to
        build a name that indicates the operator, POP, and equipment in
        question, which is useful in identifying potential problems in the
        path.</t>

        <t>Unfortunately, those addresses can also be used in another way. A
        motivated adversary can subject routers to TCP RST attacks, load-based
        DDOS, and other attacks.</t>

        <t>An alternate way to reduce this potential attack vector is to 
        not use addresses that are valid beyond the link it is attached towards. 
        A sollution describing considerations around this is given in 
        <xref target="draft-ietf-opsec-lla-only"/> while passive IPv6 
        addresses will provide network path visibility withought increasing large extend 
        of vulnerability for the devices using down the traffic path. 
        </t>
      </section>
            

      <section title="Examples of attacks">
        <t>To pick one example, attacks are being reported in which
        residential broadband customer's CPE Router is targeted with large
        volume SNMP GET Requests. The address of the router is not generally
        known; in IPv4, that may be a result of NAPT use, with the address
        being harvested from exchanges. It may be obtained from a traceroute
        to a server behind the router, or it may be determined by analysis of
        SMTP envelopes.</t>

        <t>Another example is attacks on BGP peering. BGP neighbors often peer
        between the loopback addresses of neighboring routers, to make the TCP
        session stable in the presence of link outages, but may peer using
        interface addresses. If a router is configured to use interface
        addresses in ICMP/ICMPv6 messages and to peer using those same
        addresses, the ICMP response exposes information that can be used in a
        RST attack on routing. It also facilitates any other kind of attack on
        the router, such as the previously noted SNMP attack (even if the
        router knows to refuse the message, it consumes CPU). If global
        addresses are not used - routers use link-local or private addresses -
        that makes it harder for an attacker to attack the router, but it
        means that traceroute and other uses are compromised, which is an
        attack on network forensics. If link-local addresses are used on the
        interfaces and ICMP is configured to use the loopback address, the
        router is again exposed to RST attacks.</t>
      </section>
    </section>

    <section anchor="proposal" title="Proposal">
      <t>The simplest solution seems to be to enable the router to hide in
      plain sight - to use an address as the source address in ICMP and other
      messages that is identifiable using Reverse DNS (and therefore, through
      the name, useful for network diagnostics and communication between
      operators), but does not facilitate attacks.</t>

      <t>The fundamental theory behind this proposal is the Principle of Least
      Privilege, which in this application is that an entity in the Internet
      must be able to access only the information and resources that are
      necessary for its legitimate purpose. In this case, it is reasonable,
      for various reasons, to enable a random user to identify the path his or
      her traffic is using or to identify a system in his path when reporting
      operational issues to an administration. It is not reasonable, or at
      least not required, that the user be able to specifically interact with
      any of those systems in the general case.</t>

      <t>We propose that the source IP address in an ICMP/ICMPv6 message, or
      indeed any message sent to a host that has no inherent need to contact
      the specific system, be useful for Reverse DNS, but not for touching the
      system. Ideally, it is not routable to the system in the first place; 
      The passive character of this type of addres address comes to play if
      a packet with this address as destination address on a targetted device and 
      is delivered to the interface, it is summarily dropped. Such an
      address is referred to as a "passive address", and if it comes from a
      specific prefix, the prefix is referred to as a "passive prefix".
      Addresses that are routable and not dropped on receipt will, for the
      purposes of this specification, be called "active" IP addresses.</t>

      <t>A passive address is sementically non-disguisable from any other type 
      of address and has no requirement for any new type of address-family. Any IPv4 
      or IPv6 address can become a passive address by a configuration knob when 
      specifying the interface IP address for the Interface or device. 
      </t>

      <section anchor="attributes" title="Making the address useless">
        <t>Every interface in the Internet has an address, with the exception
        of IPv4 unnumbered interfaces; even those have addresses that they
        use, which are the actual address of some other interface on the same
        system. Increasingly, this is in fact a list of addresses, some of
        which are IPv4 and some of which are IPv6.</t>

        <t>We propose that any address allocated to an interface on
        infrastructure equipment be given two binary attributes:<list
            style="hanging">
            <t hangText="UseInICMP:">If the address has this attribute TRUE,
            the corresponding address may be used as the source address of
            ICMP or ICMPv6 messages and other messages sent to hosts that have
            no need to actually touch the system. It is otherwise FALSE.</t>

            <t hangText="Respond:">If the address has this attribute TRUE, the
            device will process and respond to packets it receives that have
            this as a destination address; it is an active address. If the
            attribute is FALSE, the address is a passive address.</t>
          </list></t>

        <t>If UseInICMP is set TRUE on a Global Unicast Address or Unique
        Local Address, the address will be available for use in ICMP messages.
        If "Respond" is set TRUE, traffic sent to the address will be served
        in the usual way. This describes the present Internet usage. If
        Respond is set FALSE, traffic sent to the address will be summarily
        discarded, in effect presenting a "local firewall" blockage related to
        the address.</t>

        <t>An address that has UseInICMP set FALSE will not be used as the
        source address of an ICMP message. That address will be indiscoverable
        via ICMP messages. If Respond is TRUE and the address becomes known by
        other means, such as DNS, traffic sent to the address will be served
        in the usual way. If Respond is set FALSE, traffic sent to the address
        will be summarily discarded, in effect presenting a "local firewall"
        blockage related to the address.</t>

        <t>The scenario in view here is that <list style="symbols">
            <t>an address that is used to access the system would have
            UseInICMP FALSE (the address is not leaked in such messages) and
            Respond TRUE (messages sent to the address MAY be operated on by
            the system).</t>

            <t>an address that is used in ICMP and similar messages would have
            UseInICMP TRUE (the address MAY be leaked in such messages) and
            Respond FALSE (messages sent to the address will be dropped on
            receipt).</t>
          </list></t>
      </section>

      <section anchor="icmp" title="ICMP/ICMPv6 handling">
        <t>Per <xref target="RFC4443"></xref>, an ICMP Response such as Time
        Exceeded or Parameter Problem is sent from "the" source address of the
        interface that detected the issue. This specification narrows that: it
        SHOULD use one of the source addresses that have the attribute
        UseInICMP set to TRUE. If no address has that attribute TRUE, it
        SHOULD NOT send the message.</t>
      </section>

      <section anchor="routing" title="Removing the address from routing">
        <t>If the passive address is taken from any prefix that is not
        advertised in routing, it will be difficult for an adversary to route
        to the address, which simplifies the treatment of certain forms of
        attacks. It is not impossible; a system on the same LAN could send a
        crafted packet that would arrive anyway. However, especially in
        inter-domain routing, it is often quite reasonable to believe that
        addresses exist that need not be advertised to a neighboring
        network.</t>

        <t>One example of such an address, in IPv6, might be a <xref
        target="RFC4193">Unique Local IPv6 Unicast Address</xref>, or a global
        unicast address or prefix. There are obvious operational issues in the
        use of a global prefix; it is easy to accidentally advertise it. In an
        IPv4 network, the counterpart might be to use an <xref
        target="RFC1918"></xref> address, or to use another prefix that one
        chooses to not advertise. </t>

        <t>Link Local addresses SHOULD NOT be used in this context; while they
        are obviously unroutable except on the local LAN, they are not useful
        in Reverse DNS.</t>

        <t>One problem with this relates to <xref target="RFC2827"> Ingress
        Filtering</xref>. If the prefix used for passive addresses is not
        advertised to the neighboring network and the neighboring network is
        using unicast reverse path filtering, it will filter these responses.
        For this reason, a network doing this SHOULD advise neighboring
        networks of passive prefixes for the purpose of inclusion in ingress
        filters.</t>
      </section>

      <section anchor="dns" title="DNS and Reverse DNS">
        <t><xref target="RFC1912"></xref> recommends that "For every IP
        address, there should be a matching PTR record in the in-addr.arpa
        domain." In IPv6, there is an important special case, in that
        link-local addresses are not reflected there, and are used in routing
        protocols for local communication among IPv6 routers. Like other
        addresses, passive IP addresses SHOULD have a corresponding Reverse
        DNS entry; these names help with traceroute and in fault diagnosis.
        While active addresses may be expected to have A or AAAA records in
        the administration's own DNS, there is little point for doing so for
        passive addresses, as they are unresponsive and very likely
        unreachable.</t>

        <t>However, the names given to passive addresses SHOULD NOT be
        directly similar to the names given active IP addresses. For example,
        it may be useful to name the interfaces on a certain router so as to
        identify the router - "ethernet7.card3.router5.lax.example.com". If
        the correlation to the name of the loopback interface
        ("router5.lax.example.com") is obviously derivative, the security
        value is largely forfeit, although it might require human interaction.
        Such names should differ enough that they are not readily intuited,
        such as "rack12.lax.example.com".</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo asks the IANA for no new parameters.</t>

      <t>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 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.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This entire note could be described as addressing a set of security
      considerations. It is not a complete solution to attacks on
      infrastructure - if loopback addresses, which are used for network
      management and other purposes are generally known, the infrastructure
      can still be attacked. However, it is an important reduction of the
      attack surface. It creates no attack surface that did not already
      exist.</t>

      <section anchor="Privacy" title="Privacy Considerations">
        <t>This proposal also introduces no new privacy issues.</t>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This document grew from a conversation among the authors, John
      Brzozowski, and Thienpondt Hans. Merike Keao's review was very
      helpful.</t>
    </section>

    <section anchor="log" title="Change Log">
      <t><list style="hanging">
          <t hangText="Initial Version:">1 March 2012</t>
	  <t hangText="2th version:">7 October 2012</t>
        </list></t>
    </section>
  </middle>

  <back>
    <!-- references split to informative and normative -->

    <references title="Normative References">
      <?rfc include="reference.RFC.0791" ?>

      <?rfc include="reference.RFC.0792" ?>

      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.2460" ?>

      <?rfc include="reference.RFC.4443" ?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.ietf-v6ops-happy-eyeballs" ?>

      <reference anchor="draft-ietf-opsec-lla-only">
        <front>
          <title>Using Only Link-Local Addressing Inside an IPv6 Network</title>
          <author initials="M. Behringer, E. Vyncke"></author>
          <date month="" year="20012" />
        </front>
      </reference>


      <?rfc include="reference.RFC.1033" ?>

      <?rfc include="reference.RFC.1191" ?>

      <?rfc include="reference.RFC.1912" ?>

      <?rfc include="reference.RFC.1918" ?>

      <?rfc include="reference.RFC.1981" ?>

      <?rfc include="reference.RFC.2827" ?>

      <?rfc include="reference.RFC.4193" ?>
    </references>
  </back>
</rfc>
