--- 1/draft-ietf-opsec-ip-security-03.txt 2010-10-21 08:16:44.000000000 +0200 +++ 2/draft-ietf-opsec-ip-security-04.txt 2010-10-21 08:16:44.000000000 +0200 @@ -1,20 +1,20 @@ Operational Security Capabilities F. Gont for IP Network Infrastructure UK CPNI -(opsec) April 13, 2010 +(opsec) October 21, 2010 Internet-Draft Intended status: Informational -Expires: October 15, 2010 +Expires: April 24, 2011 Security Assessment of the Internet Protocol version 4 - draft-ietf-opsec-ip-security-03.txt + draft-ietf-opsec-ip-security-04.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 +25,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 October 15, 2010. + This Internet-Draft will expire on April 24, 2011. Copyright Notice Copyright (c) 2010 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 @@ -125,22 +125,22 @@ 4.1.1.4. Problems that arise from the ambiguity of the reassembly process . . . . . . . . . . . . . . . 51 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 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.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 @@ -148,35 +148,36 @@ 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. Advice and guidance to vendors . . . . . . . . . . . 76 Appendix B. Changes from previous versions of the draft . . . . . 76 - B.1. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 76 - B.2. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 76 - B.3. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 77 - B.4. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 77 - B.5. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 77 + B.1. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 76 + B.2. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 76 + B.3. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 76 + B.4. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 77 + B.5. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 77 + B.6. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 77 1. Preface 1.1. Introduction The TCP/IP protocols were conceived in an environment that was quite - different from the hostile environment they currently operate in. - However, the effectiveness of the protocols led to their early - adoption in production environments, to the point that, to some + 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. While many textbooks and articles have created the myth that the Internet protocols were designed for warfare environments, the top level goal for the DARPA Internet Program was the sharing of large service machines on the ARPANET [Clark1988]. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify, and overlook their security implications. While the Internet technology evolved since its inception, the @@ -296,24 +297,24 @@ to IP" (63 pages). o RFC 4632, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan" (27 pages). 1.3. Organization of this document This document is basically organized in two parts: "Internet Protocol header fields" and "Internet Protocol mechanisms". The former contains an analysis of each of the fields of the Internet Protocol - header, identifies their security implications, and discusses the - possible countermeasures. The latter contains an analysis of the - security implications of the mechanisms implemented by the Internet - Protocol. + header, identifies their security implications, and discusses + possible countermeasures for the identified threats. The latter + contains an analysis of the security implications of the mechanisms + implemented by the Internet Protocol. 2. The Internet Protocol The Internet Protocol (IP) provides a basic data transfer function for passing data blocks called "datagrams" from a source host to a destination host, across the possible intervening networks. Additionally, it provides some functions that are useful for the interconnection of heterogeneous networks, such as fragmentation and reassembly. @@ -382,25 +383,25 @@ module, it does so based on a "Protocol Type" field in the data-link packet header. In theory, different versions of IP could coexist on a network by using the same "Protocol Type" at the Link-layer, but a different value in the Version field of the IP header. Thus, a single IP module could handle all versions of the Internet Protocol, differentiating them by means of this field. However, in practice different versions of IP are identified by a - different "Protocol Type" (EtherType) 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]. + 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). 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 @@ -508,29 +509,29 @@ Figure 3: Revised Structure of the Type of Service Field (RFC 2474) The DSCP ("Differentiated Services CodePoint") is used to select the treatment the packet is to receive within the Differentiated Services Domain. The CU ("Currently Unused") field was, at the time the specification was issued, reserved for future use. The DSCP field is used to select a PHB (Per-Hop Behavior), by matching against the entire 6-bit field. Considering that the DSCP field determines how a packet is treated - within a DS domain, an attacker could send packets with a forged DSCP - field to perform a theft of service or even a Denial-of-Service - attack. In particular, an attacker could forge packets with a - codepoint of the type '11x000' which, according to Section 4.2.2.2 of - RFC 2474 [RFC2474], would give the packets preferential forwarding - treatment when compared with the PHB selected by the codepoint - '000000'. If strict priority queuing were utilized, a continuous - stream of such packets could cause a Denial of Service to other flows - which have a DSCP of lower relative order. + within a Differentiated Services (DS) domain, an attacker could send + packets with a forged DSCP field to perform a theft of service or + even a Denial-of-Service attack. In particular, an attacker could + forge packets with a codepoint of the type '11x000' which, according + to Section 4.2.2.2 of RFC 2474 [RFC2474], would give the packets + preferential forwarding treatment when compared with the PHB selected + by the codepoint '000000'. If strict priority queuing were utilized, + a continuous stream of such packets could cause a Denial of Service + to other flows which have a DSCP of lower relative order. As the DS field is incompatible with the original Type of Service field, both DS domains and networks using the original Type of Service field should protect themselves by remarking the corresponding field where appropriate, probably deploying remarking boundary nodes. Nevertheless, care must be taken so that packets received with an unrecognized DSCP do not cause the handling system to malfunction. 3.3.2.2. Explicit Congestion Notification (ECN) @@ -741,34 +742,36 @@ While in theory a pseudo-random number generator could lead to scenarios in which a given Identification number is used more than once in the same time-span for datagrams that end up getting fragmented (with the corresponding potential reassembly problems), in practice this is unlikely to cause trouble. By default, most implementations of connection-oriented protocols, such as TCP, implement some mechanism for avoiding fragmentation (such as the Path-MTU Discovery mechanism described in [RFC1191]). - Thus, fragmentation will only take place sporadically, when a non- - RFC-compliant middle-box is placed somewhere along the path that the - packets travel to get to the destination host. Once the sending - system is signaled by the middle-box that it should reduce the size - of the packets it sends, fragmentation would be avoided. Also, for - reassembly problems to arise, the same Identification value would - need to be reused very frequently, and either strong packet - reordering or packet loss would need to take place. + Thus, fragmentation will only take place if a non-RFC-compliant + middle-box that still fragments packets even when the DF bit is set + is placed somewhere along the path that the packets travel to get to + the destination host. Once the sending system is signaled by the + middle-box (by means of an ICMP "fragmentation needed and DF bit set" + error message) that it should reduce the size of the packets it + sends, fragmentation would be avoided. Also, for reassembly problems + to arise, the same Identification value would need to be reused very + frequently, and either strong packet reordering or packet loss would + need to take place. Nevertheless, regardless of what policy is used for selecting the Identification field, with the current link speeds fragmentation is - already bad enough to rely on it. A mechanism for avoiding - fragmentation (such as [RFC1191] or [RFC4821] should be implemented, - instead. + already bad enough (i.e., very likely to lead to fragment reassembly + errors) to rely on it. A mechanism for avoiding fragmentation (such + as [RFC1191] or [RFC4821] should be implemented, instead. 3.5.2.2. Connectionless Transport Protocols Connectionless transport protocols often have these characteristics: o lack of flow-control mechanisms, o lack of packet sequencing mechanisms, and/or, o lack of reliability mechanisms (such as "timeout and retransmit"). @@ -802,23 +805,23 @@ 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. In general, if IP Identification number collisions become an issue - for the application using the connection-less protocol, then use of a - different transport protocol (which hopefully avoids fragmentation) - should be considered. + 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 be dropped by the transport protocol, or would incorrectly be handed to the corresponding application. This issue is discussed in detail in section 4.1 ("Fragment Reassembly"). 3.6. Flags @@ -994,33 +997,33 @@ Most systems allow the administrator to configure the TTL to be used for the packets they originate, with the default value usually being a power of 2, or 255 (see e.g. [Arkin2000]). The recommended value for the TTL field, as specified by the IANA is 64 [IANA2006b]. This value reflects the assumed "diameter" of the Internet, plus a margin to accommodate its growth. The TTL field has a number of properties that are interesting from a security point of view. Given that the default value used for the - TTL is usually a power of two or 255, chances are that, unless the - originating system has been explicitly tuned to use a non-default + TTL is usually either a power of two, or 255, chances are that unless + the originating system has been explicitly tuned to use a non-default value, if a packet arrives with a TTL of 60, the packet was originally sent with a TTL of 64. In the same way, if a packet is received with a TTL of 120, chances are that the original packet had a TTL of 128. This discussion assumes there was no protocol scrubber, transparent proxy, or some other middle-box that overwrites the TTL field in a non-standard way, between the originating system and the point of the network in which the packet was received. - Asserting the TTL with which a packet was originally sent by the + Determining the TTL with which a packet was originally sent by the source system can help to obtain valuable information. Among other things, it may help in: o Fingerprinting the originating operating system. o Fingerprinting the originating physical device. o Mapping the network topology. o Locating the source host in the network topology. @@ -1240,20 +1243,25 @@ internet datagram. The Protocol field may not only contain a value corresponding to a protocol implemented by the system processing the packet, but also a value corresponding to a protocol not implemented, or even a value not yet assigned by the IANA [IANA2006c]. While in theory there should not be security implications from the use of any value in the protocol field, there have been security issues in the past with systems that had problems when handling packets with some specific protocol numbers [Cisco2003] [CERT2003]. + A host (i.e., end-system) that receives an IP packet encapsulating a + Protocol it does not support should drop the corresponding packet, + log the event, and possibly send an ICMP Protocol Unreachable (type + 3, code 2) error message. + 3.10. Header Checksum The Header Checksum field is an error detection mechanism meant to detect errors in the IP header. While in principle there should not be security implications arising from this field, it should be noted that due to non-RFC-compliant implementations, the Header Checksum might be exploited to detect firewalls and/or evade network intrusion detection systems (NIDS). [Ed3f2002] describes the exploitation of the TCP checksum for @@ -1724,21 +1732,21 @@ drop). [Microsoft1999] is a security advisory about a vulnerability arising from improper validation of the SSRR.Pointer field. If the option is not empty, and the address in the Destination Address field has been reached, the next address in the source route replaces the address in the Destination Address field, and the IP address of the interface that will be used to forward this datagram is recorded in its place in the source route (SSRR.Data field). - Then, the SSRR.Pointer. is incremented by 4. + Then, the SSRR.Pointer is incremented by 4. Note that the sanity checks for the SSRR.Length and the SSRR.Pointer fields described above ensure that if the option is not empty, there will be (4*n) octets in the option. That is, there will be at least one IP address to read, and enough room to record the IP address of the interface that will be used to forward this datagram. The SSRR option must be copied on fragmentation. This means that if a packet that carries the SSRR is fragmented, each of the fragments @@ -1785,21 +1793,22 @@ RR.Pointer should then incremented by 4. This option is not copied on fragmentation, and thus appears in the first fragment only. If a fragment other than the one with offset 0 contains the Record Route option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). The Record Route option can be exploited to learn about the topology of a network. However, the limited space in the IP header limits the - usefulness of this option for that purpose. + usefulness of this option for that purpose if the target network is + several hops away. 3.13.2.6. Stream Identifier (Type=136) The Stream Identifier option originally provided a means for the 16- bit SATNET stream Identifier to be carried through networks that did not support the stream concept. However, as stated by Section 4.2.2.1 of RFC 1812 [RFC1812], this option is obsolete. Therefore, it must be ignored by the processing systems. @@ -2612,30 +2621,30 @@ to approximately 15 seconds; although further research on this issue is necessary. It should be noted that in network scenarios of long-delay and high- bandwidth (usually referred to as "Long-Fat Networks"), using a long fragment timeout would likely increase the probability of collision of IP ID numbers. Therefore, in such scenarios it is highly desirable to avoid the use of fragmentation with techniques such as PMTUD [RFC1191] or PLPMTUD [RFC4821]. -4.1.2.5. countermeasure for some IDS evasion techniques +4.1.2.5. Countermeasure for some IDS evasion techniques [Shankar2003] introduces a technique named "Active Mapping" that prevents evasion of a NIDS by acquiring sufficient knowledge about the network being monitored, to assess which packets will arrive at the intended recipient, and how they will be interpreted by it. [Novak2005] describes some techniques that are applied by the Snort NIDS to avoid evasion. -4.1.2.6. countermeasure for firewall-rules bypassing +4.1.2.6. Countermeasure for firewall-rules bypassing One of the classical techniques to bypass firewall rules involves sending packets in which the header of the encapsulated protocol is fragmented. Even when it would be legal (as far as the IETF specifications are concerned) to receive such a packets, the MTUs of the network technologies used in practice are not that small to require the header of the encapsulated protocol to be fragmented. Therefore, the system performing reassembly should drop all packets which fragment the upper-layer protocol header, and this event should be logged (e.g., a counter could be incremented to reflect the packet @@ -2980,23 +2989,23 @@ Protocol (IP) and a number of implementation strategies that help to mitigate a number of vulnerabilities found in the protocol during the last 25 years or so. 6. Acknowledgements The author wishes to thank Alfred Hoenes for providing very thorough reviews of earlier versions of this document, thus leading to numerous improvements. - The author would like to thank Joel Jaeggli, Bruno Rohee, and Andrew - Yourtchenko for providing valuable comments on earlier versions of - this document. + The author would like to thank Joel Jaeggli, Warren Kumari, Bruno + Rohee, and Andrew Yourtchenko for providing valuable comments on + earlier versions of this document. This document was written by Fernando Gont on behalf of the UK CPNI (United Kingdom's Centre for the Protection of National Infrastructure), and is heavily based on the "Security Assessment of the Internet Protocol" [CPNI2008] published by the UK CPNI in 2008. The author would like to thank Randall Atkinson, John Day, Juan Fraschini, Roque Gagliano, Guillermo Gont, Martin Marino, Pekka Savola, and Christos Zoulas for providing valuable comments on earlier versions of [CPNI2008], on which this document is based. @@ -3514,52 +3523,56 @@ they may have an impact on Critical National Infrastructure's (CNI). Other ways to contact CPNI, plus CPNI's PGP public key, are available at http://www.cpni.gov.uk . Appendix B. Changes from previous versions of the draft This whole appendix should be removed by the RFC Editor before publishing this document as an RFC. -B.1. Changes from draft-ietf-opsec-ip-security-02 +B.1. Changes from draft-ietf-opsec-ip-security-03 + + o Addresses feedback received off-list by Warren Kumari. + +B.2. Changes from draft-ietf-opsec-ip-security-02 o Addresses a very thorough review by Alfred Hoenes (sent off-list) o Miscellaneous edits (centers expressions, fills missing graphics with ASCII-art, etc.) -B.2. Changes from draft-ietf-opsec-ip-security-01 +B.3. Changes from draft-ietf-opsec-ip-security-01 o Addresses rest of the feedback received from Andrew Yourtchenko (http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html) o Addresses a very thorough review by Alfred Hoenes (sent off-list) o Addresses feedback submitted by Joel Jaeggli (off-list) o Addresses feedback submitted (off-list) by Bruno Rohee. o Miscellaneous edits (centers expressions, fills missing graphics with ASCII-art, etc.) -B.3. Changes from draft-ietf-opsec-ip-security-00 +B.4. Changes from draft-ietf-opsec-ip-security-00 o Addresses part of the feedback received from Andrew Yourtchenko (http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html) -B.4. Changes from draft-gont-opsec-ip-security-01 +B.5. Changes from draft-gont-opsec-ip-security-01 o Draft resubmitted as draft-ietf, as a result of wg consensus on adopting the document as an opsec wg item. -B.5. Changes from draft-gont-opsec-ip-security-00 +B.6. Changes from draft-gont-opsec-ip-security-00 o Fixed author's affiliation. o Added Figure 6. o Fixed a few typos. o (no technical changes) Author's Address