draft-ietf-opsec-ip-security-07.txt   rfc6274.txt 
Operational Security Capabilities for F. Gont Internet Engineering Task Force (IETF) F. Gont
IP Network Infrastructure (opsec) UK CPNI Request for Comments: 6274 UK CPNI
Internet-Draft April 8, 2011 Category: Informational July 2011
Intended status: Informational ISSN: 2070-1721
Expires: October 10, 2011
Security Assessment of the Internet Protocol version 4 Security Assessment of the Internet Protocol Version 4
draft-ietf-opsec-ip-security-07.txt
Abstract Abstract
This document contains a security assessment of the IETF This document contains a security assessment of the IETF
specifications of the Internet Protocol version 4, and of a number of specifications of the Internet Protocol version 4 and of a number of
mechanisms and policies in use by popular IPv4 implementations. It 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 is based on the results of a project carried out by the UK's Centre
for the Protection of National Infrastructure (CPNI). for the Protection of National Infrastructure (CPNI).
Status of this Memo 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 This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on October 10, 2011. 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 Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Preface .........................................................4
1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Introduction ...............................................4
1.2. Scope of this document . . . . . . . . . . . . . . . . . . 7 1.2. Scope of This Document .....................................6
1.3. Organization of this document . . . . . . . . . . . . . . 8 1.3. Organization of This Document ..............................7
2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 8 2. The Internet Protocol ...........................................7
3. Internet Protocol Header Fields . . . . . . . . . . . . . . . 9 3. Internet Protocol Header Fields .................................8
3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Version ....................................................9
3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 10 3.2. IHL (Internet Header Length) ..............................10
3.3. Type of Service . . . . . . . . . . . . . . . . . . . . . 11 3.3. Type of Service (TOS) .....................................10
3.3.1. Original Interpretation . . . . . . . . . . . . . . . 11 3.3.1. Original Interpretation ............................10
3.3.2. Standard Interpretation . . . . . . . . . . . . . . . 12 3.3.2. Standard Interpretation ............................12
3.3.2.1. Differentiated Services field . . . . . . . . . . 12 3.3.2.1. Differentiated Services Field .............12
3.3.2.2. Explicit Congestion Notification (ECN) . . . . . 13 3.3.2.2. Explicit Congestion Notification (ECN) ....13
3.4. Total Length . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. Total Length ..............................................14
3.5. Identification (ID) . . . . . . . . . . . . . . . . . . . 16 3.5. Identification (ID) .......................................15
3.5.1. Some Workarounds Implemented by the Industry . . . . . 17 3.5.1. Some Workarounds Implemented by the Industry .......16
3.5.2. Possible security improvements . . . . . . . . . . . . 17 3.5.2. Possible Security Improvements .....................17
3.5.2.1. Connection-Oriented Transport Protocols . . . . . 17 3.5.2.1. Connection-Oriented Transport Protocols ...17
3.5.2.2. Connectionless Transport Protocols . . . . . . . 18 3.5.2.2. Connectionless Transport Protocols ........18
3.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.6. Flags .....................................................19
3.7. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 22 3.7. Fragment Offset ...........................................21
3.8. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 23 3.8. Time to Live (TTL) ........................................22
3.8.1. Fingerprinting the operating system in use by the 3.8.1. Fingerprinting the Operating System in Use
source host . . . . . . . . . . . . . . . . . . . . . 25 by the Source Host .................................24
3.8.2. Fingerprinting the physical device from which the 3.8.2. Fingerprinting the Physical Device from
packets originate . . . . . . . . . . . . . . . . . . 25 which the Packets Originate ........................24
3.8.3. Mapping the Network Topology . . . . . . . . . . . . . 25 3.8.3. Mapping the Network Topology .......................24
3.8.4. Locating the source host in the network topology . . . 26 3.8.4. Locating the Source Host in the Network Topology ...25
3.8.5. Evading Network Intrusion Detection Systems . . . . . 27 3.8.5. Evading Network Intrusion Detection Systems ........26
3.8.6. Improving the security of applications that make 3.8.6. Improving the Security of Applications That
use of the Internet Protocol (IP) . . . . . . . . . . 28 Make Use of the Internet Protocol (IP) .............27
3.8.7. Limiting spread . . . . . . . . . . . . . . . . . . . 29 3.8.7. Limiting Spread ....................................28
3.9. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.9. Protocol ..................................................28
3.10. Header Checksum . . . . . . . . . . . . . . . . . . . . . 29 3.10. Header Checksum ..........................................28
3.11. Source Address . . . . . . . . . . . . . . . . . . . . . . 29 3.11. Source Address ...........................................29
3.12. Destination Address . . . . . . . . . . . . . . . . . . . 30 3.12. Destination Address ......................................30
3.13. Options . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.13. Options ..................................................30
3.13.1. General issues with IP options . . . . . . . . . . . . 32 3.13.1. General Issues with IP Options ....................31
3.13.1.1. Processing requirements . . . . . . . . . . . . . 32 3.13.1.1. Processing Requirements ..................31
3.13.1.2. Processing of the options by the upper layer 3.13.1.2. Processing of the Options by the
protocol . . . . . . . . . . . . . . . . . . . . 33 Upper-Layer Protocol .....................32
3.13.1.3. General sanity checks on IP options . . . . . . . 33 3.13.1.3. General Sanity Checks on IP Options ......32
3.13.2. Issues with specific options . . . . . . . . . . . . . 35 3.13.2. Issues with Specific Options ......................34
3.13.2.1. End of Option List (Type=0) . . . . . . . . . . . 35 3.13.2.1. End of Option List (Type=0) ..............34
3.13.2.2. No Operation (Type=1) . . . . . . . . . . . . . . 35 3.13.2.2. No Operation (Type=1) ....................34
3.13.2.3. Loose Source and Record Route (LSRR) 3.13.2.3. Loose Source and Record Route
(Type=131) . . . . . . . . . . . . . . . . . . . 35 (LSRR) (Type=131) ........................34
3.13.2.4. Strict Source and Record Route (SSRR) 3.13.2.4. Strict Source and Record Route
(Type=137) . . . . . . . . . . . . . . . . . . . 38 (SSRR) (Type=137) ........................37
3.13.2.5. Record Route (Type=7) . . . . . . . . . . . . . . 40 3.13.2.5. Record Route (Type=7) ....................39
3.13.2.6. Stream Identifier (Type=136) . . . . . . . . . . 41 3.13.2.6. Stream Identifier (Type=136) .............40
3.13.2.7. Internet Timestamp (Type=68) . . . . . . . . . . 41 3.13.2.7. Internet Timestamp (Type=68) .............40
3.13.2.8. Router Alert (Type=148) . . . . . . . . . . . . . 44 3.13.2.8. Router Alert (Type=148) ..................43
3.13.2.9. Probe MTU (Type=11) (obsolete) . . . . . . . . . 45 3.13.2.9. Probe MTU (Type=11) (Obsolete) ...........44
3.13.2.10. Reply MTU (Type=12) (obsolete) . . . . . . . . . 45 3.13.2.10. Reply MTU (Type=12) (Obsolete) ..........44
3.13.2.11. Traceroute (Type=82) . . . . . . . . . . . . . . 45 3.13.2.11. Traceroute (Type=82) ....................44
3.13.2.12. DoD Basic Security Option (Type=130) . . . . . . 45 3.13.2.12. Department of Defense (DoD)
3.13.2.13. DoD Extended Security Option (Type=133) . . . . . 47 Basic Security Option (Type=130) ........45
3.13.2.14. Commercial IP Security Option (CIPSO) 3.13.2.13. DoD Extended Security Option
(Type=134) . . . . . . . . . . . . . . . . . . . 47 (Type=133) ..............................46
3.13.2.15. Sender Directed Multi-Destination Delivery 3.13.2.14. Commercial IP Security Option
(Type=149) . . . . . . . . . . . . . . . . . . . 48 (CIPSO) (Type=134) ......................47
4. Internet Protocol Mechanisms . . . . . . . . . . . . . . . . . 48 3.13.2.15. Sender Directed
4.1. Fragment reassembly . . . . . . . . . . . . . . . . . . . 48 Multi-Destination Delivery (Type=149) ...47
4.1.1. Security Implications of Fragment Reassembly . . . . . 49 4. Internet Protocol Mechanisms ...................................48
4.1.1.1. Problems related with memory allocation . . . . . 49 4.1. Fragment Reassembly .......................................48
4.1.1.2. Problems that arise from the length of the IP 4.1.1. Security Implications of Fragment Reassembly .......49
Identification field . . . . . . . . . . . . . . 51 4.1.1.1. Problems Related to Memory Allocation .....49
4.1.1.3. Problems that arise from the complexity of 4.1.1.2. Problems That Arise from the
the reassembly algorithm . . . . . . . . . . . . 52 Length of the IP Identification Field .....51
4.1.1.4. Problems that arise from the ambiguity of the 4.1.1.3. Problems That Arise from the
reassembly process . . . . . . . . . . . . . . . 52 Complexity of the Reassembly Algorithm ....52
4.1.1.5. Problems that arise from the size of the IP 4.1.1.4. Problems That Arise from the
fragments . . . . . . . . . . . . . . . . . . . . 54 Ambiguity of the Reassembly Process .......52
4.1.2. Possible security improvements . . . . . . . . . . . . 54 4.1.1.5. Problems That Arise from the Size
4.1.2.1. Memory allocation for fragment reassembly . . . . 54 of the IP Fragments .......................53
4.1.2.2. Flushing the fragment buffer . . . . . . . . . . 55 4.1.2. Possible Security Improvements .....................53
4.1.2.3. A more selective fragment buffer flushing 4.1.2.1. Memory Allocation for Fragment
strategy . . . . . . . . . . . . . . . . . . . . 56 Reassembly ................................53
4.1.2.4. Reducing the fragment timeout . . . . . . . . . . 58 4.1.2.2. Flushing the Fragment Buffer ..............54
4.1.2.5. Countermeasure for some IDS evasion techniques . 58 4.1.2.3. A More Selective Fragment Buffer
4.1.2.6. Countermeasure for firewall-rules bypassing . . . 58 Flushing Strategy .........................55
4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 59 4.1.2.4. Reducing the Fragment Timeout .............57
4.2.1. Precedence-ordered queue service . . . . . . . . . . . 59 4.1.2.5. Countermeasure for Some NIDS
4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 60 Evasion Techniques ........................58
4.2.3. Impact of Address Resolution on Buffer Management . . 60 4.1.2.6. Countermeasure for Firewall-Rules
4.2.4. Dropping packets . . . . . . . . . . . . . . . . . . . 61 Bypassing .................................58
4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 61 4.2. Forwarding ................................................58
4.3.1. Unreachable addresses . . . . . . . . . . . . . . . . 62 4.2.1. Precedence-Ordered Queue Service ...................58
4.3.2. Private address space . . . . . . . . . . . . . . . . 62 4.2.2. Weak Type of Service ...............................59
4.3.3. Former Class D Addresses (224/4 Address Block) . . . . 62 4.2.3. Impact of Address Resolution on Buffer Management ..60
4.3.4. Former Class E Addresses (240/4 Address Block) . . . . 63 4.2.4. Dropping Packets ...................................61
4.3.5. Broadcast/Multicast addresses, and 4.3. Addressing ................................................61
Connection-Oriented Protocols . . . . . . . . . . . . 63 4.3.1. Unreachable Addresses ..............................61
4.3.6. Broadcast and network addresses . . . . . . . . . . . 63 4.3.2. Private Address Space ..............................61
4.3.7. Special Internet addresses . . . . . . . . . . . . . . 63 4.3.3. Former Class D Addresses (224/4 Address Block) .....62
5. Security Considerations . . . . . . . . . . . . . . . . . . . 66 4.3.4. Former Class E Addresses (240/4 Address Block) .....62
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 66 4.3.5. Broadcast/Multicast Addresses and
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Connection-Oriented Protocols ......................62
7.1. Normative References . . . . . . . . . . . . . . . . . . . 66 4.3.6. Broadcast and Network Addresses ....................63
7.2. Informative References . . . . . . . . . . . . . . . . . . 68 4.3.7. Special Internet Addresses .........................63
Appendix A. Changes from previous versions of the draft . . . . . 76 5. Security Considerations ........................................65
A.1. Changes from draft-ietf-opsec-ip-security-05 . . . . . . . 76 6. Acknowledgements ...............................................65
A.2. Changes from draft-ietf-opsec-ip-security-04 . . . . . . . 77 7. References .....................................................66
A.3. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 77 7.1. Normative References ......................................66
A.4. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 77 7.2. Informative References ....................................68
A.5. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 77
A.6. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 77
A.7. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 77
A.8. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 77
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 78
1. Preface 1. Preface
1.1. Introduction 1.1. Introduction
The TCP/IP protocols were conceived in an environment that was quite The TCP/IP protocols were conceived in an environment that was quite
different from the hostile environment in which they currently different from the hostile environment in which they currently
operate. However, the effectiveness of the protocols led to their operate. However, the effectiveness of the protocols led to their
early adoption in production environments, to the point that, to some early adoption in production environments, to the point that, to some
extent, the current world's economy depends on them. extent, the current world's economy depends on them.
While many textbooks and articles have created the myth that the While many textbooks and articles have created the myth that the
Internet protocols were designed for warfare environments, the top Internet protocols were designed for warfare environments, the top
level goal for the DARPA Internet Program was the sharing of large level goal for the Defense Advanced Research Projects Agency (DARPA)
service machines on the ARPANET [Clark1988]. As a result, many Internet Program was the sharing of large service machines on the
protocol specifications focus only on the operational aspects of the ARPANET [Clark1988]. As a result, many protocol specifications focus
protocols they specify, and overlook their security implications. only on the operational aspects of the protocols they specify and
overlook their security implications.
While the Internet technology evolved since its inception, the While the Internet technology evolved since its inception, the
Internet's building blocks are basically the same core protocols Internet's building blocks are basically the same core protocols
adopted by the ARPANET more than two decades ago. During the last adopted by the ARPANET more than two decades ago. During the last
twenty years, many vulnerabilities have been identified in the TCP/IP 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 stacks of a number of systems. Some of them were based on flaws in
some protocol implementations, affecting only a reduced number of some protocol implementations, affecting only a reduced number of
systems, while others were based on flaws in the protocols systems, while others were based on flaws in the protocols
themselves, affecting virtually every existing implementation themselves, affecting virtually every existing implementation
[Bellovin1989]. Even in the last couple of years, researchers were [Bellovin1989]. Even in the last couple of years, researchers were
skipping to change at page 5, line 47 skipping to change at page 5, line 13
about the threats and the best mitigations known at the time the about the threats and the best mitigations known at the time the
reports were published. Unfortunately, this also led to the reports were published. Unfortunately, this also led to the
documentation of the discovered protocol vulnerabilities being spread documentation of the discovered protocol vulnerabilities being spread
among a large number of documents, which are sometimes difficult to among a large number of documents, which are sometimes difficult to
identify. identify.
For some reason, much of the effort of the security community on the For some reason, much of the effort of the security community on the
Internet protocols did not result in official documents (RFCs) being Internet protocols did not result in official documents (RFCs) being
issued by the IETF (Internet Engineering Task Force). This basically issued by the IETF (Internet Engineering Task Force). This basically
led to a situation in which "known" security problems have not always led to a situation in which "known" security problems have not always
been addressed by all vendors. In addition, in many cases vendors been addressed by all vendors. In addition, in many cases, vendors
have implemented quick "fixes" to protocol flaws without a careful have implemented quick "fixes" to protocol flaws without a careful
analysis of their effectiveness and their impact on interoperability analysis of their effectiveness and their impact on interoperability
[Silbersack2005]. [Silbersack2005].
The lack of adoption of these fixes by the IETF means that any system 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 built in the future according to the official TCP/IP specifications
will reincarnate security flaws that have already hit our will reincarnate security flaws that have already hit our
communication systems in the past. communication systems in the past.
Producing a secure TCP/IP implementation nowadays is a very difficult Nowadays, producing a secure TCP/IP implementation is a very
task, in part because of the lack of a single document that serves as difficult task, in part because of the lack of a single document that
a security roadmap for the protocols. Implementers are faced with serves as a security roadmap for the protocols. Implementers are
the hard task of identifying relevant documentation and differentiate faced with the hard task of identifying relevant documentation and
between that which provides correct advisory, and that which provides differentiating between that which provides correct advisory and that
misleading advisory based on inaccurate or wrong assumptions. which provides misleading advisory based on inaccurate or wrong
assumptions.
There is a clear need for a companion document to the IETF There is a clear need for a companion document to the IETF
specifications that discusses the security aspects and implications specifications; one that discusses the security aspects and
of the protocols, identifies the possible threats, discusses the implications of the protocols, identifies the possible threats,
possible countermeasures, and analyzes their respective discusses the possible countermeasures, and analyzes their respective
effectiveness. effectiveness.
This document is the result of an assessment of the IETF This document is the result of an assessment of the IETF
specifications of the Internet Protocol version 4 (IPv4), from a specifications of the Internet Protocol version 4 (IPv4), from a
security point of view. Possible threats were identified and, where security point of view. Possible threats were identified and, where
possible, countermeasures were proposed. Additionally, many possible, countermeasures were proposed. Additionally, many
implementation flaws that have led to security vulnerabilities have implementation flaws that have led to security vulnerabilities have
been referenced in the hope that future implementations will not been referenced in the hope that future implementations will not
incur the same problems. Furthermore, this document does not limit incur the same problems. Furthermore, this document does not limit
itself to performing a security assessment of the relevant IETF itself to performing a security assessment of the relevant IETF
specifications, but also provides an assessment of common specifications, but also provides an assessment of common
implementation strategies found in the real world. implementation strategies found in the real world.
Many IP implementations have also been subject of the so-called Many IP implementations have also been subject of the so-called
"packet-of-death" vulnerabilities, in which a single specially- "packet-of-death" vulnerabilities, in which a single specially
crafted packet causes the IP implementation to crash or otherwise crafted packet causes the IP implementation to crash or otherwise
misbehave. In most cases, the attack packet is simply malformed; in misbehave. In most cases, the attack packet is simply malformed; in
other cases, the attack packet is well-formed, but exercises a little other cases, the attack packet is well-formed, but exercises a little
used path through the IP stack. Well-designed IP implementations used path through the IP stack. Well-designed IP implementations
should protect against these attacks, and therefore this document should protect against these attacks, and therefore this document
describes a number of sanity checks that are expected to prevent most describes a number of sanity checks that are expected to prevent most
of the aforementioned "packet-of-death" attack vectors. We note that of the aforementioned "packet-of-death" attack vectors. We note that
if an IP implementation is is found vulnerable to one of these if an IP implementation is found to be vulnerable to one of these
attacks, administrators must resort to mitigating them by packet attacks, administrators must resort to mitigating them by packet
filtering. filtering.
Additionally, this document analyzes the security implications from Additionally, this document analyzes the security implications from
changes in the operational environment since the Internet Protocol changes in the operational environment since the Internet Protocol
was desgined. For example, it analyzes how the Internet Protocol was designed. For example, it analyzes how the Internet Protocol
could be exploited to evade Network Intrusion Detection Systems could be exploited to evade Network Intrusion Detection Systems
(NIDS) or to circumvent firewalls. (NIDSs) or to circumvent firewalls.
This document does not aim to be the final word on the security of 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 the Internet Protocol (IP). On the contrary, it aims to raise
awareness about many security threats based on the IP protocol that awareness about many security threats based on the IP protocol that
have been faced in the past, those that we are currently facing, and 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 those we may still have to deal with in the future. It provides
advice for the secure implementation of the Internet Protocol (IP), advice for the secure implementation of the Internet Protocol (IP),
but also provides insights about the security aspects of the Internet but also provides insights about the security aspects of the Internet
Protocol that may be of help to the Internet operations community. Protocol that may be of help to the Internet operations community.
Feedback from the community is more than encouraged to help this Feedback from the community is more than encouraged to help this
document be as accurate as possible and to keep it updated as new document be as accurate as possible and to keep it updated as new
threats are discovered. threats are discovered.
This document is heavily based on the "Security Assessment of the This document is heavily based on the "Security Assessment of the
Internet Protocol" [CPNI2008] released by the UK Centre for the Internet Protocol" [CPNI2008] released by the UK Centre for the
Protection of National Infrastructure (CPNI), available at: Protection of National Infrastructure (CPNI), available at
http://www.cpni.gov.uk/Products/technicalnotes/3677.aspx . http://www.cpni.gov.uk/Products/technicalnotes/3677.aspx.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Scope of this document 1.2. Scope of This Document
While there are a number of protocols that affect the way in which IP While there are a number of protocols that affect the way in which IP
systems operate, this document focuses only on the specifications of systems operate, this document focuses only on the specifications of
the Internet Protocol (IP). For example, routing and bootstrapping the Internet Protocol (IP). For example, routing and bootstrapping
protocols are considered out of the scope of this project. protocols are considered out of the scope of this project.
The following IETF RFCs were selected as the primary sources for the The following IETF RFCs were selected as the primary sources for the
assessment as part of this work: assessment as part of this work:
o RFC 791, "Internet Protocol. DARPA Internet Program. Protocol o RFC 791, "INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL
Specification" (51 pages). SPECIFICATION" (45 pages).
o RFC 815, "IP datagram reassembly algorithms" (9 pages). o RFC 815, "IP DATAGRAM REASSEMBLY ALGORITHMS" (9 pages).
o RFC 919, "BROADCASTING INTERNET DATAGRAMS" (8 pages). o RFC 919, "BROADCASTING INTERNET DATAGRAMS" (8 pages).
o RFC 950, "Internet Standard Subnetting Procedure" (18 pages) o RFC 950, "Internet Standard Subnetting Procedure" (18 pages)
o RFC 1112, "Host Extensions for IP Multicasting" (17 pages) o RFC 1112, "Host Extensions for IP Multicasting" (17 pages)
o RFC 1122, "Requirements for Internet Hosts -- Communication o RFC 1122, "Requirements for Internet Hosts -- Communication
Layers" (116 pages). Layers" (116 pages).
skipping to change at page 8, line 17 skipping to change at page 7, line 33
o RFC 2475, "An Architecture for Differentiated Services" (36 o RFC 2475, "An Architecture for Differentiated Services" (36
pages). pages).
o RFC 3168, "The Addition of Explicit Congestion Notification (ECN) o RFC 3168, "The Addition of Explicit Congestion Notification (ECN)
to IP" (63 pages). to IP" (63 pages).
o RFC 4632, "Classless Inter-domain Routing (CIDR): The Internet o RFC 4632, "Classless Inter-domain Routing (CIDR): The Internet
Address Assignment and Aggregation Plan" (27 pages). Address Assignment and Aggregation Plan" (27 pages).
1.3. Organization of this document 1.3. Organization of This Document
This document is basically organized in two parts: "Internet Protocol This document is basically organized in two parts: "Internet Protocol
header fields" and "Internet Protocol mechanisms". The former header fields" and "Internet Protocol mechanisms". The former
contains an analysis of each of the fields of the Internet Protocol contains an analysis of each of the fields of the Internet Protocol
header, identifies their security implications, and discusses header, identifies their security implications, and discusses
possible countermeasures for the identified threats. The latter possible countermeasures for the identified threats. The latter
contains an analysis of the security implications of the mechanisms contains an analysis of the security implications of the mechanisms
implemented by the Internet Protocol. implemented by the Internet Protocol.
2. The Internet Protocol 2. The Internet Protocol
skipping to change at page 9, line 28 skipping to change at page 8, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum | | Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address | | Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address | | Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Options ] | [ Padding ] | | [ Options ] | [ Padding ] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Internet Protocol header format Figure 1: Internet Protocol Header Format
Even though the minimum IP header size is 20 bytes, an IP module Even though the minimum IP header size is 20 bytes, an IP module
might be handed an (illegitimate) "datagram" of less than 20 bytes. might be handed an (illegitimate) "datagram" of less than 20 bytes.
Therefore, before doing any processing of the IP header fields, the Therefore, before doing any processing of the IP header fields, the
following check should be performed by the IP module on the packets following check should be performed by the IP module on the packets
handed by the link layer: handed by the link layer:
LinkLayer.PayloadSize >= 20 LinkLayer.PayloadSize >= 20
where LinkLayer.PayloadSize is the length (in octets) of the datagram where LinkLayer.PayloadSize is the length (in octets) of the datagram
skipping to change at page 10, line 6 skipping to change at page 9, line 18
The following subsections contain further sanity checks that should The following subsections contain further sanity checks that should
be performed on IP packets. be performed on IP packets.
3.1. Version 3.1. Version
This is a 4-bit field that indicates the version of the Internet This is a 4-bit field that indicates the version of the Internet
Protocol (IP), and thus the syntax of the packet. For IPv4, this Protocol (IP), and thus the syntax of the packet. For IPv4, this
field must be 4. field must be 4.
When a Link-Layer protocol de-multiplexes a packet to an internet When a link-layer protocol de-multiplexes a packet to an Internet
module, it does so based on a "Protocol Type" field in the data-link module, it does so based on a Protocol Type field in the data-link
packet header. packet header.
In theory, different versions of IP could coexist on a network by In theory, different versions of IP could coexist on a network by
using the same "Protocol Type" at the Link-layer, but a different using the same Protocol Type at the link layer, but a different value
value in the Version field of the IP header. Thus, a single IP in the Version field of the IP header. Thus, a single IP module
module could handle all versions of the Internet Protocol, could handle all versions of the Internet Protocol, differentiating
differentiating them by means of this field. them by means of this field.
However, in practice different versions of IP are identified by a However, in practice different versions of IP are identified by a
different "Protocol Type" (e.g., "EtherType" in the case of Ethernet) different Protocol Type (e.g., EtherType in the case of Ethernet)
number in the link-layer protocol header. For example, IPv4 number in the link-layer protocol header. For example, IPv4
datagrams are encapsulated in Ethernet frames using an EtherType of datagrams are encapsulated in Ethernet frames using an EtherType of
0x0800, while IPv6 datagrams are encapsulated in Ethernet frames 0x0800, while IPv6 datagrams are encapsulated in Ethernet frames
using an EtherType of 0x86DD [IANA2006a]. using an EtherType of 0x86DD [IANA_ET].
Therefore, if an IPv4 module receives a packet, the Version field Therefore, if an IPv4 module receives a packet, the Version field
must be checked to be 4. If this check fails, the packet should be must be checked to be 4. If this check fails, the packet should be
silently dropped, and this event should be logged (e.g., a counter silently dropped, and this event should be logged (e.g., a counter
could be incremented reflecting the packet drop). If an could be incremented reflecting the packet drop). If an
implementation does not performs this check, an attacker could use a implementation does not perform this check, an attacker could use a
different value for the Version field, possibly evading Network different value for the Version field, possibly evading NIDSs that
Intrusion Detection Systems (NIDS) that decide which pattern-matching decide which pattern-matching rules to apply based on the Version
rules to apply based on the Version field. field.
If the link-layer protocol employs a specific "Protocol Type" value If the link-layer protocol employs a specific "Protocol Type" value
for encapsulating IPv4 packets (as is the case of e.g. Ethernet), a for encapsulating IPv4 packets (e.g., as is the case of Ethernet), a
node should check that IPv4 packets are de-multiplexed to the IPv4 node should check that IPv4 packets are de-multiplexed to the IPv4
module when such value was used for the "Protocol Type" field of the module when such value was used for the Protocol Type field of the
link-layer protocol. If a packet does not pass this check, it should link-layer protocol. If a packet does not pass this check, it should
be silently dropped. be silently dropped.
An attacker could encapsulate IPv4 packets using other link-layer An attacker could encapsulate IPv4 packets using other link-layer
"Protocol Type" values to try to subvert link-layer Access Control "Protocol Type" values to try to subvert link-layer Access Control
Lists (ACLs), and/or for tampering with Network Intrusion Lists (ACLs) and/or for tampering with NIDSs.
Detection Systems (NIDS).
3.2. IHL (Internet Header Length) 3.2. IHL (Internet Header Length)
The IHL (Internet Header Length) field indicates the length of the The IHL (Internet Header Length) field indicates the length of the
internet header in 32-bit words (4 bytes). The following paragraphs Internet header in 32-bit words (4 bytes). The following paragraphs
decribe a number of sanity checks to be performed on the IHL field, describe a number of sanity checks to be performed on the IHL field,
such that possible packet-of-death vulnerabilities are avoided. such that possible packet-of-death vulnerabilities are avoided.
As the minimum datagram size is 20 bytes, the minimum legal value for As the minimum datagram size is 20 bytes, the minimum legal value for
this field is 5. Therefore, the following check should be enforced: this field is 5. Therefore, the following check should be enforced:
IHL >= 5 IHL >= 5
If the packet does not pass this check, it should be dropped, and 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 this event should be logged (e.g., a counter could be incremented
reflecting the packet drop). reflecting the packet drop).
For obvious reasons, the Internet header cannot be larger than the For obvious reasons, the Internet header cannot be larger than the
whole Internet datagram it is part of. Therefore, the following whole Internet datagram of which it is part. Therefore, the
check should be enforced: following check should be enforced:
IHL * 4 <= Total Length IHL * 4 <= Total Length
This needs to refer to the size of the datagram as specified by This needs to refer to the size of the datagram as specified by
the sender in the Total Length field, since link layers might have the sender in the Total Length field, since link layers might have
added some padding (see Section 3.4). added some padding (see Section 3.4).
If the packet does not pass this check, it should be dropped, and 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 this event should be logged (e.g., a counter could be incremented
reflecting the packet drop). reflecting the packet drop).
The above check allows for Internet datagrams with no data bytes in The above check allows for Internet datagrams with no data bytes in
the payload that, while nonsensical for virtually every protocol that the payload that, while nonsensical for virtually every protocol that
runs over IP, are is still legal. runs over IP, are still legal.
3.3. Type of Service 3.3. Type of Service (TOS)
3.3.1. Original Interpretation 3.3.1. Original Interpretation
Figure 2 shows the original syntax of the Type of Service field, as Figure 2 shows the original syntax of the Type of Service field, as
defined by RFC 791 [RFC0791], and updated by RFC 1349 [RFC1349]. defined by RFC 791 [RFC0791] and updated by RFC 1349 [RFC1349]. This
This definition has been superseded long ago (see Section 3.3.2.1 and definition has been superseded long ago (see Sections 3.3.2.1 and
Section 3.3.2.2), but it is still assumed by some deployed 3.3.2.2), but it is still assumed by some deployed implementations.
implementations.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | D | T | R | C | 0 | | PRECEDENCE | D | T | R | C | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 2: Type of Service Field (Original Interpretation) Figure 2: Type of Service Field (Original Interpretation)
+----------+----------------------------------------------+ +----------+----------------------------------------------+
| Bits 0-2 | Precedence | | Bits 0-2 | Precedence |
skipping to change at page 12, line 19 skipping to change at page 11, line 26
+----------+----------------------------------------------+ +----------+----------------------------------------------+
| Bit 4 | 0 = Normal Throughput, 1 = High Throughput | | Bit 4 | 0 = Normal Throughput, 1 = High Throughput |
+----------+----------------------------------------------+ +----------+----------------------------------------------+
| Bit 5 | 0 = Normal Reliability, 1 = High Reliability | | Bit 5 | 0 = Normal Reliability, 1 = High Reliability |
+----------+----------------------------------------------+ +----------+----------------------------------------------+
| Bit 6 | 0 = Normal Cost, 1 = Minimize Monetary Cost | | Bit 6 | 0 = Normal Cost, 1 = Minimize Monetary Cost |
+----------+----------------------------------------------+ +----------+----------------------------------------------+
| Bits 7 | Reserved for Future Use (must be zero) | | Bits 7 | Reserved for Future Use (must be zero) |
+----------+----------------------------------------------+ +----------+----------------------------------------------+
Table 1: TOS-bits Semantics Table 1: Semantics of the TOS Bits
+-----+-----------------+ +-----+-----------------+
| 111 | Network Control | | 111 | Network Control |
+-----+-----------------+ +-----+-----------------+
| 110 | Internetwork | | 110 | Internetwork |
+-----+-----------------+ +-----+-----------------+
| 101 | CRITIC/ECP | | 101 | CRITIC/ECP |
+-----+-----------------+ +-----+-----------------+
| 100 | Flash Override | | 100 | Flash Override |
+-----+-----------------+ +-----+-----------------+
| 011 | Flash | | 011 | Flash |
+-----+-----------------+ +-----+-----------------+
| 010 | Immediate | | 010 | Immediate |
+-----+-----------------+ +-----+-----------------+
| 001 | Priority | | 001 | Priority |
+-----+-----------------+ +-----+-----------------+
| 000 | Routine | | 000 | Routine |
+-----+-----------------+ +-----+-----------------+
Table 2: Precedence Field Values Table 2: Semantics of the Possible Precedence Field Values
The Type of Service field can be used to affect the way in which the 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. 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 Section 4.2.1 ("Precedence-Ordered Queue Service") and Section 4.2.2
("Weak TOS") of this document describe the security implications of ("Weak Type of Service") of this document describe the security
the Type of Service field in the forwarding of packets. implications of the Type of Service field in the forwarding of
packets.
3.3.2. Standard Interpretation 3.3.2. Standard Interpretation
3.3.2.1. Differentiated Services field 3.3.2.1. Differentiated Services Field
The Differentiated Services Architecture is intended to enable The Differentiated Services Architecture is intended to enable
scalable service discrimination in the Internet without the need for scalable service discrimination in the Internet without the need for
per-flow state and signaling at every hop [RFC2475]. RFC 2474 per-flow state and signaling at every hop [RFC2475]. RFC 2474
[RFC2474] redefined the IP "Type of Service" octet, introducing a [RFC2474] redefined the IP "Type of Service" octet, introducing a
Differentiated Services Field (DS Field). Figure 3 shows the format Differentiated Services Field (DS Field). Figure 3 shows the format
of the field. of the field.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
skipping to change at page 13, line 26 skipping to change at page 12, line 36
The DSCP ("Differentiated Services CodePoint") is used to select the The DSCP ("Differentiated Services CodePoint") is used to select the
treatment the packet is to receive within the Differentiated Services treatment the packet is to receive within the Differentiated Services
Domain. The CU ("Currently Unused") field was, at the time the Domain. The CU ("Currently Unused") field was, at the time the
specification was issued, reserved for future use. The DSCP field is specification was issued, reserved for future use. The DSCP field is
used to select a PHB (Per-Hop Behavior), by matching against the used to select a PHB (Per-Hop Behavior), by matching against the
entire 6-bit field. entire 6-bit field.
Considering that the DSCP field determines how a packet is treated Considering that the DSCP field determines how a packet is treated
within a Differentiated Services (DS) domain, an attacker could send within a Differentiated Services (DS) domain, an attacker could send
packets with a forged DSCP field to perform a theft of service or packets with a forged DSCP field to perform a theft of service or
even a Denial-of-Service attack. In particular, an attacker could even a Denial-of-Service (DoS) attack. In particular, an attacker
forge packets with a codepoint of the type '11x000' which, according could forge packets with a codepoint of the type '11x000' which,
to Section 4.2.2.2 of RFC 2474 [RFC2474], would give the packets according to Section 4.2.2.2 of RFC 2474 [RFC2474], would give the
preferential forwarding treatment when compared with the PHB selected packets preferential forwarding treatment when compared with the PHB
by the codepoint '000000'. If strict priority queuing were utilized, selected by the codepoint '000000'. If strict priority queuing were
a continuous stream of such packets could cause a Denial of Service utilized, a continuous stream of such packets could cause a DoS to
to other flows which have a DSCP of lower relative order. other flows that have a DSCP of lower relative order.
As the DS field is incompatible with the original Type of Service As the DS field is incompatible with the original Type of Service
field, both DS domains and networks using the original Type of field, both DS domains and networks using the original Type of
Service field should protect themselves by remarking the Service field should protect themselves by remarking the
corresponding field where appropriate, probably deploying remarking corresponding field where appropriate, probably deploying remarking
boundary nodes. Nevertheless, care must be taken so that packets boundary nodes. Nevertheless, care must be taken so that packets
received with an unrecognized DSCP do not cause the handling system received with an unrecognized DSCP do not cause the handling system
to malfunction. to malfunction.
3.3.2.2. Explicit Congestion Notification (ECN) 3.3.2.2. Explicit Congestion Notification (ECN)
RFC 3168 [RFC3168] specifies a mechanism for routers to signal RFC 3168 [RFC3168] specifies a mechanism for routers to signal
congestion to hosts exchanging IP packets, by marking the offending congestion to hosts exchanging IP packets, by marking the offending
packets, rather than discarding them. RFC 3168 defines the ECN packets rather than discarding them. RFC 3168 defines the ECN field,
field, which utilizes the CU field defined in RFC 2474 [RFC2474]. which utilizes the CU field defined in RFC 2474 [RFC2474]. Figure 4
Figure 4 shows the current syntax of the IP Type of Service field, shows the current syntax of the IP Type of Service field, with the
with the DSCP field used for Differentiated Services and the ECN DSCP field used for Differentiated Services and the ECN field.
field.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD | | DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 4: The Differentiated Services and ECN fields in IP Figure 4: The Differentiated Services and ECN Fields in IP
As such, the ECN field defines four codepoints: As such, the ECN field defines four codepoints:
+-----------+-----------+ +-----------+-----------+
| ECN field | Codepoint | | ECN field | Codepoint |
+-----------+-----------+ +-----------+-----------+
| 00 | Not-ECT | | 00 | Not-ECT |
+-----------+-----------+ +-----------+-----------+
| 01 | ECT(1) | | 01 | ECT(1) |
+-----------+-----------+ +-----------+-----------+
| 10 | ECT(0) | | 10 | ECT(0) |
+-----------+-----------+ +-----------+-----------+
| 11 | CE | | 11 | CE |
+-----------+-----------+ +-----------+-----------+
Table 3: ECN codepoints Table 3: ECN Codepoints
ECN is an end-to-end transport protocol mechanism based on ECN is an end-to-end transport protocol mechanism based on
notifications by routers through which a packet flow passes. To notifications by routers through which a packet flow passes. To
allow this interaction to happen on the fast path of routers, the ECN allow this interaction to happen on the fast path of routers, the ECN
field is located at a fixed location in the IP header. However, its field is located at a fixed location in the IP header. However, its
use must be negotiated at the transport layer, and the accumulated use must be negotiated at the transport layer, and the accumulated
congestion notifications must be communicated back to the sending congestion notifications must be communicated back to the sending
node using transport protocol means. Thus, ECN support must be node using transport protocol means. Thus, ECN support must be
specified per transport protocol. specified per transport protocol.
[RFC6040] specifies how the explicit congestion notification (ECN) [RFC6040] specifies how the Explicit Congestion Notification (ECN)
field of the IP header should be constructed on entry to and exit field of the IP header should be constructed on entry to and exit
from any IP-in-IP tunnel. from any IP-in-IP tunnel.
The security implications of ECN are discussed in detail in a number The security implications of ECN are discussed in detail in a number
of Sections of RFC 3168. Of the possible threats discussed in the of Sections of RFC 3168. Of the possible threats discussed in the
ECN specification, we believe that one that can be easily exploited ECN specification, we believe that one that can be easily exploited
is that of a host falsely indicating ECN-Capability. is that of a host falsely indicating ECN-Capability.
An attacker could set the ECT codepoint in the packets it sends, to An attacker could set the ECT codepoint in the packets it sends, to
signal the network that the endpoints of the transport protocol are signal the network that the endpoints of the transport protocol are
ECN-capable. Consequently, when experiencing moderate congestion, ECN-capable. Consequently, when experiencing moderate congestion,
routers using active queue management based on RED would mark the routers using active queue management based on Random Early Detection
packets (with the CE codepoint) rather than discard them. In this (RED) would mark the packets (with the CE codepoint) rather than
same scenario, packets of competing flows that do not have the ECT discard them. In this same scenario, packets of competing flows that
codepoint set would be dropped. Therefore, an attacker would get do not have the ECT codepoint set would be dropped. Therefore, an
better network service than the competing flows. attacker would get better network service than the competing flows.
However, if this moderate congestion turned into heavy congestion, However, if this moderate congestion turned into heavy congestion,
routers should switch to drop packets, regardless of whether the routers should switch to drop packets, regardless of whether or not
packets have the ECT codepoint set or not. the packets have the ECT codepoint set.
A number of other threats could arise if an attacker was a man in the 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 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, to the destination host). For a detailed discussion of those cases,
we urge the reader to consult Section 16 of RFC 3168. we urge the reader to consult Section 16 of RFC 3168.
There also is ongoing work in the research community and the IETF to There is also ongoing work in the research community and the IETF to
define alternate semantics for the CU / ECN field of IP TOS octet define alternate semantics for the CU/ECN field of IP TOS octet (see
(see [RFC5559], [RFC5670], and [RFC5696]). The application of these [RFC5559], [RFC5670], and [RFC5696]). The application of these
methods must be confined to tightly administered domains, and on exit methods must be confined to tightly administered domains, and on exit
from such domains, all packets need to be (re-)marked with ECN from such domains, all packets need to be (re-)marked with ECN
semantics. semantics.
3.4. Total Length 3.4. Total Length
The Total Length field is the length of the datagram, measured in 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- bytes, including both the IP header and the IP payload. Being a
bit field, it allows for datagrams of up to 65535 bytes. RFC 791 16-bit field, it allows for datagrams of up to 65535 bytes. RFC 791
[RFC0791] states that all hosts should be prepared to receive [RFC0791] states that all hosts should be prepared to receive
datagrams of up to 576 bytes (whether they arrive as a whole, or in datagrams of up to 576 bytes (whether they arrive as a whole, or in
fragments). However, most modern implementations can reassemble fragments). However, most modern implementations can reassemble
datagrams of at least 9 Kbytes. datagrams of at least 9 Kbytes.
Usually, a host will not send to a remote peer an IP datagram larger 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 than 576 bytes, unless it is explicitly signaled that the remote peer
is able to receive such "large" datagrams (for example, by means of is able to receive such "large" datagrams (for example, by means of
TCP's MSS option). However, systems should assume that they may TCP's Maximum Segment Size (MSS) option). However, systems should
receive datagrams larger than 576 bytes, regardless of whether they assume that they may receive datagrams larger than 576 bytes,
signal their remote peers to do so or not. In fact, it is common for regardless of whether or not they signal their remote peers to do so.
NFS [RFC3530] implementations to send datagrams larger than 576 In fact, it is common for Network File System (NFS) [RFC3530]
bytes, even without explicit signaling that the destination system implementations to send datagrams larger than 576 bytes, even without
can receive such "large" datagram. explicit signaling that the destination system can receive such
"large" datagram.
Additionally, see the discussion in Section 4.1 ("Fragment Additionally, see the discussion in Section 4.1 ("Fragment
reassembly") regarding the possible packet sizes resulting from Reassembly") regarding the possible packet sizes resulting from
fragment reassembly. fragment reassembly.
Implementations should be aware that the IP module could be handed a Implementations should be aware that the IP module could be handed a
packet larger than the value actually contained in the Total Length packet larger than the value actually contained in the Total Length
field. Such a difference usually has to do with legitimate padding 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 bytes at the link-layer protocol, but it could also be the result of
malicious activity by an attacker. Furthermore, even when the malicious activity by an attacker. Furthermore, even when the
maximum length of an IP datagram is 65535 bytes, if the link-layer maximum length of an IP datagram is 65535 bytes, if the link-layer
technology in use allows for payloads larger than 65535 bytes, an technology in use allows for payloads larger than 65535 bytes, an
attacker could forge such a large link-layer packet, meaning it for 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 the IP module. If the IP module of the receiving system were not
prepared to handle such an oversized link-layer payload, an prepared to handle such an oversized link-layer payload, an
unexpected failure might occur. Therefore, the memory buffer used by unexpected failure might occur. Therefore, the memory buffer used by
the IP module to store the link-layer payload should be allocated the IP module to store the link-layer payload should be allocated
according to the payload size reported by the link-layer, rather than according to the payload size reported by the link layer, rather than
according to the Total Length field of the IP packet it contains. according to the Total Length field of the IP packet it contains.
The IP module could also be handed a packet that is smaller than the The IP module could also be handed a packet that is smaller than the
actual IP packet size claimed by the Total Length field. This could actual IP packet size claimed by the Total Length field. This could
be used, for example, to produce an information leakage. Therefore, be used, for example, to produce an information leakage. Therefore,
the following check should be performed: the following check should be performed:
LinkLayer.PayloadSize >= Total Length LinkLayer.PayloadSize >= Total Length
If this check fails, the IP packet should be dropped, and this event 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 should be logged (e.g., a counter could be incremented reflecting the
packet drop). As the previous expression implies, the number of packet drop). As the previous expression implies, the number of
bytes passed by the link-layer to the IP module should contain at 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 least as many bytes as claimed by the Total Length field of the IP
header. header.
[US-CERT2002] is an example of the exploitation of a forged IP [US-CERT2002] is an example of the exploitation of a forged IP
Total Length field to produce an information leakage attack. Total Length field to produce an information leakage attack.
3.5. Identification (ID) 3.5. Identification (ID)
The Identification field is set by the sending host to aid in the The Identification field is set by the sending host to aid in the
reassembly of fragmented datagrams. At any time, it needs to be reassembly of fragmented datagrams. At any time, it needs to be
skipping to change at page 16, line 50 skipping to change at page 16, line 18
they send. they send.
This implementation strategy is inappropriate for a number of This implementation strategy is inappropriate for a number of
reasons. Firstly, if the Identification field is set on a protocol- reasons. Firstly, if the Identification field is set on a protocol-
independent basis, it will wrap more often than necessary, and thus independent basis, it will wrap more often than necessary, and thus
the implementation will be more prone to the problems discussed in the implementation will be more prone to the problems discussed in
[Kent1987] and [RFC4963]. Secondly, this implementation strategy [Kent1987] and [RFC4963]. Secondly, this implementation strategy
opens the door to an information leakage that can be exploited in a opens the door to an information leakage that can be exploited in a
number of ways. number of ways.
[Sanfilippo1998a] examined to determine the packet rate at which a [Sanfilippo1998a] describes how the Identification field can be
given system is transmitting information. Later, [Sanfilippo1998b] leveraged to determine the packet rate at which a given system is
described how a system with such an implementation can be used to transmitting information. Later, [Sanfilippo1998b] described how a
perform a stealth port scan to a third (victim) host. system with such an implementation can be used to perform a stealth
[Sanfilippo1999] explained how to exploit this implementation port scan to a third (victim) host. [Sanfilippo1999] explained how
strategy to uncover the rules of a number of firewalls. to exploit this implementation strategy to uncover the rules of a
[Bellovin2002] explains how the IP Identification field can be number of firewalls. [Bellovin2002] explains how the IP
exploited to count the number of systems behind a NAT. [Fyodor2004] Identification field can be exploited to count the number of systems
is an entire paper on most (if not all) the ways to exploit the behind a NAT. [Fyodor2004] is an entire paper on most (if not all)
information provided by the Identification field of the IP header. of the ways to exploit the information provided by the Identification
field of the IP header.
Section 4.1 contains a discussion of the security implications of Section 4.1 contains a discussion of the security implications of
the IP fragment reassembly mechanism, which is the primary the IP fragment reassembly mechanism, which is the primary
"consumer" of this field. "consumer" of this field.
3.5.1. Some Workarounds Implemented by the Industry 3.5.1. Some Workarounds Implemented by the Industry
As the IP Identification field is only used for the reassembly of As the IP Identification field is only used for the reassembly of
datagrams, some operating systems (such as Linux) decided to set this 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 field to 0 in all packets that have the DF bit set. This would, in
skipping to change at page 17, line 34 skipping to change at page 17, line 5
even if they had the DF bit set. In such a scenario, all datagrams 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 originally sent with the DF bit set would all result in fragments
with an Identification field of 0, which would lead to problems with an Identification field of 0, which would lead to problems
("collision" of the Identification number) in the reassembly process. ("collision" of the Identification number) in the reassembly process.
Linux (and Solaris) later set the IP Identification field on a per- Linux (and Solaris) later set the IP Identification field on a per-
IP-address basis. This avoids some of the security implications of IP-address basis. This avoids some of the security implications of
the IP Identification field, but not all. For example, systems the IP Identification field, but not all. For example, systems
behind a load balancer can still be counted. behind a load balancer can still be counted.
3.5.2. Possible security improvements 3.5.2. Possible Security Improvements
Contrary to common wisdom, the IP Identification field does not need 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 to be system-wide unique for each packet, but has to be unique for
each {Source Address, Destination Address, Protocol} tuple. each {Source Address, Destination Address, Protocol} tuple.
For instance, the TCP specification defines a generic send() For instance, the TCP specification defines a generic send()
function which takes the IP ID as one of its arguments. function that takes the IP ID as one of its arguments.
We provide an analysis of the possible security improvements that We provide an analysis of the possible security improvements that
could be implemented, based on whether the protocol using the could be implemented, based on whether the protocol using the
services of IP is connection-oriented or connection-less. services of IP is connection-oriented or connection-less.
3.5.2.1. Connection-Oriented Transport Protocols 3.5.2.1. Connection-Oriented Transport Protocols
To avoid the security implications of the information leakage To avoid the security implications of the information leakage
described above, a pseudo-random number generator (PRNG) could be described above, a pseudo-random number generator (PRNG) could be
used to set the IP Identification field on a {Source Address, used to set the IP Identification field on a {Source Address,
Destination Address} basis (for each connection-oriented transport Destination Address} basis (for each connection-oriented transport
protocol). protocol).
[RFC4086] provides advice on the generation of pseudo-random [RFC4086] provides advice on the generation of pseudo-random
numbers. numbers.
[Klein2007] is a security advisory that describes a weakness in [Klein2007] is a security advisory that describes a weakness in
the pseudo random number generator (PRNG) in use for the the pseudo-random number generator (PRNG) employed for the
generation of the IP Identification by a number of operating generation of the IP Identification by a number of operating
systems. systems.
While in theory a pseudo-random number generator could lead to While in theory a pseudo-random number generator could lead to
scenarios in which a given Identification number is used more than scenarios in which a given Identification number is used more than
once in the same time-span for datagrams that end up getting once in the same time span for datagrams that end up getting
fragmented (with the corresponding potential reassembly problems), in fragmented (with the corresponding potential reassembly problems), in
practice this is unlikely to cause trouble. practice, this is unlikely to cause trouble.
By default, most implementations of connection-oriented protocols, By default, most implementations of connection-oriented protocols,
such as TCP, implement some mechanism for avoiding fragmentation such as TCP, implement some mechanism for avoiding fragmentation
(such as the Path-MTU Discovery mechanism described in [RFC1191]). (such as the Path-MTU Discovery mechanism described in [RFC1191]).
Thus, fragmentation will only take place if a non-RFC-compliant Thus, fragmentation will only take place if a non-RFC-compliant
middle-box that still fragments packets even when the DF bit is set middle-box that still fragments packets even when the DF bit is set
is placed somewhere along the path that the packets travel to get to is placed somewhere along the path that the packets travel to get to
the destination host. Once the sending system is signaled by the the destination host. Once the sending system is signaled by the
middle-box (by means of an ICMP "fragmentation needed and DF bit set" middle-box (by means of an ICMP "fragmentation needed and DF bit set"
error message) that it should reduce the size of the packets it error message) that it should reduce the size of the packets it
skipping to change at page 19, line 42 skipping to change at page 19, line 12
data block (as is the case in corruption arising from collision of IP data block (as is the case in corruption arising from collision of IP
Identification numbers). Identification numbers).
In the case of UDP, unfortunately some systems have been known to In the case of UDP, unfortunately some systems have been known to
not enable the UDP checksum by default. For most applications, not enable the UDP checksum by default. For most applications,
packets containing errors should be dropped by the transport layer packets containing errors should be dropped by the transport layer
and not delivered to the application. A small number of and not delivered to the application. A small number of
applications may benefit from disabling the checksum; for example, applications may benefit from disabling the checksum; for example,
streaming media where it is desired to avoid dropping a complete streaming media where it is desired to avoid dropping a complete
sample for a single-bit error, and UDP tunneling applications sample for a single-bit error, and UDP tunneling applications
where the payload (i.e. the inner packet) is protected by its own where the payload (i.e., the inner packet) is protected by its own
transport checksum or other error detection mechanism. transport checksum or other error detection mechanism.
In general, if IP Identification number collisions become an issue In general, if IP Identification number collisions become an issue
for the application using the connection-less protocol, the for the application using the connection-less protocol, the
application designers should consider using a different transport application designers should consider using a different transport
protocol (which hopefully avoids fragmentation). protocol (which hopefully avoids fragmentation).
It must be noted that an attacker could intentionally exploit It must be noted that an attacker could intentionally exploit
collisions of IP Identification numbers to perform a Denial-of- collisions of IP Identification numbers to perform a DoS attack, by
Service attack, by sending forged fragments that would cause the sending forged fragments that would cause the reassembly process to
reassembly process to result in a corrupt datagram that would either result in a corrupt datagram that either would be dropped by the
be dropped by the transport protocol, or would incorrectly be handed transport protocol or would incorrectly be handed to the
to the corresponding application. This issue is discussed in detail corresponding application. This issue is discussed in detail in
in section 4.1 ("Fragment Reassembly"). Section 4.1 ("Fragment Reassembly").
3.6. Flags 3.6. Flags
The IP header contains 3 control bits, two of which are currently The IP header contains 3 control bits, two of which are currently
used for the fragmentation and reassembly function. used for the fragmentation and reassembly function.
As described by RFC 791, their meaning is: As described by RFC 791, their meaning is:
o Bit 0: reserved, must be zero (i.e., reserved for future o Bit 0: reserved, must be zero (i.e., reserved for future
standardization) standardization)
o Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment o Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment
o Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments o Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments
The DF bit is usually set to implement the Path-MTU Discovery (PMTUD) The DF bit is usually set to implement the Path-MTU Discovery (PMTUD)
mechanism described in [RFC1191]. However, it can also be exploited mechanism described in [RFC1191]. However, it can also be exploited
by an attacker to evade Network Intrusion Detection Systems. An by an attacker to evade Network Intrusion Detection Systems. An
attacker could send a packet with the DF bit set to a system attacker could send a packet with the DF bit set to a system
monitored by a Network Intrusion Detection System (NIDS), and monitored by a NIDS, and depending on the Path-MTU to the intended
depending on the Path-MTU to the intended recipient, the packet might recipient, the packet might be dropped by some intervening router
be dropped by some intervening router (because of being too big to be (because of being too big to be forwarded without fragmentation),
forwarded without fragmentation), without the NIDS being aware of it. without the NIDS being aware of it.
+---+ +---+
| H | | H |
+---+ Victim host +---+ Victim host
| |
Router A | MTU=1500 Router A | MTU=1500
| |
+---+ +---+ +---+ +---+ +---+ +---+
| R |-----| R |---------| R | | R |-----| R |---------| R |
+---+ +---+ +---+ +---+ +---+ +---+
skipping to change at page 21, line 29 skipping to change at page 20, line 29
NIDS Sensor | NIDS Sensor |
| |
_ ___/---\______ Attacker _ ___/---\______ Attacker
/ \_/ \_ +---+ / \_/ \_ +---+
/ Internet |---------| H | / Internet |---------| H |
\_ __/ +---+ \_ __/ +---+
\__ __ ___/ <------ \__ __ ___/ <------
\___/ \__/ 17914-byte packet \___/ \__/ 17914-byte packet
DF bit set DF bit set
Figure 5: NIDS evasion by means of the Internet Protocol DF bit Figure 5: NIDS Evasion by Means of the Internet Protocol DF Bit
In Figure 3, an attacker sends a 17914-byte datagram meant for the In Figure 3, an attacker sends a 17914-byte datagram meant for the
victim host in the same figure. The attacker's packet probably victim host in the same figure. The attacker's packet probably
contains an overlapping IP fragment or an overlapping TCP segment, contains an overlapping IP fragment or an overlapping TCP segment,
aiming at "confusing" the NIDS, as described in [Ptacek1998]. The aiming at "confusing" the NIDS, as described in [Ptacek1998]. The
packet is screened by the NIDS sensor at the network perimeter, which packet is screened by the NIDS sensor at the network perimeter, which
probably reassembles IP fragments and TCP segments for the purpose of probably reassembles IP fragments and TCP segments for the purpose of
assessing the data transferred to and from the monitored systems. assessing the data transferred to and from the monitored systems.
However, as the attacker's packet should transit a link with an MTU However, as the attacker's packet should transit a link with an MTU
smaller than 17914 bytes (1500 bytes in this example), the router smaller than 17914 bytes (1500 bytes in this example), the router
skipping to change at page 22, line 6 skipping to change at page 21, line 6
screened packet never reached the intended destination, and thus get screened packet never reached the intended destination, and thus get
an incorrect picture of the data being transferred to the monitored an incorrect picture of the data being transferred to the monitored
systems. systems.
[Shankar2003] introduces a technique named "Active Mapping" that [Shankar2003] introduces a technique named "Active Mapping" that
prevents evasion of a NIDS by acquiring sufficient knowledge about prevents evasion of a NIDS by acquiring sufficient knowledge about
the network being monitored, to assess which packets will arrive the network being monitored, to assess which packets will arrive
at the intended recipient, and how they will be interpreted by it. 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 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 Fragments) and the DF (Don't Fragment) bits set. While in principle
such a packet might seem nonsensical, there are a number of reasons 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 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 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 processing a packet that was too large to be forwarded without
fragmentation. Instead of simply dropping the corresponding packet fragmentation. Instead of simply dropping the corresponding packet
and sending an ICMP error message to the source host, some middle- and sending an ICMP error message to the source host, some middle-
boxes fragment the packet (copying the DF bit to each fragment), and boxes fragment the packet (copying the DF bit to each fragment), and
also send an ICMP error message to the originating system. Second, also send an ICMP error message to the originating system. Second,
some systems (notably Linux) set both the MF and the DF bits to some systems (notably Linux) set both the MF and the DF bits to
implement Path-MTU Discovery (PMTUD) for UDP. These scenarios should implement Path-MTU Discovery (PMTUD) for UDP. These scenarios should
be taken into account when configuring firewalls and/or tuning be taken into account when configuring firewalls and/or tuning NIDSs.
Network Intrusion Detection Systems (NIDS).
Section 4.1 contains a discussion of the security implications of the Section 4.1 contains a discussion of the security implications of the
IP fragment reassembly mechanism. IP fragment reassembly mechanism.
3.7. Fragment Offset 3.7. Fragment Offset
The Fragment Offset is used for the fragmentation and reassembly of The Fragment Offset is used for the fragmentation and reassembly of
IP datagrams. It indicates where in the original datagram payload IP datagrams. It indicates where in the original datagram payload
the payload of the fragment belongs, and is measured in units of the payload of the fragment belongs, and is measured in units of
eight bytes. As a consequence, all fragments (except the last one), eight bytes. As a consequence, all fragments (except the last one),
skipping to change at page 23, line 39 skipping to change at page 22, line 39
and a Total Length of 65535. Assuming an IHL of 5 (i.e., a header 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 + length of 20 bytes), the reassembled datagram would be 65532 +
(65535 - 20) = 131047 bytes. (65535 - 20) = 131047 bytes.
Additionally, the IP module should implement all the necessary Additionally, the IP module should implement all the necessary
measures to be able to handle such illegitimate reassembled measures to be able to handle such illegitimate reassembled
datagrams, so as to avoid them from overflowing the buffer(s) used datagrams, so as to avoid them from overflowing the buffer(s) used
for the reassembly function. for the reassembly function.
[CERT1996c] and [Kenney1996] describe the exploitation of this [CERT1996c] and [Kenney1996] describe the exploitation of this
issue to perform a Denial-of-Service (DoS) attack. issue to perform a DoS attack.
Section 4.1 contains a discussion of the security implications of the Section 4.1 contains a discussion of the security implications of the
IP fragment reassembly mechanism. IP fragment reassembly mechanism.
3.8. Time to Live (TTL) 3.8. Time to Live (TTL)
The Time to Live (TTL) field has two functions: to bound the lifetime The Time to Live (TTL) field has two functions: to bound the lifetime
of the upper-layer packets (e.g., TCP segments) and to prevent of the upper-layer packets (e.g., TCP segments) and to prevent
packets from looping indefinitely in the network. packets from looping indefinitely in the network.
Originally, this field was meant to indicate the maximum time a Originally, this field was meant to indicate the maximum time a
datagram was allowed to remain in the internet system, in units of datagram was allowed to remain in the Internet system, in units of
seconds. As every internet module that processes a datagram must seconds. As every Internet module that processes a datagram must
decrement the TTL by at least one, the original definition of the TTL decrement the TTL by at least one, the original definition of the TTL
field became obsolete, and in practice it is interpreted as a hop field became obsolete, and in practice it is interpreted as a hop
count (see Section 5.3.1 of [RFC1812]). count (see Section 5.3.1 of [RFC1812]).
Most systems allow the administrator to configure the TTL to be used Most systems allow the administrator to configure the TTL to be used
for the packets they originate, with the default value usually being for the packets they originate, with the default value usually being
a power of 2, or 255 (see e.g. [Arkin2000]). The recommended value a power of 2, or 255 (e.g., see [Arkin2000]). The recommended value
for the TTL field, as specified by the IANA is 64 [IANA2006b]. This for the TTL field, as specified by the IANA is 64 [IANA_IP_PARAM].
value reflects the assumed "diameter" of the Internet, plus a margin This value reflects the assumed "diameter" of the Internet, plus a
to accommodate its growth. margin to accommodate its growth.
The TTL field has a number of properties that are interesting from a 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 security point of view. Given that the default value used for the
TTL is usually either a power of two, or 255, chances are that unless TTL is usually either a power of two, or 255, chances are that unless
the originating system has been explicitly tuned to use a non-default 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 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 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 received with a TTL of 120, chances are that the original packet had
a TTL of 128. a TTL of 128.
skipping to change at page 25, line 5 skipping to change at page 24, line 5
o Evading Network Intrusion Detection Systems. o Evading Network Intrusion Detection Systems.
However, it can also be used to perform important functions such as: However, it can also be used to perform important functions such as:
o Improving the security of applications that make use of the o Improving the security of applications that make use of the
Internet Protocol (IP). Internet Protocol (IP).
o Limiting spread of packets. o Limiting spread of packets.
3.8.1. Fingerprinting the operating system in use by the source host 3.8.1. Fingerprinting the Operating System in Use by the Source Host
Different operating systems use a different default TTL for the Different operating systems use a different default TTL for the
packets they send. Thus, asserting the TTL with which a packet was packets they send. Thus, asserting the TTL with which a packet was
originally sent will help heuristics to reduce the number of possible originally sent will help heuristics to reduce the number of possible
operating systems in use by the source host. It should be noted that operating systems in use by the source host. It should be noted that
since most systems use only a handful of different default values, since most systems use only a handful of different default values,
the granularity of OS fingerprinting that this technique provides is the granularity of OS fingerprinting that this technique provides is
negligible. Additionally, these defaults may be configurable negligible. Additionally, these defaults may be configurable
(system-wide or per protocol), and managed systems may employ such (system-wide or per protocol), and managed systems may employ such
opportunities for operational purposes and to defeat the capability opportunities for operational purposes and to defeat the capability
of fingerprinting heuristics. of fingerprinting heuristics.
3.8.2. Fingerprinting the physical device from which the packets 3.8.2. Fingerprinting the Physical Device from which the Packets
originate Originate
When several systems are behind a middle-box such as a NAT or a load 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 balancer, the TTL may help to count the number of systems behind the
middle-box. If each of the systems behind the middle-box uses a middle-box. If each of the systems behind the middle-box uses a
different default TTL value for the packets it sends, or each system different default TTL value for the packets it sends, or each system
is located at different distances in the network topology, an is located at different distances in the network topology, an
attacker could stimulate responses from the devices being attacker could stimulate responses from the devices being
fingerprinted, and responses that arrive with different TTL values fingerprinted, and responses that arrive with different TTL values
could be assumed to come from a different devices. could be assumed to come from a different devices.
skipping to change at page 26, line 5 skipping to change at page 25, line 5
3.8.3. Mapping the Network Topology 3.8.3. Mapping the Network Topology
An originating host may set the TTL field of the packets it sends to An originating host may set the TTL field of the packets it sends to
progressively increasing values in order to elicit an ICMP error progressively increasing values in order to elicit an ICMP error
message from the routers that decrement the TTL of each packet to message from the routers that decrement the TTL of each packet to
zero, and thereby determine the IP addresses of the routers on the zero, and thereby determine the IP addresses of the routers on the
path to the packet's destination. This procedure has been path to the packet's destination. This procedure has been
traditionally employed by the traceroute tool. traditionally employed by the traceroute tool.
3.8.4. Locating the source host in the network topology 3.8.4. Locating the Source Host in the Network Topology
The TTL field may also be used to locate the source system in the The TTL field may also be used to locate the source system in the
network topology [Northcutt2000]. network topology [Northcutt2000].
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| A |-----| R |------| R |----| R |-----| R | | A |-----| R |------| R |----| R |-----| R |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
/ | / \ / | / \
/ | / \ / | / \
/ | / +---+ / | / +---+
skipping to change at page 26, line 32 skipping to change at page 25, line 32
+---+ +---+ +---+ \ +---| +---+ +---+ +---+ \ +---|
| R |----------| R |-- \ | R |----------| R |-- \
+---+ +---+ \ \ +---+ +---+ \ \
| \ / \ +---+| +---+ | \ / \ +---+| +---+
| \ / ----| R |------| R | | \ / ----| R |------| R |
| \ / +---+ +---+ | \ / +---+ +---+
+---+ \ +---+ +---+ +---+ \ +---+ +---+
| B | \| R |----| C | | B | \| R |----| C |
+---+ +---+ +---+ +---+ +---+ +---+
Figure 6: Tracking a host by means of the TTL field Figure 6: Tracking a Host by Means of the TTL Field
Consider network topology of Figure 6. Assuming that an attacker Consider network topology of Figure 6. Assuming that an attacker
("F" in the figure) is performing some type of attack that requires ("F" in the figure) is performing some type of attack that requires
forging the Source Address (such as for a TCP-based DoS reflection forging the Source Address (such as for a TCP-based DoS reflection
attack), and some of the involved hosts are willing to cooperate to attack), and some of the involved hosts are willing to cooperate to
locate the attacking system. locate the attacking system.
Assuming that: Assuming that:
o All the packets A gets have a TTL of 61. o All the packets A gets have a TTL of 61.
skipping to change at page 28, line 5 skipping to change at page 27, line 5
Systems. Depending on the position of a sensor relative to the Systems. Depending on the position of a sensor relative to the
destination host of the examined packet, the NIDS may get a different destination host of the examined packet, the NIDS may get a different
picture from that of the intended destination system. As an example, picture from that of the intended destination system. As an example,
a sensor may process a packet that will expire before getting to the a sensor may process a packet that will expire before getting to the
destination host. A general countermeasure for this type of attack destination host. A general countermeasure for this type of attack
is to normalize the traffic that gets to an organizational network. is to normalize the traffic that gets to an organizational network.
Examples of such traffic normalization can be found in [Paxson2001]. Examples of such traffic normalization can be found in [Paxson2001].
OpenBSD Packet Filter is an example of a packet filter that includes OpenBSD Packet Filter is an example of a packet filter that includes
TTL-normalization functionality [OpenBSD-PF] TTL-normalization functionality [OpenBSD-PF]
3.8.6. Improving the security of applications that make use of the 3.8.6. Improving the Security of Applications That Make Use of the
Internet Protocol (IP) Internet Protocol (IP)
In some scenarios, the TTL field can be also used to improve the In some scenarios, the TTL field can be also used to improve the
security of an application, by restricting the hosts that can security of an application, by restricting the hosts that can
communicate with the given application [RFC5082]. For example, there communicate with the given application [RFC5082]. For example, there
are applications for which the communicating systems are typically in are applications for which the communicating systems are typically in
the same network segment (i.e., there are no intervening routers). the same network segment (i.e., there are no intervening routers).
Such an application is the BGP (Border Gateway Protocol) utilized by Such an application is the BGP (Border Gateway Protocol) utilized by
two peer routers (usually on a shared link medium). two peer routers (usually on a shared link medium).
skipping to change at page 28, line 40 skipping to change at page 27, line 40
The TTL field can be used in a similar way in scenarios in which the The TTL field can be used in a similar way in scenarios in which the
cooperating systems are not in the same network segment (i.e., multi- cooperating systems are not in the same network segment (i.e., multi-
hop peering). In that case, the following check could be enforced: hop peering). In that case, the following check could be enforced:
TTL >= 255 - DeltaHops TTL >= 255 - DeltaHops
This means that the set of hosts from which packets will be accepted 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 for the protected application will be reduced to those that are no
more than DeltaHops away. While for obvious reasons the level of more than DeltaHops away. While for obvious reasons the level of
protection will be smaller than in the case of directly-connected protection will be smaller than in the case of directly connected
peers, the use of the TTL field for protecting multi-hop peering peers, the use of the TTL field for protecting multi-hop peering
still reduces the set of hosts that could potentially perform a still reduces the set of hosts that could potentially perform a
number of attacks against the protected application. number of attacks against the protected application.
This use of the TTL field has been officially documented by the IETF This use of the TTL field has been officially documented by the IETF
under the name "Generalized TTL Security Mechanism" (GTSM) in under the name "Generalized TTL Security Mechanism" (GTSM) in
[RFC5082]. [RFC5082].
Some protocol scrubbers enforce a minimum value for the TTL field of Some protocol scrubbers enforce a minimum value for the TTL field of
the packets they forward. It must be understood that depending on the packets they forward. It must be understood that depending on
the minimum TTL being enforced, and depending on the particular the minimum TTL being enforced, and depending on the particular
network setup, the protocol scrubber may actually help attackers to network setup, the protocol scrubber may actually help attackers to
fool the GTSM, by "raising" the TTL of the attacking packets. fool the GTSM, by "raising" the TTL of the attacking packets.
3.8.7. Limiting spread 3.8.7. Limiting Spread
The originating host sets the TTL field to a small value (frequently The originating host sets the TTL field to a small value (frequently
1, for link-scope services) in order to artifically limit the 1, for link-scope services) in order to artificially limit the
(topological) distance the packet is allowed to travel. This is (topological) distance the packet is allowed to travel. This is
suggested in Section 4.2.2.9 of RFC 1812 [RFC1812]. Further suggested in Section 4.2.2.9 of RFC 1812 [RFC1812]. Further
discussion of this technique can be found in in RFC 1112 [RFC1112]. discussion of this technique can be found in RFC 1112 [RFC1112].
3.9. Protocol 3.9. Protocol
The Protocol field indicates the protocol encapsulated in the The Protocol field indicates the protocol encapsulated in the
internet datagram. The Protocol field may not only contain a value Internet datagram. The Protocol field may not only contain a value
corresponding to a protocol implemented by the system processing the corresponding to a protocol implemented by the system processing the
packet, but also a value corresponding to a protocol not implemented, packet, but also a value corresponding to a protocol not implemented,
or even a value not yet assigned by the IANA [IANA2006c]. or even a value not yet assigned by the IANA [IANA_PROT_NUM].
While in theory there should not be security implications from the While in theory there should not be security implications from the
use of any value in the protocol field, there have been security use of any value in the protocol field, there have been security
issues in the past with systems that had problems when handling issues in the past with systems that had problems when handling
packets with some specific protocol numbers [Cisco2003] [CERT2003]. packets with some specific protocol numbers [Cisco2003] [CERT2003].
A host (i.e., end-system) that receives an IP packet encapsulating a A host (i.e., end-system) that receives an IP packet encapsulating a
Protocol it does not support should drop the corresponding packet, Protocol it does not support should drop the corresponding packet,
log the event, and possibly send an ICMP Protocol Unreachable (type log the event, and possibly send an ICMP Protocol Unreachable (type
3, code 2) error message. 3, code 2) error message.
3.10. Header Checksum 3.10. Header Checksum
The Header Checksum field is an error detection mechanism meant to The Header Checksum field is an error-detection mechanism meant to
detect errors in the IP header. While in principle there should not detect errors in the IP header. While in principle there should not
be security implications arising from this field, it should be noted be security implications arising from this field, it should be noted
that due to non-RFC-compliant implementations, the Header Checksum that due to non-RFC-compliant implementations, the Header Checksum
might be exploited to detect firewalls and/or evade network intrusion might be exploited to detect firewalls and/or evade NIDSs.
detection systems (NIDS).
[Ed3f2002] describes the exploitation of the TCP checksum for [Ed3f2002] describes the exploitation of the TCP checksum for
performing such actions. As there are internet routers known to not performing such actions. As there are Internet routers known to not
check the IP Header Checksum, and there might also be middle-boxes check the IP Header Checksum, and there might also be middle-boxes
(NATs, firewalls, etc.) not checking the IP checksum allegedly due to (NATs, firewalls, etc.) not checking the IP checksum allegedly due to
performance reasons, similar malicious activity to the one described performance reasons, similar malicious activity to the one described
in [Ed3f2002] might be performed with the IP checksum. in [Ed3f2002] might be performed with the IP checksum.
3.11. Source Address 3.11. Source Address
The Source Address of an IP datagram identifies the node from which The Source Address of an IP datagram identifies the node from which
the packet originated. the packet originated.
Strictly speaking, the Source Address of an IP datagram identifies Strictly speaking, the Source Address of an IP datagram identifies
the interface of the sending system from which the packet was the interface of the sending system from which the packet was
sent, (rather than the originating "system"), as in the Internet sent, (rather than the originating "system"), as in the Internet
Architecture there's no concept of "node address". Architecture there's no concept of "node address".
Unfortunately, it is trivial to forge the Source Address of an Unfortunately, it is trivial to forge the Source Address of an
Internet datagram because of the apparent lack of consistent "egress Internet datagram because of the apparent lack of consistent "egress
filtering" near the edge of the network. This has been exploited in filtering" near the edge of the network. This has been exploited in
the past for performing a variety of DoS (Denial of Service) attacks the past for performing a variety of DoS attacks [NISCC2004]
[NISCC2004] [RFC4987] [CERT1996a] [CERT1996b] [CERT1998a], and to [RFC4987] [CERT1996a] [CERT1996b] [CERT1998a] and for impersonating
impersonate as other systems in scenarios in which authentication was other systems in scenarios in which authentication was based on the
based on the Source Address of the sending system [daemon91996]. Source Address of the sending system [daemon91996].
The extent to which these attacks can be successfully performed in The extent to which these attacks can be successfully performed in
the Internet can be reduced through deployment of ingress/egress the Internet can be reduced through deployment of ingress/egress
filtering in the internet routers. [NISCC2006] is a detailed guide filtering in the Internet routers. [NISCC2006] is a detailed guide
on ingress and egress filtering. [RFC2827] and [RFC3704] discuss on ingress and egress filtering. [RFC2827] and [RFC3704] discuss
ingress filtering. [GIAC2000] discusses egress filtering. ingress filtering. [GIAC2000] discusses egress filtering.
[SpooferProject] measures the Internet's susceptibility to forged [SpooferProject] measures the Internet's susceptibility to forged
Source Address IP packets. Source Address IP packets.
Even when the obvious field on which to perform checks for Even when the obvious field on which to perform checks for
ingress/egress filtering is the Source Address and Destination ingress/egress filtering is the Source Address and Destination
Address fields of the IP header, there are other occurrences of IP Address fields of the IP header, there are other occurrences of IP
addresses on which the same type of checks should be performed. addresses on which the same type of checks should be performed.
One example is the IP addresses contained in the payload of ICMP One example is the IP addresses contained in the payload of ICMP
error messages, as discussed in [RFC5927] and [Gont2006]. error messages, as discussed in [RFC5927] and [Gont2006].
There are a number of sanity checks that should be performed on the 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 Source Address of an IP datagram. Details can be found in
4.2 ("Addressing"). Section 4.3 ("Addressing").
Additionally, there exist freely available tools that allow Additionally, there exist freely available tools that allow
administrators to monitor which IP addresses are used with which MAC administrators to monitor which IP addresses are used with which MAC
addresses [LBNL2006]. This functionality is also included in many addresses [LBNL2006]. This functionality is also included in many
Network Intrusion Detection Systems (NIDS). NIDSs.
It is also very important to understand that authentication should It is also very important to understand that authentication should
never rely solely on the Source Address used by the communicating never rely solely on the Source Address used by the communicating
systems. systems.
3.12. Destination Address 3.12. Destination Address
The Destination Address of an IP datagram identifies the destination The Destination Address of an IP datagram identifies the destination
host to which the packet is meant to be delivered. host to which the packet is meant to be delivered.
Strictly speaking, the Destination Address of an IP datagram Strictly speaking, the Destination Address of an IP datagram
identifies the interface of the destination network interface, identifies the interface of the destination network interface,
rather than the destination "system", as in the Internet rather than the destination "system", as in the Internet
Architecture there's no concept of "node address". Architecture there's no concept of "node address".
There are a number of sanity checks that should be performed on the There are a number of sanity checks that should be performed on the
Destination Address of an IP datagram. Details can be found in Destination Address of an IP datagram. Details can be found in
Section 4.2 ("Addressing"). Section 4.3 ("Addressing").
3.13. Options 3.13. Options
According to RFC 791, IP options must be implemented by all IP According to RFC 791, IP options must be implemented by all IP
modules, both in hosts and gateways (i.e., end-systems and modules, both in hosts and gateways (i.e., end-systems and
intermediate-systems). This means that the general rules for intermediate-systems). This means that the general rules for
assembling, parsing, and processing of IP options must be assembling, parsing, and processing of IP options must be
implemented. RFC 791 defines a set of options that "must be implemented. RFC 791 defines a set of options that "must be
understood", but this set has been updated by RFC 1122 [RFC1122], RFC understood", but this set has been updated by RFC 1122 [RFC1122], RFC
1812 [RFC1812], and other documents. Section 3.13.2 of this document 1812 [RFC1812], and other documents. Section 3.13.2 of this document
skipping to change at page 31, line 42 skipping to change at page 30, line 47
There are two cases for the format of an option: There are two cases for the format of an option:
o Case 1: A single byte of option-type. o Case 1: A single byte of option-type.
o Case 2: An option-type byte, an option-length byte, and the actual o Case 2: An option-type byte, an option-length byte, and the actual
option-data bytes. option-data bytes.
In Case 2, the option-length byte counts the option-type byte and the In Case 2, the option-length byte counts the option-type byte and the
option-length byte, as well as the actual option-data bytes. option-length byte, as well as the actual option-data bytes.
All current and future options except "End of Option List" (Type = 0) All current and future options except End of Option List (Type = 0)
and "No Operation" (Type = 1), are of Class 2. and No Operation (Type = 1), are of Class 2.
The option-type has three fields: The option-type has three fields:
o 1 bit: copied flag. o 1 bit: copied flag.
o 2 bits: option class. o 2 bits: option class.
o 5 bits: option number. o 5 bits: option number.
This format allows for the creation of new options for the extension This format allows for the creation of new options for the extension
of the Internet Protocol (IP) and their transparent treatment on of the Internet Protocol (IP) and their transparent treatment on
intermediate systems that do not "understand" them, under direction intermediate-systems that do not "understand" them, under direction
of the first three functional parts. of the first three functional parts.
The copied flag indicates whether this option should be copied to all The copied flag indicates whether this option should be copied to all
fragments in the event the packet carrying it needs to be fragmented: fragments in the event the packet carrying it needs to be fragmented:
o 0 = not copied. o 0 = not copied.
o 1 = copied. o 1 = copied.
The values for the option class are: The values for the option class are:
skipping to change at page 32, line 30 skipping to change at page 31, line 34
o 1 = reserved for future use. o 1 = reserved for future use.
o 2 = debugging and measurement. o 2 = debugging and measurement.
o 3 = reserved for future use. o 3 = reserved for future use.
Finally, the option number identifies the syntax of the rest of the Finally, the option number identifies the syntax of the rest of the
option. option.
[IANA2006b] contains the list of the currently assigned IP option [IANA_IP_PARAM] contains the list of the currently assigned IP option
numbers. It should be noted that IP systems are required to ignore numbers. It should be noted that IP systems are required to ignore
those options they do not implement. those options they do not implement.
3.13.1. General issues with IP options 3.13.1. General Issues with IP Options
The following subsections discuss security issues that apply to all The following subsections discuss security issues that apply to all
IP options. The proposed checks should be performed in addition to IP options. The proposed checks should be performed in addition to
any option-specific checks proposed in the next sections. any option-specific checks proposed in the next sections.
3.13.1.1. Processing requirements 3.13.1.1. Processing Requirements
Router manufacturers tend to do IP option processing on the main Router manufacturers tend to do IP option processing on the main
processor, rather than on line cards. Unless special care is taken, processor, rather than on line cards. Unless special care is taken,
this represents Denial of Service (DoS) risk, as there is potential this represents DoS risk, as there is potential for overwhelming the
for overwhelming the router with option processing. router with option processing.
To reduce the impact of these packets on the system performance, a To reduce the impact of these packets on the system performance, a
few countermeasures could be implemented: few countermeasures could be implemented:
o Rate-limit the number of packets with IP options that are o Rate-limit the number of packets with IP options that are
processed by the system. processed by the system.
o Enforce a limit on the maximum number of options to be accepted on o Enforce a limit on the maximum number of options to be accepted on
a given internet datagram. a given Internet datagram.
The first check avoids a flow of packets with IP options to overwhelm The first check avoids a flow of packets with IP options to overwhelm
the system in question. The second check avoids packets with many IP the system in question. The second check avoids packets with many IP
options to affect the performance of the system. options to affect the performance of the system.
3.13.1.2. Processing of the options by the upper layer protocol 3.13.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 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 received in IP datagrams must be passed to the transport layer (or to
ICMP processing when the datagram is an ICMP message). Therefore, ICMP processing when the datagram is an ICMP message). Therefore,
care in option processing must be taken not only at the internet care in option processing must be taken not only at the Internet
layer, but also in every protocol module that may end up processing layer but also in every protocol module that may end up processing
the options included in an IP datagram. the options included in an IP datagram.
3.13.1.3. General sanity checks on IP options 3.13.1.3. General Sanity Checks on IP Options
There are a number of sanity checks that should be performed on IP There are a number of sanity checks that should be performed on IP
options before further option processing is done. They help prevent options before further option processing is done. They help prevent
a number of potential security problems, including buffer overflows. a number of potential security problems, including buffer overflows.
When these checks fail, the packet carrying the option should be When these checks fail, the packet carrying the option should be
dropped, and this event should be logged (e.g., a counter could be dropped, and this event should be logged (e.g., a counter could be
incremented to reflect the packet drop). incremented to reflect the packet drop).
RFC 1122 [RFC1122] recommends to send an ICMP "Parameter Problem" RFC 1122 [RFC1122] recommends to send an ICMP "Parameter Problem"
message to the originating system when a packet is dropped because of message to the originating system when a packet is dropped because of
skipping to change at page 34, line 10 skipping to change at page 33, line 18
must not crash as the result of an option length that is outside must not crash as the result of an option length that is outside
the possible range, and mentions that erroneous option lengths the possible range, and mentions that erroneous option lengths
have been observed to put some IP implementations into infinite have been observed to put some IP implementations into infinite
loops. loops.
For options that belong to the "Case 2" described in the previous For options that belong to the "Case 2" described in the previous
section, the following check should be performed: section, the following check should be performed:
option-length >= 2 option-length >= 2
The value "2" accounts for the option-type byte, and the The value "2" accounts for the option-type byte and the option-
option-length byte. length byte.
This check prevents, among other things, loops in option This check prevents, among other things, loops in option
processing that may arise from incorrect option lengths. processing that may arise from incorrect option lengths.
Additionally, while the option-length byte of IP options of Additionally, while the option-length byte of IP options of
"Case 2" allows for an option length of up to 255 bytes, there is "Case 2" allows for an option length of up to 255 bytes, there is
a limit on legitimate option length imposed by the space available a limit on legitimate option length imposed by the space available
for options in the IP header. for options in the IP header.
For all options of "Case 2", the following check should be For all options of "Case 2", the following check should be
enforced: enforced:
option-offset + option-length <= IHL * 4 option-offset + option-length <= IHL * 4
Where option-offset is the offset of the first byte of the option Where option-offset is the offset of the first byte of the option
within the IP header, with the first byte of the IP header being within the IP header, with the first byte of the IP header being
assigned an offset of 0. assigned an offset of 0.
This check assures that the option does not claim to extend beyond This check assures that the option does not claim to extend beyond
the IP header. If the packet does not pass this check, it should 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 dropped, and this event should be logged (e.g., a counter could
be incremented to reflect the packet drop). be incremented to reflect the packet drop).
The aforementioned check is meant to detect forged option-length The aforementioned check is meant to detect forged option-length
values that might make an option overlap with the IP payload. values that might make an option overlap with the IP payload.
This would be particularly dangerous for those IP options which This would be particularly dangerous for those IP options that
request the processing systems to write information into the request the processing systems to write information into the
option-data area (such as the Record Route option), as it would option-data area (such as the Record Route option), as it would
allow the generation of overflows. allow the generation of overflows.
Data types Data types
Many IP options use pointer and length fields. Care must be taken Many IP options use pointer and length fields. Care must be taken
as to the data type used for these fields in the implementation. 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 For example, if an 8-bit signed data type were used to hold an
8-bit pointer, then, pointer values larger than 128 might 8-bit pointer, then, pointer values larger than 128 might
mistakenly be interpreted as negative numbers, and thus might lead mistakenly be interpreted as negative numbers, and thus might lead
to unpredictable results. to unpredictable results.
3.13.2. Issues with specific options 3.13.2. Issues with Specific Options
3.13.2.1. End of Option List (Type=0) 3.13.2.1. End of Option List (Type=0)
This option is used to indicate the "end of options" in those cases 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 in which the end of options would not coincide with the end of the
Internet Protocol Header. Octets in the IP header following the "End Internet Protocol header. Octets in the IP header following the "End
of Option List" are to be regarded as padding (they should set to 0 of Option List" are to be regarded as padding (they should set to 0
by the originator and must to be ignored by receiving nodes). by the originator and must to be ignored by receiving nodes).
However, an originating node could alternatively fill the remaining However, an originating node could alternatively fill the remaining
space in the Internet header with No Operation options (see space in the Internet header with No Operation options (see
Section 3.13.2.2). The End of Option List option allows slightly Section 3.13.2.2). The End of Option List option allows slightly
more efficient parsing on receiving nodes and should be preferred by more efficient parsing on receiving nodes and should be preferred by
packet originators. All IP systems are required to understand both packet originators. All IP systems are required to understand both
encodings. encodings.
3.13.2.2. No Operation (Type=1) 3.13.2.2. No Operation (Type=1)
The no-operation option is basically meant to allow the sending The No Operation option is basically meant to allow the sending
system to align subsequent options in, for example, 32-bit system to align subsequent options in, for example, 32-bit
boundaries, but it can also be used at the end of the options (se boundaries, but it can also be used at the end of the options (see
Section Section 3.13.2.1). Section 3.13.2.1).
With a single exception (see Section 3.13.2.13 below), this option is With a single exception (see Section 3.13.2.13), this option is the
the only IP option defined so far that can occur in multiple only IP option defined so far that can occur in multiple instances in
instances in a single IP packet. a single IP packet.
This option does not have security implications. This option does not have security implications.
3.13.2.3. Loose Source and Record Route (LSRR) (Type=131) 3.13.2.3. Loose Source and Record Route (LSRR) (Type=131)
This option lets the originating system specify a number of This option lets the originating system specify a number of
intermediate systems a packet must pass through to get to the intermediate-systems a packet must pass through to get to the
destination host. Additionally, the route followed by the packet is destination host. Additionally, the route followed by the packet is
recorded in the option. The receiving host (end-system) must use the recorded in the option. The receiving host (end-system) must use the
reverse of the path contained in the received LSRR option. reverse of the path contained in the received LSRR option.
The LSSR option can be of help in debugging some network problems. The LSSR option can be of help in debugging some network problems.
Some ISP (Internet Service Provider) peering agreements require Some ISP (Internet Service Provider) peering agreements require
support for this option in the routers within the peer of the ISP. support for this option in the routers within the peer of the ISP.
The LSRR option has well-known security implications. Among other The LSRR option has well-known security implications. Among other
things, the option can be used to: things, the option can be used to:
o Bypass firewall rules o Bypass firewall rules
o Reach otherwise unreachable internet systems
o Reach otherwise unreachable Internet systems
o Establish TCP connections in a stealthy way o Establish TCP connections in a stealthy way
o Learn about the topology of a network o Learn about the topology of a network
o Perform bandwidth-exhaustion attacks o Perform bandwidth-exhaustion attacks
Of these attack vectors, the one that has probably received least Of these attack vectors, the one that has probably received the least
attention is the use of the LSRR option to perform bandwidth attention is the use of the LSRR option to perform bandwidth
exhaustion attacks. The LSRR option can be used as an amplification exhaustion attacks. The LSRR option can be used as an amplification
method for performing bandwidth-exhaustion attacks, as an attacker method for performing bandwidth-exhaustion attacks, as an attacker
could make a packet bounce multiple times between a number of systems could make a packet bounce multiple times between a number of systems
by carefully crafting an LSRR option. by carefully crafting an LSRR option.
This is the IPv4-version of the IPv6 amplification attack that was This is the IPv4-version of the IPv6 amplification attack that was
widely publicized in 2007 [Biondi2007]. The only difference is widely publicized in 2007 [Biondi2007]. The only difference is
that the maximum length of the IPv4 header (and hence the LSRR that the maximum length of the IPv4 header (and hence the LSRR
option) limits the amplification factor when compared to the IPv6 option) limits the amplification factor when compared to the IPv6
counter-part. counterpart.
While the LSSR option may be of help in debugging some network While the LSSR option may be of help in debugging some network
problems, its security implications outweigh any legitimate use. problems, its security implications outweigh any legitimate use.
All systems should, by default, drop IP packets that contain an LSRR All systems should, by default, drop IP packets that contain an LSRR
option, and should log this event (e.g., a counter could be option, and should log this event (e.g., a counter could be
incremented to reflect the packet drop). However, they should incremented to reflect the packet drop). However, they should
provide a system-wide toggle to enable support for this option for provide a system-wide toggle to enable support for this option for
those scenarios in which this option is required. Such system-wide those scenarios in which this option is required. Such system-wide
toggle should default to "off" (or "disable"). toggle should default to "off" (or "disable").
skipping to change at page 37, line 35 skipping to change at page 36, line 45
a multiple of 4. Consequently, the following check should be a multiple of 4. Consequently, the following check should be
performed: performed:
LSRR.Pointer % 4 == 0 LSRR.Pointer % 4 == 0
If a packet does not pass this check, it should be dropped, and this 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 event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
When a system receives an IP packet with the LSRR option passing the When a system receives an IP packet with the LSRR option passing the
above checks, it should check whether the source route is empty or above checks, it should check whether or not the source route is
not. The option is empty if: empty. The option is empty if:
LSRR.Pointer > LSRR.Length LSRR.Pointer > LSRR.Length
In that case, routing should be based on the Destination Address In that case, routing should be based on the Destination Address
field, and no further processing should be done on the LSRR option. field, and no further processing should be done on the LSRR option.
[Microsoft1999] is a security advisory about a vulnerability [Microsoft1999] is a security advisory about a vulnerability
arising from improper validation of the LSRR.Pointer field. arising from improper validation of the LSRR.Pointer field.
If the address in the Destination Address field has been reached, and If the address in the Destination Address field has been reached, and
the option is not empty, the next address in the source route the option is not empty, the next address in the source route
replaces the address in the Destination Address field, and the IP replaces the address in the Destination Address field, and the IP
address of the interface that will be used to forward this datagram address of the interface that will be used to forward this datagram
is recorded in its place in the LSRR.Data field. Then, the is recorded in its place in the LSRR.Data field. Then, the
LSRR.Pointer. is incremented by 4. LSRR.Pointer. is incremented by 4.
Note that the sanity checks for the LSRR.Length and the Note that the sanity checks for the LSRR.Length and the
LSRR.Pointer fields described above ensure that if the option is LSRR.Pointer fields described above ensure that if the option is
not empty, there will be (4*n) octets in the option. That is, not empty, there will be (4*n) octets in the option. That is,
there will be at least one IP address to read, and enough room to there will be at least one IP address to read and enough room to
record the IP address of the interface that will be used to record the IP address of the interface that will be used to
forward this datagram. forward this datagram.
The LSRR must be copied on fragmentation. This means that if a The LSRR must be copied on fragmentation. This means that if a
packet that carries the LSRR is fragmented, each of the fragments packet that carries the LSRR is fragmented, each of the fragments
will have to go through the list of systems specified in the LSRR will have to go through the list of systems specified in the LSRR
option. option.
3.13.2.4. Strict Source and Record Route (SSRR) (Type=137) 3.13.2.4. Strict Source and Record Route (SSRR) (Type=137)
This option allows the originating system to specify a number of This option allows the originating system to specify a number of
intermediate systems a packet must pass through to get to the intermediate-systems a packet must pass through to get to the
destination host. Additionally, the route followed by the packet is destination host. Additionally, the route followed by the packet is
recorded in the option, and the destination host (end-system) must recorded in the option, and the destination host (end-system) must
use the reverse of the path contained in the received SSRR option. use the reverse of the path contained in the received SSRR option.
This option is similar to the Loose Source and Record Route (LSRR) 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 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 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). (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. The SSSR option can be of help in debugging some network problems.
skipping to change at page 41, line 20 skipping to change at page 40, line 28
event should be logged (e.g., a counter could be incremented to event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
The Record Route option can be exploited to learn about the topology The Record Route option can be exploited to learn about the topology
of a network. However, the limited space in the IP header limits the of a network. However, the limited space in the IP header limits the
usefulness of this option for that purpose if the target network is usefulness of this option for that purpose if the target network is
several hops away. several hops away.
3.13.2.6. Stream Identifier (Type=136) 3.13.2.6. Stream Identifier (Type=136)
The Stream Identifier option originally provided a means for the 16- The Stream Identifier option originally provided a means for the
bit SATNET stream Identifier to be carried through networks that did 16-bit SATNET stream Identifier to be carried through networks that
not support the stream concept. did not support the stream concept.
However, as stated by Section 4.2.2.1 of RFC 1812 [RFC1812], this However, as stated by Section 4.2.2.1 of RFC 1812 [RFC1812], this
option is obsolete. Therefore, it must be ignored by the processing option is obsolete. Therefore, it must be ignored by the processing
systems. systems.
In the case of legacy systems still using this option, the length 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 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 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 logged (e.g., a counter could be incremented to reflect the packet
drop). drop).
RFC 791 states that this option appears at most once in a given RFC 791 states that this option appears at most once in a given
datagram. Therefore, if a packet contains more than one instance of datagram. Therefore, if a packet contains more than one instance of
this option, it should be dropped, and this event should be logged this option, it should be dropped, and this event should be logged
(e.g., a counter could be incremented to reflect the packet drop). (e.g., a counter could be incremented to reflect the packet drop).
3.13.2.7. Internet Timestamp (Type=68) 3.13.2.7. Internet Timestamp (Type=68)
This option provides a means for recording the time at which each This option provides a means for recording the time at which each
system processed this datagram. The timestamp option has a number of system processed this datagram. The timestamp option has a number of
security implications. Among them are: security implications. Among them are the following:
o It allows an attacker to obtain the current time of the systems 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 that process the packet, which the attacker may find useful in a
number of scenarios. number of scenarios.
o It may be used to map the network topology, in a similar way to o It may be used to map the network topology, in a similar way to
the IP Record Route option. the IP Record Route option.
o It may be used to fingerprint the operating system in use by a o It may be used to fingerprint the operating system in use by a
system processing the datagram. system processing the datagram.
o It may be used to fingerprint physical devices, by analyzing the o It may be used to fingerprint physical devices by analyzing the
clock skew. clock skew.
Therefore, by default, the timestamp option should be ignored. Therefore, by default, the timestamp option should be ignored.
For those systems that have been explicitly configured to honor this For those systems that have been explicitly configured to honor this
option, the rest of this subsection describes some sanity checks that option, the rest of this subsection describes some sanity checks that
should be enforced on the option before further processing. should be enforced on the option before further processing.
The option begins with an option-type byte, which must be equal to The option begins with an option-type byte, which must be equal to
68. The second byte is the option-length, which includes the option- 68. The second byte is the option-length, which includes the option-
skipping to change at page 43, line 13 skipping to change at page 42, line 22
IT.Pointer % 8 == 5 IT.Pointer % 8 == 5
If the packet does not pass this check, it should be dropped, and 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 this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
The flag field has three possible legal values: The flag field has three possible legal values:
o 0: Record time stamps only, stored in consecutive 32-bit words. o 0: Record time stamps only, stored in consecutive 32-bit words.
o 1: Record each timestamp preceded with the internet address of the o 1: Record each timestamp preceded with the Internet address of the
registering entity. registering entity.
o 3: The internet address fields of the option are pre-specified. o 3: The internet address fields of the option are pre-specified.
An IP module only registers its timestamp if it matches its own An IP module only registers its timestamp if it matches its own
address with the next specified internet address. address with the next specified Internet address.
Therefore the following check should be performed: Therefore the following check should be performed:
IT.Flag == 0 || IT.Flag == 1 || IT.Flag == 3 IT.Flag == 0 || IT.Flag == 1 || IT.Flag == 3
If the packet does not pass this check, it should be dropped, and 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 this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
The timestamp field is a right-justified 32-bit timestamp in The timestamp field is a right-justified 32-bit timestamp in
milliseconds since UTC. If the time is not available in milliseconds since UTC. If the time is not available in
milliseconds, or cannot be provided with respect to UTC, then any milliseconds, or cannot be provided with respect to UTC, then any
time may be inserted as a timestamp, provided the high order bit of time may be inserted as a timestamp, provided the high-order bit of
the timestamp is set, to indicate this non-standard value. the timestamp is set, to indicate this non-standard value.
According to RFC 791, the initial contents of the timestamp area must According to RFC 791, the initial contents of the timestamp area must
be initialized to zero, or internet address/zero pairs. However, be initialized to zero, or Internet address/zero pairs. However,
internet systems should be able to handle non-zero values, possibly Internet systems should be able to handle non-zero values, possibly
discarding the offending datagram. discarding the offending datagram.
When an internet system receives a packet with an Internet Timestamp When an Internet system receives a packet with an Internet Timestamp
option, it decides whether it should record its timestamp in the option, it decides whether it should record its timestamp in the
option. If it determines that it should, it should then determine option. If it determines that it should, it should then determine
whether the timestamp data area is full, by means of the following whether the timestamp data area is full, by means of the following
check: check:
IT.Pointer > IT.Length IT.Pointer > IT.Length
If this condition is true, the timestamp data area is full. If not, If this condition is true, the timestamp data area is full. If not,
there is room in the timestamp data area. there is room in the timestamp data area.
skipping to change at page 45, line 10 skipping to change at page 44, line 19
reflect the packet drop). reflect the packet drop).
A packet that contains a Router Alert option with an option value A packet that contains a Router Alert option with an option value
corresponding to functionality supported by an active module in the corresponding to functionality supported by an active module in the
router will not go through the router's fast-path but will be router will not go through the router's fast-path but will be
processed in the slow path of the router, handing it over for closer processed in the slow path of the router, handing it over for closer
inspection to the modules that has registered the matching option inspection to the modules that has registered the matching option
value. Therefore, this option may impact the performance of the value. Therefore, this option may impact the performance of the
systems that handle the packet carrying it. systems that handle the packet carrying it.
[I-D.ietf-intarea-router-alert-considerations] analyzes the [ROUTER-ALERT] analyzes the security implications of the Router
security implications of the Router Alert option, and identifies Alert option, and identifies controlled environments in which the
controlled environments in which the Router Alert option can be Router Alert option can be used safely.
used safely.
As explained in RFC 2113 [RFC2113], hosts should ignore this option. As explained in RFC 2113 [RFC2113], hosts should ignore this option.
3.13.2.9. Probe MTU (Type=11) (obsolete) 3.13.2.9. Probe MTU (Type=11) (Obsolete)
This option was defined in RFC 1063 [RFC1063], and originally This option was defined in RFC 1063 [RFC1063] and originally provided
provided a mechanism to discover the Path-MTU. a mechanism to discover the Path-MTU.
This option is obsolete, and therefore any packet that is received This option is obsolete, and therefore any packet that is received
containing this option should be dropped, and this event should be containing this option should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet logged (e.g., a counter could be incremented to reflect the packet
drop). drop).
3.13.2.10. Reply MTU (Type=12) (obsolete) 3.13.2.10. Reply MTU (Type=12) (Obsolete)
This option is defined in RFC 1063 [RFC1063], and originally provided This option is defined in RFC 1063 [RFC1063], and originally provided
a mechanism to discover the Path-MTU. a mechanism to discover the Path-MTU.
This option is obsolete, and therefore any packet that is received This option is obsolete, and therefore any packet that is received
containing this option should be dropped, and this event should be containing this option should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet logged (e.g., a counter could be incremented to reflect the packet
drop). drop).
3.13.2.11. Traceroute (Type=82) 3.13.2.11. Traceroute (Type=82)
This option is defined in RFC 1393 [RFC1393], and originally provided This option is defined in RFC 1393 [RFC1393], and originally provided
a mechanism to trace the path to a host. a mechanism to trace the path to a host.
This option is obsolete, and therefore any packet that is received The Traceroute option was specified as "experimental", and it was
containing this option should be dropped, and this event should be never deployed on the public Internet. Therefore, any packet that is
logged (e.g., a counter could be incremented to reflect the packet received containing this option should be dropped, and this event
drop). 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.13.2.12. Department of Defense (DoD) Basic Security Option (Type=130)
This option is used by Multi-Level-Secure (MLS) end-systems and This option is used by Multi-Level-Secure (MLS) end-systems and
intermediate systems in specific environments to [RFC1108]: intermediate-systems in specific environments to [RFC1108]:
o Transmit from source to destination in a network standard o Transmit from source to destination in a network standard
representation the common security labels required by computer representation the common security labels required by computer
security models, security models,
o Validate the datagram as appropriate for transmission from the o Validate the datagram as appropriate for transmission from the
source and delivery to the destination, and, source and delivery to the destination, and
o Ensure that the route taken by the datagram is protected to the o Ensure that the route taken by the datagram is protected to the
level required by all protection authorities indicated on the level required by all protection authorities indicated on the
datagram. datagram.
It is specified by RFC 1108 [RFC1108] (which obsoletes RFC 1038 It is specified by RFC 1108 [RFC1108] (which obsoletes RFC 1038
[RFC1038]). [RFC1038]).
RFC 791 [RFC0791] defined the "Security Option" (Type=130), which RFC 791 [RFC0791] defined the "Security Option" (Type=130), which
used the same option type as the DoD Basic Security option used the same option type as the DoD Basic Security option
discussed in this section. The "Security Option" specified in RFC discussed in this section. The "Security Option" specified in RFC
791 is considered obsolete by Section 3.2.1.8 of RFC 1122, and 791 is considered obsolete by Section 3.2.1.8 of RFC 1122, and
therefore the discussion in this section is focused on the DoD therefore the discussion in this section is focused on the DoD
Basic Security option specified by RFC 1108 [RFC1108]. Basic Security option specified by RFC 1108 [RFC1108].
Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement
this option". this option".
The DoD Basic Security Option is currently implemented in a number of The DoD Basic Security option is currently implemented in a number of
operating systems (e.g., [IRIX2008], [SELinux2008], [Solaris2008], operating systems (e.g., [IRIX2008], [SELinux2009], [Solaris2007],
and [Cisco2008]), and deployed in a number of high-security networks. and [Cisco2008]), and deployed in a number of high-security networks.
Systems that belong to networks in which this option is in use should Systems that belong to networks in which this option is in use should
process the DoD Basic Security option contained in each packet as process the DoD Basic Security option contained in each packet as
specified in [RFC1108]. specified in [RFC1108].
RFC 1108 states that the option should appear at most once in a RFC 1108 states that the option should appear at most once in a
datagram. Therefore, if more than one DoD Basic Security option datagram. Therefore, if more than one DoD Basic Security option
(BSO) appears in a given datagram, the corresponding datagram should (BSO) appears in a given datagram, the corresponding datagram should
be dropped, and this event should be logged (e.g., a counter could be be dropped, and this event should be logged (e.g., a counter could be
skipping to change at page 47, line 7 skipping to change at page 46, line 17
performed: performed:
BSO.Length >= 3 BSO.Length >= 3
If the packet does not pass this check, it should be dropped, and 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 this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
Current deployments of the security options described in this Current deployments of the security options described in this
section and the two subsequent sections have motivated the section and the two subsequent sections have motivated the
proposal of a "Common Architecture Label IPv6 Security Option specification of a "Common Architecture Label IPv6 Security Option
(CALIPSO)" for the IPv6 protocol. [RFC5570]. (CALIPSO)" for the IPv6 protocol [RFC5570].
3.13.2.13. DoD Extended Security Option (Type=133) 3.13.2.13. DoD Extended Security Option (Type=133)
This option permits additional security labeling information, beyond This option permits additional security labeling information, beyond
that present in the Basic Security Option (Section 3.13.2.12), to be that present in the Basic Security option (Section 3.13.2.13), to be
supplied in an IP datagram to meet the needs of registered supplied in an IP datagram to meet the needs of registered
authorities. It is specified by RFC 1108 [RFC1108]. authorities. It is specified by RFC 1108 [RFC1108].
This option may be present only in conjunction with the DoD Basic This option may be present only in conjunction with the DoD Basic
Security option. Therefore, if a packet contains a DoD Extended Security option. Therefore, if a packet contains a DoD Extended
Security option (ESO), but does not contain a DoD Basic Security Security option (ESO), but does not contain a DoD Basic Security
option, it should be dropped, and this event should be logged (e.g., option, it should be dropped, and this event should be logged (e.g.,
a counter could be incremented to reflect the packet drop). It a counter could be incremented to reflect the packet drop). It
should be noted that, unlike the DoD Basic Security option, this should be noted that, unlike the DoD Basic Security option, this
option may appear multiple times in a single IP header. option may appear multiple times in a single IP header.
skipping to change at page 48, line 6 skipping to change at page 47, line 21
The TSIG proposal was taken to the Commercial Internet Security The TSIG proposal was taken to the Commercial Internet Security
Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an
Internet-Draft was produced [CIPSO1992]. The Internet-Draft was Internet-Draft was produced [CIPSO1992]. The Internet-Draft was
never published as an RFC, but the proposal was later standardized never published as an RFC, but the proposal was later standardized
by the U.S. National Institute of Standards and Technology (NIST) by the U.S. National Institute of Standards and Technology (NIST)
as "Federal Information Processing Standard Publication 188" as "Federal Information Processing Standard Publication 188"
[FIPS1994]. [FIPS1994].
It is currently implemented in a number of operating systems (e.g., It is currently implemented in a number of operating systems (e.g.,
IRIX [IRIX2008], Security-Enhanced Linux [SELinux2008], and Solaris IRIX [IRIX2008], Security-Enhanced Linux [SELinux2009], and Solaris
[Solaris2008]), and deployed in a number of high-security networks. [Solaris2007]), and deployed in a number of high-security networks.
[Zakrzewski2002] and [Haddad2004] provide an overview of a Linux [Zakrzewski2002] and [Haddad2004] provide an overview of a Linux
implementation. implementation.
Systems that belong to networks in which this option is in use should Systems that belong to networks in which this option is in use should
process the CIPSO option contained in each packet as specified in process the CIPSO option contained in each packet as specified in
[CIPSO1992]. [CIPSO1992].
According to the option syntax specified in [CIPSO1992] the following According to the option syntax specified in [CIPSO1992], the
validation check should be performed: following validation check should be performed:
CIPSO.Length >= 6 CIPSO.Length >= 6
If a packet does not pass this check, it should be dropped, and this 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 event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
3.13.2.15. Sender Directed Multi-Destination Delivery (Type=149) 3.13.2.15. Sender Directed Multi-Destination Delivery (Type=149)
This option is defined in RFC 1770 [RFC1770], and originally provided This option is defined in RFC 1770 [RFC1770] and originally provided
unreliable UDP delivery to a set of addresses included in the option. unreliable UDP delivery to a set of addresses included in the option.
This option is obsolete. If a received packet contains this 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 it should be dropped, and this event should be logged (e.g., a
counter could be incremented to reflect the packet drop). counter could be incremented to reflect the packet drop).
4. Internet Protocol Mechanisms 4. Internet Protocol Mechanisms
4.1. Fragment reassembly 4.1. Fragment Reassembly
To accommodate networks with different Maximum Transmission Units To accommodate networks with different Maximum Transmission Units
(MTUs), the Internet Protocol provides a mechanism for the (MTUs), the Internet Protocol provides a mechanism for the
fragmentation of IP packets by end-systems (hosts) and/or fragmentation of IP packets by end-systems (hosts) and/or
intermediate systems (routers). Reassembly of fragments is performed intermediate-systems (routers). Reassembly of fragments is performed
only by the end-systems. only by the end-systems.
[Cerf1974] provides the rationale for why packet reassembly is not [Cerf1974] provides the rationale for why packet reassembly is not
performed by intermediate systems. performed by intermediate-systems.
During the last few decades, IP fragmentation and reassembly has been During the last few decades, IP fragmentation and reassembly has been
exploited in a number of ways, to perform actions such as evading exploited in a number of ways, to perform actions such as evading
Network Intrusion Detection Systems (NIDS), bypassing firewall rules, NIDSs, bypassing firewall rules, and performing DoS attacks.
and performing Denial of Service (DoS) attacks.
[Bendi1998] and [Humble1998] are examples of the exploitation of [Bendi1998] and [Humble1998] are examples of the exploitation of
these issues for performing Denial of Service (DoS) attacks. these issues for performing DoS attacks. [CERT1997] and
[CERT1997] and [CERT1998b] document these issues. [Anderson2001] [CERT1998b] document these issues. [Anderson2001] is a survey of
is a survey of fragmentation attacks. [US-CERT2001] is an example fragmentation attacks. [US-CERT2001] is an example of the
of the exploitation of IP fragmentation to bypass firewall rules. exploitation of IP fragmentation to bypass firewall rules.
[CERT1999] describes the implementation of fragmentation attacks [CERT1999] describes the implementation of fragmentation attacks
in Distributed Denial of Service (DDoS) attack tools. in Distributed Denial-of-Service (DDoS) attack tools.
The problem with IP fragment reassembly basically has to do with the The problem with IP fragment reassembly basically has to do with the
complexity of the function, in a number of aspects: complexity of the function, in a number of aspects:
o Fragment reassembly is a stateful operation for a stateless o Fragment reassembly is a stateful operation for a stateless
protocol (IP). The IP module at the host performing the protocol (IP). The IP module at the host performing the
reassembly function must allocate memory buffers both for reassembly function must allocate memory buffers both for
temporarily storing the received fragments, and to perform the temporarily storing the received fragments and to perform the
reassembly function. Attackers can exploit this fact to exhaust reassembly function. Attackers can exploit this fact to exhaust
memory buffers at the system performing the fragment reassembly. memory buffers at the system performing the fragment reassembly.
o The fragmentation and reassembly mechanisms were designed at a o The fragmentation and reassembly mechanisms were designed at a
time in which the available bandwidths were very different from time in which the available bandwidths were very different from
the bandwidths available nowadays. With the current available the bandwidths available nowadays. With the current available
bandwidths, a number of interoperability problems may arise, and bandwidths, a number of interoperability problems may arise, and
these issues may be intentionally exploited by attackers to these issues may be intentionally exploited by attackers to
perform Denial of Service (DoS) attacks. perform DoS attacks.
o Fragment reassembly must usually be performed without any o Fragment reassembly must usually be performed without any
knowledge of the properties of the path the fragments follow. knowledge of the properties of the path the fragments follow.
Without this information, hosts cannot make any educated guess on Without this information, hosts cannot make any educated guess on
how long they should wait for missing fragments to arrive. how long they should wait for missing fragments to arrive.
o The fragment reassembly algorithm, as described by the IETF o The fragment reassembly algorithm, as described by the IETF
specifications, is ambiguous, and allows for a number of specifications, is ambiguous, and allows for a number of
interpretations, each of which has found place in different TCP/IP interpretations, each of which has found place in different TCP/IP
stack implementations. stack implementations.
o The reassembly process is somewhat complex. Fragments may arrive o The reassembly process is somewhat complex. Fragments may arrive
out of order, duplicated, overlapping each other, etc. This out of order, duplicated, overlapping each other, etc. This
complexity has lead to numerous bugs in different implementations complexity has lead to numerous bugs in different implementations
of the IP protocol. of the IP protocol.
4.1.1. Security Implications of Fragment Reassembly 4.1.1. Security Implications of Fragment Reassembly
4.1.1.1. Problems related with memory allocation 4.1.1.1. Problems Related to Memory Allocation
When an IP datagram is received by an end-system, it will be When an IP datagram is received by an end-system, it will be
temporarily stored in system memory, until the IP module processes it temporarily stored in system memory, until the IP module processes it
and hands it to the protocol machine that corresponds to the and hands it to the protocol machine that corresponds to the
encapsulated protocol. encapsulated protocol.
In the case of fragmented IP packets, while the IP module may perform In the case of fragmented IP packets, while the IP module may perform
preliminary processing of the IP header (such as checking the header preliminary processing of the IP header (such as checking the header
for errors and processing IP options), fragments must be kept in for errors and processing IP options), fragments must be kept in
system buffers until all fragments are received and are reassembled system buffers until all fragments are received and are reassembled
into a complete internet datagram. into a complete Internet datagram.
As mentioned above, because the internet layer will not usually have As mentioned above, because the Internet layer will not usually have
information about the characteristics of the path between the system information about the characteristics of the path between the system
and the remote host, no educated guess can be made on the amount of and the remote host, no educated guess can be made on the amount of
time that should be waited for the other fragments to arrive. time that should be waited for the other fragments to arrive.
Therefore, the specifications recommend to wait for a period of time Therefore, the specifications recommend to wait for a period of time
that is acceptable for virtually all the possible network scenarios that is acceptable for virtually all the possible network scenarios
in which the protocols might operate. After that time has elapsed, in which the protocols might operate. After that time has elapsed,
all the received fragments for the corresponding incomplete packet all the received fragments for the corresponding incomplete packet
are discarded. are discarded.
The original IP Specification, RFC 791 [RFC0791], states that The original IP Specification, RFC 791 [RFC0791], states that
skipping to change at page 51, line 26 skipping to change at page 51, line 5
allocated by the IP module as a whole, then, when this limit is allocated by the IP module as a whole, then, when this limit is
reached, all further IP packets that arrive would be discarded, reached, all further IP packets that arrive would be discarded,
until some fragments time out and free memory is available again. until some fragments time out and free memory is available again.
o If the system enforces limits on the amount memory that can be o If the system enforces limits on the amount memory that can be
allocated for the reassembly of fragments, then, when this limit allocated for the reassembly of fragments, then, when this limit
is reached, all further fragments that arrive would be discarded, is reached, all further fragments that arrive would be discarded,
until some fragment(s) time out and free memory is available until some fragment(s) time out and free memory is available
again. again.
4.1.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 Field
The Internet Protocols are currently being used in environments that The Internet Protocols are currently being used in environments that
are quite different from the ones in which they were conceived. For are quite different from the ones in which they were conceived. For
instance, the availability of bandwidth at the time the Internet instance, the availability of bandwidth at the time the Internet
Protocol was designed was completely different from the availability Protocol was designed was completely different from the availability
of bandwidth in today's networks. of bandwidth in today's networks.
The Identification field is a 16-bit field that is used for the The Identification field is a 16-bit field that is used for the
fragmentation and reassembly function. In the event a datagram gets fragmentation and reassembly function. In the event a datagram gets
fragmented, all the corresponding fragments will share the same fragmented, all the corresponding fragments will share the same
skipping to change at page 51, line 49 skipping to change at page 51, line 28
number} four-tuple. Thus, the system receiving the fragments will be number} four-tuple. Thus, the system receiving the fragments will be
able to uniquely identify them as fragments that correspond to the able to uniquely identify them as fragments that correspond to the
same IP datagram. At a given point in time, there must be at most same IP datagram. At a given point in time, there must be at most
only one packet in the network with a given four-tuple. If not, an only one packet in the network with a given four-tuple. If not, an
Identification number "collision" might occur, and the receiving Identification number "collision" might occur, and the receiving
system might end up "mixing" fragments that correspond to different system might end up "mixing" fragments that correspond to different
IP datagrams which simply reused the same Identification number. IP datagrams which simply reused the same Identification number.
For example, sending over a 1 Gbit/s path a continuous stream of For example, sending over a 1 Gbit/s path a continuous stream of
(UDP) packets of roughly 1 kb size that all get fragmented into (UDP) packets of roughly 1 kb size that all get fragmented into
two equally sized fragments of 576 octets each (minimum reasesmbly two equally sized fragments of 576 octets each (minimum reassembly
buffer size) would repeat the IP Identification values within less buffer size) would repeat the IP Identification values within less
than 0.65 seconds (assuming roughly 10% link layer overhead); with than 0.65 seconds (assuming roughly 10% link layer overhead); with
shorter packets that still get fragmented, this figure could shorter packets that still get fragmented, this figure could
easily drop below 0.4 seconds. With a single IP packet dropped in easily drop below 0.4 seconds. With a single IP packet dropped in
this short timeframe, packets would start to be reassembled this short time frame, packets would start to be reassembled
wrongly and continuously once in such interval until an error wrongly and continuously once in such interval until an error
detection and recovery algorithm at an upper layer lets the detection and recovery algorithm at an upper layer lets the
application back out. application back out.
For each group of fragments whose Identification numbers "collide", For each group of fragments whose Identification numbers "collide",
the fragment reassembly will lead to corrupted packets. The IP the fragment reassembly will lead to corrupted packets. The IP
payload of the reassembled datagram will be handed to the payload of the reassembled datagram will be handed to the
corresponding upper layer protocol, where the error will (hopefully) corresponding upper-layer protocol, where the error will (hopefully)
be detected by some error detecting code (such as the TCP checksum) be detected by some error detecting code (such as the TCP checksum)
and the packet will be discarded. and the packet will be discarded.
An attacker could exploit this fact to intentionally cause a system An attacker could exploit this fact to intentionally cause a system
to discard all or part of the fragmented traffic it gets, thus to discard all or part of the fragmented traffic it gets, thus
performing a Denial-of-Service attack. Such an attacker would simply performing a DoS attack. Such an attacker would simply establish a
establish a flow of fragments with different IP Identification flow of fragments with different IP Identification numbers, to trash
numbers, to trash all or part of the IP Identification space. As a all or part of the IP Identification space. As a result, the
result, the receiving system would use the attacker's fragments for receiving system would use the attacker's fragments for the
the reassembly of legitimate datagrams, leading to corrupted packets reassembly of legitimate datagrams, leading to corrupted packets
which would later (and hopefully) get dropped. which would later (and hopefully) get dropped.
In most cases, use of a long fragment timeout will benefit the In most cases, use of a long fragment timeout will benefit the
attacker, as forged fragments will keep the IP Identification space attacker, as forged fragments will keep the IP Identification space
trashed for a longer period of time. trashed for a longer period of time.
4.1.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 Algorithm
As IP packets can be duplicated by the network, and each packet may 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 take a different path to get to the destination host, fragments may
arrive not only out of order and/or duplicated, but also overlapping. arrive not only out of order and/or duplicated but also overlapping.
This means that the reassembly process can be somewhat complex, with This means that the reassembly process can be somewhat complex, with
the corresponding implementation being not specifically trivial. the corresponding implementation being not specifically trivial.
[Shannon2001] analyzes the causes and attributes of fragment traffic [Shannon2001] analyzes the causes and attributes of fragment traffic
measured in several types of WANs. measured in several types of WANs.
During the years, a number of attacks have exploited bugs in the During the years, a number of attacks have exploited bugs in the
reassembly function of several operating systems, producing buffer reassembly function of several operating systems, producing buffer
overflows that have led, in most cases, to a crash of the attacked overflows that have led, in most cases, to a crash of the attacked
system. system.
4.1.1.4. Problems that arise from the ambiguity of the reassembly 4.1.1.4. Problems That Arise from the Ambiguity of the Reassembly
process Process
Network Intrusion Detection Systems (NIDSs) typically monitor the Network Intrusion Detection Systems (NIDSs) typically monitor the
traffic on a given network with the intent of identifying traffic traffic on a given network with the intent of identifying traffic
patterns that might indicate network intrusions. patterns that might indicate network intrusions.
In the presence of IP fragments, in order to detect illegitimate In the presence of IP fragments, in order to detect illegitimate
activity at the transport or application layers (i.e., any protocol activity at the transport or application layers (i.e., any protocol
layer above the network layer), a NIDS must perform IP fragment layer above the network layer), a NIDS must perform IP fragment
reassembly. reassembly.
skipping to change at page 53, line 23 skipping to change at page 52, line 49
reassembly function performed by the NIDS should be the same as that reassembly function performed by the NIDS should be the same as that
of the reassembly function performed by the intended recipient of the of the reassembly function performed by the intended recipient of the
packets. packets.
However, a number of factors make the result of the reassembly However, a number of factors make the result of the reassembly
process ambiguous: process ambiguous:
o The IETF specifications are ambiguous as to what should be done in o The IETF specifications are ambiguous as to what should be done in
the event overlapping fragments were received. Thus, in the the event overlapping fragments were received. Thus, in the
presence of overlapping data, the system performing the reassembly presence of overlapping data, the system performing the reassembly
function is free to either honor the first set of data received, function is free to honor either the first set of data received,
the latest copy received, or any other copy received in between. the latest copy received, or any other copy received in between.
o As the specifications do not enforce any specific fragment timeout o As the specifications do not enforce any specific fragment timeout
value, different systems may choose different values for the value, different systems may choose different values for the
fragment timeout. This means that given a set of fragments fragment timeout. This means that given a set of fragments
received at some specified time intervals, some systems will received at some specified time intervals, some systems will
reassemble the fragments into a full datagram, while others may reassemble the fragments into a full datagram, while others may
timeout the fragments and therefore drop them. timeout the fragments and therefore drop them.
o As mentioned before, as the fragment buffers get full, a Denial of o As mentioned before, as the fragment buffers get full, a DoS
Service (DoS) condition will occur unless some action is taken. condition will occur unless some action is taken. Many systems
Many systems flush part of the fragment buffers when some flush part of the fragment buffers when some threshold is reached.
threshold is reached. Thus, depending on fragment load, timing Thus, depending on fragment load, timing issues, and flushing
issues, and flushing policy, a NIDS may get incorrect assumptions policy, a NIDS may get incorrect assumptions about how (and if)
about how (and if) fragments are being reassembled by their fragments are being reassembled by their intended recipient.
intended recipient.
As originally discussed by [Ptacek1998], these issues can be As originally discussed by [Ptacek1998], these issues can be
exploited by attackers to evade intrusion detection systems. exploited by attackers to evade intrusion detection systems.
There exist freely available tools to forcefully fragment IP There exist freely available tools to forcefully fragment IP
datagrams so as to help evade Intrusion Detection Systems. Frag datagrams so as to help evade Intrusion Detection Systems. Frag
router [Song1999] is an example of such a tool; it allows an attacker router [Song1999] is an example of such a tool; it allows an attacker
to perform all the evasion techniques described in [Ptacek1998]. to perform all the evasion techniques described in [Ptacek1998].
Ftester [Barisani2006] is a tool that helps to audit systems Ftester [Barisani2006] is a tool that helps to audit systems
regarding fragmentation issues. regarding fragmentation issues.
4.1.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 One approach to fragment filtering involves keeping track of the
results of applying filter rules to the first fragment (i.e., the results of applying filter rules to the first fragment (i.e., the
fragment with a Fragment Offset of 0), and applying them to fragment with a Fragment Offset of 0), and applying them to
subsequent fragments of the same packet. The filtering module would subsequent fragments of the same packet. The filtering module would
maintain a list of packets indexed by the Source Address, Destination maintain a list of packets indexed by the Source Address, Destination
Address, Protocol, and Identification number. When the initial Address, Protocol, and Identification number. When the initial
fragment is seen, if the MF bit is set, a list item would be 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 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 non-zero Fragment Offset come in, look up the list element
with a matching Source Address/Destination Address/Protocol/ with a matching Source Address/Destination Address/Protocol/
Identification and apply the stored result (pass or block). When a Identification and apply the stored result (pass or block). When a
fragment with a zero MF bit is seen, free the list element. fragment with a zero MF bit is seen, free the list element.
Unfortunately, the rules of this type of packet filter can usually be Unfortunately, the rules of this type of packet filter can usually be
bypassed. [RFC1858] describes the details of the involved technique. bypassed. [RFC1858] describes the details of the involved technique.
4.1.2. Possible security improvements 4.1.2. Possible Security Improvements
4.1.2.1. 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 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 to reassemble the fragments of a given packet. There are basically
two options: two options:
o Upon receipt of the first fragment, allocate a buffer that will be o Upon receipt of the first fragment, allocate a buffer that will be
large enough to concatenate the payload of each fragment. large enough to concatenate the payload of each fragment.
o Upon receipt of the first fragment, create the first node of a o Upon receipt of the first fragment, create the first node of a
linked list to which each of the following fragments will be linked list to which each of the following fragments will be
linked. When all fragments have been received, copy the IP linked. When all fragments have been received, copy the IP
payload of each of the fragments (in the correct order) to a payload of each of the fragments (in the correct order) to a
separate buffer that will be handed to the protocol being separate buffer that will be handed to the protocol being
encapsulated in the IP payload. encapsulated in the IP payload.
While the first of the choices might seem to be the most straight- While the first of the choices might seem to be the most
forward, it implies that even when a single small fragment of a given straightforward, it implies that even when a single small fragment of
packet is received, the amount of memory that will be allocated for a given packet is received, the amount of memory that will be
that fragment will account for the size of the complete IP datagram, allocated for that fragment will account for the size of the complete
thus using more system resources than what is actually needed. IP datagram, thus using more system resources than what is actually
needed.
Furthermore, the only situation in which the actual size of the whole Furthermore, the only situation in which the actual size of the whole
datagram will be known is when the last fragment of the packet is datagram will be known is when the last fragment of the packet is
received first, as that is the only packet from which the total size received first, as that is the only packet from which the total size
of the IP datagram can be asserted. Otherwise, memory should be of the IP datagram can be asserted. Otherwise, memory should be
allocated for the largest possible packet size (65535 bytes). allocated for the largest possible packet size (65535 bytes).
The IP module should also enforce a limit on the amount of memory The IP module should also enforce a limit on the amount of memory
that can be allocated for IP fragments, as well as a limit on the 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. number of fragments that at any time will be allowed in the system.
skipping to change at page 55, line 20 skipping to change at page 54, line 45
Furthermore, the IP module should keep a different buffer for IP Furthermore, the IP module should keep a different buffer for IP
fragments than for complete IP datagrams. This will basically fragments than for complete IP datagrams. This will basically
separate the effects of fragment attacks on non-fragmented traffic. separate the effects of fragment attacks on non-fragmented traffic.
Most TCP/IP implementations, such as that in Linux and those in BSD- Most TCP/IP implementations, such as that in Linux and those in BSD-
derived systems, already implement this. derived systems, already implement this.
[Jones2002] analyzes the amount of memory that may be needed for the [Jones2002] analyzes the amount of memory that may be needed for the
fragment reassembly buffer depending on a number of network fragment reassembly buffer depending on a number of network
characteristics. characteristics.
4.1.2.2. 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 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 used for fragments, and those that aim to cause a collision of IP
Identification numbers, there are a number of countermeasures that Identification numbers, there are a number of countermeasures that
can be implemented. can be implemented.
Even with these countermeasures in place, there is still the issue of Even with these countermeasures in place, there is still the issue of
what to do when the buffer pool used for IP fragments gets full. what to do when the buffer pool used for IP fragments gets full.
Basically, if the fragment buffer is full, no instance of Basically, if the fragment buffer is full, no instance of
communication that relies on fragmentation will be able to progress. communication that relies on fragmentation will be able to progress.
skipping to change at page 56, line 4 skipping to change at page 55, line 30
packet (i.e., fragment with a given Identification number) is packet (i.e., fragment with a given Identification number) is
flushed, all the other fragments that correspond to the same datagram flushed, all the other fragments that correspond to the same datagram
should be flushed. As in order for a packet to be reassembled all of should be flushed. As in order for a packet to be reassembled all of
its fragments must be received by the system performing the its fragments must be received by the system performing the
reassembly function, flushing only a subset of the fragments of a reassembly function, flushing only a subset of the fragments of a
given packet would keep the corresponding buffers tied to fragments given packet would keep the corresponding buffers tied to fragments
that would never reassemble into a complete datagram. Additionally, that would never reassemble into a complete datagram. Additionally,
care must be taken so that, in the event that subsequent buffer care must be taken so that, in the event that subsequent buffer
flushes need to be performed, it is not always the same set of flushes need to be performed, it is not always the same set of
fragments that get dropped, as such a behavior would probably cause a fragments that get dropped, as such a behavior would probably cause a
selective Denial of Service (DoS) to the traffic flows to which that selective DoS to the traffic flows to which that set of fragments
set of fragments belongs. belongs.
Many TCP/IP implementations define a threshold for the number of Many TCP/IP implementations define a threshold for the number of
fragments that, when reached, triggers a fragment-buffer flush. Some fragments that, when reached, triggers a fragment-buffer flush. Some
systems flush 1/2 of the fragment buffer when the threshold is systems flush 1/2 of the fragment buffer when the threshold is
reached. As mentioned before, the idea of flushing the buffer is to reached. As mentioned before, the idea of flushing the buffer is to
create some free space in the fragment buffer, on the premise that create some free space in the fragment buffer, on the premise that
this will allow for new and legitimate fragments to be processed by this will allow for new and legitimate fragments to be processed by
the IP module, thus letting communication survive the overwhelming the IP module, thus letting communication survive the overwhelming
situation. On the other hand, the idea of flushing a somewhat large 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 portion of the buffer is to avoid flushing always the same set of
packets. packets.
4.1.2.3. A more selective fragment buffer flushing strategy 4.1.2.3. A More Selective Fragment Buffer Flushing Strategy
One of the difficulties in implementing countermeasures for the One of the difficulties in implementing countermeasures for the
fragmentation attacks described throughout Section 4.1 is that it is fragmentation attacks described throughout Section 4.1 is that it is
difficult to perform validation checks on the received fragments. difficult to perform validation checks on the received fragments.
For instance, the fragment on which validity checks could be For instance, the fragment on which validity checks could be
performed, the first fragment, may be not the first fragment to performed, the first fragment, may be not the first fragment to
arrive at the destination host. arrive at the destination host.
Fragments can not only arrive out of order because of packet Fragments cannot only arrive out of order because of packet
reordering performed by the network, but also because the system (or reordering performed by the network, but also because the system (or
systems) that fragmented the IP datagram may indeed transmit the systems) that fragmented the IP datagram may indeed transmit the
fragments out of order. A notable example of this is the Linux fragments out of order. A notable example of this is the Linux
TCP/IP stack, which transmits the fragments in reverse order. TCP/IP stack, which transmits the fragments in reverse order.
This means that we cannot enforce checks on the fragments for which This means that we cannot enforce checks on the fragments for which
we allocate reassembly resources, as the first fragment we receive we allocate reassembly resources, as the first fragment we receive
for a given packet may be some other fragment than the first one (the for a given packet may be some other fragment than the first one (the
one with an Fragment Offset of 0). one with an Fragment Offset of 0).
However, at the point in which we decide to free some space in the 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. 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 The first thing we would like to do is to stop different types of
traffic from interfering with each other. This means, in principle, traffic from interfering with each other. This means, in principle,
that we do not want fragmented UDP traffic to interfere with that we do not want fragmented UDP traffic to interfere with
fragmented TCP traffic. In order to implement this traffic fragmented TCP traffic. In order to implement this traffic
separation for the different protocols, a different fragment buffer separation for the different protocols, a different fragment buffer
pool would be needed, in principle, for each of the 256 different pool would be needed, in principle, for each of the 256 different
protocols that can be encapsulated in an IP datagram. protocols that can be encapsulated in an IP datagram.
We believe a tradeoff is to implement two separate fragment buffers: We believe a trade-off is to implement two separate fragment buffers:
one for IP datagrams that encapsulate IPsec packets, and another for one for IP datagrams that encapsulate IPsec packets and another for
the rest of the traffic. This basically means that traffic not the rest of the traffic. This basically means that traffic not
protected by IPsec will not interfere with those flows of protected by IPsec will not interfere with those flows of
communication that are being protected by IPsec. communication that are being protected by IPsec.
The processing of each of these two different fragment buffer pools The processing of each of these two different fragment buffer pools
would be completely independent from each other. In the case of the would be completely independent from each other. In the case of the
IPsec fragment buffer pool, when the buffers needs to be flushed, the IPsec fragment buffer pool, when the buffers needs to be flushed, the
following refined policy could be applied: following refined policy could be applied:
o First, for each packet for which the IPsec header has been o First, for each packet for which the IPsec header has been
received, check that the SPI field of the IPsec header corresponds received, check that the Security Parameters Index (SPI) field of
to an existing IPsec Security Association (SA), and probably also the IPsec header corresponds to an existing IPsec Security
check that the IPsec sequence number is valid. If the check Association (SA), and probably also check that the IPsec sequence
fails, drop all the fragments that correspond to this packet. number is valid. If the check fails, drop all the fragments that
correspond to this packet.
o Second, if still more fragment buffers need to be flushed, drop o Second, if still more fragment buffers need to be flushed, drop
all the fragments that correspond to packets for which the full all the fragments that correspond to packets for which the full
IPsec header has not yet been received. The number of packets for IPsec header has not yet been received. The number of packets for
which this flushing is performed depends on the amount of free which this flushing is performed depends on the amount of free
space that needs to be created. space that needs to be created.
o Third, if after flushing packets with invalid IPsec information o Third, if after flushing packets with invalid IPsec information
(First step), and packets on which validation checks could not be (First step), and packets on which validation checks could not be
performed (Second step), there is still not enough space in the performed (Second step), there is still not enough space in the
skipping to change at page 57, line 38 skipping to change at page 57, line 16
space is created. space is created.
The rationale behind this policy is that, at the point of flushing The rationale behind this policy is that, at the point of flushing
fragment buffers, we prefer to keep those packets on which we could fragment buffers, we prefer to keep those packets on which we could
successfully perform a number of validation checks, over those successfully perform a number of validation checks, over those
packets on which those checks failed, or the checks could not even be packets on which those checks failed, or the checks could not even be
performed. performed.
By checking both the IPsec SPI and the IPsec sequence number, it is By checking both the IPsec SPI and the IPsec sequence number, it is
virtually impossible for an attacker that is off-path to perform a virtually impossible for an attacker that is off-path to perform a
Denial-of-Service attack to communication flows being protected by DoS attack to communication flows being protected by IPsec.
IPsec.
Unfortunately, some IP implementations (such as that in Linux Unfortunately, some IP implementations (such as that in Linux
[Linux2006]), when performing fragmentation, send the corresponding [Linux]), when performing fragmentation, send the corresponding
fragments in reverse order. In such cases, at the point of flushing fragments in reverse order. In such cases, at the point of flushing
the fragment buffer, legitimate fragments will receive the same the fragment buffer, legitimate fragments will receive the same
treatment as the possible forged fragments. treatment as the possible forged fragments.
This refined flushing policy provides an increased level of This refined flushing policy provides an increased level of
protection against this type of resource exhaustion attack, while not protection against this type of resource exhaustion attack, while not
making the situation of out-of-order IPsec-secured traffic worse than making the situation of out-of-order IPsec-secured traffic worse than
with the simplified flushing policy described in the previous with the simplified flushing policy described in the previous
section. section.
4.1.2.4. Reducing the fragment timeout 4.1.2.4. Reducing the Fragment Timeout
RFC 1122 [RFC1122] states that the reassembly timeout should be a RFC 1122 [RFC1122] states that the reassembly timeout should be a
fixed value between 60 and 120 seconds. The rationale behind these fixed value between 60 and 120 seconds. The rationale behind these
long timeout values is that they should accommodate any path long timeout values is that they should accommodate any path
characteristics, such as long-delay paths. However, it must be noted characteristics, such as long-delay paths. However, it must be noted
that this timer is really measuring inter-fragment delays, or, more that this timer is really measuring inter-fragment delays, or, more
specifically, fragment jitter. specifically, fragment jitter.
If all fragments take paths of similar characteristics, the inter- If all fragments take paths of similar characteristics, the inter-
fragment delay will usually be, at most, a few seconds. fragment delay will usually be, at most, a few seconds.
Nevertheless, even if fragments take different paths of different Nevertheless, even if fragments take different paths of different
characteristics, the recommended 60 to 120 seconds are, in practice, characteristics, the recommended 60 to 120 seconds are, in practice,
excessive. excessive.
Some systems have already reduced the fragment timeout to 30 seconds Some systems have already reduced the fragment timeout to 30 seconds
[Linux2006]. The fragment timeout could probably be further reduced [Linux]. The fragment timeout could probably be further reduced to
to approximately 15 seconds; although further research on this issue approximately 15 seconds; although further research on this issue is
is necessary. necessary.
It should be noted that in network scenarios of long-delay and high- It should be noted that in network scenarios of long-delay and high-
bandwidth (usually referred to as "Long-Fat Networks"), using a long bandwidth (usually referred to as "Long-Fat Networks"), using a long
fragment timeout would likely increase the probability of collision fragment timeout would likely increase the probability of collision
of IP ID numbers. Therefore, in such scenarios it is highly of IP ID numbers. Therefore, in such scenarios it is highly
desirable to avoid the use of fragmentation with techniques such as desirable to avoid the use of fragmentation with techniques such as
PMTUD [RFC1191] or PLPMTUD [RFC4821]. PMTUD [RFC1191] or PLPMTUD [RFC4821].
4.1.2.5. Countermeasure for some IDS evasion techniques 4.1.2.5. Countermeasure for Some NIDS Evasion Techniques
[Shankar2003] introduces a technique named "Active Mapping" that [Shankar2003] introduces a technique named "Active Mapping" that
prevents evasion of a NIDS by acquiring sufficient knowledge about prevents evasion of a NIDS by acquiring sufficient knowledge about
the network being monitored, to assess which packets will arrive at the network being monitored, to assess which packets will arrive at
the intended recipient, and how they will be interpreted by it. the intended recipient, and how they will be interpreted by it.
[Novak2005] describes some techniques that are applied by the Snort [Novak2005] describes some techniques that are applied by the Snort
NIDS to avoid evasion. [Snort] NIDS to avoid evasion.
4.1.2.6. Countermeasure for firewall-rules bypassing 4.1.2.6. Countermeasure for Firewall-Rules Bypassing
One of the classical techniques to bypass firewall rules involves One of the classical techniques to bypass firewall rules involves
sending packets in which the header of the encapsulated protocol is sending packets in which the header of the encapsulated protocol is
fragmented. Even when it would be legal (as far as the IETF fragmented. Even when it would be legal (as far as the IETF
specifications are concerned) to receive such a packets, the MTUs of specifications are concerned) to receive such a packets, the MTUs of
the network technologies used in practice are not that small to the network technologies used in practice are not that small to
require the header of the encapsulated protocol to be fragmented. require the header of the encapsulated protocol to be fragmented
Therefore, the system performing reassembly should drop all packets (e.g., see [RFC2544]). Therefore, the system performing reassembly
which fragment the upper-layer protocol header, and this event should should drop all packets which fragment the upper-layer protocol
be logged (e.g., a counter could be incremented to reflect the packet header, and this event should be logged (e.g., a counter could be
drop). incremented to reflect the packet drop).
Additionally, given that many middle-boxes such as firewalls create Additionally, given that many middle-boxes such as firewalls create
state according to the contents of the first fragment of a given state according to the contents of the first fragment of a given
packet, it is best that, in the event an end-system receives packet, it is best that, in the event an end-system receives
overlapping fragments, it honors the information contained in the overlapping fragments, it honors the information contained in the
fragment that was received first. fragment that was received first.
RFC 1858 [RFC1858] describes the abuse of IP fragmentation to bypass RFC 1858 [RFC1858] describes the abuse of IP fragmentation to bypass
firewall rules. RFC 3128 [RFC3128] corrects some errors in RFC 1858. firewall rules. RFC 3128 [RFC3128] corrects some errors in RFC 1858.
4.2. Forwarding 4.2. Forwarding
4.2.1. Precedence-ordered queue service 4.2.1. Precedence-Ordered Queue Service
Section 5.3.3.1 of RFC 1812 [RFC1812] states that routers should Section 5.3.3.1 of RFC 1812 [RFC1812] states that routers should
implement precedence-ordered queue service. This means that when a implement precedence-ordered queue service. This means that when a
packet is selected for output on a (logical) link, the packet of packet is selected for output on a (logical) link, the packet of
highest precedence that has been queued for that link is sent. highest precedence that has been queued for that link is sent.
Section 5.3.3.2 of RFC 1812 advices routers to default to maintaining Section 5.3.3.2 of RFC 1812 advises routers to default to maintaining
strict precedence-ordered service. strict precedence-ordered service.
Unfortunately, given that it is trivial to forge the IP precedence Unfortunately, given that it is trivial to forge the IP precedence
field of the IP header, an attacker could simply forge a high field of the IP header, an attacker could simply forge a high
precedence number in the packets it sends, to illegitimately get precedence number in the packets it sends to illegitimately get
better network service. If precedence-ordered queued service is not better network service. If precedence-ordered queued service is not
required in a particular network infrastructure, it should be required in a particular network infrastructure, it should be
disabled, and thus all packets would receive the same type of disabled, and thus all packets would receive the same type of
service, despite the values in their Type of Service or service, despite the values in their Type of Service or
Differentiated Services fields. Differentiated Services fields.
When Precedence-ordered queue service is required in the network When precedence-ordered queue service is required in the network
infrastructure, in order to mitigate the attack vector discussed in infrastructure, in order to mitigate the attack vector discussed in
the previous paragraph, edge routers or switches should be configured the previous paragraph, edge routers or switches should be configured
to police and remark the Type of Service or Differentiated Services to police and remark the Type of Service or Differentiated Services
values, according to the type of service at which each end-system has values, according to the type of service at which each end-system has
been allowed to send packets. been allowed to send packets.
Bullet 4 of Section 5.3.3.3 of RFC 1812 states that routers "MUST NOT Bullet 4 of Section 5.3.3.3 of RFC 1812 states that routers "MUST NOT
change precedence settings on packets it did not originate". change precedence settings on packets it did not originate".
However, given the security implications of the Precedence field, it However, given the security implications of the Precedence field, it
is fair for routers, switches or other middle-boxes, particularly is fair for routers, switches, or other middle-boxes, particularly
those in the network edge, to overwrite the Type of Service (or those in the network edge, to overwrite the Type of Service (or
Differentiated Services) field of the packets they are forwarding, Differentiated Services) field of the packets they are forwarding,
according to a configured network policy (this is the specified according to a configured network policy (this is the specified
behavior for DS domains [RFC2475]). behavior for DS domains [RFC2475]).
Section 5.3.3.1 and Section 5.3.6 of RFC 1812 states that if Sections 5.3.3.1 and 5.3.6 of RFC 1812 state that if precedence-
precedence-ordered queue service is implemented and enabled, the ordered queue service is implemented and enabled, the router "MUST
router "MUST NOT discard a packet whose precedence is higher than NOT discard a packet whose precedence is higher than that of a packet
that of a packet that is not discarded". While this recommendation that is not discarded". While this recommendation makes sense given
makes sense given the semantics of the Precedence field, it is the semantics of the Precedence field, it is important to note that
important to note that it would be simple for an attacker to send it would be simple for an attacker to send packets with forged high
packets with forged high Precedence value to congest some internet Precedence value to congest some internet router(s), and cause all
router(s), and cause all (or most) traffic with a lower Precedence (or most) traffic with a lower Precedence value to be discarded.
value to be discarded.
4.2.2. Weak Type of Service 4.2.2. Weak Type of Service
Section 5.2.4.3 of RFC 1812 describes the algorithm for determining Section 5.2.4.3 of RFC 1812 describes the algorithm for determining
the next-hop address (i.e., the forwarding algorithm). Bullet 3, the next-hop address (i.e., the forwarding algorithm). Bullet 3,
"Weak TOS", addresses the case in which routes contain a "type of "Weak TOS", addresses the case in which routes contain a "type of
service" attribute. It states that in case a packet contains a non- service" attribute. It states that in case a packet contains a non-
default TOS (i.e., 0000), only routes with the same TOS or with the default TOS (i.e., 0000), only routes with the same TOS or with the
default TOS should be considered for forwarding that packet. default TOS should be considered for forwarding that packet.
However, this means that if among the longest match routes for a However, this means that if among the longest match routes for a
given packet are routes with some TOS other than the one contained in given packet are routes with some TOS other than the one contained in
the received packet, and no routes with the default TOS, the the received packet, and no routes with the default TOS, the
corresponding packet would be dropped. This may or may not be a corresponding packet would be dropped. This may or may not be a
desired behavior. desired behavior.
An alternative for the case in which among the "longest match" routes An alternative for the case in which among the "longest match" routes
there are only routes with non-default type of service which do not there are only routes with non-default type of service that do not
match the TOS contained in the received packet, would be to use a match the TOS contained in the received packet, would be to use a
route with any other TOS. While this route would most likely not be 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 able to address the type of service requested by packet, it would, at
least, provide a "best effort" service. least, provide a "best effort" service.
It must be noted that Section 5.3.2 of RFC 1812 allows routers to not It must be noted that Section 5.3.2 of RFC 1812 allows routers to not
honor the TOS field. Therefore, the proposed alternative behavior is honor the TOS field. Therefore, the proposed alternative behavior is
still compliant with the IETF specifications. still compliant with the IETF specifications.
While officially specified in the RFC series, TOS-based routing is While officially specified in the RFC series, TOS-based routing is
not widely deployed in the Internet. not widely deployed in the Internet.
4.2.3. Impact of Address Resolution on Buffer Management 4.2.3. Impact of Address Resolution on Buffer Management
In the case of broadcast link-layer technologies, in order for a 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 system to transfer an IP datagram it must usually first map an IP
address to the corresponding link-layer address (for example, by address to the corresponding link-layer address (for example, by
means of the ARP protocol [RFC0826]) . This means that while this means of the Address Resolution Protocol (ARP) [RFC0826]) . This
operation is being performed, the packets that would require such a means that while this operation is being performed, the packets that
mapping would need to be kept in memory. This may happen both in the would require such a mapping would need to be kept in memory. This
case of hosts and in the case of routers. may happen both in the case of hosts and in the case of routers.
This situation might be exploited by an attacker, which could send a This situation might be exploited by an attacker, which could send a
large amount of packets to a non-existent host which would supposedly large amount of packets to a non-existent host that would supposedly
be directly connected to the attacked router. While trying to map be directly connected to the attacked router. While trying to map
the corresponding IP address into a link-layer address, the attacked the corresponding IP address into a link-layer address, the attacked
router would keep in memory all the packets that would need to make router would keep in memory all the packets that would need to make
use of that link-layer address. At the point in which the mapping use of that link-layer address. At the point in which the mapping
function times out, depending on the policy implemented by the function times out, depending on the policy implemented by the
attacked router, only the packet that triggered the call to the attacked router, only the packet that triggered the call to the
mapping function might be dropped. In that case, the same operation mapping function might be dropped. In that case, the same operation
would be repeated for every packet destined to the non-existent host. would be repeated for every packet destined to the non-existent host.
Depending on the timeout value for the mapping function, this Depending on the timeout value for the mapping function, this
situation might lead the router to run out of free buffer space, with situation might lead the router to run out of free buffer space, with
the consequence that incoming legitimate packets would have to be the consequence that incoming legitimate packets would have to be
dropped, or that legitimate packets already stored in the router's dropped, or that legitimate packets already stored in the router's
buffers might get dropped. Both of these situations would lead buffers might get dropped. Both of these situations would lead
either to a complete Denial of Service, or to a degradation of the either to a complete DoS or to a degradation of the network service.
network service.
One countermeasure to this problem would be to drop, at the point the One countermeasure to this problem would be to drop, at the point the
mapping function times out, all the packets destined to the address mapping function times out, all the packets destined to the address
that timed out. In addition, a "negative cache entry" might be kept that timed out. In addition, a "negative cache entry" might be kept
in the module performing the matching function, so that for some in the module performing the matching function, so that for some
amount of time, the mapping function would return an error when the amount of time, the mapping function would return an error when the
IP module requests to perform a mapping for some address for which IP module requests to perform a mapping for some address for which
the mapping has recently timed out. the mapping has recently timed out.
A common implementation strategy for routers is that when a packet A common implementation strategy for routers is that when a packet
is received that requires an ARP resolution to be performed before is received that requires an ARP resolution to be performed before
the packet can be forwarded, the packet is dropped and the router the packet can be forwarded, the packet is dropped and the router
is then engaged in the ARP procedure. is then engaged in the ARP procedure.
4.2.4. Dropping packets 4.2.4. Dropping Packets
In some scenarios, it may be necessary for a host or router to drop 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 packets from the output queue. In the event that one of such packets
happens to be an IP fragment, and there were other fragments of the happens to be an IP fragment, and there were other fragments of the
same packet in the queue, those other fragments should also be same packet in the queue, those other fragments should also be
dropped. The rationale for this policy is that it is nonsensical to dropped. The rationale for this policy is that it is nonsensical to
spend system resources on those other fragments, because, as long as spend system resources on those other fragments, because, as long as
one fragment is missing, it will be impossible for the receiving one fragment is missing, it will be impossible for the receiving
system to reassemble them into a complete IP datagram. system to reassemble them into a complete IP datagram.
Some systems have been known to drop just a subset of fragments of a Some systems have been known to drop just a subset of fragments of a
given datagram, leading to a denial of service condition, as only a given datagram, leading to a denial-of-service condition, as only a
subset of all the fragments of the packets were actually transferred subset of all the fragments of the packets were actually transferred
to the next hop. to the next hop.
4.3. Addressing 4.3. Addressing
4.3.1. Unreachable addresses
4.3.1. Unreachable Addresses
It is important to understand that while there are some addresses It is important to understand that while there are some addresses
that are supposed to be unreachable from the public Internet (such as that are supposed to be unreachable from the public Internet (such as
the private IP addresses described in RFC 1918 [RFC1918], or the the private IP addresses described in RFC 1918 [RFC1918], or the
"loopback" address), there are a number of tricks an attacker can "loopback" address), there are a number of tricks an attacker can
perform to reach those IP addresses that would otherwise be perform to reach those IP addresses that would otherwise be
unreachable (e.g., exploit the LSRR or SSRR IP options). Therefore, unreachable (e.g., exploit the LSRR or SSRR IP options). Therefore,
when applicable, packet filtering should be performed at private when applicable, packet filtering should be performed at the private
network boundary to assure that those addresses will be unreachable. network boundary to assure that those addresses will be unreachable.
Similarly, link-local unicast addresses [RFC3927] and multicast Similarly, link-local unicast addresses [RFC3927] and multicast
addresses with limited scope (link- and site-local addresses) should addresses with limited scope (link- and site-local addresses) should
not be accessible from outside the proper network boundaries and not not be accessible from outside the proper network boundaries and not
be passed across these boundaries. be passed across these boundaries.
[RFC5735] provides a summary of special use IPv4 addresses. [RFC5735] provides a summary of special use IPv4 addresses.
4.3.2. Private address space 4.3.2. Private Address Space
The Internet Assigned Numbers Authority (IANA) has reserved the The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private internets: following three blocks of the IP address space for private internets:
o 10.0.0.0 - 10.255.255.255 (10/8 prefix) 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 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) o 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
Use of these address blocks is described in RFC 1918 [RFC1918]. Use of these address blocks is described in RFC 1918 [RFC1918].
Where applicable, packet filtering should be performed at the Where applicable, packet filtering should be performed at the
organizational perimeter to assure that these addresses are not organizational perimeter to assure that these addresses are not
reachable from outside the private network where such addresses are reachable from outside the private network where such addresses are
employed. employed.
skipping to change at page 62, line 42 skipping to change at page 62, line 17
Use of these address blocks is described in RFC 1918 [RFC1918]. Use of these address blocks is described in RFC 1918 [RFC1918].
Where applicable, packet filtering should be performed at the Where applicable, packet filtering should be performed at the
organizational perimeter to assure that these addresses are not organizational perimeter to assure that these addresses are not
reachable from outside the private network where such addresses are reachable from outside the private network where such addresses are
employed. employed.
4.3.3. Former Class D Addresses (224/4 Address Block) 4.3.3. Former Class D Addresses (224/4 Address Block)
The former Class D addresses correspond to the 224/4 address block, The former Class D addresses correspond to the 224/4 address block
and are used for Internet multicast. Therefore, if a packet is and are used for Internet multicast. Therefore, if a packet is
received with a "Class D" address as the Source Address, it should be received with a "Class D" address as the Source Address, it should be
dropped, and this event should be logged (e.g., a counter could be dropped, and this event should be logged (e.g., a counter could be
incremented to reflect the packet drop). Additionally, if an IP incremented to reflect the packet drop). Additionally, if an IP
packet with a multicast Destination Address is received for a packet with a multicast Destination Address is received for a
connection-oriented protocol (e.g., TCP), the packet should be connection-oriented protocol (e.g., TCP), the packet should be
dropped (see Section 4.3.5), and this event should be logged (e.g., a dropped (see Section 4.3.5), and this event should be logged (e.g., a
counter could be incremented to reflect the packet drop). counter could be incremented to reflect the packet drop).
4.3.4. Former Class E Addresses (240/4 Address Block) 4.3.4. Former Class E Addresses (240/4 Address Block)
skipping to change at page 63, line 18 skipping to change at page 62, line 40
and are currently reserved for experimental use. As a result, a most and are currently reserved for experimental use. As a result, a most
routers discard packets that contain a "Class" E address as the routers discard packets that contain a "Class" E address as the
Source Address or Destination Address. If a packet is received with Source Address or Destination Address. If a packet is received with
a 240/4 address as the Source Address and/or the Destination Address, a 240/4 address as the Source Address and/or the Destination Address,
the packet should be dropped and this event should be logged (e.g., a the packet should be dropped and this event should be logged (e.g., a
counter could be incremented to reflect the packet drop). counter could be incremented to reflect the packet drop).
It should be noted that the broadcast address 255.255.255.255 still It should be noted that the broadcast address 255.255.255.255 still
must be treated as indicated in Section 4.3.7 of this document. must be treated as indicated in Section 4.3.7 of this document.
4.3.5. Broadcast/Multicast addresses, and Connection-Oriented Protocols 4.3.5. Broadcast/Multicast Addresses and Connection-Oriented Protocols
For connection-oriented protocols, such as TCP, shared state is For connection-oriented protocols, such as TCP, shared state is
maintained between only two endpoints at a time. Therefore, if an IP maintained between only two endpoints at a time. Therefore, if an IP
packet with a multicast (or broadcast) Destination Address is packet with a multicast (or broadcast) Destination Address is
received for a connection-oriented protocol (e.g., TCP), the packet received for a connection-oriented protocol (e.g., TCP), the packet
should be dropped, and this event should be logged (e.g., a counter should be dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop). could be incremented to reflect the packet drop).
4.3.6. Broadcast and network addresses 4.3.6. Broadcast and Network Addresses
Originally, the IETF specifications did not permit IP addresses to Originally, the IETF specifications did not permit IP addresses to
have the value 0 or -1 (shorthand for all bits set to 1) for any of have the value 0 or -1 (shorthand for all bits set to 1) for any of
the Host number, network number, or subnet number fields, except for the Host number, network number, or subnet number fields, except for
the cases indicated in Section 4.3.7. However, this changed the cases indicated in Section 4.3.7. However, this changed
fundamentally with the deployment of Classless Inter-Domain Routing fundamentally with the deployment of Classless Inter-Domain Routing
(CIDR) [RFC4632], as with CIDR a system cannot know a priori what the (CIDR) [RFC4632], as with CIDR a system cannot know a priori what the
subnet mask is for a particular IP address. subnet mask is for a particular IP address.
Many systems now allow administrators to use the values 0 or -1 for Many systems now allow administrators to use the values 0 or -1 for
those fields. Despite that according to the original IETF those fields. Despite that according to the original IETF
specifications these addresses are illegal, modern IP implementations specifications these addresses are illegal, modern IP implementations
should consider these addresses to be valid. should consider these addresses to be valid.
4.3.7. Special Internet addresses 4.3.7. Special Internet Addresses
RFC 1812 [RFC1812] discusses the use of some special internet RFC 1812 [RFC1812] discusses the use of some special Internet
addresses, which is of interest to perform some sanity checks on the addresses, which is of interest to perform some sanity checks on the
Source Address and Destination Address fields of an IP packet. It Source Address and Destination Address fields of an IP packet. It
uses the following notation for an IP address: uses the following notation for an IP address:
{ <Network-prefix>, <Host-number> } { <Network-prefix>, <Host-number> }
where the length of the network prefix is generally implied by the where the length of the network prefix is generally implied by the
network mask assigned to the IP interface under consideration. network mask assigned to the IP interface under consideration.
RFC 1122 [RFC1122] contained a similar discussion of special RFC 1122 [RFC1122] contained a similar discussion of special
internet addresses, including some of the form { <Network-prefix>, Internet addresses, including some of the form { <Network-prefix>,
<Subnet-number>, <Host-number> }. However, as explained in <Subnet-number>, <Host-number> }. However, as explained in
Section 4.2.2.11 of RFC 1812, in a CIDR world, the subnet number 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 is clearly an extension of the network prefix and cannot be
distinguished from the remainder of the prefix. distinguished from the remainder of the prefix.
{0, 0} {0, 0}
This address means "this host on this network". It is meant to be This address means "this host on this network". It is meant to be
used only during the initialization procedure, by which the host used only during the initialization procedure, by which the host
learns its own IP address. learns its own IP address.
skipping to change at page 65, line 18 skipping to change at page 64, line 46
This is the directed broadcast to the specified network. As This is the directed broadcast to the specified network. As
recommended by RFC 2644 [RFC2644], routers should not forward recommended by RFC 2644 [RFC2644], routers should not forward
network-directed broadcasts. This avoids the corresponding network network-directed broadcasts. This avoids the corresponding network
from being utilized as, for example, a "smurf amplifier" [CERT1998a]. from being utilized as, for example, a "smurf amplifier" [CERT1998a].
As noted in Section 4.3.6 of this document, many systems now allow As noted in Section 4.3.6 of this document, many systems now allow
administrators to configure these addresses as unicast addresses for administrators to configure these addresses as unicast addresses for
network interfaces. In such scenarios, routers should forward these network interfaces. In such scenarios, routers should forward these
addresses as if they were traditional unicast addresses. addresses as if they were traditional unicast addresses.
In some scenarios a host may have knowledge about a particular IP In some scenarios, a host may have knowledge about a particular IP
address being a network-directed broadcast address, rather than a address being a network-directed broadcast address, rather than a
unicast address (e.g., that IP address is configured on the local unicast address (e.g., that IP address is configured on the local
system as a "broadcast address"). In such scenarios, if a system can system as a "broadcast address"). In such scenarios, if a system can
infer that the Source Address of a received packet is a network- infer that the Source Address of a received packet is a network-
directed broadcast address, the packet should be dropped, and this directed broadcast address, the packet should be dropped, and this
event should be logged (e.g., a counter could be incremented to event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
As noted in Section 4.3.6 of this document, with the deployment of 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 CIDR [RFC4632], it may be difficult for a system to infer whether a
skipping to change at page 68, line 51 skipping to change at page 68, line 26
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
BCP 153, RFC 5735, January 2010. BCP 153, RFC 5735, January 2010.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, November 2010. Notification", RFC 6040, November 2010.
7.2. Informative References 7.2. Informative References
[Anderson2001] [Anderson2001]
Anderson, J., "An Analysis of Fragmentation Attacks", Anderson, J., "An Analysis of Fragmentation Attacks",
Available at: http://www.ouah.org/fragma.html , 2001. 2001, <http://www.ouah.org/fragma.html>.
[Arkin2000] [Arkin2000]
Arkin, "IP TTL Field Value with ICMP (Oops - Identifying Arkin, "IP TTL Field Value with ICMP (Oops - Identifying
Windows 2000 again and more)", http:// Windows 2000 again and more)", 2000,
ofirarkin.files.wordpress.com/2008/11/ <http://ofirarkin.files.wordpress.com/2008/11/
ofirarkin2000-06.pdf, 2000. ofirarkin2000-06.pdf>.
[Barisani2006] [Barisani2006]
Barisani, A., "FTester - Firewall and IDS testing tool", Barisani, A., "FTester - Firewall and IDS testing tool",
Available at: http://dev.inversepath.com/trac/ftester , 2001, <http://dev.inversepath.com/trac/ftester>.
2001.
[Bellovin1989] [Bellovin1989]
Bellovin, S., "Security Problems in the TCP/IP Protocol Bellovin, S., "Security Problems in the TCP/IP Protocol
Suite", Computer Communication Review Vol. 19, No. 2, pp. Suite", Computer Communication Review Vol. 19, No. 2, pp.
32-48, 1989. 32-48, 1989.
[Bellovin2002] [Bellovin2002]
Bellovin, S., "A Technique for Counting NATted Hosts", Bellovin, S., "A Technique for Counting NATted Hosts",
IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. IMW'02 Nov. 6-8, 2002, Marseille, France, 2002.
[Bendi1998] [Bendi1998]
Bendi, "Bonk exploit", http://www.insecure.org/sploits/ Bendi, "Bonk exploit", 1998,
95.NT.fragmentation.bonk.html , 1998. <http://www.insecure.org/sploits/
95.NT.fragmentation.bonk.html>.
[Biondi2007] [Biondi2007]
Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", Biondi, P. and A. Ebalard, "IPv6 Routing Header Security",
CanSecWest 2007 Security Conference http://www.secdev.org/ CanSecWest 2007 Security Conference, 2007,
conf/IPv6_RH_security-csw07.pdf, 2007. <http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>.
[CERT1996a] [CERT1996a]
CERT, "CERT Advisory CA-1996-01: UDP Port Denial-of- CERT, "CERT Advisory CA-1996-01: UDP Port Denial-of-
Service Attack", Service Attack", 1996,
http://www.cert.org/advisories/CA-1996-01.html, 1996. <http://www.cert.org/advisories/CA-1996-01.html>.
[CERT1996b] [CERT1996b]
CERT, "CERT Advisory CA-1996-21: TCP SYN Flooding and IP CERT, "CERT Advisory CA-1996-21: TCP SYN Flooding and IP
Spoofing Attacks", Spoofing Attacks", 1996,
http://www.cert.org/advisories/CA-1996-21.html, 1996. <http://www.cert.org/advisories/CA-1996-21.html>.
[CERT1996c] [CERT1996c]
CERT, "CERT Advisory CA-1996-26: Denial-of-Service Attack CERT, "CERT Advisory CA-1996-26: Denial-of-Service Attack
via ping", via ping", 1996,
http://www.cert.org/advisories/CA-1996-26.html, 1996. <http://www.cert.org/advisories/CA-1996-26.html>.
[CERT1997] [CERT1997] CERT, "CERT Advisory CA-1997-28: IP Denial-of-Service
CERT, "CERT Advisory CA-1997-28: IP Denial-of-Service Attacks", 1997,
Attacks", http://www.cert.org/advisories/CA-1997-28.html, <http://www.cert.org/advisories/CA-1997-28.html>.
1997.
[CERT1998a] [CERT1998a]
CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of- CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of-
Service Attacks", Service Attacks", 1998,
http://www.cert.org/advisories/CA-1998-01.html, 1998. <http://www.cert.org/advisories/CA-1998-01.html>.
[CERT1998b] [CERT1998b]
CERT, "CERT Advisory CA-1998-13: Vulnerability in Certain CERT, "CERT Advisory CA-1998-13: Vulnerability in Certain
TCP/IP Implementations", TCP/IP Implementations", 1998,
http://www.cert.org/advisories/CA-1998-13.html, 1998. <http://www.cert.org/advisories/CA-1998-13.html>.
[CERT1999]
CERT, "CERT Advisory CA-1999-17: Denial-of-Service Tools",
http://www.cert.org/advisories/CA-1999-17.html, 1999.
[CERT2001] [CERT1999] CERT, "CERT Advisory CA-1999-17: Denial-of-Service Tools",
CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in 1999, <http://www.cert.org/advisories/CA-1999-17.html>.
TCP/IP Initial Sequence Numbers",
http://www.cert.org/advisories/CA-2001-09.html, 2001.
[CERT2003] [CERT2003] CERT, "CERT Advisory CA-2003-15: Cisco IOS Interface
CERT, "CERT Advisory CA-2003-15: Cisco IOS Interface Blocked by IPv4 Packet", 2003,
Blocked by IPv4 Packet", <http://www.cert.org/advisories/CA-2003-15.html>.
http://www.cert.org/advisories/CA-2003-15.html, 2003.
[CIPSO1992] [CIPSO1992]
CIPSO, "COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)", IETF CIPSO, "COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)", Work
Internet-Draft (draft-ietf-cipso-ipsecurity-01.txt), work in Progress, 1992.
in progress , 1992.
[CIPSOWG1994] [CIPSOWG1994]
CIPSOWG, "Commercial Internet Protocol Security Option CIPSOWG, "Commercial Internet Protocol Security Option
(CIPSO) Working Group", http://www.ietf.org/proceedings/ (CIPSO) Working Group", 1994, <http://www.ietf.org/
94jul/charters/cipso-charter.html, 1994. proceedings/94jul/charters/cipso-charter.html>.
[CPNI2008] [CPNI2008] Gont, F., "Security Assessment of the Internet Protocol",
Gont, F., "Security Assessment of the Internet Protocol",
2008, <http://www.cpni.gov.uk/Docs/InternetProtocol.pdf>. 2008, <http://www.cpni.gov.uk/Docs/InternetProtocol.pdf>.
[Cerf1974] [Cerf1974] Cerf, V. and R. Kahn, "A Protocol for Packet Network
Cerf, V. and R. Kahn, "A Protocol for Packet Network
Intercommunication", IEEE Transactions on Intercommunication", IEEE Transactions on
Communications Vol. 22, No. 5, May 1974, pp. 637-648, Communications Vol. 22, No. 5, May 1974, pp. 637-648,
1974. 1974.
[Cisco2003] [Cisco2003]
Cisco, "Cisco Security Advisory: Cisco IOS Interface Cisco, "Cisco Security Advisory: Cisco IOS Interface
Blocked by IPv4 packet", http://www.cisco.com/en/US/ Blocked by IPv4 packet", 2003, <http://www.cisco.com/en/
products/products_security_advisory09186a00801a34c2.shtml, US/products/
2003. products_security_advisory09186a00801a34c2.shtml>.
[Cisco2008] [Cisco2008]
Cisco, "Cisco IOS Security Configuration Guide, Release Cisco, "Cisco IOS Security Configuration Guide, Release
12.2", http://www.cisco.com/en/US/docs/ios/12_2/security/ 12.2", 2003, <http://www.cisco.com/en/US/docs/ios/12_2/
configuration/guide/scfipso.html, 2003. security/configuration/guide/scfipso.html>.
[Clark1988] [Clark1988]
Clark, D., "The Design Philosophy of the DARPA Internet Clark, D., "The Design Philosophy of the DARPA Internet
Protocols", Computer Communication Review Vol. 18, No. 4, Protocols", Computer Communication Review Vol. 18, No. 4,
1988. 1988.
[Ed3f2002] [Ed3f2002] Ed3f, "Firewall spotting and networks analysis with a
Ed3f, "Firewall spotting and networks analisys with a broken CRC", Phrack Magazine, Volume 0x0b, Issue
broken CRC", Phrack Magazine, Volume 0x0b, Issue 0x3c, 0x3c, Phile #0x0c of 0x10, 2002, <http://www.phrack.org/
Phile #0x0c of 0x10 http://www.phrack.org/ issues.html?issue=60&id=12&mode=txt>.
issues.html?issue=60&id=12&mode=txt, 2002.
[FIPS1994] [FIPS1994] FIPS, "Standard Security Label for Information Transfer",
FIPS, "Standard Security Label for Information Transfer",
Federal Information Processing Standards Publication. FIP Federal Information Processing Standards Publication. FIP
PUBS 188 http://csrc.nist.gov/publications/fips/fips188/ PUBS 188, 1994, <http://csrc.nist.gov/publications/fips/
fips188.pdf, 1994. fips188/fips188.pdf>.
[Fyodor2004] [Fyodor2004]
Fyodor, "Idle scanning and related IP ID games", Fyodor, "Idle scanning and related IP ID games", 2004,
http://www.insecure.org/nmap/idlescan.html, 2004. <http://www.insecure.org/nmap/idlescan.html>.
[GIAC2000] [GIAC2000] GIAC, "Egress Filtering v 0.2", 2000,
GIAC, "Egress Filtering v 0.2", <http://www.sans.org/y2k/egress.htm>.
http://www.sans.org/y2k/egress.htm, 2000.
[Gont2006] [Gont2006] Gont, F., "Advanced ICMP packet filtering", 2006,
Gont, F., "Advanced ICMP packet filtering", <http://www.gont.com.ar/papers/icmp-filtering.html>.
http://www.gont.com.ar/papers/icmp-filtering.html, 2006.
[Haddad2004] [Haddad2004]
Haddad, I. and M. Zakrzewski, "Security Distribution for Haddad, I. and M. Zakrzewski, "Security Distribution for
Linux Clusters", Linux Linux Clusters", Linux Journal, 2004,
Journal http://www.linuxjournal.com/article/6943, 2004. <http://www.linuxjournal.com/article/6943>.
[Humble1998] [Humble1998]
Humble, "Nestea exploit", Humble, "Nestea exploit", 1998,
http://www.insecure.org/sploits/linux.PalmOS.nestea.html, <http://www.insecure.org/sploits/
1998. linux.PalmOS.nestea.html>.
[I-D.ietf-intarea-router-alert-considerations]
Faucheur, F., "IP Router Alert Considerations and Usage",
draft-ietf-intarea-router-alert-considerations-03 (work in
progress), March 2011.
[I-D.templin-mtuassurance]
Templin, F., "Requirements for IP-in-IP Tunnel MTU
Assurance", draft-templin-mtuassurance-02 (work in
progress), October 2006.
[IANA2006a] [IANA_ET] IANA, "Ether Types",
Ether Types, <http://www.iana.org/assignments/ethernet-numbers>.
"http://www.iana.org/assignments/ethernet-numbers".
[IANA2006b] [IANA_IP_PARAM]
IP Parameters, IANA, "IP Parameters",
"http://www.iana.org/assignments/ip-parameters". <http://www.iana.org/assignments/ip-parameters>.
[IANA2006c] [IANA_PROT_NUM]
Protocol Numbers, IANA, "Protocol Numbers",
"http://www.iana.org/assignments/protocol-numbers". <http://www.iana.org/assignments/protocol-numbers>.
[IRIX2008] [IRIX2008] IRIX, "IRIX 6.5 trusted_networking(7) manual page", 2008,
IRIX, "IRIX 6.5 trusted_networking(7) manual page", http: <http://techpubs.sgi.com/library/tpl/cgi-bin/
//techpubs.sgi.com/library/tpl/cgi-bin/
getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/ getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/
cat7/trusted_networking.z, 2008. cat7/trusted_networking.z>.
[Jones2002] [Jones2002]
Jones, R., "A Method Of Selecting Values For the Jones, R., "A Method Of Selecting Values For the
Parameters Controlling IP Fragment Reassembly", ftp:// Parameters Controlling IP Fragment Reassembly", 2002,
ftp.cup.hp.com/dist/networking/briefs/ip_reass_tuning.txt, <ftp://ftp.cup.hp.com/dist/networking/briefs/
2002. ip_reass_tuning.txt>.
[Kenney1996] [Kenney1996]
Kenney, M., "The Ping of Death Page", Kenney, M., "The Ping of Death Page", 1996,
http://www.insecure.org/sploits/ping-o-death.html, 1996. <http://www.insecure.org/sploits/ping-o-death.html>.
[Kent1987] [Kent1987] Kent, C. and J. Mogul, "Fragmentation considered harmful",
Kent, C. and J. Mogul, "Fragmentation considered harmful",
Proc. SIGCOMM '87 Vol. 17, No. 5, October 1987, 1987. Proc. SIGCOMM '87 Vol. 17, No. 5, October 1987, 1987.
[Klein2007] [Klein2007]
Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
Predictable IP ID Vulnerability", http:// Predictable IP ID Vulnerability", 2007,
www.trusteer.com/files/ <http://www.trusteer.com/files/
OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP
_ID_Vulnerability.pdf, 2007. _ID_Vulnerability.pdf>.
[Kohno2005] [Kohno2005]
Kohno, T., Broido, A., and kc. Claffy, "Remote Physical Kohno, T., Broido, A., and kc. Claffy, "Remote Physical
Device Fingerprinting", IEEE Transactions on Dependable Device Fingerprinting", IEEE Transactions on Dependable
and Secure Computing Vol. 2, No. 2, 2005. and Secure Computing Vol. 2, No. 2, 2005.
[LBNL2006] [LBNL2006] LBNL/NRG, "arpwatch tool", 2006, <http://ee.lbl.gov/>.
LBNL/NRG, "arpwatch tool", http://ee.lbl.gov/, 2006.
[Linux2006] [Linux] Linux Kernel Organization, "The Linux Kernel Archives",
The Linux Project, "http://www.kernel.org". <http://www.kernel.org>.
[Microsoft1999] [Microsoft1999]
Microsoft, "Microsoft Security Program: Microsoft Security Microsoft, "Microsoft Security Program: Microsoft Security
Bulletin (MS99-038). Patch Available for "Spoofed Route Bulletin (MS99-038). Patch Available for "Spoofed Route
Pointer" Vulnerability", http://www.microsoft.com/ Pointer" Vulnerability", 1999, <http://www.microsoft.com/
technet/security/bulletin/ms99-038.mspx, 1999. technet/security/bulletin/ms99-038.mspx>.
[NISCC2004] [NISCC2004]
NISCC, "NISCC Vulnerability Advisory 236929: Vulnerability NISCC, "NISCC Vulnerability Advisory 236929: Vulnerability
Issues in TCP", Issues in TCP", 2004, <http://www.cpni.gov.uk>.
http://www.uniras.gov.uk/niscc/docs/
re-20040420-00391.pdf, 2004.
[NISCC2005] [NISCC2005]
NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP:
Vulnerability Issues in ICMP packets with TCP payloads", Vulnerability Issues in ICMP packets with TCP payloads",
http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf, 2005, <http://www.gont.com.ar/advisories/index.html>.
2005.
[NISCC2006] [NISCC2006]
NISCC, "NISCC Technical Note 01/2006: Egress and Ingress NISCC, "NISCC Technical Note 01/2006: Egress and Ingress
Filtering", http://www.niscc.gov.uk/niscc/docs/ Filtering", 2006, <http://www.cpni.gov.uk>.
re-20060420-00294.pdf?lang=en, 2006.
[Northcutt2000] [Northcutt2000]
Northcut, S. and Novak, "Network Intrusion Detection - An Northcut, S. and Novak, "Network Intrusion Detection - An
Analyst's Handbook", Second Edition New Riders Publishing, Analyst's Handbook", Second Edition New Riders Publishing,
2000. 2000.
[Novak2005] [Novak2005]
Novak, "Target-Based Fragmentation Reassembly", Novak, "Target-Based Fragmentation Reassembly", 2005,
http://www.snort.org/reg/docs/target_based_frag.pdf, <http://www.snort.org/assets/165/target_based_frag.pdf>.
2005.
[OpenBSD-PF] [OpenBSD-PF]
Sanfilippo, S., "PF: Scrub (Packet Normalization)", Sanfilippo, S., "PF: Scrub (Packet Normalization)", 2010,
http://www.openbsd.org/faq/pf/scrub.html, 2010. <ftp://ftp.openbsd.org/pub/OpenBSD/doc/pf-faq.pdf>.
[OpenBSD1998] [OpenBSD1998]
OpenBSD, "OpenBSD Security Advisory: IP Source Routing OpenBSD, "OpenBSD Security Advisory: IP Source Routing
Problem", Problem", 1998,
http://www.openbsd.org/advisories/sourceroute.txt, 1998. <http://www.openbsd.org/advisories/sourceroute.txt>.
[Paxson2001] [Paxson2001]
Paxson, V., Handley, M., and C. Kreibich, "Network Paxson, V., Handley, M., and C. Kreibich, "Network
Intrusion Detection: Evasion, Traffic Normalization, and Intrusion Detection: Evasion, Traffic Normalization, and
End-to-End Protocol Semantics", USENIX Conference, 2001, End-to-End Protocol Semantics", USENIX Conference, 2001.
2001.
[Ptacek1998] [Ptacek1998]
Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial
of Service: Eluding Network Intrusion Detection", of Service: Eluding Network Intrusion Detection", 1998,
http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps, <http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps>.
1998.
[RFC0815] Clark, D., "IP datagram reassembly algorithms", RFC 815, [RFC0815] Clark, D., "IP datagram reassembly algorithms", RFC 815,
July 1982. July 1982.
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858, Considerations for IP Fragment Filtering", RFC 1858,
October 1995. October 1995.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999. Network Interconnect Devices", RFC 2544, March 1999.
[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 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack (RFC 1858)", RFC 3128, June 2001. Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003. (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, April 2006.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963, July 2007. Errors at High Data Rates", RFC 4963, July 2007.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, August 2007. Mitigations", RFC 4987, August 2007.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009. Architecture", RFC 5559, June 2009.
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common
skipping to change at page 75, line 18 skipping to change at page 74, line 5
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-
Nodes", RFC 5670, November 2009. Nodes", RFC 5670, November 2009.
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion Information", Encoding and Transport of Pre-Congestion Information",
RFC 5696, November 2009. RFC 5696, November 2009.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[SELinux2008] [ROUTER-ALERT]
Security Enhanced Linux, "http://www.nsa.gov/selinux/". Le Faucheur, F., Ed., "IP Router Alert Considerations and
Usage", Work in Progress, June 2011.
[SELinux2009]
NSA, "Security-Enhanced Linux",
<http://www.nsa.gov/research/selinux/>.
[Sanfilippo1998a] [Sanfilippo1998a]
Sanfilippo, S., "about the ip header id", Post to Bugtraq Sanfilippo, S., "about the ip header id", Post to Bugtraq
mailing-list, Mon Dec 14 mailing-list, Mon Dec 14 1998,
1998 http://www.kyuzz.org/antirez/papers/ipid.html, 1998. <http://www.kyuzz.org/antirez/papers/ipid.html>.
[Sanfilippo1998b] [Sanfilippo1998b]
Sanfilippo, S., "Idle scan", Post to Bugtraq mailing- Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list,
list http://www.kyuzz.org/antirez/papers/dumbscan.html, 1998, <http://www.kyuzz.org/antirez/papers/dumbscan.html>.
1998.
[Sanfilippo1999] [Sanfilippo1999]
Sanfilippo, S., "more ip id", Post to Bugtraq mailing- Sanfilippo, S., "more ip id", Post to Bugtraq mailing-
list http://www.kyuzz.org/antirez/papers/moreipid.html, list, 1999,
1999. <http://www.kyuzz.org/antirez/papers/moreipid.html>.
[Shankar2003] [Shankar2003]
Shankar, U. and V. Paxson, "Active Mapping: Resisting NIDS Shankar, U. and V. Paxson, "Active Mapping: Resisting NIDS
Evasion Without Altering Traffic", Evasion Without Altering Traffic", 2003,
http://www.icir.org/vern/papers/activemap-oak03.pdf, <http://www.icir.org/vern/papers/activemap-oak03.pdf>.
2003.
[Shannon2001] [Shannon2001]
Shannon, C., Moore, D., and K. Claffy, "Characteristics of Shannon, C., Moore, D., and K. Claffy, "Characteristics of
Fragmented IP Traffic on Internet Links", 2001. Fragmented IP Traffic on Internet Links", 2001.
[Silbersack2005] [Silbersack2005]
Silbersack, M., "Improving TCP/IP security through Silbersack, M., "Improving TCP/IP security through
randomization without sacrificing interoperability", randomization without sacrificing interoperability",
EuroBSDCon 2005 Conference http://www.silby.com/ EuroBSDCon 2005 Conference, 2005,
eurobsdcon05/eurobsdcon_slides.pdf, 2005. <http://www.silby.com/eurobsdcon05/eurobsdcon_slides.pdf>.
[Solaris2008] [Snort] Sourcefire, Inc., "Snort", <http://www.snort.org>.
Solaris Trusted Extensions - Labeled Security for Absolute
Protection, "http://www.sun.com/software/solaris/ds/
trusted_extensions.jsp#3", 2008.
[Song1999] [Solaris2007]
Song, D., "Frag router tool", Oracle, "ORACLE SOLARIS WITH TRUSTED EXTENSIONS", 2007, <h
http://www.anzen.com/research/nidsbench/. ttp://www.oracle.com/us/products/servers-storage/solaris/
solaris-trusted-ext-ds-075583.pdf>.
[Song1999] Song, D., "Frag router tool",
<http://www.monkey.org/~dugsong/fragroute/>.
[SpooferProject] [SpooferProject]
MIT ANA, "The MIT ANA Spoofer project", MIT ANA, "Spoofer Project", 2010,
http://spoofer.csail.mit.edu/index.php, 2010. <http://spoofer.csail.mit.edu/index.php>.
[US-CERT2001] [US-CERT2001]
US-CERT, "US-CERT Vulnerability Note VU#446689: Check US-CERT, "US-CERT Vulnerability Note VU#446689: Check
Point FireWall-1 allows fragmented packets through Point FireWall-1 allows fragmented packets through
firewall if Fast Mode is enabled", firewall if Fast Mode is enabled", 2001,
http://www.kb.cert.org/vuls/id/446689, 2001. <http://www.kb.cert.org/vuls/id/446689>.
[US-CERT2002] [US-CERT2002]
US-CERT, "US-CERT Vulnerability Note VU#310387: Cisco IOS US-CERT, "US-CERT Vulnerability Note VU#310387: Cisco IOS
discloses fragments of previous packets when Express discloses fragments of previous packets when Express
Forwarding is enabled", Forwarding is enabled", 2002.
http://www.kb.cert.org/vuls/id/310387, 2002.
[Watson2004] [Watson2004]
Watson, P., "Slipping in the Window: TCP Reset Attacks", Watson, P., "Slipping in the Window: TCP Reset Attacks",
CanSecWest Conference , 2004. CanSecWest Conference, 2004.
[Zakrzewski2002] [Zakrzewski2002]
Zakrzewski, M. and I. Haddad, "Linux Distributed Security Zakrzewski, M. and I. Haddad, "Linux Distributed Security
Module", http://www.linuxjournal.com/article/6215, 2002. Module", 2002, <http://www.linuxjournal.com/article/6215>.
[daemon91996] [daemon91996]
daemon9, route, and infinity, "IP-spoofing Demystified daemon9, route, and infinity, "IP-spoofing Demystified
(Trust-Relationship Exploitation)", Phrack Magazine, (Trust-Relationship Exploitation)", Phrack Magazine,
Volume Seven, Issue Forty-Eight, File 14 of 18 http:// Volume Seven, Issue Forty-Eight, File 14 of 18, 1988, <htt
www.phrack.org/issues.html?issue=48&id=14&mode=txt, 1988. p://www.phrack.org/issues.html?issue=48&id=14&mode=txt>.
Appendix A. Changes from previous versions of the draft
This whole appendix should be removed by the RFC Editor before
publishing this document as an RFC.
A.1. Changes from draft-ietf-opsec-ip-security-05
o Addresses IESG review comments by Tim Polk (?).
A.2. Changes from draft-ietf-opsec-ip-security-04
o Addresses IESG review comments by Jari Arkko, Stewart Bryant,
Adrian Farrel, Peter Saint-Andre, and Sean Turner.
A.3. Changes from draft-ietf-opsec-ip-security-03
o Addresses feedback received off-list by Warren Kumari.
A.4. Changes from draft-ietf-opsec-ip-security-02
o Addresses a very thorough review by Alfred Hoenes (sent off-list)
o Miscellaneous edits (centers expressions, fills missing graphics
with ASCII-art, etc.)
A.5. 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.)
A.6. 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)
A.7. 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.
A.8. Changes from draft-gont-opsec-ip-security-00
o Fixed author's affiliation.
o Added Figure 6.
o Fixed a few typos.
o (no technical changes)
Author's Address Author's Address
Fernando Gont Fernando Gont
UK Centre for the Protection of National Infrastructure UK Centre for the Protection of National Infrastructure
Email: fernando@gont.com.ar EMail: fernando@gont.com.ar
URI: http://www.cpni.gov.uk URI: http://www.cpni.gov.uk
 End of changes. 261 change blocks. 
693 lines changed or deleted 586 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/