--- 1/draft-ietf-opsec-ip-security-06.txt 2011-04-09 00:16:15.000000000 +0200 +++ 2/draft-ietf-opsec-ip-security-07.txt 2011-04-09 00:16:15.000000000 +0200 @@ -1,20 +1,19 @@ -Operational Security Capabilities F. Gont -for IP Network Infrastructure UK CPNI -(opsec) January 27, 2011 -Internet-Draft +Operational Security Capabilities for F. Gont +IP Network Infrastructure (opsec) UK CPNI +Internet-Draft April 8, 2011 Intended status: Informational -Expires: July 31, 2011 +Expires: October 10, 2011 Security Assessment of the Internet Protocol version 4 - draft-ietf-opsec-ip-security-06.txt + draft-ietf-opsec-ip-security-07.txt Abstract This document contains a security assessment of the IETF specifications of the Internet Protocol version 4, and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). Status of this Memo @@ -25,21 +24,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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." - This Internet-Draft will expire on July 31, 2011. + This Internet-Draft will expire on October 10, 2011. Copyright Notice Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -49,127 +48,126 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scope of this document . . . . . . . . . . . . . . . . . . 7 1.3. Organization of this document . . . . . . . . . . . . . . 8 2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 8 - 3. Internet Protocol Header Fields . . . . . . . . . . . . . . . 8 + 3. Internet Protocol Header Fields . . . . . . . . . . . . . . . 9 3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 10 3.3. Type of Service . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. Original Interpretation . . . . . . . . . . . . . . . 11 3.3.2. Standard Interpretation . . . . . . . . . . . . . . . 12 3.3.2.1. Differentiated Services field . . . . . . . . . . 12 3.3.2.2. Explicit Congestion Notification (ECN) . . . . . 13 - 3.4. Total Length . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.4. Total Length . . . . . . . . . . . . . . . . . . . . . . . 15 3.5. Identification (ID) . . . . . . . . . . . . . . . . . . . 16 - 3.5.1. Some Workarounds Implemented by the Industry . . . . . 16 + 3.5.1. Some Workarounds Implemented by the Industry . . . . . 17 3.5.2. Possible security improvements . . . . . . . . . . . . 17 3.5.2.1. Connection-Oriented Transport Protocols . . . . . 17 3.5.2.2. Connectionless Transport Protocols . . . . . . . 18 - 3.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 3.7. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 21 - 3.8. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 22 + 3.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 3.7. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 22 + 3.8. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 23 3.8.1. Fingerprinting the operating system in use by the - source host . . . . . . . . . . . . . . . . . . . . . 24 + source host . . . . . . . . . . . . . . . . . . . . . 25 3.8.2. Fingerprinting the physical device from which the - packets originate . . . . . . . . . . . . . . . . . . 24 - 3.8.3. Mapping the Network Topology . . . . . . . . . . . . . 24 - 3.8.4. Locating the source host in the network topology . . . 25 - 3.8.5. Evading Network Intrusion Detection Systems . . . . . 26 + packets originate . . . . . . . . . . . . . . . . . . 25 + 3.8.3. Mapping the Network Topology . . . . . . . . . . . . . 25 + 3.8.4. Locating the source host in the network topology . . . 26 + 3.8.5. Evading Network Intrusion Detection Systems . . . . . 27 3.8.6. Improving the security of applications that make - use of the Internet Protocol (IP) . . . . . . . . . . 27 - 3.8.7. Limiting spread . . . . . . . . . . . . . . . . . . . 28 - 3.9. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 3.10. Header Checksum . . . . . . . . . . . . . . . . . . . . . 28 - 3.11. Source Address . . . . . . . . . . . . . . . . . . . . . . 28 - 3.12. Destination Address . . . . . . . . . . . . . . . . . . . 29 - 3.13. Options . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 3.13.1. General issues with IP options . . . . . . . . . . . . 31 - 3.13.1.1. Processing requirements . . . . . . . . . . . . . 31 + use of the Internet Protocol (IP) . . . . . . . . . . 28 + 3.8.7. Limiting spread . . . . . . . . . . . . . . . . . . . 29 + 3.9. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 3.10. Header Checksum . . . . . . . . . . . . . . . . . . . . . 29 + 3.11. Source Address . . . . . . . . . . . . . . . . . . . . . . 29 + 3.12. Destination Address . . . . . . . . . . . . . . . . . . . 30 + 3.13. Options . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 3.13.1. General issues with IP options . . . . . . . . . . . . 32 + 3.13.1.1. Processing requirements . . . . . . . . . . . . . 32 3.13.1.2. Processing of the options by the upper layer - protocol . . . . . . . . . . . . . . . . . . . . 32 - 3.13.1.3. General sanity checks on IP options . . . . . . . 32 - - 3.13.2. Issues with specific options . . . . . . . . . . . . . 34 - 3.13.2.1. End of Option List (Type=0) . . . . . . . . . . . 34 - 3.13.2.2. No Operation (Type=1) . . . . . . . . . . . . . . 34 + protocol . . . . . . . . . . . . . . . . . . . . 33 + 3.13.1.3. General sanity checks on IP options . . . . . . . 33 + 3.13.2. Issues with specific options . . . . . . . . . . . . . 35 + 3.13.2.1. End of Option List (Type=0) . . . . . . . . . . . 35 + 3.13.2.2. No Operation (Type=1) . . . . . . . . . . . . . . 35 3.13.2.3. Loose Source and Record Route (LSRR) - (Type=131) . . . . . . . . . . . . . . . . . . . 34 + (Type=131) . . . . . . . . . . . . . . . . . . . 35 3.13.2.4. Strict Source and Record Route (SSRR) - (Type=137) . . . . . . . . . . . . . . . . . . . 37 - 3.13.2.5. Record Route (Type=7) . . . . . . . . . . . . . . 39 - 3.13.2.6. Stream Identifier (Type=136) . . . . . . . . . . 40 - 3.13.2.7. Internet Timestamp (Type=68) . . . . . . . . . . 40 - 3.13.2.8. Router Alert (Type=148) . . . . . . . . . . . . . 43 - 3.13.2.9. Probe MTU (Type=11) (obsolete) . . . . . . . . . 44 - 3.13.2.10. Reply MTU (Type=12) (obsolete) . . . . . . . . . 44 - 3.13.2.11. Traceroute (Type=82) . . . . . . . . . . . . . . 44 - 3.13.2.12. DoD Basic Security Option (Type=130) . . . . . . 44 - 3.13.2.13. DoD Extended Security Option (Type=133) . . . . . 46 + (Type=137) . . . . . . . . . . . . . . . . . . . 38 + 3.13.2.5. Record Route (Type=7) . . . . . . . . . . . . . . 40 + 3.13.2.6. Stream Identifier (Type=136) . . . . . . . . . . 41 + 3.13.2.7. Internet Timestamp (Type=68) . . . . . . . . . . 41 + 3.13.2.8. Router Alert (Type=148) . . . . . . . . . . . . . 44 + 3.13.2.9. Probe MTU (Type=11) (obsolete) . . . . . . . . . 45 + 3.13.2.10. Reply MTU (Type=12) (obsolete) . . . . . . . . . 45 + 3.13.2.11. Traceroute (Type=82) . . . . . . . . . . . . . . 45 + 3.13.2.12. DoD Basic Security Option (Type=130) . . . . . . 45 + 3.13.2.13. DoD Extended Security Option (Type=133) . . . . . 47 3.13.2.14. Commercial IP Security Option (CIPSO) - (Type=134) . . . . . . . . . . . . . . . . . . . 46 + (Type=134) . . . . . . . . . . . . . . . . . . . 47 3.13.2.15. Sender Directed Multi-Destination Delivery - (Type=149) . . . . . . . . . . . . . . . . . . . 47 - 4. Internet Protocol Mechanisms . . . . . . . . . . . . . . . . . 47 - 4.1. Fragment reassembly . . . . . . . . . . . . . . . . . . . 47 - 4.1.1. Security Implications of Fragment Reassembly . . . . . 48 - 4.1.1.1. Problems related with memory allocation . . . . . 48 + (Type=149) . . . . . . . . . . . . . . . . . . . 48 + 4. Internet Protocol Mechanisms . . . . . . . . . . . . . . . . . 48 + 4.1. Fragment reassembly . . . . . . . . . . . . . . . . . . . 48 + 4.1.1. Security Implications of Fragment Reassembly . . . . . 49 + 4.1.1.1. Problems related with memory allocation . . . . . 49 4.1.1.2. Problems that arise from the length of the IP - Identification field . . . . . . . . . . . . . . 50 + Identification field . . . . . . . . . . . . . . 51 4.1.1.3. Problems that arise from the complexity of - the reassembly algorithm . . . . . . . . . . . . 51 + the reassembly algorithm . . . . . . . . . . . . 52 4.1.1.4. Problems that arise from the ambiguity of the - reassembly process . . . . . . . . . . . . . . . 51 + reassembly process . . . . . . . . . . . . . . . 52 4.1.1.5. Problems that arise from the size of the IP - fragments . . . . . . . . . . . . . . . . . . . . 53 - 4.1.2. Possible security improvements . . . . . . . . . . . . 53 - 4.1.2.1. Memory allocation for fragment reassembly . . . . 53 - 4.1.2.2. Flushing the fragment buffer . . . . . . . . . . 54 + fragments . . . . . . . . . . . . . . . . . . . . 54 + 4.1.2. Possible security improvements . . . . . . . . . . . . 54 + 4.1.2.1. Memory allocation for fragment reassembly . . . . 54 + 4.1.2.2. Flushing the fragment buffer . . . . . . . . . . 55 4.1.2.3. A more selective fragment buffer flushing - strategy . . . . . . . . . . . . . . . . . . . . 55 - 4.1.2.4. Reducing the fragment timeout . . . . . . . . . . 57 - 4.1.2.5. Countermeasure for some IDS evasion techniques . 57 - 4.1.2.6. Countermeasure for firewall-rules bypassing . . . 57 - 4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 58 - 4.2.1. Precedence-ordered queue service . . . . . . . . . . . 58 - 4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 59 - 4.2.3. Impact of Address Resolution on Buffer Management . . 59 - 4.2.4. Dropping packets . . . . . . . . . . . . . . . . . . . 60 - 4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 60 - 4.3.1. Unreachable addresses . . . . . . . . . . . . . . . . 61 - 4.3.2. Private address space . . . . . . . . . . . . . . . . 61 - 4.3.3. Former Class D Addresses (224/4 Address Block) . . . . 61 - 4.3.4. Former Class E Addresses (240/4 Address Block) . . . . 62 + strategy . . . . . . . . . . . . . . . . . . . . 56 + 4.1.2.4. Reducing the fragment timeout . . . . . . . . . . 58 + 4.1.2.5. Countermeasure for some IDS evasion techniques . 58 + 4.1.2.6. Countermeasure for firewall-rules bypassing . . . 58 + 4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 59 + 4.2.1. Precedence-ordered queue service . . . . . . . . . . . 59 + 4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 60 + 4.2.3. Impact of Address Resolution on Buffer Management . . 60 + 4.2.4. Dropping packets . . . . . . . . . . . . . . . . . . . 61 + 4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 61 + 4.3.1. Unreachable addresses . . . . . . . . . . . . . . . . 62 + 4.3.2. Private address space . . . . . . . . . . . . . . . . 62 + 4.3.3. Former Class D Addresses (224/4 Address Block) . . . . 62 + 4.3.4. Former Class E Addresses (240/4 Address Block) . . . . 63 4.3.5. Broadcast/Multicast addresses, and - Connection-Oriented Protocols . . . . . . . . . . . . 62 - 4.3.6. Broadcast and network addresses . . . . . . . . . . . 62 - 4.3.7. Special Internet addresses . . . . . . . . . . . . . . 62 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 65 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 65 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 67 - Appendix A. Changes from previous versions of the draft . . . . . 75 - A.1. Changes from draft-ietf-opsec-ip-security-05 . . . . . . . 75 - A.2. Changes from draft-ietf-opsec-ip-security-04 . . . . . . . 76 - A.3. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 76 - A.4. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 76 - A.5. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 76 - A.6. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 76 - A.7. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 76 - A.8. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 76 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 77 + Connection-Oriented Protocols . . . . . . . . . . . . 63 + 4.3.6. Broadcast and network addresses . . . . . . . . . . . 63 + 4.3.7. Special Internet addresses . . . . . . . . . . . . . . 63 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 66 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 66 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 66 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 68 + Appendix A. Changes from previous versions of the draft . . . . . 76 + A.1. Changes from draft-ietf-opsec-ip-security-05 . . . . . . . 76 + A.2. Changes from draft-ietf-opsec-ip-security-04 . . . . . . . 77 + A.3. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 77 + A.4. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 77 + A.5. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 77 + A.6. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 77 + A.7. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 77 + A.8. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 77 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 78 1. Preface 1.1. Introduction The TCP/IP protocols were conceived in an environment that was quite different from the hostile environment in which they currently operate. However, the effectiveness of the protocols led to their early adoption in production environments, to the point that, to some extent, the current world's economy depends on them. @@ -246,20 +244,26 @@ misbehave. In most cases, the attack packet is simply malformed; in other cases, the attack packet is well-formed, but exercises a little used path through the IP stack. Well-designed IP implementations should protect against these attacks, and therefore this document describes a number of sanity checks that are expected to prevent most of the aforementioned "packet-of-death" attack vectors. We note that if an IP implementation is is found vulnerable to one of these attacks, administrators must resort to mitigating them by packet filtering. + Additionally, this document analyzes the security implications from + changes in the operational environment since the Internet Protocol + was desgined. For example, it analyzes how the Internet Protocol + could be exploited to evade Network Intrusion Detection Systems + (NIDS) or to circumvent firewalls. + This document does not aim to be the final word on the security of the Internet Protocol (IP). On the contrary, it aims to raise awareness about many security threats based on the IP protocol that have been faced in the past, those that we are currently facing, and those we may still have to deal with in the future. It provides advice for the secure implementation of the Internet Protocol (IP), but also provides insights about the security aspects of the Internet Protocol that may be of help to the Internet operations community. Feedback from the community is more than encouraged to help this @@ -407,28 +411,47 @@ However, in practice different versions of IP are identified by a different "Protocol Type" (e.g., "EtherType" in the case of Ethernet) number in the link-layer protocol header. For example, IPv4 datagrams are encapsulated in Ethernet frames using an EtherType of 0x0800, while IPv6 datagrams are encapsulated in Ethernet frames using an EtherType of 0x86DD [IANA2006a]. Therefore, if an IPv4 module receives a packet, the Version field must be checked to be 4. If this check fails, the packet should be silently dropped, and this event should be logged (e.g., a counter - could be incremented reflecting the packet drop). + could be incremented reflecting the packet drop). If an + implementation does not performs this check, an attacker could use a + different value for the Version field, possibly evading Network + Intrusion Detection Systems (NIDS) that decide which pattern-matching + rules to apply based on the Version field. + + If the link-layer protocol employs a specific "Protocol Type" value + for encapsulating IPv4 packets (as is the case of e.g. Ethernet), a + node should check that IPv4 packets are de-multiplexed to the IPv4 + module when such value was used for the "Protocol Type" field of the + link-layer protocol. If a packet does not pass this check, it should + be silently dropped. + + An attacker could encapsulate IPv4 packets using other link-layer + "Protocol Type" values to try to subvert link-layer Access Control + Lists (ACLs), and/or for tampering with Network Intrusion + Detection Systems (NIDS). 3.2. IHL (Internet Header Length) - The IHL (Internet Header Length) indicates the length of the internet - header in 32-bit words (4 bytes). As the minimum datagram size is 20 - bytes, the minimum legal value for this field is 5. Therefore, the - following check should be enforced: + The IHL (Internet Header Length) field indicates the length of the + internet header in 32-bit words (4 bytes). The following paragraphs + decribe a number of sanity checks to be performed on the IHL field, + such that possible packet-of-death vulnerabilities are avoided. + + As the minimum datagram size is 20 bytes, the minimum legal value for + this field is 5. Therefore, the following check should be enforced: IHL >= 5 If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented reflecting the packet drop). For obvious reasons, the Internet header cannot be larger than the whole Internet datagram it is part of. Therefore, the following check should be enforced: @@ -487,20 +510,21 @@ +-----+-----------------+ | 101 | CRITIC/ECP | +-----+-----------------+ | 100 | Flash Override | +-----+-----------------+ | 011 | Flash | +-----+-----------------+ | 010 | Immediate | +-----+-----------------+ | 001 | Priority | + +-----+-----------------+ | 000 | Routine | +-----+-----------------+ Table 2: Precedence Field Values The Type of Service field can be used to affect the way in which the packet is treated by the systems of a network that process it. Section 4.2.1 ("Precedence-ordered queue service") and Section 4.2.3 ("Weak TOS") of this document describe the security implications of the Type of Service field in the forwarding of packets. @@ -825,24 +849,27 @@ result in a corrupt datagram. While some existing work [Silbersack2005] assumes that this error would be caught by some upper-layer error detection code, the error detection code in question (such as UDP's checksum) might not be able to reliably detect data corruption arising from the replacement of a complete data block (as is the case in corruption arising from collision of IP Identification numbers). In the case of UDP, unfortunately some systems have been known to not enable the UDP checksum by default. For most applications, - packets containing errors should be dropped. Probably the only - application that may benefit from disabling the checksum is - streaming media, to avoid dropping a complete sample for a single- - bit error. + packets containing errors should be dropped by the transport layer + and not delivered to the application. A small number of + applications may benefit from disabling the checksum; for example, + streaming media where it is desired to avoid dropping a complete + sample for a single-bit error, and UDP tunneling applications + where the payload (i.e. the inner packet) is protected by its own + transport checksum or other error detection mechanism. In general, if IP Identification number collisions become an issue for the application using the connection-less protocol, the application designers should consider using a different transport protocol (which hopefully avoids fragmentation). It must be noted that an attacker could intentionally exploit collisions of IP Identification numbers to perform a Denial-of- Service attack, by sending forged fragments that would cause the reassembly process to result in a corrupt datagram that would either @@ -3298,22 +3325,22 @@ Linux Clusters", Linux Journal http://www.linuxjournal.com/article/6943, 2004. [Humble1998] Humble, "Nestea exploit", http://www.insecure.org/sploits/linux.PalmOS.nestea.html, 1998. [I-D.ietf-intarea-router-alert-considerations] Faucheur, F., "IP Router Alert Considerations and Usage", - draft-ietf-intarea-router-alert-considerations-02 (work in - progress), October 2010. + draft-ietf-intarea-router-alert-considerations-03 (work in + progress), March 2011. [I-D.templin-mtuassurance] Templin, F., "Requirements for IP-in-IP Tunnel MTU Assurance", draft-templin-mtuassurance-02 (work in progress), October 2006. [IANA2006a] Ether Types, "http://www.iana.org/assignments/ethernet-numbers".