One document matched: draft-taylor-v6ops-fragdrop-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!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 RFC2671 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2671.xml">
<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC6192 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6192.xml">
<!ENTITY RFC6946 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6946.xml">
<!ENTITY I-D.ietf-6man-oversized-header-chain PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-oversized-header-chain.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<!-- <?rfc strict="yes" ?> -->
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-taylor-v6ops-fragdrop-01"
     ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
     pre5378Trust200902
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

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

  <front>
    <title abbrev="Why Operators Filter Fragments">Why Operators Filter
    Fragments and What It Implies</title>

    <author fullname="Joel Jaeggli" initials="J." surname="Jaeggli">
      <organization>Zynga</organization>

      <address>
        <postal>
          <street>630 taylor ct #10</street>

          <city>Mountain View</city>

          <region>CA</region>

          <code>94043</code>

          <country>USA</country>
        </postal>

        <email>jjaeggli@zynga.com</email>
      </address>
    </author>

    <author fullname="Lorenzo Colitti" initials="L." surname="Colitti">
      <organization>Google</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <email>lorenzo@google.com</email>
      </address>
    </author>

    <author fullname="Warren Kumari" initials="W." surname="Kumari">
      <organization>Google</organization>

      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>

          <city>Mountain View</city>

          <region>CA</region>

          <code>94043</code>

          <country>USA</country>
        </postal>

        <phone/>

        <email>warren@kumari.net</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>

        <phone/>

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

    <author fullname="Merike Kaeo" initials="M." surname="Kaeo">
      <organization>Double Shot Security</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <email>merike@doubleshotsecurity.com</email>
      </address>
    </author>

    <!-- Another author who claims to be an editor -->

    <author fullname="Tom Taylor" initials="T." role="editor" surname="Taylor">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city>Ottawa</city>

          <region>Ontario</region>

          <code/>

          <country>Canada</country>
        </postal>

        <phone/>

        <email>tom.taylor.stds@gmail.com</email>
      </address>
    </author>

    <date month="May" year="2013"/>

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Engineering Task Force</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>fragmentation</keyword>

    <keyword>IPv6</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>This memo was written to make application developers and network
      operators aware of the significant possibility that IPv6 packets
      containing fragmentation extension headers may fail to reach their
      destination. Some protocol or application assumptions about the ability
      to use messages larger than a single packet may accordingly not be
      supportable in all networks or circumstances.</t>

      <t>This memo provides observational evidence for the dropping of IPv6
      fragments along a significant number of paths, explores the operational
      impact of fragmentation and the reasons and scenarios where drops occur,
      and considers the effect of fragment drops on applications where
      fragmentation is known to occur, particularly including DNS.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Measurements of whether Internet Service Providers and edge networks
      deliver IPv6 fragments to their destination reveal that for IPv6 in
      particular, fragments are being dropped along a substantial number of
      paths. The filtering of IPv6 datagrams with fragmentation headers is
      presumed to be a non-issue in the core of the Internet, where fragments
      are routed just like any other IPv6 datagram. However, fragmentation can
      creates operational issues at the edges of the Internet that may lead to
      administratively imposed filtering or inadvertent failure to deliver the
      fragment to the end-system or application.</t>

      <t><xref target="itHappens"/> begins with some observations on how often
      IPv6 fragment loss occurs in practice. We go on to look at the
      operational reasons for filtering fragments, a key aspect of which is
      the limitations they expose in the application of security policy, at
      resource bottlenecks and in forwarding decisions. <xref
      target="appEffect"/> then looks at the impact on key applications,
      particularly DNS.</t>

      <t>In the longer run, as network operators gain a better understanding
      of the risks and non-risks of fragmentation and as middlebox, customer
      premise equipment (CPE), and host implementations improve, we believe
      that some incidence of fragment dropping currently required will
      diminish. Some of the justifications for filtering will persist in the
      long-term, and application developers and network operators must remain
      aware of the implications.</t>

      <t>This document deliberately refrains from discussing possible
      responses to the problem posed by the dropping of IPv6 fragments. Such a
      discussion will quickly turn up a number of possibilities,
      application-specific or more general; but the amount of time needed to
      specify and deploy a given resolution will be a major constraint in
      choosing amongst them. In any event, that discussion is likely to
      proceed in multiple directions, occur in different areas and is
      therefore considered beyond the scope of this memo.</t>
    </section>

    <section anchor="itHappens" title="Observations and Rationale">
      <t><xref target="Blackhole"/> is a good public reference for some
      empirical data on IPv6 fragment filtering. It describes experiments run
      to determine the incidence and location of ICMP Packet Too Big and
      fragment filtering. The authors used fragmented DNS packets to determine
      the latter, setting the servers to an IPv6 minimum of 1280 bytes to
      avoid any PMTU issues. The tests found for IPv6 that filtering appeared
      to be occurring on some 10% of the tested paths. The filtering appeared
      to be located at the edge (enterprise and customer networks) rather than
      in the core.</t>

      <section title="Possible Causes">
        <t>Why does such filtering happen? One cause is non-conforming
        implementations in CPE and low-end routers. Some network managers
        filter fragments on principle, thinking this is an easier way to deter
        realizable attacks utilizing IPv6 fragments without thinking of other
        network impacts, similar to the practice of filtering ICMP Packet Too
        Big. Both implementations and management should improve over time,
        reducing the problem somewhat.</t>

        <t>Some filtering and dropping of fragments is known to be done for
        hardware, performance, or topological considerations.</t>

        <section title="Stateful inspection">
          <t>Stateful inspection devices or destination hosts can readily
          experience resource exhaustion if they are flooded with fragments
          that are not followed in a timely manner by the remaining fragments
          of the original datagram. Holding fragments for reassembly even on
          end-system firewalls can readily result in an effective denial of
          service by memory and CPU exhaustion even if techniques, such as
          virtual re-assambly exist.</t>
        </section>

        <section title="Stateless ACLs">
          <t>Stateless ACLs at layer 4 and up may be difficult to apply to
          fragments other than the first one in which enough of the upper
          layer header is present. As <xref target="Attacks"/> demonstrates,
          inconsistencies in reassembly logic between middleboxes or CPEs and
          hosts can cause fragments to be wrongfully discarded, or can allow
          exploits to pass undetected through middleboxes. Stateless load
          balancing schemes may hash fragmented datagrams from the same flow
          to different paths because the 5-tuple may be available on only the
          initial fragment. While rehashing has the possibility of reordering
          packets in ISP cores it is not disastrous. However, in front of a
          stateful inspection device, load balancer tier, or anycast service
          instance, where headers other than the L3 header -- for example, the
          L4 header, interface index (for traffic already rehashed onto
          different paths), DS fields -- are considered as part of the hash,
          rehashing may result in the fragments being delivered to different
          end-systems</t>
        </section>

        <section title="Performance considerations">
          <t>Leaving aside these incentives towards fragment dropping, other
          considerations may weigh on the operator's mind. One example cited
          on the NANOG list was that of a router where fragment processing was
          done by the control plane processor rather than in the forwarding
          plane hardware, with a consequent hit on performance.</t>
        </section>

        <section title="Other considerations">
          <t>Another incentive toward dropping of fragments is the
          disproportionate number of software errors still being encountered
          in fragment processing. Since this code is exercised less frequently
          than the rest of the stack, bugs remain longer in the code before
          they are detected. Some of these software errors can introduce
          vulnerabilities subject to exploitation. It is common practice <xref
          target="RFC6192"/> to recommend that control-plane ACLs protecting
          routers and network devices be configured to drop all fragments.</t>
        </section>

        <section title="Conclusions">
          <t>Operators weigh the risks associated with each of the
          considerations just enumerated, and come up with the most suitable
          policy for their circumstances. It is likely that at least some
          operators will find it desirable to drop fragments in at least some
          cases.</t>

          <t>The IETF and operators can help this effort by identifying
          specific classes of fragments that do not represent legitimate use
          cases and hence should always be dropped. Examples of this work are
          given by <xref target="RFC6946"/> and <xref
          target="I-D.ietf-6man-oversized-header-chain"/>. The problem of
          inconsistent implementations may also be mitigated by providing
          further advice on the more difficult points. However, some cases
          will remain where legitimate fragments are discarded for legitimate
          reasons. The potential problems these cases pose for applications is
          our next topic.</t>
        </section>
      </section>

      <!-- itHappens -->

      <section anchor="appEffect" title="Impact on Applications">
        <t>Some applications can live without fragmentation, some cannot. UDP
        DNS is one application that has the potential to be impacted when
        fragment dropping occurs. EDNS0 extensions <xref target="RFC2671"/>
        allow for responses in UDP PDUs that are greater than 512 bytes.
        Particularly with DNSSEC <xref target="RFC4033"/>, responses may be
        larger than the link MTU and fragmentation would therefore occur at
        the sending host in order to respond using UDP. The current choices
        open to the operators of DNS servers in this situation are to defer
        deployment of DNSSEC, fragment responses, or use TCP if there are
        cases where the rrset would be expected to exceed the MTU. The use of
        fallback to TCP will impose a major resource and performance hit and
        increases vulnerability to denial of service attacks.</t>

        <t>Other applications, such as the Network File System, NFS, are also
        known to fragment large UDP packets for datagrams larger than the MTU.
        NFS is most often restricted to the internal networks of
        organizations. In general, managing NFS connectivity should not be
        impacted by decisions mananging fragment drops at network borders or
        end-systems.</t>
      </section>
    </section>

    <!-- appEffect -->

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors of this document would like to thank the RIPE Atlas
      project and NLNetlabs whose conclusions ignited this document.</t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The potential for denial of service attacks, as well as limitations
      inherent in upper-layer filtering when dealing with non-initial
      fragments are significant issues under consideration by operators and
      end-users filtering fragments. This document does not offer alternative
      solutions to that problem, it does describe the impact of those
      filtering practices.</t>
    </section>
  </middle>

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

  <back>
    <references title="Informative References">
      &RFC2671;

      &RFC4033;

      &RFC6192;

      &RFC6946;

      <reference anchor="Blackhole">
        <front>
          <title>Discovering Path MTU black holes on the Internet using RIPE
          Atlas</title>

          <author fullname="Maikel de Boer" initials="M." surname="de Boer">
            <organization>U. of Amsterdam</organization>
          </author>

          <author fullname="Jeffrey Bosma" initials="J." surname="Bosma">
            <organization>U. of Amsterdam</organization>
          </author>

          <date month="July" year="2012"/>
        </front>

        <annotation>http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf</annotation>
      </reference>

      <reference anchor="Attacks">
        <front>
          <title>Attacking IPv6 Implementation Using Fragmentation</title>

          <author fullname="Antonios Atlasis" initials="A." surname="Atlasis">
            <organization>Centre for Strategic Cyberspace + Security
            Science</organization>
          </author>

          <date month="March" year="2012"/>
        </front>

        <annotation>http://media.blackhat.com/bh-eu-12/Atlasis/bh-eu-12-Atlasis-Attacking_IPv6-WP.pdf</annotation>
      </reference>

      &I-D.ietf-6man-oversized-header-chain;
    </references>

    <!-- Change Log

v00 2012-10-09  PTT   Initial version
v01 wk
v02 jj
-->
  </back>
</rfc>