--- 1/draft-ietf-6man-overlap-fragment-02.txt 2009-07-05 03:12:10.000000000 +0200 +++ 2/draft-ietf-6man-overlap-fragment-03.txt 2009-07-05 03:12:10.000000000 +0200 @@ -1,19 +1,19 @@ 6man Working Group S. Krishnan Internet-Draft Ericsson -Updates: 2460 (if approved) March 8, 2009 +Updates: 2460 (if approved) July 2, 2009 Intended status: Standards Track -Expires: September 9, 2009 +Expires: January 3, 2010 Handling of overlapping IPv6 fragments - draft-ietf-6man-overlap-fragment-02 + draft-ietf-6man-overlap-fragment-03 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. @@ -22,21 +22,21 @@ 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." 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 9, 2009. + This Internet-Draft will expire on January 3, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights @@ -51,22 +51,23 @@ fragments. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . 3 2. Overlapping Fragments . . . . . . . . . . . . . . . . . . . . . 3 3. The attack . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 - 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 + 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Fragmentation is used in IPv6 when the IPv6 packet will not fit inside the path MTU to its destination. When fragmentation is performed an IPv6 node uses a fragment header as specified in section 4.5 of the IPv6 base specification [RFC2460] to break down the datagram into smaller fragments that will fit in the path MTU. The destination node receives these fragments and reassembles them. The @@ -143,32 +144,32 @@ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset| Reserved |U|A|P|R|S|F| Window | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: First Fragment The TCP header has the following values of the flags S(YN)=1 and - A(CK)=1. This makes an inspecting stateful firewall think that it is - a response packet for a connection request initiated from the trusted - side of the firewall. Hence it will allow the fragment to pass. It - will also allow the following fragments with the same Fragment - Identification value in the fragment header to pass through. + A(CK)=1. This may make an inspecting stateful firewall think that it + is a response packet for a connection request initiated from the + trusted side of the firewall. Hence it will allow the fragment to + pass. It will also allow the following fragments with the same + Fragment Identification value in the fragment header to pass through. A malicious node can form a second fragment with a TCP header that - changes the flags and sets S(YN)=1 and A(CK)=0. This would change - the packet on the receiving end to consider the packet as a - connection request instead of a response. By doing this the - malicious node has bypassed the firewall's access control to initiate - a connection request to a node protected by a firewall. + changes the flags and sets S(YN)=1 and A(CK)=0. This can change the + packet on the receiving end to consider the packet as a connection + request instead of a response. By doing this the malicious node has + bypassed the firewall's access control to initiate a connection + request to a node protected by a firewall. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH |NextHdr=DOH(60)| Reserved | FragmentOffset = 10 |Res|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification=aaaabbbb | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==TCP | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -180,37 +181,45 @@ Figure 4: Second Fragment Note that this attack is much more serious in IPv6 than in IPv4. In IPv4 the overlapping part of the TCP header did not include the source and destination ports. In IPv6 the attack can easily work to replace the source or destination port with an overlapping fragment. 4. Recommendation IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT - create overlapping fragments. IPv6 nodes that receive a fragment - that overlaps with a previously received fragment MUST cease the - reassembly process and MUST discard the previously received fragments - with the same IPv6 Source Address, IPv6 Destination Address and - Fragment Identification. + create overlapping fragments. When reassembling an IPv6 datagram, if + one or more its constituent fragments is determined to be an + overlapping fragment, the entire datagram (and any constituent + fragments, including those not yet received), MUST be silently + discarded. 5. Security Considerations This document discusses an attack that can be used to bypass IPv6 firewalls using overlapping fragments. It recommends disallowing overlapping fragments in order to prevent this attack. -6. IANA Considerations +6. Acknowledgements + + The author would like to thank Thomas Narten, Doug Montgomery, + Gabriel Montenegro, Remi Denis-Courmont, Marla Azinger, Arnaud + Ebalard, Seiichi Kawamura, Behcet Sarikaya, Vishwas Manral, Christian + Vogt, and Alfred Hoenes for their reviews and suggestions that made + this document better. + +7. IANA Considerations This document does not require any action from the IANA. -7. Normative References +8. Normative References [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.