One document matched: draft-ietf-opsec-lla-only-02.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3209 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC3704 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3704.xml">
<!ENTITY RFC4193 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY RFC4443 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC5837 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5837.xml">
<!ENTITY RFC6192 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6192.xml">
<!ENTITY I-D.jdurand-bgp-security PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jdurand-bgp-security.xml">
<!ENTITY I-D.ietf-grow-private-ip-sp-cores PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-grow-private-ip-sp-cores.xml">
<!ENTITY I-D.ietf-ospf-prefix-hiding PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ospf-prefix-hiding.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<rfc category="info" docName="draft-ietf-opsec-lla-only-02" ipr="trust200902"
     submissionType="IETF" xml:lang="en">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="Link-Local Only">Using Only Link-Local Addressing Inside an
    IPv6 Network</title>

    <author fullname="Michael Behringer" initials="M." surname="Behringer">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>400 Avenue Roumanille, Bat 3</street>

          <city>Biot</city>

          <region/>

          <code>06410</code>

          <country>France</country>
        </postal>

        <email>mbehring@cisco.com</email>
      </address>
    </author>

    <author fullname="Eric Vyncke" initials="E" surname="Vyncke">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>De Kleetlaan, 6A</street>

          <city>Diegem</city>

          <region/>

          <code>1831</code>

          <country>Belgium</country>
        </postal>

        <email>evyncke@cisco.com</email>
      </address>
    </author>

    <date day="22" month="October" year="2012"/>

    <!-- Meta-data Declarations -->

    <area>Operations and Management</area>

    <workgroup>Operational Security Capabilities for IP Network
    Infrastructure</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>IPv6 security routing</keyword>

    <keyword>Link-Local</keyword>

    <keyword>Routing Protocol</keyword>

    <keyword>Security</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>In an IPv6 network it is possible to use only link-local addresses on
      infrastructure links between routers. This document discusses the
      advantages and disadvantages of this approach to help the decision
      process for a given network.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction" toc="default">
      <t>An infrastructure link between a set of routers typically does not
      require global or even <xref target="RFC4193">unique local
      addressing</xref>. Using link-local addressing on such links has a
      number of advantages, for example that routing tables do not need to
      carry link addressing, and can therefore be significantly smaller. This
      helps to decrease failover times in certain routing convergence events.
      An interface of a router is also not reachable beyond the link
      boundaries, therefore reducing the attack horizon.</t>

      <t>We propose to configure neither globally routable IPv6 addresses nor
      unique local addresses on infrastructure links of routers, wherever
      possible. We recommend to use exclusively link-local addresses on such
      links.</t>

      <t>This document discusses the advantages and caveats of this
      approach.</t>

      <t>Note: <xref target="I-D.ietf-ospf-prefix-hiding"/> describes another
      approach for OPSFv2 and OSPFv3 by modifying the existing protocols while
      this document does not modify any protocol but works only for IPv6.</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">RFC2119</xref> when they appear in ALL CAPS. These
        words may also appear in this document in lower case as plain English
        words, absent their normative meanings.</t>
      </section>
    </section>

    <section anchor="using"
             title="Using Link-Local Address on Infrastructure Links"
             toc="default">
      <t>This document proposes to use only link-local addresses (LLA) on all
      router interfaces on infrastructure links. Routers typically do not need
      to be reached from nodes of the network, nor from outside the network.
      For an network operator there may be reasons to send packets to an
      infrastructure link for certain monitoring tasks; many of those tasks
      could also be handled differently, not requiring routable address space
      on infrastructure links.</t>

      <section anchor="approach" title="The Approach" toc="default">
        <t>Neither global IPv6 addresses nor unique local addresses are
        configured on infrastructure links. In the absence of specific global
        or unique local address definitions, the default behavior of routers
        is to use link-local addresses notably for routing protocols. These
        link-local addresses SHOULD be hard-coded to prevent the change of
        EUI-64 addresses when changing of MAC address (such as after changing
        a network interface card).</t>

        <t><xref target="RFC4443">ICMPv6</xref> error messages
        (packet-too-big, time-exceeded...) are required for routers, therefore
        a loopback interface must be configured with an IPv6 address with a
        greater scope than link-local (this will usually be a global scope).
        This greater than link-local scope IPv6 address must be used as the
        source IPv6 address for all generated ICMPv6 messages sent to a non
        link-local address and must belong to the operator and be part of an
        announced prefix (with a suitable prefix length) to avoid being
        dropped by other routers implementing <xref target="RFC3704"/>.</t>

        <t>The effect on specific traffic types is as follows:<list
            style="symbols">
            <t>Control plane protocols, such as BGP, ISIS, OSPFv3, RIPng, PIM
            work by default or can be configured to work with link-local
            addresses.</t>

            <t>Management plane traffic, such as SSH, Telnet, SNMP, ICMP echo
            request ... can be addressed to loopback addresses of routers with
            a greater than link-local scope address. Router management can
            also be done over out-of-band channels.</t>

            <t>ICMP error message can be sourced from a loopback address. They
            must not be sourced from link-local addresses when the destination
            is non link-local.</t>

            <t>Data plane traffic is forwarded independently of the link
            address type.</t>

            <t>Neighbor discovery (neighbor solicitation and neighbor
            advertisement) is done by using link-local unicast and multicast
            addresses, therefore neighbor discovery is not affected.</t>
          </list>We therefore conclude that it is possible to construct a
        working network in this way.</t>
      </section>

      <section anchor="advantages" title="Advantages" toc="default">
        <t>Smaller routing tables: Since the routing protocol only needs to
        carry one loopback address per router, it is smaller than in the
        traditional approach where every infrastructure link addresses are
        carried in the routing protocol. This reduces memory consumption, and
        increases the convergence speed in some routing failover cases
        (notably because the Forwarding Information Base to be downloaded to
        line cards are smaller but also because there are less prefixes in the
        Routing Information Base hence accelerating the routing algorithm).
        Note: smaller routing tables can also be achieved by putting
        interfaces in passive mode for the IGP.</t>

        <t>Reduced attack surface: Every routable address on a router
        constitutes a potential attack point: a remote attacker can send
        traffic to that address, for example a TCP SYN flood, or he can intent
        SSH brute force password attacks. If a network only uses loopback
        addresses for the routers, only those loopback addresses need to be
        protected from outside the network. This significantly eases
        protection measures, such as infrastructure access control lists. See
        also <xref target="I-D.ietf-grow-private-ip-sp-cores"/> for further
        discussion on this topic.</t>

        <t>Lower configuration complexity: LLAs require no specific
        configuration (except when they are statically configured), thereby
        lowering the complexity and size of router configurations. This also
        reduces the likelihood of configuration mistakes.</t>

        <t>Simpler DNS: Less routable address space in use also means less DNS
        mappings to maintain.</t>
      </section>

      <section anchor="caveats" title="Caveats" toc="default">
        <t>Interface ping: If an interface doesn't have a routable address, it
        can only be pinged from a node on the same link. Therefore it is not
        possible to ping a specific link interface remotely. A possible
        workaround is to ping the loopback address of a router instead. In
        most cases today it is not possible to see which link the packet was
        received on; however, <xref target="RFC5837">RFC5837</xref> suggests
        to include the interface identifier of the interface a packet was
        received on in the ICMP response; it must be noted that there are
        little implemention of this ICMP extension. With this approach it
        would be possible to ping a router on the loopback address, yet see
        which interface the packet was received on. To check liveliness of a
        specific interface it may be necessary to use other methods, for
        example to connect to the router via SSH and to check locally or use
        SNMP.</t>

        <t>Traceroute: Similar to the ping case, a reply to a traceroute
        packet would come from a loopback address with a greater than
        link-local address. Today this does not display the specific interface
        the packets came in on. Also here, <xref
        target="RFC5837">RFC5837</xref> provides a solution.</t>

        <t>Hardware dependency: LLAs are usually EUI-64 based, hence, they
        change when the MAC address is changed. This could pose problem in a
        case where the routing neighbor must be configured explicitly (e.g.
        BGP) and a line card needs to be physically replaced hence changing
        the EUI-64 LLA and breaking the routing neighborship. But, LLAs can be
        statically configured such as fe80::1 and fe80::2 which can be used to
        configure any required static routing neighborship.</t>

        <t>Network Management System (NMS) toolkits: If there is any NMS tool
        that makes use of interface IP address of a router to carry out any of
        NMS functions, then it would no longer work, if the interface is
        missing routable address. A possible workaround for such tools is to
        use the routable loopback address of the router instead. Most vendor
        implementations allow the specification of the loopback address for
        SYSLOG, IPfix, SNMP. LLDP (IEEE 802.1AB-2009) runs directly over
        Ethernet and does not require any IPv6 address so dynamic network
        discovery is not hindered when using LLDP. But, network discovery
        based on NDP cache content will only display the link-local addresses
        and not the loopback global address; therefore, network discovery
        should rather be based on the Route Information Base to detect
        adjacent nodes.</t>

        <t>MPLS and RSVP-TE <xref target="RFC3209"/> allows establishing MPLS
        LSP on a path that is explicitly identified by a strict sequence of IP
        prefixes or addresses (each pertaining to an interface or a router on
        the path). This is commonly used for Fast Re-Route (FRR). However, if
        an interface uses only a link-local address, then such LSPs cannot be
        established. At the time of writing this document, there is no
        workaround for this case; therefore where RSVP-TE is being used, the
        approach proposed in this document does not work.</t>
      </section>

      <section title="Internet Exchange Points">
        <t>Internet Exchange Points (IXPs) have a special importance in the
        global Internet, because they connect a high number of networks in a
        single location, and because significant part of Internet traffic pass
        through at least one IXP. An IXP with all the service provider nodes
        requires therefore a very high level of security. The address space
        used on an IXP is generally known, as it is registered in the global
        Internet Route Registry, or it is easily discoverable through
        traceroute. The IXP prefix is especially critical, because practically
        all addresses on this prefix are critical systems in the Internet.</t>

        <t>Apart from general device security guidelines, there are generally
        two additional ways to raise security (see also <xref
        target="I-D.jdurand-bgp-security"/>): <list style="numbers">
            <t>Not to announce the prefix in question, and</t>

            <t>To drop all traffic destined to the IXP prefixes from traffic
            from remote locations.</t>
          </list>Not announcing the prefix of the IXP however would frequently
        result in traceroute and similar packets (required for PMTUd) to be
        dropped due to uRPF checks. Given that PMTUd is critical, this is
        generally not acceptable. Dropping all external traffic to the IXP
        prefix is hard to implement, because if only one service provider on
        an IXP routes does not filter correctly, then all IXP routers are
        reachable from at least that service provider network.</t>

        <t>As the prefix used in IXP is usually longer than a /48 it is
        frequently dropped by route filters on the Internet having the same
        net effect as not announced the prefix.</t>

        <t>Using link-local addresses on the IXP may help in this scenario. In
        this case, the generated ICMP packets would be generated from loopback
        interfaces or from any other interfaces with globally routable sources
        without any configuration. However in this case, each service provider
        would use his own address space, making a generic attack against all
        devices on the IXP harder. Also all the loopback addresses on the IXP
        can be discovered by a potential attacker by a simple traceroute; a
        generic attack is therefore still possible, but it would require
        significantly more work.</t>

        <t>In some cases service providers carry the IXP addresses in their
        IGP for certain forms of traffic engineering across multiple exit
        points. If link local addresses are used, these cannot be used for
        this purpose; in this case, the service provider would have to employ
        other methods of traffic engineering.</t>
      </section>

      <section title="Summary" toc="default">
        <t>Using link-local addressing only on infrastructure links has a
        number of advantages, such as a smaller routing table size and a
        reduced attack surface. It also simplifies router configurations.
        However, the way certain network management tasks are carried out
        today has to be adapted to provide the same level of detail, for
        example interface identifiers in traceroute.</t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>Using LLAs only on infrastructure links reduces the attack surface of
      a router: loopback addresses with routed addresses are still reachable
      and must be secured, but infrastructure links can only be attacked from
      the local link. This simplifies security of control and management
      planes. The proposal does not impact the security of the data plane.
      This proposal does not address <xref target="RFC6192">control
      plane</xref> attacks generated by data plane packets (such as hop-limit
      expiration or packets containing a hop-by-hop extension header).</t>

      <t>As in the traditional approach, this approach relies on the
      assumption that all routers can be trusted due to physical and
      operational security.</t>
    </section>

    <section title="IANA Considerations">
      <t>There are no IANA considerations or implications that arise from this
      document.</t>
    </section>

    <section title="Acknowledgements">
      <t>The authors would like to thank Salman Asadullah, Brian Carpenter,
      Benoit Claise, Simon Eng, Wes George, Janos Mohacsi, Alvaro Retana, Ivan
      Pepelnjak for their useful comments about this work.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      &RFC2119;
    </references>

    <references title="Informative References">
      &RFC3209;

      &RFC3704;

      &RFC4193;

      &RFC4443;

      &RFC5837;

      &RFC6192;

      &I-D.ietf-ospf-prefix-hiding;

      &I-D.ietf-grow-private-ip-sp-cores;

      &I-D.jdurand-bgp-security;
    </references>
  </back>
</rfc>