tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6274

 Errata 
Informational
Pages: 75
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: OPSEC

Security Assessment of the Internet Protocol Version 4

Part 1 of 5, p. 1 to 8
None       Next RFC Part

 


Top       ToC       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       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       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       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       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       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       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       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 RFC Part