Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6274

Security Assessment of the Internet Protocol Version 4

Pages: 75
Informational
Errata
Part 1 of 5 – Pages 1 to 8
None   None   Next

Top   ToC   RFC6274 - Page 1
Internet Engineering Task Force (IETF)                           F. Gont
Request for Comments: 6274                                       UK CPNI
Category: Informational                                        July 2011
ISSN: 2070-1721


         Security Assessment of the Internet Protocol Version 4

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 document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6274. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents 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 Simplified BSD License.
Top   ToC   RFC6274 - Page 2

Table of Contents

1. Preface .........................................................4 1.1. Introduction ...............................................4 1.2. Scope of This Document .....................................6 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) ..............................10 3.3. Type of Service (TOS) .....................................10 3.3.1. Original Interpretation ............................10 3.3.2. Standard Interpretation ............................12 3.3.2.1. Differentiated Services Field .............12 3.3.2.2. Explicit Congestion Notification (ECN) ....13 3.4. Total Length ..............................................14 3.5. Identification (ID) .......................................15 3.5.1. Some Workarounds Implemented by the Industry .......16 3.5.2. Possible Security Improvements .....................17 3.5.2.1. Connection-Oriented Transport Protocols ...17 3.5.2.2. Connectionless Transport Protocols ........18 3.6. Flags .....................................................19 3.7. Fragment Offset ...........................................21 3.8. Time to Live (TTL) ........................................22 3.8.1. Fingerprinting the Operating System in Use by the Source Host .................................24 3.8.2. Fingerprinting the Physical Device from which the Packets Originate ........................24 3.8.3. Mapping the Network Topology .......................24 3.8.4. Locating the Source Host in the Network Topology ...25 3.8.5. Evading Network Intrusion Detection Systems ........26 3.8.6. Improving the Security of Applications That Make Use of the Internet Protocol (IP) .............27 3.8.7. Limiting Spread ....................................28 3.9. Protocol ..................................................28 3.10. Header Checksum ..........................................28 3.11. Source Address ...........................................29 3.12. Destination Address ......................................30 3.13. Options ..................................................30 3.13.1. General Issues with IP Options ....................31 3.13.1.1. Processing Requirements ..................31 3.13.1.2. Processing of the Options by the Upper-Layer Protocol .....................32 3.13.1.3. General Sanity Checks on IP Options ......32 3.13.2. Issues with Specific Options ......................34 3.13.2.1. End of Option List (Type=0) ..............34 3.13.2.2. No Operation (Type=1) ....................34
Top   ToC   RFC6274 - Page 3
                  3.13.2.3. Loose Source and Record Route
                            (LSRR) (Type=131) ........................34
                  3.13.2.4. Strict Source and Record Route
                            (SSRR) (Type=137) ........................37
                  3.13.2.5. Record Route (Type=7) ....................39
                  3.13.2.6. Stream Identifier (Type=136) .............40
                  3.13.2.7. Internet Timestamp (Type=68) .............40
                  3.13.2.8. Router Alert (Type=148) ..................43
                  3.13.2.9. Probe MTU (Type=11) (Obsolete) ...........44
                  3.13.2.10. Reply MTU (Type=12) (Obsolete) ..........44
                  3.13.2.11. Traceroute (Type=82) ....................44
                  3.13.2.12. Department of Defense (DoD)
                             Basic Security Option (Type=130) ........45
                  3.13.2.13. DoD Extended Security Option
                             (Type=133) ..............................46
                  3.13.2.14. Commercial IP Security Option
                             (CIPSO) (Type=134) ......................47
                  3.13.2.15. Sender Directed
                             Multi-Destination Delivery (Type=149) ...47
   4. Internet Protocol Mechanisms ...................................48
      4.1. Fragment Reassembly .......................................48
           4.1.1. Security Implications of Fragment Reassembly .......49
                  4.1.1.1. Problems Related to Memory Allocation .....49
                  4.1.1.2. Problems That Arise from the
                           Length of the IP Identification Field .....51
                  4.1.1.3. Problems That Arise from the
                           Complexity of the Reassembly Algorithm ....52
                  4.1.1.4. Problems That Arise from the
                           Ambiguity of the Reassembly Process .......52
                  4.1.1.5. Problems That Arise from the Size
                           of the IP Fragments .......................53
           4.1.2. Possible Security Improvements .....................53
                  4.1.2.1. Memory Allocation for Fragment
                           Reassembly ................................53
                  4.1.2.2. Flushing the Fragment Buffer ..............54
                  4.1.2.3. A More Selective Fragment Buffer
                           Flushing Strategy .........................55
                  4.1.2.4. Reducing the Fragment Timeout .............57
                  4.1.2.5. Countermeasure for Some NIDS
                           Evasion Techniques ........................58
                  4.1.2.6. Countermeasure for Firewall-Rules
                           Bypassing .................................58
      4.2. Forwarding ................................................58
           4.2.1. Precedence-Ordered Queue Service ...................58
           4.2.2. Weak Type of Service ...............................59
           4.2.3. Impact of Address Resolution on Buffer Management ..60
           4.2.4. Dropping Packets ...................................61
      4.3. Addressing ................................................61
Top   ToC   RFC6274 - Page 4
           4.3.1. Unreachable Addresses ..............................61
           4.3.2. Private Address Space ..............................61
           4.3.3. Former Class D Addresses (224/4 Address Block) .....62
           4.3.4. Former Class E Addresses (240/4 Address Block) .....62
           4.3.5. Broadcast/Multicast Addresses and
                  Connection-Oriented Protocols ......................62
           4.3.6. Broadcast and Network Addresses ....................63
           4.3.7. Special Internet Addresses .........................63
   5. Security Considerations ........................................65
   6. Acknowledgements ...............................................65
   7. References .....................................................66
      7.1. Normative References ......................................66
      7.2. Informative References ....................................68

1. Preface

1.1. Introduction

The TCP/IP protocols were conceived in an environment that was quite different from the hostile environment in which they currently operate. However, the effectiveness of the protocols led to their early adoption in production environments, to the point that, to some extent, the current world's economy depends on them. While many textbooks and articles have created the myth that the Internet protocols were designed for warfare environments, the top level goal for the Defense Advanced Research Projects Agency (DARPA) Internet Program was the sharing of large service machines on the ARPANET [Clark1988]. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify and overlook their security implications. While the Internet technology evolved since its inception, the Internet's building blocks are basically the same core protocols adopted by the ARPANET more than two decades ago. During the last twenty years, many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some of them were based on flaws in some protocol implementations, affecting only a reduced number of systems, while others were based on flaws in the protocols themselves, affecting virtually every existing implementation [Bellovin1989]. Even in the last couple of years, researchers were still working on security problems in the core protocols [RFC5927] [Watson2004] [NISCC2004] [NISCC2005]. The discovery of vulnerabilities in the TCP/IP protocols led to reports being published by a number of CSIRTs (Computer Security Incident Response Teams) and vendors, which helped to raise awareness about the threats and the best mitigations known at the time the
Top   ToC   RFC6274 - Page 5
   reports were published.  Unfortunately, this also led to the
   documentation of the discovered protocol vulnerabilities being spread
   among a large number of documents, which are sometimes difficult to
   identify.

   For some reason, much of the effort of the security community on the
   Internet protocols did not result in official documents (RFCs) being
   issued by the IETF (Internet Engineering Task Force).  This basically
   led to a situation in which "known" security problems have not always
   been addressed by all vendors.  In addition, in many cases, vendors
   have implemented quick "fixes" to protocol flaws without a careful
   analysis of their effectiveness and their impact on interoperability
   [Silbersack2005].

   The lack of adoption of these fixes by the IETF means that any system
   built in the future according to the official TCP/IP specifications
   will reincarnate security flaws that have already hit our
   communication systems in the past.

   Nowadays, producing a secure TCP/IP implementation is a very
   difficult task, in part because of the lack of a single document that
   serves as a security roadmap for the protocols.  Implementers are
   faced with the hard task of identifying relevant documentation and
   differentiating between that which provides correct advisory and that
   which provides misleading advisory based on inaccurate or wrong
   assumptions.

   There is a clear need for a companion document to the IETF
   specifications; one that discusses the security aspects and
   implications of the protocols, identifies the possible threats,
   discusses the possible countermeasures, and analyzes their respective
   effectiveness.

   This document is the result of an assessment of the IETF
   specifications of the Internet Protocol version 4 (IPv4), from a
   security point of view.  Possible threats were identified and, where
   possible, countermeasures were proposed.  Additionally, many
   implementation flaws that have led to security vulnerabilities have
   been referenced in the hope that future implementations will not
   incur the same problems.  Furthermore, this document does not limit
   itself to performing a security assessment of the relevant IETF
   specifications, but also provides an assessment of common
   implementation strategies found in the real world.

   Many IP implementations have also been subject of the so-called
   "packet-of-death" vulnerabilities, in which a single specially
   crafted packet causes the IP implementation to crash or otherwise
   misbehave.  In most cases, the attack packet is simply malformed; in
Top   ToC   RFC6274 - Page 6
   other cases, the attack packet is well-formed, but exercises a little
   used path through the IP stack.  Well-designed IP implementations
   should protect against these attacks, and therefore this document
   describes a number of sanity checks that are expected to prevent most
   of the aforementioned "packet-of-death" attack vectors.  We note that
   if an IP implementation is found to be vulnerable to one of these
   attacks, administrators must resort to mitigating them by packet
   filtering.

   Additionally, this document analyzes the security implications from
   changes in the operational environment since the Internet Protocol
   was designed.  For example, it analyzes how the Internet Protocol
   could be exploited to evade Network Intrusion Detection Systems
   (NIDSs) or to circumvent firewalls.

   This document does not aim to be the final word on the security of
   the Internet Protocol (IP).  On the contrary, it aims to raise
   awareness about many security threats based on the IP protocol that
   have been faced in the past, those that we are currently facing, and
   those we may still have to deal with in the future.  It provides
   advice for the secure implementation of the Internet Protocol (IP),
   but also provides insights about the security aspects of the Internet
   Protocol that may be of help to the Internet operations community.

   Feedback from the community is more than encouraged to help this
   document be as accurate as possible and to keep it updated as new
   threats are discovered.

   This document is heavily based on the "Security Assessment of the
   Internet Protocol" [CPNI2008] released by the UK Centre for the
   Protection of National Infrastructure (CPNI), available at
   http://www.cpni.gov.uk/Products/technicalnotes/3677.aspx.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.2. Scope of This Document

While there are a number of protocols that affect the way in which IP systems operate, this document focuses only on the specifications of the Internet Protocol (IP). For example, routing and bootstrapping protocols are considered out of the scope of this project. The following IETF RFCs were selected as the primary sources for the assessment as part of this work:
Top   ToC   RFC6274 - Page 7
   o  RFC 791, "INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL
      SPECIFICATION" (45 pages).

   o  RFC 815, "IP DATAGRAM REASSEMBLY ALGORITHMS" (9 pages).

   o  RFC 919, "BROADCASTING INTERNET DATAGRAMS" (8 pages).

   o  RFC 950, "Internet Standard Subnetting Procedure" (18 pages)

   o  RFC 1112, "Host Extensions for IP Multicasting" (17 pages)

   o  RFC 1122, "Requirements for Internet Hosts -- Communication
      Layers" (116 pages).

   o  RFC 1812, "Requirements for IP Version 4 Routers" (175 pages).

   o  RFC 2474, "Definition of the Differentiated Services Field (DS
      Field) in the IPv4 and IPv6 Headers" (20 pages).

   o  RFC 2475, "An Architecture for Differentiated Services" (36
      pages).

   o  RFC 3168, "The Addition of Explicit Congestion Notification (ECN)
      to IP" (63 pages).

   o  RFC 4632, "Classless Inter-domain Routing (CIDR): The Internet
      Address Assignment and Aggregation Plan" (27 pages).

1.3. Organization of This Document

This document is basically organized in two parts: "Internet Protocol header fields" and "Internet Protocol mechanisms". The former contains an analysis of each of the fields of the Internet Protocol header, identifies their security implications, and discusses possible countermeasures for the identified threats. The latter contains an analysis of the security implications of the mechanisms implemented by the Internet Protocol.

2. The Internet Protocol

The Internet Protocol (IP) provides a basic data transfer function for passing data blocks called "datagrams" from a source host to a destination host, across the possible intervening networks. Additionally, it provides some functions that are useful for the interconnection of heterogeneous networks, such as fragmentation and reassembly.
Top   ToC   RFC6274 - Page 8
   The "datagram" has a number of characteristics that makes it
   convenient for interconnecting systems [Clark1988]:

   o  It eliminates the need of connection state within the network,
      which improves the survivability characteristics of the network.

   o  It provides a basic service of data transport that can be used as
      a building block for other transport services (reliable data
      transport services, etc.).

   o  It represents the minimum network service assumption, which
      enables IP to be run over virtually any network technology.



(page 8 continued on part 2)

Next Section