One document matched: draft-ietf-opsec-lla-only-01.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.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-01" 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="21" month="September" 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 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 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 also be sourced from the loopback
            address.</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, thereby lowering the complexity and size of router
        configurations. This also reduces the likelihood of configuration
        mistakes.</t>

        <t>Simpler DNS: Less greater-than-link-local address space in use also
        means less DNS mappings to maintain because DNS is not really suitable
        to contain link-local addresses as DNS has no clue to the link
        scope.</t>
      </section>

      <section anchor="caveats" title="Caveats and Possible Workarounds"
               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.</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 FRR. However, if an interface
        uses only a link-local address, then such LSPs can not be established.
        A possible workaround is to use loose sequence of IP prefixes or
        addresses (each pertaining to a router) to identify an explicit path
        along with shared-risk-link-group (to not use a set of common
        interfaces).</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 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;
    </references>
  </back>
</rfc>