--- 1/draft-ietf-opsec-ip-security-01.txt 2010-02-20 13:10:59.000000000 +0100 +++ 2/draft-ietf-opsec-ip-security-02.txt 2010-02-20 13:10:59.000000000 +0100 @@ -1,20 +1,28 @@ Operational Security Capabilities F. Gont for IP Network Infrastructure UK CPNI -(opsec) August 20, 2009 +(opsec) February 20, 2010 Internet-Draft Intended status: Informational -Expires: February 21, 2010 +Expires: August 24, 2010 Security Assessment of the Internet Protocol version 4 - draft-ietf-opsec-ip-security-01.txt + draft-ietf-opsec-ip-security-02.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 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. @@ -23,128 +31,142 @@ 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 February 21, 2010. + This Internet-Draft will expire on August 24, 2010. Copyright Notice - Copyright (c) 2009 IETF Trust and the persons identified as the + 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 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 - and restrictions with respect to this document. - -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). + 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. Table of Contents - 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.2. Scope of this document . . . . . . . . . . . . . . . . . . 6 - 1.3. Organization of this document . . . . . . . . . . . . . . 6 - 2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 6 - 3. Internet Protocol header fields . . . . . . . . . . . . . . . 7 - 3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 8 - 3.3. TOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.4. Total Length . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.5. Identification (ID) . . . . . . . . . . . . . . . . . . . 11 - 3.5.1. Some workarounds implemented by the industry . . . . . 12 - 3.5.2. Possible security improvements . . . . . . . . . . . . 12 - 3.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 3.7. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 16 - 3.8. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 17 - 3.9. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 3.10. Header Checksum . . . . . . . . . . . . . . . . . . . . . 22 - 3.11. Source Address . . . . . . . . . . . . . . . . . . . . . . 22 - 3.12. Destination Address . . . . . . . . . . . . . . . . . . . 23 - 3.13. Options . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 3.13.1. General issues with IP options . . . . . . . . . . . . 24 - 3.13.1.1. Processing requirements . . . . . . . . . . . . . 24 - 3.13.1.2. Processing of the options by the upper layer - protocol . . . . . . . . . . . . . . . . . . . . 25 - 3.13.1.3. General sanity checks on IP options . . . . . . . 25 - 3.13.2. Issues with specific options . . . . . . . . . . . . . 27 - 3.13.2.1. End of Option List (Type = 0) . . . . . . . . . . 27 - 3.13.2.2. No Operation (Type = 1) . . . . . . . . . . . . . 27 - 3.13.2.3. Loose Source Record Route (LSRR) (Type = 131) . . 27 - 3.13.2.4. Strict Source and Record Route (SSRR) (Type = - 137) . . . . . . . . . . . . . . . . . . . . . . 30 - 3.13.2.5. Record Route (Type = 7) . . . . . . . . . . . . . 34 - 3.13.2.6. Stream Identifier (Type = 136) . . . . . . . . . 35 - 3.13.2.7. Internet Timestamp (Type = 68) . . . . . . . . . 36 - 3.13.2.8. Router Alert (Type = 148) . . . . . . . . . . . . 39 - 3.13.2.9. Probe MTU (Type =11) . . . . . . . . . . . . . . 40 - 3.13.2.10. Reply MTU (Type = 12) . . . . . . . . . . . . . . 40 - 3.13.2.11. Traceroute (Type = 82) . . . . . . . . . . . . . 40 - 3.13.2.12. DoD Basic Security Option (Type = 130) . . . . . 40 - 3.13.2.13. DoD Extended Security Option (Type = 133) . . . . 41 - 3.13.2.14. Commercial IP Security Option (CIPSO) (Type = + 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.2. Scope of this document . . . . . . . . . . . . . . . . . . 7 + 1.3. Organization of this document . . . . . . . . . . . . . . 7 + 2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 7 + 3. Internet Protocol header fields . . . . . . . . . . . . . . . 8 + 3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 9 + 3.3. Differentiated Services field . . . . . . . . . . . . . . 10 + 3.4. Explicit Congestion Notification (ECN) . . . . . . . . . . 11 + 3.5. Total Length . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.6. Identification (ID) . . . . . . . . . . . . . . . . . . . 13 + 3.6.1. Some workarounds implemented by the industry . . . . . 14 + 3.6.2. Possible security improvements . . . . . . . . . . . . 14 + 3.7. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 3.8. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 18 + 3.9. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 19 + 3.9.1. Fingerprinting the operating system in use by the + source host . . . . . . . . . . . . . . . . . . . . . 20 + 3.9.2. Fingerprinting the physical device from which the + packets originate . . . . . . . . . . . . . . . . . . 20 + 3.9.3. Locating the source host in the network topology . . . 20 + 3.9.4. Evading Network Intrusion Detection Systems . . . . . 22 + 3.9.5. Improving the security of applications that make + use of the Internet Protocol (IP) . . . . . . . . . . 22 + 3.10. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 3.11. Header Checksum . . . . . . . . . . . . . . . . . . . . . 24 + 3.12. Source Address . . . . . . . . . . . . . . . . . . . . . . 24 + 3.13. Destination Address . . . . . . . . . . . . . . . . . . . 25 + 3.14. Options . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 3.14.1. General issues with IP options . . . . . . . . . . . . 26 + 3.14.1.1. Processing requirements . . . . . . . . . . . . . 26 + 3.14.1.2. Processing of the options by the upper layer + protocol . . . . . . . . . . . . . . . . . . . . 27 + 3.14.1.3. General sanity checks on IP options . . . . . . . 27 + 3.14.2. Issues with specific options . . . . . . . . . . . . . 29 + 3.14.2.1. End of Option List (Type = 0) . . . . . . . . . . 29 + 3.14.2.2. No Operation (Type = 1) . . . . . . . . . . . . . 29 + 3.14.2.3. Loose Source Record Route (LSRR) (Type = 131) . . 29 + 3.14.2.4. Strict Source and Record Route (SSRR) (Type = + 137) . . . . . . . . . . . . . . . . . . . . . . 32 + 3.14.2.5. Record Route (Type = 7) . . . . . . . . . . . . . 34 + 3.14.2.6. Stream Identifier (Type = 136) . . . . . . . . . 36 + 3.14.2.7. Internet Timestamp (Type = 68) . . . . . . . . . 36 + 3.14.2.8. Router Alert (Type = 148) . . . . . . . . . . . . 39 + 3.14.2.9. Probe MTU (Type =11) . . . . . . . . . . . . . . 40 + 3.14.2.10. Reply MTU (Type = 12) . . . . . . . . . . . . . . 40 + 3.14.2.11. Traceroute (Type = 82) . . . . . . . . . . . . . 40 + 3.14.2.12. DoD Basic Security Option (Type = 130) . . . . . 41 + 3.14.2.13. DoD Extended Security Option (Type = 133) . . . . 42 + 3.14.2.14. Commercial IP Security Option (CIPSO) (Type = 134) . . . . . . . . . . . . . . . . . . . . . . 42 - 3.13.2.15. Sender Directed Multi-Destination Delivery + 3.14.2.15. Sender Directed Multi-Destination Delivery (Type = 149) . . . . . . . . . . . . . . . . . . 43 - 3.14. Differentiated Services field . . . . . . . . . . . . . . 43 - 3.15. Explicit Congestion Notification (ECN) . . . . . . . . . . 44 + 3.15. TOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4. Internet Protocol Mechanisms . . . . . . . . . . . . . . . . . 45 4.1. Fragment reassembly . . . . . . . . . . . . . . . . . . . 45 - 4.1.1. Problems related with memory allocation . . . . . . . 46 - 4.1.2. Problems that arise from the length of the IP - Identification field . . . . . . . . . . . . . . . . . 48 - 4.1.3. Problems that arise from the complexity of the - reassembly algorithm . . . . . . . . . . . . . . . . . 49 - 4.1.4. Problems that arise from the ambiguity of the - reassembly process . . . . . . . . . . . . . . . . . . 49 - 4.1.5. Problems that arise from the size of the IP - fragments . . . . . . . . . . . . . . . . . . . . . . 50 - 4.1.6. Possible security improvements . . . . . . . . . . . . 50 - 4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 56 - 4.2.1. Precedence-ordered queue service . . . . . . . . . . . 56 - 4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 57 + 4.1.1. Security Implications of Fragment Reassembly . . . . . 46 + 4.1.1.1. Problems related with memory allocation . . . . . 46 + 4.1.1.2. Problems that arise from the length of the IP + Identification field . . . . . . . . . . . . . . 48 + 4.1.1.3. Problems that arise from the complexity of + the reassembly algorithm . . . . . . . . . . . . 48 + 4.1.1.4. Problems that arise from the ambiguity of the + reassembly process . . . . . . . . . . . . . . . 49 + 4.1.1.5. Problems that arise from the size of the IP + fragments . . . . . . . . . . . . . . . . . . . . 50 + 4.1.2. Possible security improvements . . . . . . . . . . . . 50 + 4.1.2.1. Memory allocation for fragment reassembly . . . . 50 + 4.1.2.2. Flushing the fragment buffer . . . . . . . . . . 51 + 4.1.2.3. A more selective fragment buffer flushing + strategy . . . . . . . . . . . . . . . . . . . . 52 + 4.1.2.4. Reducing the fragment timeout . . . . . . . . . . 54 + 4.1.2.5. Counter-measure for some IDS evasion + techniques . . . . . . . . . . . . . . . . . . . 55 + 4.1.2.6. Counter-measure for firewall-rules bypassing . . 55 + 4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 55 + 4.2.1. Precedence-ordered queue service . . . . . . . . . . . 55 + 4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 56 4.2.3. Address Resolution . . . . . . . . . . . . . . . . . . 57 4.2.4. Dropping packets . . . . . . . . . . . . . . . . . . . 58 4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 58 4.3.1. Unreachable addresses . . . . . . . . . . . . . . . . 58 - 4.3.2. Private address space . . . . . . . . . . . . . . . . 59 + 4.3.2. Private address space . . . . . . . . . . . . . . . . 58 4.3.3. Class D addresses (224/4 address block) . . . . . . . 59 4.3.4. Class E addresses (240/4 address block) . . . . . . . 59 4.3.5. Broadcast and multicast addresses, and - connection-oriented protocols . . . . . . . . . . . . 60 + connection-oriented protocols . . . . . . . . . . . . 59 4.3.6. Broadcast and network addresses . . . . . . . . . . . 60 4.3.7. Special Internet addresses . . . . . . . . . . . . . . 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 64 Appendix A. Advice and guidance to vendors . . . . . . . . . . . 72 Appendix B. Changes from previous versions of the draft (to be removed by the RFC Editor before publishing this document as an RFC) . . . . . . . . . . . . . . 73 - B.1. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 73 - B.2. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 73 - B.3. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 73 + B.1. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 73 + B.2. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 73 + B.3. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 73 + B.4. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 73 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 @@ -382,97 +404,140 @@ IHL * 4 <= Total Length 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). The above check allows for Internet datagrams with no data bytes in the payload that, while nonsensical for virtually every protocol that runs over IP, it is still legal. -3.3. TOS +3.3. Differentiated Services field - Figure 2 shows the syntax of the Type of Service field, defined by - RFC 791 [RFC0791], and updated by RFC 1349 [RFC1349]. + The Differentiated Services Architecture is intended to enable + scalable service discrimination in the Internet without the need for + per-flow state and signaling at every hop [RFC2475]. RFC 2474 + [RFC2474] defines a Differentiated Services Field (DS Field), which + is intended to supersede the original Type of Service field. Figure + 5 shows the format of the field. + + 0 1 2 3 4 5 6 7 + +---+---+---+---+---+---+---+---+ + | DSCP | CU | + +---+---+---+---+---+---+---+---+ + + Figure 2: Structure of the DS Field + + 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, 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 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 + pockets could perform 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.4. Explicit Congestion Notification (ECN) + + RFC 3168 [RFC3168] specifies a mechanism for routers to signal + congestion to hosts sending IP packets, by marking the offending + packets, rather than discarding them. RFC 3168 defines the ECN + field, which utilizes the CU unused field of the DSCP field described + in Section 3.14 of this document. Figure 6 shows the syntax of the + ECN field, together with the DSCP field used for Differentiated + Services. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ - | PRECEDENCE | D | T | R | C | 0 | + | DS FIELD, DSCP | ECN FIELD | +-----+-----+-----+-----+-----+-----+-----+-----+ - Figure 2: Type of Service field + Figure 3: The Differentiated Services and ECN fields in IP - +----------+----------------------------------------------+ - | Bits 0-2 | Precedence | - +----------+----------------------------------------------+ - | Bit 3 | 0 = Normal Delay, 1 = Low Delay | - +----------+----------------------------------------------+ - | Bit 4 | 0 = Normal Throughput, 1 = High Throughput | - +----------+----------------------------------------------+ - | Bit 5 | 0 = Normal Reliability, 1 = High Reliability | - +----------+----------------------------------------------+ - | Bit 6 | 0 = Normal Cost, 1 = Minimize Monetary Cost | - +----------+----------------------------------------------+ - | Bits 7 | Reserved for Future Use (must be zero) | - +----------+----------------------------------------------+ + As such, the ECN field defines four codepoints: - Table 1: TOS bits + +-----------+-----------+ + | ECN field | Codepoint | + +-----------+-----------+ + | 00 | Not-ECT | + +-----------+-----------+ + | 01 | ECT(1) | + +-----------+-----------+ + | 10 | ECT(0) | + +-----------+-----------+ + | 11 | CE | + +-----------+-----------+ - +-----+-----------------+ - | 111 | Network Control | - +-----+-----------------+ - | 110 | Internetwork | - +-----+-----------------+ - | 101 | CRITIC/ECP | - +-----+-----------------+ - | 100 | Flash Override | - +-----+-----------------+ - | 011 | Flash | - +-----+-----------------+ - | 010 | Immediate | - +-----+-----------------+ - | 001 | Priority | - +-----+-----------------+ - | 000 | Routine | - +-----+-----------------+ + Table 1: ECN codepoints - Table 2: Precedence field + The security implications of ECN are discussed in detail in a number + of Sections of RFC 3168. Of the possible threats discussed in the + ECN specification, we believe that one that can be easily exploited + is that of host falsely indicating ECN-Capability. - 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. + An attacker could set the ECT codepoint in the packets it sends, to + signal the network that the endpoints of the transport protocol are + ECN-capable. Consequently, when experiencing moderate congestion, + routers using active queue management based on RED would mark the + packets (with the CE codepoint) rather than discard them. In the + same scenario, packets of competing flows that do not have the ECT + codepoint set would be dropped. Therefore, an attacker would get + better network service than the competing flows. -3.4. Total Length + However, if this moderate congestion turned into heavy congestion, + routers should switch to drop packets, regardless of whether the + packets have the ECT codepoint set or not. + + A number of other threats could arise if an attacker was a man in the + middle (i.e., was in the middle of the path the packets travel to get + to the destination host). For a detailed discussion of those cases, + we urge the reader to consult Section 16 of RFC 3168. + +3.5. Total Length The Total Length field is the length of the datagram, measured in bytes, including both the IP header and the IP payload. Being a 16- bit field, it allows for datagrams of up to 65535 bytes. RFC 791 [RFC0791] states that all hosts should be prepared to receive datagrams of up to 576 bytes (whether they arrive as a whole, or in fragments). However, most modern implementations can reassemble datagrams of at least 9 Kbytes. Usually, a host will not send to a remote peer an IP datagram larger than 576 bytes, unless it is explicitly signaled that the remote peer is able to receive such "large" datagrams (for example, by means of TCP's MSS option). However, systems should assume that they may be sent datagrams larger than 576 bytes, regardless of whether they signal their remote peers to do so or not. In fact, it is common for NFS [RFC3530]implementations to send datagrams larger than 576 bytes, even without explicit signaling that the destination system can receive such "large" datagram. - Additionally, see the discussion in Section 4.1 "Fragment reassembly" - regarding the possible packet sizes resulting from fragment - reassembly. + o Additionally, see the discussion in Section 4.1 "Fragment + reassembly" regarding the possible packet sizes resulting from + fragment reassembly. Implementations should be aware that the IP module could be handed a packet larger than the value actually contained in the Total Length field. Such a difference usually has to do with legitimate padding bytes at the link-layer protocol, but it could also be the result of malicious activity by an attacker. Furthermore, even when the maximum length of an IP datagram is 65535 bytes, if the link-layer technology in use allows for payloads larger than 65535 bytes, an attacker could forge such a large link-layer packet, meaning it for the IP module. If the IP module of the receiving system were not @@ -489,24 +554,24 @@ LinkLayer.PayloadSize >= Total Length If this check fails, the IP packet should be dropped, and this event should be logged (e.g., a counter could be incremented reflecting the packet drop). As the previous expression implies, the number of bytes passed by the link-layer to the IP module should contain at least as many bytes as claimed by the Total Length field of the IP header. - [US-CERT2002] is an example of the exploitation of a forged IP Total - Length field to produce an information leakage attack. + o [US-CERT2002] is an example of the exploitation of a forged IP + Total Length field to produce an information leakage attack. -3.5. Identification (ID) +3.6. Identification (ID) The Identification field is set by the sending host to aid in the reassembly of fragmented datagrams. At any time, it needs to be unique for each set of {Source Address, Destination Address, Protocol}. In many systems, the value used for this field is determined at the IP layer, on a protocol-independent basis. Many of those systems also simply increment the IP Identification field for each packet they send. @@ -524,62 +589,63 @@ transmitting information. Later, [Sanfilippo1998b] described how a system with such an implementation can be used to perform a stealth port scan to a third (victim) host. [Sanfilippo1999] explained how to exploit this implementation strategy to uncover the rules of a number of firewalls. [Bellovin2002] explains how the IP Identification field can be exploited to count the number of systems behind a NAT. [Fyodor2004] is an entire paper on most (if not all) the ways to exploit the information provided by the Identification field of the IP header. -3.5.1. Some workarounds implemented by the industry +3.6.1. Some workarounds implemented by the industry As the IP Identification field is only used for the reassembly of datagrams, some operating systems (such as Linux) decided to set this field to 0 in all packets that have the DF bit set. This would, in principle, avoid any type of information leakage. However, it was detected that some non-RFC-compliant middle-boxes fragmented packets even if they had the DF bit set. In such a scenario, all datagrams originally sent with the DF bit set would all result in fragments that would have an Identification field of 0, which would lead to problems ("collision" of the Identification number) in the reassembly process. Linux (and Solaris) later set the IP Identification field on a per- IP-address basis. This avoids some of the security implications of the IP Identification field, but not all. For example, systems behind a load balancer can still be counted. -3.5.2. Possible security improvements +3.6.2. Possible security improvements Contrary to common wisdom, the IP Identification field does not need to be system-wide unique for each packet, but has to be unique for each {Source Address, Destination Address, Protocol} tuple. - For instance, the TCP specification defines a generic send() function - which takes the IP ID as one of its arguments. + o For instance, the TCP specification defines a generic send() + function which takes the IP ID as one of its arguments. We provide an analysis of the possible security improvements that could be implemented, based on whether the protocol using the services of IP is connection-oriented or connection-less. Connection-oriented protocols To avoid the security implications of the information leakage described above, a pseudo-random number generator (PRNG) could be used to set the IP Identification field on a {Source Address, Destination Address} basis (for each connection-oriented transport protocol). - [Klein2007] is a security advisory that describes a weakness in the - pseudo random number generator (PRNG) in use for the generation of - the IP Identification by a number of operating systems. + o [Klein2007] is a security advisory that describes a weakness in + the pseudo random number generator (PRNG) in use for the + generation of the IP Identification by a number of operating + systems. 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]). @@ -628,50 +694,50 @@ In the event this was not the case, the reassembly of fragments would 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 be intended to detect single bit errors, rather than 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. + o 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. 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 +3.7. Flags The IP header contains 3 control bits, two of which are currently used for the fragmentation and reassembly function. As described by RFC 791, their meaning is: Bit 0: reserved, must be zero Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment - Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments The DF bit is usually set to implement the Path-MTU Discovery (PMTUD) mechanism described in [RFC1191]. However, it can also be exploited by an attacker to evade Network Intrusion Detection Systems. An attacker could send a packet with the DF bit set to a system monitored by a NIDS, and depending on the Path-MTU to the intended recipient, the packet might be dropped by some intervening router (because of being too big to be forwarded without fragmentation), without the NIDS being aware of it. @@ -672,60 +738,60 @@ by an attacker to evade Network Intrusion Detection Systems. An attacker could send a packet with the DF bit set to a system monitored by a NIDS, and depending on the Path-MTU to the intended recipient, the packet might be dropped by some intervening router (because of being too big to be forwarded without fragmentation), without the NIDS being aware of it. (still to be added) (See Figure 3 in Page 13 of the CPNI document) - Figure 3: NIDS evasion by means of the Internet Protocol DF bit + Figure 4: NIDS evasion by means of the Internet Protocol DF bit In Figure 3, an attacker sends a 17914-byte datagram meant to the victim host in the same figure. The attacker's packet probably contains an overlapping IP fragment or an overlapping TCP segment, aiming at "confusing" the NIDS, as described in [Ptacek1998]. The packet is screened by the NIDS sensor at the network perimeter, which probably reassembles IP fragments and TCP segments for the purpose of assessing the data transferred to and from the monitored systems. However, as the attacker's packet should transit a link with an MTU smaller than 17914 bytes (1500 bytes in this example), the router that encounters that this packet cannot be forwarded without fragmentation (Router B) discards the packet, and sends an ICMP "fragmentation needed and DF bit set" error message to the source host. In this scenario, the NIDS may remain unaware that the screened packet never reached the intended destination, and thus get an incorrect picture of the data being transferred to the monitored systems. - [Shankar2003] introduces a technique named "Active Mapping" that + o [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. + the network being monitored, to assess which packets will arrive + at the intended recipient, and how they will be interpreted by it. Some firewalls are known to drop packets that have both the MF (More Fragments) and the DF (Don't fragment) bits set. While in principle such a packet might seem nonsensical, there are a number of reasons for which non-malicious packets with these two bits set can be found in a network. First, they may exist as the result of some middle-box processing a packet that was too large to be forwarded without fragmentation. Instead of simply dropping the corresponding packet and sending an ICMP error message to the source host, some middle- boxes fragment the packet (copying the DF bit to each fragment), and also send an ICMP error message to the originating system. Second, some systems (notably Linux) set both the MF and the DF bits to implement Path-MTU Discovery (PMTUD) for UDP. These scenarios should be taken into account when configuring firewalls and/or tuning Network Intrusion Detection Systems (NIDS). -3.7. Fragment Offset +3.8. Fragment Offset The Fragment Offset is used for the fragmentation and reassembly of IP datagrams. It indicates where in the original datagram the fragment belongs, and is measured in units of eight bytes. As a consequence, all fragments (except the last one), have to be aligned on an 8-byte boundary. Therefore, if a packet has the MF flag set, the following check should be enforced: (Total Length - IHL * 4) % 8 == 0 @@ -746,36 +812,36 @@ dropped, and this event should be logged (e.g., a counter could be incremented reflecting the packet drop). To detect such a case, the following check should be enforced on all packets for which the Fragment Offset contains a non-zero value: Fragment Offset * 8 + (Total Length - IHL * 4) <= 65535 In the worst-case scenario, the reassembled datagram could have a size of up to 131043 bytes. - Such a datagram would result when the first fragment has a Fragment - Offset of 0 and a Total Length of 65532, and the second (and last) - fragment has a Fragment Offset of 8189 (65512 bytes), and a Total - Length of 65535. Assuming an IHL of 5 (i.e., a header length of 20 - bytes), the reassembled datagram would be 65532 + (65535 - 20) = - 131047 bytes. + o Such a datagram would result when the first fragment has a + Fragment Offset of 0 and a Total Length of 65532, and the second + (and last) fragment has a Fragment Offset of 8189 (65512 bytes), + and a Total Length of 65535. Assuming an IHL of 5 (i.e., a header + length of 20 bytes), the reassembled datagram would be 65532 + + (65535 - 20) = 131047 bytes. Additionally, the IP module should implement all the necessary measures to be able to handle such illegitimate reassembled datagrams, so as to avoid them from overflowing the buffer(s) used for the reassembly function. - [CERT1996c] and [Kenney1996] describe the exploitation of this issue - to perform a Denial of Service (DoS) attack. + o [CERT1996c] and [Kenney1996] describe the exploitation of this + issue to perform a Denial of Service (DoS) attack. -3.8. Time to Live (TTL) +3.9. Time to Live (TTL) The Time to Live (TTL) field has two functions: to bind the lifetime of the upper-layer packets (e.g., TCP segments) and to prevent packets from looping indefinitely in the network. Originally, this field was meant to indicate maximum time a datagram was allowed to remain in the internet system, in units of seconds. As every internet module that processes a datagram must decrement the TTL by at least one, the original definition of the TTL field became obsolete, and it must now be interpreted as a hop count. @@ -788,71 +854,73 @@ 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 eight, 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. + o 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 source system can help to obtain valuable information. Among other things, it may help in: o Fingerprinting the operating system being used by the source host. o Fingerprinting the physical device from which the packets originate. o Locating the source host in the network topology. Additionally, it can be used to perform functions such as: o Evading Network Intrusion Detection Systems. o Improving the security of applications that make use of the Internet Protocol (IP). - Fingerprinting the operating system in use by the source host +3.9.1. Fingerprinting the operating system in use by the source host Different operating systems use a different default TTL for the packets they send. Thus, asserting the TTL with which a packet was originally sent will help to reduce the number of possible operating systems in use by the source host. - Fingerprinting the physical device from which the packets originate +3.9.2. Fingerprinting the physical device from which the packets + originate When several systems are behind a middle-box such as a NAT or a load balancer, the TTL may help to count the number of systems behind the middle-box. If each of the systems behind the middle-box use a different default TTL for the packets they send, or they are located in a different place of the network topology, an attacker could stimulate responses from the devices being fingerprinted, and each response that arrives with a different TTL could be assumed to come from a different device. - Of course, there are many other and much more precise techniques to - fingerprint physical devices. Among drawbacks of this method, while - many systems differ in the default TTL they use for the packets they - send, there are also many implementations which use the same default - TTL. Additionally, packets sent by a given device may take different - routes (e.g., due to load sharing or route changes), and thus a given - packet may incorrectly be presumed to come from a different device, - when in fact it just traveled a different route. + o Of course, there are many other and much more precise techniques + to fingerprint physical devices. Among drawbacks of this method, + while many systems differ in the default TTL they use for the + packets they send, there are also many implementations which use + the same default TTL. Additionally, packets sent by a given + device may take different routes (e.g., due to load sharing or + route changes), and thus a given packet may incorrectly be + presumed to come from a different device, when in fact it just + traveled a different route. - Locating the source host in the network topology +3.9.3. Locating the source host in the network topology The TTL field may also be used to locate the source system in the network topology [Northcutt2000]. +---+ +---+ +---+ +---+ +---+ | A |-----| R |------| R |----| R |-----| R | +---+ +---+ +---+ +---+ +---+ / | / \ / | / \ / | / +---+ @@ -865,23 +933,23 @@ +---+ +---+ +---+ \ +---| | R |----------| R |-- \ +---+ +---+ \ \ | \ / \ +---+| +---+ | \ / ----| R |------| R | | \ / +---+ +---+ +---+ \ +---+ +---+ | B | \| R |----| C | +---+ +---+ +---+ - Figure 4: Tracking a host by means of the TTL field + Figure 5: Tracking a host by means of the TTL field - Consider network topology of Figure 4. Assuming that an attacker + Consider network topology of Figure 5. Assuming that an attacker ("F" in the figure) is performing some type of attack that requires forging the Source Address (such as a TCP-based DoS reflection attack), and some of the involved hosts are willing to cooperate to locate the attacking system. Assuming that: o All the packets A gets have a TTL of 61. o All the packets B gets have a TTL of 61. @@ -919,57 +987,56 @@ large for the information to be useful. o The attacker may be using a non-default TTL value, or, what is worse, using a pseudo-random value for the TTL of the packets it sends. o The packets sent by the attacker may take different routes, as a result of a change in network topology, load sharing, etc., and thus may lead to an incorrect analysis. - Evading Network Intrusion Detection Systems +3.9.4. Evading Network Intrusion Detection Systems The TTL field can be used to evade Network Intrusion Detection Systems. Depending on the position of a sensor relative to the destination host of the examined packet, the NIDS may get a different - picture from that got by the intended destination system. As an - example, a sensor may process a packet that will expire before - getting to the destination host. A general counter-measure for this - type of attack is to normalize the traffic that gets to an - organizational network. Examples of such traffic normalization can - be found in [Paxson2001]. + picture from that of the intended destination system. As an example, + a sensor may process a packet that will expire before getting to the + destination host. A general counter-measure for this type of attack + is to normalize the traffic that gets to an organizational network. + Examples of such traffic normalization can be found in [Paxson2001]. - Improving the security of applications that make use of the Internet - Protocol (IP) +3.9.5. Improving the security of applications that make use of the + Internet Protocol (IP) In some scenarios, the TTL field can be also used to improve the security of an application, by restricting the hosts that can communicate with the given application. For example, there are applications for which the communicating systems are typically in the same network segment (i.e., there are no intervening routers). Such an application is the BGP (Border Gateway Protocol) between utilized by two peer routers. If both systems use a TTL of 255 for all the packets they send to each other, then a check could be enforced to require all packets meant for the application in question to have a TTL of 255. As all packets sent by systems that are not in the same network segment will have a TTL smaller than 255, those packets will not pass the check enforced by these two cooperating peers. This check reduces the set of systems that may perform attacks against the protected application (BGP in this case), thus mitigating the attack vectors described in [NISCC2004] and [Watson2004]. - This same check is enforced for related ICMP error messages, with the - intent of mitigating the attack vectors described in [NISCC2005] and - [I-D.ietf-tcpm-icmp-attacks]. + o This same check is enforced for related ICMP error messages, with + the intent of mitigating the attack vectors described in + [NISCC2005] and [I-D.ietf-tcpm-icmp-attacks]. The TTL field can be used in a similar way in scenarios in which the cooperating systems either do not use a default TTL of 255, or are not in the same network segment (i.e., multi-hop peering). In that case, the following check could be enforced: TTL >= 255 - DeltaHops This means that the set of hosts from which packets will be accepted for the protected application will be reduced to those that are no @@ -982,106 +1049,107 @@ This use of the TTL field has been officially documented by the IETF under the name "Generalized TTL Security Mechanism" (GTSM) in [RFC5082]. Some protocol scrubbers enforce a minimum value for the TTL field of the packets they forward. It must be understood that depending on the minimum TTL being enforced, and depending on the particular network setup, the protocol scrubber may actually help attackers to fool the GTSM, by "raising" the TTL of the attacking packets. -3.9. Protocol +3.10. Protocol The Protocol field indicates the protocol encapsulated in the internet datagram. The Protocol field may not only contain a value corresponding to an implemented protocol within the system, 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]. -3.10. Header Checksum +3.11. 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 performing such actions. As there are internet routers known to not check the IP Header Checksum, and there might also be middle-boxes (NATs, firewalls, etc.) not checking the IP checksum allegedly due to performance reasons, similar malicious activity to the one described in [Ed3f2002] might be performed with the IP checksum. -3.11. Source Address +3.12. Source Address The Source Address of an IP datagram identifies the node from which the packet originated. - Strictly speaking, the Source Address of an IP datagram identifies - the interface of the sending system from which the packet was sent, - (rather than the originating "system"), as in the Internet + o Strictly speaking, the Source Address of an IP datagram identifies + the interface of the sending system from which the packet was + sent, (rather than the originating "system"), as in the Internet Architecture there's no concept of "node". Unfortunately, it is trivial to forge the Source Address of an Internet datagram. This has been exploited in the past for performing a variety of DoS (Denial of Service) attacks [NISCC2004] [RFC4987] [CERT1996a] [CERT1996b] [CERT1998a], and to impersonate as other systems in scenarios in which authentication was based on the Source Address of the sending system [daemon91996]. The extent to which these attacks can be successfully performed in the Internet can be reduced through deployment of ingress/egress filtering in the internet routers. [NISCC2006] is a detailed guide on ingress and egress filtering. [RFC3704] and [RFC2827] discuss ingress filtering. [GIAC2000] discusses egress filtering. - Even when the obvious field on which to perform checks for ingress/ - egress filtering is the Source Address and Destination Address fields - of the IP header, there are other occurrences of IP addresses on - which the same type of checks should be performed. One example is - the IP addresses contained in the payload of ICMP error messages, as - discussed in [I-D.ietf-tcpm-icmp-attacks] and [Gont2006]. + o Even when the obvious field on which to perform checks for + ingress/egress filtering is the Source Address and Destination + Address fields of the IP header, there are other occurrences of IP + addresses on which the same type of checks should be performed. + One example is the IP addresses contained in the payload of ICMP + error messages, as discussed in [I-D.ietf-tcpm-icmp-attacks] and + [Gont2006]. There are a number of sanity checks that should be performed on the Source Address of an IP datagram. Details can be found in Section 4.2 ("Addressing"). Additionally, there exist freely available tools that allow administrators to monitor which IP addresses are used with which MAC addresses [LBNL2006]. This functionality is also included in many Network Intrusion Detection Systems (NIDS). It is also very important to understand that authentication should never rely on the Source Address of the communicating systems. -3.12. Destination Address +3.13. Destination Address The Destination Address of an IP datagram identifies the destination host to which the packet is meant to be delivered. - Strictly speaking, the Destination Address of an IP datagram - identifies the interface of the destination network interface, rather - than the destination "system", as in the Internet Architecture - there's no concept of "node". + o Strictly speaking, the Destination Address of an IP datagram + identifies the interface of the destination network interface, + rather than the destination "system", as in the Internet + Architecture there's no concept of "node". There are a number of sanity checks that should be performed on the Destination Address of an IP datagram. Details can be found in Section 4.2 ("Addressing"). -3.13. Options +3.14. Options According to RFC 791, IP options must be implemented by all IP modules, both in hosts and gateways (i.e., end-systems and intermediate-systems). There are two cases for the format of an option: o Case 1: A single byte of option-type. o Case 2: An option-type byte, an option-length byte, and the actual @@ -1117,56 +1185,56 @@ o 2 = debugging and measurement. o 3 = reserved for future use. This format allows for the creation of new options for the extension of the Internet Protocol (IP). Finally, the option number identifies the syntax of the rest of the option. -3.13.1. General issues with IP options +3.14.1. General issues with IP options The following subsections discuss security issues that apply to all IP options. The proposed checks should be performed in addition to any option-specific checks proposed in the next sections. -3.13.1.1. Processing requirements +3.14.1.1. Processing requirements Router manufacturers tend to do IP option processing on the main processor, rather than on line cards. Unless special care is taken, - this may be a security risk, as there is potential for overwhelming - the router with option processing. + this represents Denial of Service (DoS) risk, as there is potential + for overwhelming the router with option processing. To reduce the impact of these packets on the system performance, a few counter-measures could be implemented: o Rate-limit the number of packets with IP options that are processed by the system. o Enforce a limit on the maximum number of options to be accepted on a given internet datagram. The first check avoids a flow of packets with IP options to overwhelm the system in question. The second check avoids packets with multiple IP options to affect the performance of the system. -3.13.1.2. Processing of the options by the upper layer protocol +3.14.1.2. Processing of the options by the upper layer protocol Section 3.2.1.8 of RFC 1122 [RFC1122] states that all the IP options received in IP datagrams must be passed to the transport layer (or to ICMP processing when the datagram is an ICMP message). Therefore, care in option processing must be taken not only at the internet layer, but also in every protocol module that may end up processing the options included in an IP datagram. -3.13.1.3. General sanity checks on IP options +3.14.1.3. General sanity checks on IP options There are a number of sanity checks that should be performed on IP options before further option processing is done. They help prevent a number of potential security problems, including buffer overflows. When these checks fail, the packet carrying the option should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). RFC 1122 [RFC1122] recommends to send an ICMP "Parameter Problem" message to the originating system when a packet is dropped because of @@ -1188,21 +1256,21 @@ Section 3.2.1.8 of RFC 1122 explicitly states that the IP layer must not crash as the result of an option length that is outside the possible range, and mentions that erroneous option lengths have been observed to put some IP implementations into infinite loops. For options that belong to the "Case 2" described in the previous section, the following check should be performed: option-length >= 2 - The value "2" accounts for the option-type byte, and the option- + o The value "2" accounts for the option-type byte, and the option- length byte. This check prevents, among other things, loops in option processing that may arise from incorrect option lengths. Additionally, while the option-length byte of IP options of "Case 2" allows for an option length of up to 255 bytes, there is a limit on legitimate option length imposed by the syntax of the IP header. For all options of "Case 2", the following check should be enforced: @@ -1226,42 +1294,42 @@ Data types Many IP options use pointer and length fields. Care must be taken as to the data type used for these fields in the implementation. For example, if an 8-bit signed data type were used to hold an 8-bit pointer, then, pointer values larger than 128 might mistakenly be interpreted as negative numbers, and thus might lead to unpredictable results. -3.13.2. Issues with specific options +3.14.2. Issues with specific options -3.13.2.1. End of Option List (Type = 0) +3.14.2.1. End of Option List (Type = 0) This option is used to indicate the "end of options" in those cases in which the end of options would not coincide with the end of the Internet Protocol Header. IP systems are required to ignore those options they do not implement. Therefore, even in those cases in which this option is required, but is missing, IP systems should be able to process the remaining bytes of the IP header without any problems. -3.13.2.2. No Operation (Type = 1) +3.14.2.2. No Operation (Type = 1) The no-operation option is basically meant to allow the sending system to align subsequent options in, for example, 32-bit boundaries. This option does not have security implications. -3.13.2.3. Loose Source Record Route (LSRR) (Type = 131) +3.14.2.3. Loose Source Record Route (LSRR) (Type = 131) This option lets the originating system specify a number of intermediate systems a packet must pass through to get to the destination host. Additionally, the route followed by the packet is recorded in the option. The receiving host (end-system) must use the reverse of the path contained in the received LSRR option. The LSSR option can be of help in debugging some network problems. Some ISP (Internet Service Provider) peering agreements require support for this option in the routers within the peer of the ISP. @@ -1271,46 +1339,45 @@ o Bypass firewall rules o Reach otherwise unreachable internet systems o Establish TCP connections in a stealthy way o Learn about the topology of a network o Perform bandwidth-exhaustion attacks - Of these attack vectors, the one that has probably received least attention is the use of the LSRR option to perform bandwidth exhaustion attacks. The LSRR option can be used as an amplification method for performing bandwidth-exhaustion attacks, as an attacker could make a packet bounce multiple times between a number of systems by carefully crafting an LSRR option. - This is the IPv4-version of the IPv6 amplification attack that was - widely publicized in 2007 [Biondi2007]. The only difference is that - the maximum length of the IPv4 header (and hence the LSRR option) - limits the amplification factor when compared to the IPv6 counter- - part. + o This is the IPv4-version of the IPv6 amplification attack that was + widely publicized in 2007 [Biondi2007]. The only difference is + that the maximum length of the IPv4 header (and hence the LSRR + option) limits the amplification factor when compared to the IPv6 + counter-part. While the LSSR option may be of help in debugging some network problems, its security implications outweigh any legitimate use. All systems should, by default, drop IP packets that contain an LSRR option, and should log this event (e.g., a counter could be incremented to reflect the packet drop). However, they should provide a system-wide toggle to enable support for this option for those scenarios in which this option is required. Such system-wide toggle should default to "off" (or "disable"). - [OpenBSD1998] is a security advisory about an improper implementation - of such a system-wide in 4.4BSD kernels. + [OpenBSD1998] is a security advisory about an improper + implementation of such a system-wide toggle in 4.4BSD kernels. Section 3.3.5 of RFC 1122 [RFC1122] states that a host may be able to act as an intermediate hop in a source route, forwarding a source- routed datagram to the next specified hop. We strongly discourage host software from forwarding source-routed datagrams. If processing of source-routed datagrams is explicitly enabled in a system, the following sanity checks should be performed. RFC 791 states that this option should appear, at most, once in a @@ -1362,188 +1430,117 @@ When a system receives an IP packet with the LSRR route option, it should check whether the source route is empty or not. The option is empty if: LSRR.Pointer > LSRR.Length In that case, routing should be based on the Destination Address field, and no further processing should be done on the LSRR option. - [Microsoft1999] is a security advisory about a vulnerability arising - from improper validation of the LSRR.Pointer field. + o [Microsoft1999] is a security advisory about a vulnerability + arising from improper validation of the LSRR.Pointer field. If the address in the Destination Address field has been reached, and the option is not empty, the next address in the source route replaces the address in the Destination Address field. The IP address of the interface that will be used to forward this datagram should be recorded into the LSRR. However, before writing in the route data area, the following check should be performed: LSRR.Length - LSRR.Pointer >= 3 This assures that there will be at least 4 bytes of space in which to record the IP address. 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 to reflect the packet drop). - An offset of "1" corresponds to the option type, that's why the + o An offset of "1" corresponds to the option type, that's why the performed check is LSRR.Length - LSRR.Pointer >=3, and not LSRR.Length - LSRR.Pointer >=4. The LSRR must be copied on fragmentation. This means that if a packet that carries the LSRR is fragmented, each of the fragments will have to go through the list of systems specified in the LSRR option. -3.13.2.4. Strict Source and Record Route (SSRR) (Type = 137) +3.14.2.4. Strict Source and Record Route (SSRR) (Type = 137) This option allows the originating system to specify a number of intermediate systems a packet must pass through to get to the destination host. Additionally, the route followed by the packet is recorded in the option, and the destination host (end-system) must use the reverse of the path contained in the received SSRR option. This option is similar to the Loose Source and Record Route (LSRR) option, with the only difference that in the case of SSRR, the route specified in the option is the exact route the packet must take (i.e., no other intervening routers are allowed to be in the route). The SSSR option can be of help in debugging some network problems. Some ISP (Internet Service Provider) peering agreements require support for this option in the routers within the peer of the ISP. - The SSRR option has well-known security implications. Among other - things, the option can be used to: - - o Bypass firewall rules - - o Reach otherwise unreachable internet systems - - o Establish TCP connections in a stealthy way - - o Learn about the topology of a network - o Perform bandwidth-exhaustion attacks - - Of these attack vectors, the one that has probably received least - attention is the use of the SSRR option to perform bandwidth - exhaustion attacks. The SSRR option can be used as an amplification - method for performing bandwidth-exhaustion attacks, as an attacker - could make a packet bounce multiple times between a number of systems - by carefully crafting an LSRR option. - - This is the IPv4-version of the IPv6 amplification attack that was - widely publicized in 2007 [Biondi2007]. The only difference is that - the maximum length for the IPv4 header (and hence the SSRR option) - limits the amplification factor when compared to the IPv6 counter- - part. + The SSRR option has the same security implications as the LSRR + option. Please refer to Section Section 3.14.2.3 for a discussion of + such security implications. - While the SSSR option may be of help in debugging some network - problems, its security implications outweigh any legitimate use of - it. + As with the LSRR, while the SSSR option may be of help in debugging + some network problems, its security implications outweigh any + legitimate use of it. All systems should, by default, drop IP packets that contain an LSRR option, and should log this event (e.g., a counter could be incremented to reflect the packet drop). However, they should provide a system-wide toggle to enable support for this option for those scenarios in which this option is required. Such system-wide toggle should default to "off" (or "disable"). - [OpenBSD1998] is a security advisory about an improper implementation - of such a system-wide in 4.4BSD kernels. + [OpenBSD1998] is a security advisory about an improper + implementation of such a system-wide toggle in 4.4BSD kernels. In the event processing of the SSRR option were explicitly enabled, - there are some sanity checks that should be performed. + the same sanity checks described for the LSRR option in + Section 3.14.2.3 should be performed on the SSRR option. Namely, + sanity checks shoudl be performed on the option length (SSRR.Length) + and the Pointer field (SSRR.Pointer). - RFC 791 states that this option should appear, at most, once in a - given packet. Thus, if a packet is found to have more than one SSRR - option, it should be dropped, and this event should be logged (e.g., - a counter could be incremented to reflect the packet drop). Also, if - a packet contains a combination of SSRR and LSRR options, it should - be dropped, and this event should be logged (e.g., a counter could be + If the packet passes the aforementioned sanity checks, the receiving + system should determine whether the Destination Address of the packet + corresponds to one of its IP addresses. If does not, it should be + dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). - As the SSRR option is meant to specify the route a packet should - follow from source to destination, use of more than one SSRR option - in a single packet would be nonsensical. Therefore, hosts and - routers should check the IP header and discard the packet if it - contains more than one SSRR option, or a combination of LSRR and SSRR - options. - - As with many other IP options, the SSRR option contains a Length - field that indicates the length of the option. Given the format of - the option, the length field should be checked to be at least 3: - - SSRR.Length >= 3 - - 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 to - reflect the packet drop). - - Additionally, the following check should be performed on the length - field: - - SSRR.Offset + SSRR.Length < IHL *4 - - This check assures that the option does not overlap with the IP - payload (i.e., it does not go past the IP header). 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 to reflect the packet - drop). - - The Pointer field is relative to this option, with the minimum legal - value being 4. Therefore, the following check should be performed: - - SSRR.Pointer >= 4 - - 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 to - reflect the packet drop). - - Additionally, the Pointer field should be a multiple of 4. - Consequently, the following check should be performed: - - SSRR.Pointer % 4 == 0 - - If a packet does not pass this check, it should be dropped, and this - event should be logged (e.g., a counter could be incremented to - reflect the packet drop). - - If the packet passes the above checks, the receiving system should - determine whether the Destination Address of the packet corresponds - to one of its IP addresses. If does not, it should be dropped, and - this event should be logged (e.g., a counter could be incremented to - reflect the packet drop). - - Contrary to the IP Loose Source and Record Route (LSRR) option, the - SSRR option does not allow in the route other routers than those - contained in the option. If the system implements the weak end- - system model, it is allowed for the system to receive a packet + Contrary to the IP Loose Source and Record Route (LSRR) option, + the SSRR option does not allow in the route other routers than + those contained in the option. If the system implements the weak + end-system model, it is allowed for the system to receive a packet destined to any of its IP addresses, on any of its interfaces. If - the system implements the strong end-system model, a packet destined - to it can be received only on the interface that corresponds to the - IP address contained in the Destination Address field [RFC1122]. + the system implements the strong end-system model, a packet + destined to it can be received only on the interface that + corresponds to the IP address contained in the Destination Address + field [RFC1122]. If the packet passes this check, the receiving system should determine whether the source route is empty or not. The option is empty if: SSRR.Pointer > SSRR.Length In that case, if the address in the destination field has not been reached, the packet should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). - [Microsoft1999] is a security advisory about a vulnerability arising - from improper validation of the SSRR.Pointer field. + [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. This IP address must be reachable without the use of any intervening router (i.e., the address must belong to any of the networks to which the system is directly attached). If that is not the case, the packet should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). @@ -1560,127 +1557,101 @@ This assures that there will be at least 4 bytes of space on which to record the IP address. 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 to reflect the packet drop). The SSRR option must be copied on fragmentation. This means that if a packet that carries the SSRR is fragmented, each of the fragments will have to go through the list of systems specified in the SSRR option. -3.13.2.5. Record Route (Type = 7) +3.14.2.5. Record Route (Type = 7) This option provides a means to record the route that a given packet follows. The option begins with an 8-bit option code, which must be equal to 7. The second byte is the option length, which includes the option- type byte, the option-length byte, the pointer byte, and the actual option-data. The third byte is a pointer into the route data, indicating the first byte of the area in which to store the next route data. The pointer is relative to the option start. RFC 791 states that this option should appear, at most, once in a given packet. Therefore, if a packet has more than one instance of this option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). - Given the format of the option, the Length field should be checked to - be at least 3: - - RR.Length >= 3 - - 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 to - reflect the packet drop). - - Additionally, the following check should be performed on the Length - field: - - RR.Offset + RR_Length < IHL *4 - - This check assures that the option does not overlap with the IP - payload (i.e., it does not go past the IP header). 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 to reflect the packet + The same sanity checks performed for the Length field and the Pointer + field of the LSRR and the SSRR options should be performed on the + Length field (RR.Length) and the Pointer field (RR.Pointer) of the RR + option. And, as with the LSRR and SSRR options, if the packet does + not pass these checks it should be dropped, and this event should be + logged (e.g., a counter could be incremented to reflect the packet drop). - The pointer field is relative to this option, with the minimum legal - value being 4. Therefore, the following check should be performed: - - RR.Pointer >= 3 - - If the packet does not pass this check, it should be silently - dropped, and this event should be logged (e.g., a counter could be - incremented to reflect the packet drop). - - Additionally, the Pointer field should be a multiple of 4. - Consequently, the following check should be performed: - - RR.Pointer % 4 == 0 - When a system receives an IP packet with the Record Route option, it should check whether there is space in the option to store route information. The option is full if: RR.Pointer > RR.Length If the option is full, the datagram should be forwarded without further processing of this option. If not, the following check should be performed before writing any route data into the option: RR.Pointer - RR.Length >= 3 If the packet does not pass this check, the packet should be considered in error, and therefore should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). If the option is not full (i.e., RR.Pointer <= RR.Length), but - RR.Pointer - RR.Length < 4, it means that while there's space in the - option, there is not not enough space to store an IP address. It is - fair to assume that such an scenario will only occur when the packet - has been crafted. + RR.Pointer - RR.Length < 4, it means that while there's space in + the option, there is not not enough space to store an IP address. + It is fair to assume that such an scenario will only occur when + the packet has been crafted. If the packet passes this check, the IP address of the interface that will be used to forward this datagram should be recorded into the area pointed by the RR.Pointer, and RR.Pointer should then be 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). -3.13.2.6. Stream Identifier (Type = 136) +3.14.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 should be ignored by the processing systems. In the case of legacy systems still using this option, the length field of the option should be checked to be 4. If the option does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). RFC 791 states that this option appears at most once in a given datagram. Therefore, if a packet contains more than one instance of this option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). -3.13.2.7. Internet Timestamp (Type = 68) +3.14.2.7. Internet Timestamp (Type = 68) This option provides a means for recording the time at which each system processed this datagram. The timestamp option has a number of security implications. Among them are: o It allows an attacker to obtain the current time of the systems that process the packet, which the attacker may find useful in a number of scenarios. o It may be used to map the network topology, in a similar way to @@ -1822,21 +1793,21 @@ corresponding 32-bit timestamp. The system's timestamp should be stored at the area pointed by IT.Pointer + 4. Then, the pointer byte should be incremented by 8. [Kohno2005] describes a technique for fingerprinting devices by measuring the clock skew. It exploits, among other things, the timestamps that can be obtained by means of the ICMP timestamp request messages [RFC0791]. However, the same fingerprinting method could be implemented with the aid of the Internet Timestamp option. -3.13.2.8. Router Alert (Type = 148) +3.14.2.8. Router Alert (Type = 148) The Router Alert option is defined in RFC 2113 [RFC2113]. It has the semantic "routers should examine this packet more closely". A packet that contains a Router Alert option will not go through the router's fast-path and will be processed in the router more slowly than if the option were not set. Therefore, this option may impact the performance of the systems that handle the packet carrying it. According to the syntax of the option as defined in RFC 2113, the following check should be enforced: @@ -1849,75 +1820,75 @@ performed on the Value field: RA.Value == 0 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 to reflect the packet drop). As explained in RFC 2113, hosts should ignore this option. -3.13.2.9. Probe MTU (Type =11) +3.14.2.9. Probe MTU (Type =11) This option is defined in RFC 1063 [RFC1063], and originally provided a mechanism to discover the Path-MTU. This option is obsolete, and therefore any packet that is received containing this option should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). -3.13.2.10. Reply MTU (Type = 12) +3.14.2.10. Reply MTU (Type = 12) This option is defined in RFC 1063 [RFC1063], and originally provided a mechanism to discover the Path-MTU. This option is obsolete, and therefore any packet that is received containing this option should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). -3.13.2.11. Traceroute (Type = 82) +3.14.2.11. Traceroute (Type = 82) This option is defined in RFC 1393 [RFC1393], and originally provided a mechanism to trace the path to a host. This option is obsolete, and therefore any packet that is received containing this option should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). -3.13.2.12. DoD Basic Security Option (Type = 130) +3.14.2.12. DoD Basic Security Option (Type = 130) This option is used by end-systems and intermediate systems of an internet to [RFC1108]: o Transmit from source to destination in a network standard representation the common security labels required by computer security models, o Validate the datagram as appropriate for transmission from the source and delivery to the destination, and, o Ensure that the route taken by the datagram is protected to the level required by all protection authorities indicated on the datagram. It is specified by RFC 1108 [RFC1108] (which obsoletes RFC 1038 [RFC1038]). - RFC 791 [RFC0791] defined the "Security Option" (Type = 130), which - used the same option type as the DoD Basic Security option discussed - in this section. The "Security Option" specified in RFC 791 is - considered obsolete by Section 4.2.2.1 of RFC 1812, and therefore the - discussion in this section is focused on the DoD Basic Security - option specified by RFC 1108 [RFC1108]. + o RFC 791 [RFC0791] defined the "Security Option" (Type = 130), + which used the same option type as the DoD Basic Security option + discussed in this section. The "Security Option" specified in RFC + 791 is considered obsolete by Section 4.2.2.1 of RFC 1812, and + therefore the discussion in this section is focused on the DoD + Basic Security option specified by RFC 1108 [RFC1108]. Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement this option". The DoD Basic Security Option is currently implemented in a number of operating systems (e.g., [IRIX2008], [SELinux2008], [Solaris2008], and [Cisco2008]), and deployed in a number of high-security networks. RFC 1108 states that the option should appear at most once in a datagram. Therefore, if more than one DoD Basic Security option @@ -1932,25 +1903,25 @@ BSO.Length >= 3 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 to reflect the packet drop). Systems that belong to networks in which this option is in use should process the DoD Basic Security option contained in each packet as specified in [RFC1108]. - Current deployments of the DoD Security Options have motivated the + o Current deployments of the DoD Security Options have motivated the proposal of a "Common Architecture Label IPv6 Security Option (CALIPSO)" for the IPv6 protocol. [RFC1038]. -3.13.2.13. DoD Extended Security Option (Type = 133) +3.14.2.13. DoD Extended Security Option (Type = 133) This option permits additional security labeling information, beyond that present in the Basic Security Option (Section 3.13.2.12), to be supplied in an IP datagram to meet the needs of registered authorities. It is specified by RFC 1108 [RFC1108]. This option may be present only in conjunction with the DoD Basic Security option. Therefore, if a packet contains a DoD Extended Security option (ESO), but does not contain a DoD Basic Security option, it should be dropped, and this event should be logged (e.g., @@ -1965,185 +1936,145 @@ ESO.Length >= 3 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 to reflect the packet drop). Systems that belong to networks in which this option is in use, should process the DoD Extended Security option contained in each packet as specified in RFC 1108 [RFC1108]. -3.13.2.14. Commercial IP Security Option (CIPSO) (Type = 134) +3.14.2.14. Commercial IP Security Option (CIPSO) (Type = 134) This option was proposed by the Trusted Systems Interoperability Group (TSIG), with the intent of meeting trusted networking requirements for the commercial trusted systems market place. It is specified in [CIPSO1992] and [FIPS1994]. - The TSIG proposal was taken to the Commercial Internet Security + o The TSIG proposal was taken to the Commercial Internet Security Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an Internet-Draft was produced [CIPSO1992]. The Internet-Draft was - never published as an RFC, and the proposal was later standardized by - the U.S. National Institute of Standards and Technology (NIST) as - "Federal Information Processing Standard Publication 188" [FIPS1994]. + never published as an RFC, and the proposal was later standardized + by the U.S. National Institute of Standards and Technology (NIST) + as "Federal Information Processing Standard Publication 188" + [FIPS1994]. It is currently implemented in a number of operating systems (e.g., IRIX [IRIX2008], Security-Enhanced Linux [SELinux2008], and Solaris [Solaris2008]), and deployed in a number of high-security networks. - [Zakrzewski2002] and [Haddad2004] provide an overview of a Linux + o [Zakrzewski2002] and [Haddad2004] provide an overview of a Linux implementation. According to the option syntax specified in [CIPSO1992] the following validation check should be performed: CIPSO.Length >= 6 If a packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). Systems that belong to networks in which this option is in use should process the CIPSO option contained in each packet as specified in [CIPSO1992]. -3.13.2.15. Sender Directed Multi-Destination Delivery (Type = 149) +3.14.2.15. Sender Directed Multi-Destination Delivery (Type = 149) This option is defined in RFC 1770 [RFC1770], and originally provided unreliable UDP delivery to a set of addresses included in the option. This option is obsolete. If a received packet contains this option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). -3.14. Differentiated Services field - - The Differentiated Services Architecture is intended to enable - scalable service discrimination in the Internet without the need for - per-flow state and signaling at every hop [RFC2475]. RFC 2474 - [RFC2474] defines a Differentiated Services Field (DS Field), which - is intended to supersede the original Type of Service field. Figure - 5 shows the format of the field. - - 0 1 2 3 4 5 6 7 - +---+---+---+---+---+---+---+---+ - | DSCP | CU | - +---+---+---+---+---+---+---+---+ - - Figure 5: Structure of the DS Field - - 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, 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 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 - pockets could perform 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.15. Explicit Congestion Notification (ECN) +3.15. TOS - RFC 3168 [RFC3168] specifies a mechanism for routers to signal - congestion to hosts sending IP packets, by marking the offending - packets, rather than discarding them. RFC 3168 defines the ECN - field, which utilizes the CU unused field of the DSCP field described - in Section 3.14 of this document. Figure 6 shows the syntax of the - ECN field, together with the DSCP field used for Differentiated - Services. + Figure 2 shows the syntax of the Type of Service field, as defined by + RFC 791 [RFC0791], and updated by RFC 1349 [RFC1349]. We provide a + discussion of this obsoleted definition, legacy implementations might + still be using these semantics. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ - | DS FIELD, DSCP | ECN FIELD | + | PRECEDENCE | D | T | R | C | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ - Figure 6: The Differentiated Services and ECN fields in IP - - As such, the ECN field defines four codepoints: - - +-----------+-----------+ - | ECN field | Codepoint | - +-----------+-----------+ - | 00 | Not-ECT | - +-----------+-----------+ - | 01 | ECT(1) | - +-----------+-----------+ - | 10 | ECT(0) | - +-----------+-----------+ - | 11 | CE | - +-----------+-----------+ + Figure 6: Type of Service field - Table 3: ECN codepoints + +----------+----------------------------------------------+ + | Bits 0-2 | Precedence | + +----------+----------------------------------------------+ + | Bit 3 | 0 = Normal Delay, 1 = Low Delay | + +----------+----------------------------------------------+ + | Bit 4 | 0 = Normal Throughput, 1 = High Throughput | + +----------+----------------------------------------------+ + | Bit 5 | 0 = Normal Reliability, 1 = High Reliability | + +----------+----------------------------------------------+ + | Bit 6 | 0 = Normal Cost, 1 = Minimize Monetary Cost | + +----------+----------------------------------------------+ + | Bits 7 | Reserved for Future Use (must be zero) | + +----------+----------------------------------------------+ - The security implications of ECN are discussed in detail in a number - of Sections of RFC 3168. Of the possible threats discussed in the - ECN specification, we believe that one that can be easily exploited - is that of host falsely indicating ECN-Capability. + Table 2: TOS bits - An attacker could set the ECT codepoint in the packets it sends, to - signal the network that the endpoints of the transport protocol are - ECN-capable. Consequently, when experiencing moderate congestion, - routers using active queue management based on RED would mark the - packets (with the CE codepoint) rather than discard them. In the - same scenario, packets of competing flows that do not have the ECT - codepoint set would be dropped. Therefore, an attacker would get - better network service than the competing flows. + +-----+-----------------+ + | 111 | Network Control | + +-----+-----------------+ + | 110 | Internetwork | + +-----+-----------------+ + | 101 | CRITIC/ECP | + +-----+-----------------+ + | 100 | Flash Override | + +-----+-----------------+ + | 011 | Flash | + +-----+-----------------+ + | 010 | Immediate | + +-----+-----------------+ + | 001 | Priority | + +-----+-----------------+ + | 000 | Routine | + +-----+-----------------+ - However, if this moderate congestion turned into heavy congestion, - routers should switch to drop packets, regardless of whether the - packets have the ECT codepoint set or not. + Table 3: Precedence field - A number of other threats could arise if an attacker was a man in the - middle (i.e., was in the middle of the path the packets travel to get - to the destination host). For a detailed discussion of those cases, - we urge the reader to consult Section 16 of RFC 3168. + 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. 4. Internet Protocol Mechanisms 4.1. Fragment reassembly To accommodate networks with different Maximum Transmission Units (MTUs), the Internet Protocol provides a mechanism for the fragmentation of IP packets by end-systems (hosts) and/or intermediate systems (routers). Reassembly of fragments is performed only by the end-systems. - [Cerf1974] provides the rationale for which packet reassembly is not - performed by intermediate systems. + o [Cerf1974] provides the rationale for which packet reassembly is + not performed by intermediate systems. During the last few decades, IP fragmentation and reassembly has been exploited in a number of ways, to perform actions such as evading Network Intrusion Detection Systems (NIDS), bypassing firewall rules, and performing Denial of Service (DoS) attacks. - [Bendi1998] and [Humble1998] are examples of the exploitation of + o [Bendi1998] and [Humble1998] are examples of the exploitation of these issues for performing Denial of Service (DoS) attacks. - [CERT1997] and [CERT1998b] document these issues. [Anderson2001] is - a survey of fragmentation attacks. [US-CERT2001] is an example of - the exploitation of IP fragmentation to bypass firewall rules. - [CERT1999] describes the implementation of fragmentation attacks in - Distributed Denial of Service (DDoS) attack tools. + [CERT1997] and [CERT1998b] document these issues. [Anderson2001] + is a survey of fragmentation attacks. [US-CERT2001] is an example + of the exploitation of IP fragmentation to bypass firewall rules. + [CERT1999] describes the implementation of fragmentation attacks + in Distributed Denial of Service (DDoS) attack tools. The problem with IP fragment reassembly basically has to do with the complexity of the function, in a number of aspects: o Fragment reassembly is a stateful operation for a stateless protocol (IP). The IP module at the host performing the reassembly function must allocate memory buffers both for temporarily storing the received fragments, and to perform the reassembly function. Attackers can exploit this fact to exhaust memory buffers at the system performing the fragment reassembly. @@ -2163,21 +2094,23 @@ o The fragment reassembly algorithm, as described by the IETF specifications, is ambiguous, and allows for a number of interpretations, each of which has found place in different TCP/IP stack implementations. o The reassembly process is somewhat complex. Fragments may arrive out of order, duplicated, overlapping each other, etc. This complexity has lead to numerous bugs in different implementations of the IP protocol. -4.1.1. Problems related with memory allocation +4.1.1. Security Implications of Fragment Reassembly + +4.1.1.1. Problems related with memory allocation When an IP datagram is received by an end-system, it will be temporarily stored in system memory, until the IP module processes it and hands it to the protocol machine that corresponds to the encapsulated protocol. In the case of fragmented IP packets, while the IP module may perform preliminary processing of the IP header (such as checking the header for errors and processing IP options), fragments must be kept in system buffers until all fragments are received and are reassembled @@ -2189,28 +2122,28 @@ amount of time that should be waited for the other fragments to arrive. Therefore, the specifications recommend to wait for a period of time that will be acceptable for virtually all the possible network scenarios in which the protocols might operate. Specifically, RFC 1122 [RFC1122] states that the reassembly timeout should be a fixed value between 60 and 120 seconds. If after waiting for that period of time the remaining fragments have not yet arrived, all the received fragments for the corresponding packet are discarded. - The original IP Specification, RFC 791 [RFC0791], states that systems - should wait for at least 15 seconds for the missing fragments to - arrive. Systems that follow the "Example Reassembly Procedure" - described in Section 3.2 of RFC 791 may end up using a reassembly - timer of up to 4.25 minutes, with minimum of 15 seconds. Section - 3.3.2 ("Reassembly") of RFC 1122 corrected this advice, stating that - the reassembly timeout should be a fixed value between 60 and 120 - seconds. + o The original IP Specification, RFC 791 [RFC0791], states that + systems should wait for at least 15 seconds for the missing + fragments to arrive. Systems that follow the "Example Reassembly + Procedure" described in Section 3.2 of RFC 791 may end up using a + reassembly timer of up to 4.25 minutes, with minimum of 15 + seconds. Section 3.3.2 ("Reassembly") of RFC 1122 corrected this + advice, stating that the reassembly timeout should be a fixed + value between 60 and 120 seconds. However, the longer the system waits for the missing fragments to arrive, the longer the corresponding system resources must be tied to the corresponding packet. The amount of system memory is finite, and even with today's systems, it can still be considered a scarce resource. An attacker could take advantage of the uncomfortable situation the system performing fragment reassembly is in, by sending forged fragments that will never reassemble into a complete datagram. That @@ -2244,21 +2177,21 @@ reached, all further IP packets that arrive would be discarded, until some fragments time out and free memory is available again. o If the system enforces limits on the amount memory that can be allocated for the reassembly of fragments (in addition to enforcing a limit for the IP module as a whole), then, when this limit is reached, all further fragments that arrive would be discarded, until some fragment(s) time out and free memory is available again. -4.1.2. Problems that arise from the length of the IP Identification +4.1.1.2. Problems that arise from the length of the IP Identification field The Internet Protocols are currently being used in environments that are quite different from the ones in which they were conceived. For instance, the availability of bandwidth at the time the Internet Protocol was designed was completely different from the availability of bandwidth in today's networks. The Identification field is a 16-bit field that is used for the fragmentation and reassembly function. In the event a datagram gets @@ -2285,38 +2218,39 @@ establish a flow of fragments with different IP Identification numbers, to trash all or part of the IP Identification space. As a result, the receiving system would use the attacker's fragments for the reassembly of legitimate datagrams, leading to corrupted packets which would later (and hopefully) get dropped. In most cases, use of a long fragment timeout will benefit the attacker, as forged fragments will keep the IP Identification space trashed for a longer period of time. -4.1.3. Problems that arise from the complexity of the reassembly +4.1.1.3. Problems that arise from the complexity of the reassembly algorithm As IP packets can be duplicated by the network, and each packet may take a different path to get to the destination host, fragments may arrive not only out of order and/or duplicated, but also overlapping. This means that the reassembly process can be somewhat complex, with the corresponding implementation being not specifically trivial. [Shannon2001] analyzes the causes and attributes of fragment traffic measured in several types of WANs. During the years, a number of attacks have exploited bugs in the reassembly function of a number of operating systems, producing buffer overflows that have led, in most cases, to a crash of the attacked system. -4.1.4. Problems that arise from the ambiguity of the reassembly process +4.1.1.4. Problems that arise from the ambiguity of the reassembly + process Network Intrusion Detection Systems (NIDSs) typically monitor the traffic on a given network with the intent of identifying traffic patterns that might indicate network intrusions. In the presence of IP fragments, in order to detect illegitimate activity at the transport or application layers (i.e., any protocol layer above the network layer), a NIDS must perform IP fragment reassembly. @@ -2352,40 +2286,40 @@ As originally discussed by [Ptacek1998], these issues can be exploited by attackers to evade intrusion detection systems. There exist freely available tools to forcefully fragment IP datagrams so as to help evade Intrusion Detection Systems. Frag router [Song1999] is an example of such a tool; it allows an attacker to perform all the evasion techniques described in [Ptacek1998]. Ftester [Barisani2006] is a tool that helps to audit systems regarding fragmentation issues. -4.1.5. Problems that arise from the size of the IP fragments +4.1.1.5. Problems that arise from the size of the IP fragments One approach to fragment filtering involves keeping track of the results of applying filter rules to the first fragment (i.e., the fragment with a Fragment Offset of 0), and applying them to subsequent fragments of the same packet. The filtering module would maintain a list of packets indexed by the Source Address, Destination Address, Protocol, and Identification number. When the initial fragment is seen, if the MF bit is set, a list item would be allocated to hold the result of filter access checks. When packets with a non-zero Fragment Offset come in, look up the list element with a matching Source Address/Destination Address/Protocol/ Identification and apply the stored result (pass or block). When a fragment with a zero MF bit is seen, free the list element. Unfortunately, the rules of this type of packet filter can usually be bypassed. [RFC1858] describes the details of the involved technique. -4.1.6. Possible security improvements +4.1.2. Possible security improvements - Memory allocation for fragment reassembly +4.1.2.1. Memory allocation for fragment reassembly A design choice usually has to be made as to how to allocate memory to reassemble the fragments of a given packet. There are basically two options: o Upon receipt of the first fragment, allocate a buffer that will be large enough to concatenate the payload of each fragment. o Upon receipt of the first fragment, create the first node of a linked list to which each of the following fragments will be @@ -2416,21 +2350,21 @@ Furthermore, the IP module should keep a different buffer for IP fragments than for complete IP datagrams. This will basically separate the effects of fragment attacks on non-fragmented traffic. Most TCP/IP implementations, such as that in Linux and those in BSD- derived systems, already implement this. [Jones2002] contains an analysis about the amount of memory that may be needed for the fragment reassembly buffer depending on a number of network characteristics. - Flushing the fragment buffer +4.1.2.2. Flushing the fragment buffer In the case of those attacks that aim to consume the memory buffers used for fragments, and those that aim to cause a collision of IP Identification numbers, there are a number of counter-measures that can be implemented. The IP module should enforce a limit on the amount of memory that can be allocated for IP fragments, as well as a limit on the number of fragments that at any time will be allowed in the system. This will basically limit the resources spent on the reassembly process, and @@ -2474,39 +2408,39 @@ fragments that, when reached, triggers a fragment-buffer flush. Some systems flush 1/2 of the fragment buffer when the threshold is reached. As mentioned before, the idea of flushing the buffer is to create some free space in the fragment buffer, on the premise that this will allow for new and legitimate fragments to be processed by the IP module, thus letting communication survive the overwhelming situation. On the other hand, the idea of flushing a somewhat large portion of the buffer is to avoid flushing always the same set of packets. - A more selective fragment buffer flushing strategy +4.1.2.3. A more selective fragment buffer flushing strategy One of the difficulties in implementing counter-measures for the fragmentation attacks described in this document is that it is difficult to perform validation checks on the received fragments. For instance, the fragment on which validity checks could be performed, the first fragment, may be not the first fragment to arrive at the destination host. Fragments can not only arrive out of order because of packet reordering performed by the network, but also because the system (or systems) that fragmented the IP datagram may indeed transmit the fragments out of order. A notable example of this is the Linux TCP/IP stack, which transmits the fragments in reverse order. - This means that we cannot enforce checks on the fragments for which - we allocate reassembly resources, as the first fragment we receive - for a given packet may be some other fragment than the first one (the - one with an Fragment Offset of 0). + o This means that we cannot enforce checks on the fragments for + which we allocate reassembly resources, as the first fragment we + receive for a given packet may be some other fragment than the + first one (the one with an Fragment Offset of 0). However, at the point in which we decide to free some space in the fragment buffer, some refinements can be done to the flushing policy. The first thing we would like to do is to stop different types of traffic from interfering with each other. This means, in principle, that we do not want fragmented UDP traffic to interfere with fragmented TCP traffic. In order to implement this traffic separation for the different protocols, a different fragment buffer would be needed, in principle, for each of the 256 different protocols that can be encapsulated in an IP datagram. @@ -2557,21 +2491,21 @@ fragments in reverse order. In such cases, at the point of flushing the fragment buffer, legitimate fragments will receive the same treatment as the possible forged fragments. This refined flushing policy provides an increased level of protection against this type of resource exhaustion attack, while not making the situation of out-of-order IPsec-secured traffic worse than with the simplified flushing policy described in the previous section. - Reducing the fragment timeout +4.1.2.4. Reducing the fragment timeout RFC 1122 [RFC1122] states that the reassembly timeout should be a fixed value between 60 and 120 seconds. The rationale behind these long timeout values is that they should accommodate any path characteristics, such as long-delay paths. However, it must be noted that this timer is really measuring inter-fragment delays, or, more specifically, fragment jitter. If all fragments take paths of similar characteristics, the inter- fragment delay will usually be, at most, a few seconds. @@ -2580,34 +2514,34 @@ excessive. Some systems have already reduced the fragment timeout to 30 seconds [Linux2006]. The fragment timeout could probably be further reduced 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 mandatory to - avoid the use of fragmentation with techniques such as PMTUD - [RFC1191] or PLPMTUD [RFC4821]. + 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]. - Counter-measure for some IDS evasion techniques +4.1.2.5. Counter-measure 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. - Counter-measure for firewall-rules bypassing +4.1.2.6. Counter-measure 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 @@ -2687,21 +2621,21 @@ match" routes there are only routes with non-default type of services which do not match the TOS contained in the received packet, to use a route with any other TOS. While this route would most likely not be able to address the type of service requested by packet, it would, at least, provide a "best effort" service. It must be noted that Section 5.3.2 of RFC 1812 allows for routers for not honoring the TOS field. Therefore, the proposed alternative behavior is still compliant with the IETF specifications. - While officially specified in the RFC series, TOS-based routing is + o While officially specified in the RFC series, TOS-based routing is not widely deployed in the Internet. 4.2.3. Address Resolution In the case of broadcast link-layer technologies, in order for a system to transfer an IP datagram it must usually first map an IP address to the corresponding link-layer address (for example, by means of the ARP protocol [RFC0826]) . This means that while this operation is being performed, the packets that would require such a mapping would need to be kept in memory. This may happen both in the @@ -2727,24 +2660,24 @@ network service. One counter-measure to this problem would be to drop, at the point the mapping function times out all the packets destined to the address that timed out. In addition, a "negative cache entry" might be kept in the module performing the matching function, so that for some amount of time, the mapping function would return an error when the IP module requests to perform a mapping for some address for which the mapping has recently timed out. - A common implementation strategy for routers is that when a packet is - received that requires an ARP request to be performed before the - packet can be forwarded, the packet is dropped and the router is then - engaged in the ARP procedure. + o A common implementation strategy for routers is that when a packet + is received that requires an ARP request to be performed before + the packet can be forwarded, the packet is dropped and the router + is then engaged in the ARP procedure. 4.2.4. Dropping packets In some scenarios, it may be necessary for a host or router to drop packets from the output queue. In the event one of such packets happens to be an IP fragment, and there were other fragments of the same packet in the queue, those other fragments should also be dropped. The rationale for this policy is that it is nonsensical to spend system resources on those other fragments, because, as long as one fragment is missing, it will be impossible for the receiving @@ -2761,29 +2694,30 @@ It is important to understand that while there are some addresses that are supposed to be unreachable from the public Internet (such as those described in RFC 1918 [RFC1918], or the "loopback" address), there are a number of tricks an attacker can perform to reach those IP addresses that would otherwise be unreachable (e.g., exploit the LSRR or SSRR IP options). Therefore, when applicable, packet filtering should be performed at organizational network boundary to assure that those addresses will be unreachable. + [RFC5735] provides a summary of special use IPv4 addresses. + 4.3.2. Private address space The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets: o 10.0.0.0 - 10.255.255.255 (10/8 prefix) o 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) - o 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) Use of these address blocks is described in RFC 1918 [RFC1918]. Where applicable, packet filtering should be performed at the organizational perimeter to assure that these addresses are not reachable from outside the enterprise network. 4.3.3. Class D addresses (224/4 address block) @@ -2840,26 +2774,26 @@ 4.3.7. Special Internet addresses RFC 1812 [RFC1812] discusses the use of some special internet addresses, which is of interest to perform some sanity checks on the Source Address and Destination Address fields of an IP packet. It uses the following notation for an IP address: { , } - RFC 1122 [RFC1122] contained a similar discussion of special internet - addresses, including some of the form { , , }. However, as explained in Section 4.2.2.11 - of RFC 1812, in a CIDR world, the subnet number is clearly an - extension of the network prefix and cannot be interpreted without the - remainder of the prefix. + o RFC 1122 [RFC1122] contained a similar discussion of special + internet addresses, including some of the form { , + , }. However, as explained in + Section 4.2.2.11 of RFC 1812, in a CIDR world, the subnet number + is clearly an extension of the network prefix and cannot be + interpreted without the remainder of the prefix. {0, 0} This address means "this host on this network". It is meant to be used only during the initialization procedure, by which the host learns its own IP address. If a packet is received with 0.0.0.0 as the Source Address for any purpose other than bootstrapping, the corresponding packet should be silently dropped, and this event should be logged (e.g., a counter @@ -2882,27 +2816,27 @@ reflect the packet drop). {-1, -1} This address is the local broadcast address. It should not be used as a source IP address. If a packet is received with 255.255.255.255 as the Source Address, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). - Some systems, when receiving an ICMP echo request, for example, will - use the Destination Address in the ICMP echo request packet as the - Source Address of the response they send (in this case, an ICMP echo - reply). Thus, when such systems receive a request sent to a - broadcast address, the Source Address of the response will contain a - broadcast address. This should be considered a bug, rather than a - malicious use of the limited broadcast address. + o Some systems, when receiving an ICMP echo request, for example, + will use the Destination Address in the ICMP echo request packet + as the Source Address of the response they send (in this case, an + ICMP echo reply). Thus, when such systems receive a request sent + to a broadcast address, the Source Address of the response will + contain a broadcast address. This should be considered a bug, + rather than a malicious use of the limited broadcast address. {Network number, -1} This is the directed broadcast to the specified network. As recommended by RFC 2644 [RFC2644], routers should not forward network-directed broadcasts. This avoids the corresponding network from being utilized as, for example, a "smurf amplifier" [CERT1998a]. As noted in Section 4.3.6 of this document, many systems now allow administrators to configure these addresses as unicast addresses for @@ -2913,21 +2847,22 @@ address being a network-directed broadcast address, rather than a unicast address (e.g., that IP address is configured on the local system as a "broadcast address"). In such scenarios, if a system can infer the Source Address of a received packet is a network-directed broadcast address, the packet should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). As noted in Section 4.3.6 of this document, with the deployment of CIDR [RFC4632], it may be difficult for a system to infer whether a - particular IP address is a broadcast address. + particular IP address that does not belong to a directly attached + subnet is a broadcast address. {127, any} This is the internal host loopback address. Any packet that arrives on any physical interface containing this address as the Source Address, the Destination Address, or as part of a source route (either LSRR or SSRR), should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). @@ -2942,22 +2877,23 @@ 5. Security Considerations This document discusses the security implications of the Internet Protocol (IP), and discusses 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 would like to thank Andrew Yourtchenko for providing - valuable comments on earlier versions of this document. + The author would like to thank Alfred Hoenes, Joel Jaeggli, 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 Centre for the Protection of National Infrastructure (CPNI). 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 @@ -3015,23 +2951,30 @@ Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999. + [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic + Configuration of IPv4 Link-Local Addresses", RFC 3927, + May 2005. + [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. + [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", + BCP 153, RFC 5735, January 2010. + 7.2. Informative References [Anderson2001] Anderson, J., "An Analysis of Fragmentation Attacks", Available at: http://www.ouah.org/fragma.html , 2001. [Barisani2006] Barisani, A., "FTester - Firewall and IDS testing tool", Available at: http://dev.inversepath.com/trac/ftester , 2001. @@ -3175,22 +3118,22 @@ http://www.insecure.org/sploits/linux.PalmOS.nestea.html, 1998. [I-D.fuller-240space] Fuller, V., "Reclassifying 240/4 as usable unicast address space", draft-fuller-240space-02 (work in progress), March 2008. [I-D.ietf-tcpm-icmp-attacks] Gont, F., "ICMP attacks against TCP", - draft-ietf-tcpm-icmp-attacks-05 (work in progress), - June 2009. + draft-ietf-tcpm-icmp-attacks-10 (work in progress), + January 2010. [I-D.stjohns-sipso] StJohns, M., "Common Architecture Label IPv6 Security Option (CALIPSO)", draft-stjohns-sipso-11 (work in progress), March 2009. [I-D.templin-mtuassurance] Templin, F., "Requirements for IP-in-IP Tunnel MTU Assurance", draft-templin-mtuassurance-02 (work in progress), October 2006. @@ -3305,24 +3248,30 @@ July 1982. [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. + [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for + Network Interconnect Devices", RFC 2544, March 1999. + [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. + [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains + via IPv4 Clouds", RFC 3056, February 2001. + [RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003. @@ -3428,35 +3377,49 @@ vulnerabilities and potential threats to IT systems especially where 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 (to be removed by the RFC Editor before publishing this document as an RFC) -B.1. Changes from draft-ietf-opsec-ip-security-00 +B.1. 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.2. 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.2. Changes from draft-gont-opsec-ip-security-01 +B.3. 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.3. Changes from draft-gont-opsec-ip-security-00 +B.4. Changes from draft-gont-opsec-ip-security-00 o Fixed author's affiliation. - o Added Figure 4. + o Added Figure 5. o Fixed a few typos. o (no technical changes) Author's Address Fernando Gont UK Centre for the Protection of National Infrastructure