draft-ietf-6man-overlap-fragment-02.txt   draft-ietf-6man-overlap-fragment-03.txt 
6man Working Group S. Krishnan 6man Working Group S. Krishnan
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 2460 (if approved) March 8, 2009 Updates: 2460 (if approved) July 2, 2009
Intended status: Standards Track Intended status: Standards Track
Expires: September 9, 2009 Expires: January 3, 2010
Handling of overlapping IPv6 fragments Handling of overlapping IPv6 fragments
draft-ietf-6man-overlap-fragment-02 draft-ietf-6man-overlap-fragment-03
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 16 skipping to change at page 2, line 16
fragments. fragments.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . 3
2. Overlapping Fragments . . . . . . . . . . . . . . . . . . . . . 3 2. Overlapping Fragments . . . . . . . . . . . . . . . . . . . . . 3
3. The attack . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The attack . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
Fragmentation is used in IPv6 when the IPv6 packet will not fit Fragmentation is used in IPv6 when the IPv6 packet will not fit
inside the path MTU to its destination. When fragmentation is inside the path MTU to its destination. When fragmentation is
performed an IPv6 node uses a fragment header as specified in section performed an IPv6 node uses a fragment header as specified in section
4.5 of the IPv6 base specification [RFC2460] to break down the 4.5 of the IPv6 base specification [RFC2460] to break down the
datagram into smaller fragments that will fit in the path MTU. The datagram into smaller fragments that will fit in the path MTU. The
destination node receives these fragments and reassembles them. The destination node receives these fragments and reassembles them. The
skipping to change at page 5, line 30 skipping to change at page 5, line 30
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number | | Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset| Reserved |U|A|P|R|S|F| Window | | Offset| Reserved |U|A|P|R|S|F| Window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: First Fragment Figure 3: First Fragment
The TCP header has the following values of the flags S(YN)=1 and 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(CK)=1. This may make an inspecting stateful firewall think that it
a response packet for a connection request initiated from the trusted is a response packet for a connection request initiated from the
side of the firewall. Hence it will allow the fragment to pass. It trusted side of the firewall. Hence it will allow the fragment to
will also allow the following fragments with the same Fragment pass. It will also allow the following fragments with the same
Identification value in the fragment header to pass through. Fragment Identification value in the fragment header to pass through.
A malicious node can form a second fragment with a TCP header that 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 changes the flags and sets S(YN)=1 and A(CK)=0. This can change the
the packet on the receiving end to consider the packet as a packet on the receiving end to consider the packet as a connection
connection request instead of a response. By doing this the request instead of a response. By doing this the malicious node has
malicious node has bypassed the firewall's access control to initiate bypassed the firewall's access control to initiate a connection
a connection request to a node protected by a firewall. request to a node protected by a firewall.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH
|NextHdr=DOH(60)| Reserved | FragmentOffset = 10 |Res|0| |NextHdr=DOH(60)| Reserved | FragmentOffset = 10 |Res|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification=aaaabbbb | | Identification=aaaabbbb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==TCP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==TCP
| Source Port | Destination Port | | Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 29 skipping to change at page 6, line 29
Figure 4: Second Fragment Figure 4: Second Fragment
Note that this attack is much more serious in IPv6 than in IPv4. In 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 IPv4 the overlapping part of the TCP header did not include the
source and destination ports. In IPv6 the attack can easily work to source and destination ports. In IPv6 the attack can easily work to
replace the source or destination port with an overlapping fragment. replace the source or destination port with an overlapping fragment.
4. Recommendation 4. Recommendation
IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT
create overlapping fragments. IPv6 nodes that receive a fragment create overlapping fragments. When reassembling an IPv6 datagram, if
that overlaps with a previously received fragment MUST cease the one or more its constituent fragments is determined to be an
reassembly process and MUST discard the previously received fragments overlapping fragment, the entire datagram (and any constituent
with the same IPv6 Source Address, IPv6 Destination Address and fragments, including those not yet received), MUST be silently
Fragment Identification. discarded.
5. Security Considerations 5. Security Considerations
This document discusses an attack that can be used to bypass IPv6 This document discusses an attack that can be used to bypass IPv6
firewalls using overlapping fragments. It recommends disallowing firewalls using overlapping fragments. It recommends disallowing
overlapping fragments in order to prevent this attack. 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. 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 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858, Considerations for IP Fragment Filtering", RFC 1858,
October 1995. October 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
 End of changes. 10 change blocks. 
23 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/