Network Working Group                                        S. Krishnan
Request for Comments: 5722                                      Ericsson
Updates: 2460                                              December 2009
Category: Standards Track
        
Network Working Group                                        S. Krishnan
Request for Comments: 5722                                      Ericsson
Updates: 2460                                              December 2009
Category: Standards Track
        

Handling of Overlapping IPv6 Fragments

处理重叠的IPv6片段

Abstract

摘要

The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues associated with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments.

基本IPv6规范中指定的碎片和重组算法允许碎片重叠。本文档演示了与允许重叠片段相关的安全问题,并更新了IPv6规范以明确禁止重叠片段。

Status of This Memo

关于下段备忘

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2009 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本,并且提供BSD许可中所述的代码组件时不提供任何担保。

Table of Contents

目录

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................2
   2. Overlapping Fragments ...........................................2
   3. The Attack ......................................................3
   4. Node Behavior ...................................................5
   5. Security Considerations .........................................5
   6. Acknowledgements ................................................5
   7. References ......................................................6
      7.1. Normative References .......................................6
      7.2. Informative References .....................................6
        
   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................2
   2. Overlapping Fragments ...........................................2
   3. The Attack ......................................................3
   4. Node Behavior ...................................................5
   5. Security Considerations .........................................5
   6. Acknowledgements ................................................5
   7. References ......................................................6
      7.1. Normative References .......................................6
      7.2. Informative References .....................................6
        
1. Introduction
1. 介绍

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 algorithm specified for fragmentation in [RFC2460] does not prevent the fragments from overlapping, and this can lead to some security issues with firewalls [RFC4942]. This document explores the issues that can be caused by overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments.

在IPv6中,当IPv6数据包不适合MTU到其目的地的路径时,使用分段。当执行分段时,IPv6节点使用IPv6基本规范[RFC2460]第4.5节中规定的分段头,将数据报分解为适合路径MTU的较小分段。目标节点接收这些片段并重新组装它们。[RFC2460]中为碎片指定的算法无法防止碎片重叠,这可能导致防火墙[RFC4942]出现一些安全问题。本文档探讨了重叠片段可能导致的问题,并更新了IPv6规范以明确禁止重叠片段。

1.1. Conventions Used in This Document
1.1. 本文件中使用的公约

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 [RFC2119].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。

2. Overlapping Fragments
2. 重叠碎片

Commonly used firewalls use the algorithm specified in [RFC1858] to weed out malicious packets that try to overwrite parts of the transport-layer header in order to bypass inbound connection checks. [RFC1858] prevents an overlapping fragment attack on an upper-layer protocol (in this case, TCP) by recommending that packets with a fragment offset of 1 be dropped. While this works well for IPv4 fragments, it will not work for IPv6 fragments. This is because the fragmentable part of the IPv6 packet can contain extension headers before the TCP header, making this check less effective.

常用防火墙使用[RFC1858]中指定的算法来清除试图覆盖传输层报头部分以绕过入站连接检查的恶意数据包。[RFC1858]通过建议丢弃片段偏移量为1的数据包,防止上层协议(在本例中为TCP)上的重叠片段攻击。虽然这对IPv4片段有效,但对IPv6片段无效。这是因为IPv6数据包的可碎片部分可能在TCP报头之前包含扩展报头,从而降低了此检查的有效性。

3. The Attack
3. 袭击

This attack describes how a malicious node can bypass a firewall using overlapping fragments. Consider a sufficiently large IPv6 packet that needs to be fragmented.

此攻击描述恶意节点如何使用重叠片段绕过防火墙。考虑一个需要细分的足够大的IPv6数据包。

   +------------------+--------------------//-----------------------+
   |  Unfragmentable  |                 Fragmentable                |
   |       Part       |                     Part                    |
   +------------------+--------------------//-----------------------+
        
   +------------------+--------------------//-----------------------+
   |  Unfragmentable  |                 Fragmentable                |
   |       Part       |                     Part                    |
   +------------------+--------------------//-----------------------+
        

Figure 1: Large IPv6 Packet

图1:大型IPv6数据包

This packet is split into several fragments by the sender so that the packet can fit inside the path MTU. Let's say the packet is split into two fragments.

发送方将此数据包拆分为多个片段,以便数据包可以装入路径MTU中。假设数据包被分成两部分。

   +------------------+--------+--------------------+
   |  Unfragmentable  |Fragment|       first        |
   |       Part       | Header |      fragment      |
   +------------------+--------+--------------------+
        
   +------------------+--------+--------------------+
   |  Unfragmentable  |Fragment|       first        |
   |       Part       | Header |      fragment      |
   +------------------+--------+--------------------+
        
   +------------------+--------+--------------------+
   |  Unfragmentable  |Fragment|       second       |
   |       Part       | Header |      fragment      |
   +------------------+--------+--------------------+
        
   +------------------+--------+--------------------+
   |  Unfragmentable  |Fragment|       second       |
   |       Part       | Header |      fragment      |
   +------------------+--------+--------------------+
        

Figure 2: Fragmented IPv6 Packet

图2:碎片化IPv6数据包

Consider the first fragment. Let's say it contains a destination options header (DOH) 80 octets long and is followed by a TCP header.

考虑第一个片段。假设它包含一个80个八位字节长的目的地选项标头(DOH),后跟一个TCP标头。

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH
 |NextHdr=DOH(60)|   Reserved    |   FragmentOffset = 0    |Res|1|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Identification=aaaabbbb                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==DOH
 |NextHdr=TCP(6) | HdrExtLen = 9 |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 .                                                               .
 .                            Options                            .
 .                                                               .
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==TCP
 |        Source Port            |       Destination Port        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Sequence Number                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Acknowledgment Number                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Offset| Reserved  |U|A|P|R|S|F|           Window              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH
 |NextHdr=DOH(60)|   Reserved    |   FragmentOffset = 0    |Res|1|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Identification=aaaabbbb                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==DOH
 |NextHdr=TCP(6) | HdrExtLen = 9 |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 .                                                               .
 .                            Options                            .
 .                                                               .
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==TCP
 |        Source Port            |       Destination Port        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Sequence Number                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Acknowledgment Number                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Offset| Reserved  |U|A|P|R|S|F|           Window              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 3: First Fragment

图3:第一个片段

The TCP header has the following values of the flags: S(YN)=1 and 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.

TCP头具有以下标志值:S(YN)=1和A(CK)=1。这可能会使检查状态防火墙认为它是从防火墙的受信任端发起的连接请求的响应包。因此,它将允许片段通过。它还将允许片段头中具有相同片段标识值的以下片段通过。

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 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.

恶意节点可以使用TCP标头形成第二个片段,该标头更改标志并设置S(YN)=1和A(CK)=0。这可以改变接收端上的分组,将分组视为连接请求而不是响应。通过这样做,恶意节点绕过防火墙的访问控制,向受防火墙保护的节点发起连接请求。

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH
|NextHdr=DOH(60)|   Reserved    |   FragmentOffset = 10   |Res|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Identification=aaaabbbb                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==TCP
|        Source Port            |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Sequence Number                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset| Reserved  |U|A|P|R|S|F|           Window              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH
|NextHdr=DOH(60)|   Reserved    |   FragmentOffset = 10   |Res|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Identification=aaaabbbb                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==TCP
|        Source Port            |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Sequence Number                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset| Reserved  |U|A|P|R|S|F|           Window              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 4: Second Fragment

图4:第二个片段

Note that this attack is much more serious in IPv6 than in IPv4. In IPv4, the overlapping part of the TCP header does 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.

请注意,此攻击在IPv6中比在IPv4中严重得多。在IPv4中,TCP头的重叠部分不包括源端口和目标端口。在IPv6中,攻击可以很容易地将源端口或目标端口替换为重叠的片段。

4. Node Behavior
4. 节点行为

IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT 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.

传输需要分段的数据报的IPv6节点不得创建重叠的分段。在重新组装IPv6数据报时,如果确定其一个或多个组成片段是重叠片段,则必须无声地丢弃整个数据报(以及任何组成片段,包括尚未接收到的片段)。

Nodes MAY also provide mechanisms to track the reception of such packets, for instance, by implementing counters or alarms relating to these events.

节点还可以提供跟踪此类分组的接收的机制,例如,通过实现与这些事件相关的计数器或警报。

5. Security Considerations
5. 安全考虑

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.

本文档讨论一种攻击,该攻击可用于使用重叠片段绕过IPv6防火墙。它建议不允许重叠片段以防止这种攻击。

6. Acknowledgements
6. 致谢

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, Bob Hinden, Carl Wallace, Jari Arkko, Pasi Eronen, Francis

作者要感谢托马斯·纳滕、道格·蒙哥马利、加布里埃尔·黑山、雷米·丹尼斯·库尔蒙、玛拉·阿辛格、阿诺·埃巴拉德、川村正一、白塞特·萨里卡亚、维什瓦·曼拉尔、克里斯蒂安·沃格特、鲍勃·欣登、卡尔·华莱士、贾里·阿尔科、帕西·艾隆、弗朗西斯

Dupont, Neville Brownlee, Dan Romascanu, Lars Eggert, Cullen Jennings, and Alfred Hoenes for their reviews and suggestions that made this document better.

杜邦、内维尔·布朗利、丹·罗马斯卡努、拉尔斯·艾格特、卡伦·詹宁斯和阿尔弗雷德·霍恩斯感谢他们的评论和建议,这些评论和建议使本文件变得更好。

7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

[RFC2460]Deering,S.和R.Hinden,“互联网协议,第6版(IPv6)规范”,RFC 2460,1998年12月。

7.2. Informative References
7.2. 资料性引用

[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.

[RFC1858]Ziemba,G.,Reed,D.,和P.Trana,“IP片段过滤的安全考虑”,RFC 1858,1995年10月。

[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/Co-existence Security Considerations", RFC 4942, September 2007.

[RFC4942]Davies,E.,Krishnan,S.,和P.Savola,“IPv6过渡/共存安全考虑”,RFC 49422007年9月。

Author's Address

作者地址

Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada

Suresh Krishnan Ericsson加拿大魁北克皇家山Decarie镇8400大道

   EMail: suresh.krishnan@ericsson.com
        
   EMail: suresh.krishnan@ericsson.com