wdiff draft-ietf-opsec-ip-security-01.txt draft-ietf-opsec-ip-security-02.txt

Operational Security Capabilities F. Gont
for IP Network Infrastructure UK CPNI
(opsec) August February 20, 2009 2010
Internet-Draft
Intended status: Informational
Expires: February 21, August 24, 2010

Security Assessment of the Internet Protocol version 4
draft-ietf-opsec-ip-security-01.txt
draft-ietf-opsec-ip-security-02.txt

Abstract

This document contains a security assessment of the IETF
specifications of the Internet Protocol version 4, and of a number of
mechanisms and policies in use by popular IPv4 implementations. It
is based on the results of a project carried out by the UK's Centre
for the Protection of National Infrastructure (CPNI).

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on February 21, August 24, 2010.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.

Abstract

This Code Components extracted from this document contains a security assessment of the IETF
specifications must
include Simplified BSD License text as described in Section 4.e of
the Internet Protocol version 4, and of a number of
mechanisms Trust Legal Provisions and policies are provided without warranty as
described in use by popular IPv4 implementations. It
is based on the results of a project carried out by the UK's Centre
for the Protection of National Infrastructure (CPNI). BSD License.

Table of Contents

1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5
1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 5
1.2. Scope of this document . . . . . . . . . . . . . . . . . . 6 7
1.3. Organization of this document . . . . . . . . . . . . . . 6 7
2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 6 7
3. Internet Protocol header fields . . . . . . . . . . . . . . . 7 8
3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 8 9
3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 8 9
3.3. TOS . . . Differentiated Services field . . . . . . . . . . . . . . 10
3.4. Explicit Congestion Notification (ECN) . . . . . . . . . . 9
3.4. 11
3.5. Total Length . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. 12
3.6. Identification (ID) . . . . . . . . . . . . . . . . . . . 11
3.5.1. 13
3.6.1. Some workarounds implemented by the industry . . . . . 12
3.5.2. 14
3.6.2. Possible security improvements . . . . . . . . . . . . 12
3.6. 14
3.7. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.7. 16
3.8. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 16
3.8. 18
3.9. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 17
3.9. Protocol 19
3.9.1. Fingerprinting the operating system in use by the
source host . . . . . . . . . . . . . . . . . . . . . 20
3.9.2. Fingerprinting the physical device from which the
packets originate . . . . . 21
3.10. Header Checksum . . . . . . . . . . . . . 20
3.9.3. Locating the source host in the network topology . . . 20
3.9.4. Evading Network Intrusion Detection Systems . . . . . 22
3.11. Source Address
3.9.5. Improving the security of applications that make
use of the Internet Protocol (IP) . . . . . . . . . . 22
3.10. Protocol . . . . . . . . . . . . 22
3.12. Destination Address . . . . . . . . . . . . . 23
3.11. Header Checksum . . . . . . 23
3.13. Options . . . . . . . . . . . . . . . 24
3.12. Source Address . . . . . . . . . . 23
3.13.1. General issues . . . . . . . . . . . . 24
3.13. Destination Address . . . . . . . . . . . . . . . . . . . 25
3.14. Options . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.14.1. General issues with IP options . . . . . . . . . . . . 24
3.13.1.1. 26
3.14.1.1. Processing requirements . . . . . . . . . . . . . 24
3.13.1.2. 26
3.14.1.2. Processing of the options by the upper layer
protocol . . . . . . . . . . . . . . . . . . . . 25
3.13.1.3. 27
3.14.1.3. General sanity checks on IP options . . . . . . . 25
3.13.2. 27
3.14.2. Issues with specific options . . . . . . . . . . . . . 27
3.13.2.1. 29
3.14.2.1. End of Option List (Type = 0) . . . . . . . . . . 27
3.13.2.2. 29
3.14.2.2. No Operation (Type = 1) . . . . . . . . . . . . . 27
3.13.2.3. 29
3.14.2.3. Loose Source Record Route (LSRR) (Type = 131) . . 27
3.13.2.4. 29
3.14.2.4. Strict Source and Record Route (SSRR) (Type =
137) . . . . . . . . . . . . . . . . . . . . . . 30
3.13.2.5. 32
3.14.2.5. Record Route (Type = 7) . . . . . . . . . . . . . 34
3.13.2.6.
3.14.2.6. Stream Identifier (Type = 136) . . . . . . . . . 35
3.13.2.7. 36
3.14.2.7. Internet Timestamp (Type = 68) . . . . . . . . . 36
3.13.2.8.
3.14.2.8. Router Alert (Type = 148) . . . . . . . . . . . . 39
3.13.2.9.
3.14.2.9. Probe MTU (Type =11) . . . . . . . . . . . . . . 40
3.13.2.10.
3.14.2.10. Reply MTU (Type = 12) . . . . . . . . . . . . . . 40
3.13.2.11.
3.14.2.11. Traceroute (Type = 82) . . . . . . . . . . . . . 40
3.13.2.12.
3.14.2.12. DoD Basic Security Option (Type = 130) . . . . . 40
3.13.2.13. 41
3.14.2.13. DoD Extended Security Option (Type = 133) . . . . 41
3.13.2.14. 42
3.14.2.14. Commercial IP Security Option (CIPSO) (Type =
134) . . . . . . . . . . . . . . . . . . . . . . 42
3.13.2.15.
3.14.2.15. Sender Directed Multi-Destination Delivery
(Type = 149) . . . . . . . . . . . . . . . . . . 43
3.14. Differentiated Services field
3.15. TOS . . . . . . . . . . . . . . . . 43
3.15. Explicit Congestion Notification (ECN) . . . . . . . . . . 44 . 43
4. Internet Protocol Mechanisms . . . . . . . . . . . . . . . . . 45
4.1. Fragment reassembly . . . . . . . . . . . . . . . . . . . 45
4.1.1. Security Implications of Fragment Reassembly . . . . . 46
4.1.1.1. Problems related with memory allocation . . . . . . . 46
4.1.2.
4.1.1.2. Problems that arise from the length of the IP
Identification field . . . . . . . . . . . . . . . . . 48
4.1.3.
4.1.1.3. Problems that arise from the complexity of
the reassembly algorithm . . . . . . . . . . . . . . . . . 49
4.1.4. 48
4.1.1.4. Problems that arise from the ambiguity of the
reassembly process . . . . . . . . . . . . . . . . . . 49
4.1.5.
4.1.1.5. Problems that arise from the size of the IP
fragments . . . . . . . . . . . . . . . . . . . . . . 50
4.1.6.
4.1.2. Possible security improvements . . . . . . . . . . . . 50
4.1.2.1. Memory allocation for fragment reassembly . . . . 50
4.1.2.2. Flushing the fragment buffer . . . . . . . . . . 51
4.1.2.3. A more selective fragment buffer flushing
strategy . . . . . . . . . . . . . . . . . . . . 52
4.1.2.4. Reducing the fragment timeout . . . . . . . . . . 54
4.1.2.5. Counter-measure for some IDS evasion
techniques . . . . . . . . . . . . . . . . . . . 55
4.1.2.6. Counter-measure for firewall-rules bypassing . . 55
4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 56 55
4.2.1. Precedence-ordered queue service . . . . . . . . . . . 56 55
4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 57 56
4.2.3. Address Resolution . . . . . . . . . . . . . . . . . . 57
4.2.4. Dropping packets . . . . . . . . . . . . . . . . . . . 58
4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.1. Unreachable addresses . . . . . . . . . . . . . . . . 58
4.3.2. Private address space . . . . . . . . . . . . . . . . 59 58
4.3.3. Class D addresses (224/4 address block) . . . . . . . 59
4.3.4. Class E addresses (240/4 address block) . . . . . . . 59
4.3.5. Broadcast and multicast addresses, and
connection-oriented protocols . . . . . . . . . . . . 60 59
4.3.6. Broadcast and network addresses . . . . . . . . . . . 60
4.3.7. Special Internet addresses . . . . . . . . . . . . . . 60
5. Security Considerations . . . . . . . . . . . . . . . . . . . 62
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.1. Normative References . . . . . . . . . . . . . . . . . . . 63
7.2. Informative References . . . . . . . . . . . . . . . . . . 64
Appendix A. Advice and guidance to vendors . . . . . . . . . . . 72
Appendix B. Changes from previous versions of the draft (to
be removed by the RFC Editor before publishing
this document as an RFC) . . . . . . . . . . . . . . 73
B.1. Changes from draft-ietf-opsec-ip-security-00 draft-ietf-opsec-ip-security-01 . . . . . . . 73
B.2. Changes from draft-gont-opsec-ip-security-01 draft-ietf-opsec-ip-security-00 . . . . . . . 73
B.3. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 73
B.4. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 73
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 73

1. Preface

1.1. Introduction

The TCP/IP protocols were conceived in an environment that was quite
different from the hostile environment they currently operate in.
However, the effectiveness of the protocols led to their early
adoption in production environments, to the point that, to some
extent, the current world's economy depends on them.

While many textbooks and articles have created the myth that the
Internet protocols were designed for warfare environments, the top
level goal for the DARPA Internet Program was the sharing of large
service machines on the ARPANET [Clark1988]. As a result, many
protocol specifications focus only on the operational aspects of the
protocols they specify, and overlook their security implications.

While the Internet technology evolved since it inception, the
Internet's building blocks are basically the same core protocols
adopted by the ARPANET more than two decades ago. During the last
twenty years, many vulnerabilities have been identified in the TCP/IP
stacks of a number of systems. Some of them were based in flaws in
some protocol implementations, affecting only a reduced number of
systems, while others were based in flaws in the protocols
themselves, affecting virtually every existing implementation
[Bellovin1989]. Even in the last couple of years, researchers were
still working on security problems in the core protocols
[I-D.ietf-tcpm-icmp-attacks] [Watson2004] [NISCC2004] [NISCC2005].

The discovery of vulnerabilities in the TCP/IP protocols led to
reports being published by a number of CSIRTs (Computer Security
Incident Response Teams) and vendors, which helped to raise awareness
about the threats and the best mitigations known at the time the
reports were published. Unfortunately, this also led to the
documentation of the discovered protocol vulnerabilities being spread
among a large number of documents, which are sometimes difficult to
identify.

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

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

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

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

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

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

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

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

1.2. Scope of this document

While there are a number of protocols that affect the way in which IP
systems operate, this document focuses only on the specifications of
the Internet Protocol (IP). For example, routing and bootstrapping
protocols are considered out of the scope of this project.

The following IETF RFCs were selected for assessment as part of this
work:

o RFC 791, "Internet Protocol. DARPA Internet Program. Protocol
Specification" (51 pages).

o RFC 815, "IP datagram reassembly algorithms" (9 pages).

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

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

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

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

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

1.3. Organization of this document

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

2. The Internet Protocol

The Internet Protocol (IP) provides a basic data transfer function,
in the form of data blocks called "datagrams", from a source host to
a destination host, across the possible intervening networks.
Additionally, it provides some functions that are useful for the
interconnection of heterogeneous networks, such as fragmentation and
reassembly.

The "datagram" has a number of characteristics that makes it
convenient for interconnecting systems [Clark1988]:

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

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

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

3. Internet Protocol header fields

The IETF specifications of the Internet Protocol define the syntax of
the protocol header, along with the semantics of each of its fields.
Figure 1 shows the format of an IP datagram.

Figure 1: Internet Protocol header format

Even when the minimum IP header size is 20 bytes, an IP module might
be handed an (illegitimate) "datagram" of less than 20 bytes.
Therefore, before doing any processing of the IP header fields, the
following check should be performed by the IP module on the packets
handed by the link layer:

LinkLayer.PayloadSize >= 20

If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented
reflecting the packet drop).

The following subsections contain further sanity checks that should
be performed on IP packets.

3.1. Version

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
field must be 4.

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
packet header.

In theory, different versions of IP could coexist on a network by
using the same "Protocol Type" at the Link-layer, but a different
value in the Version field of the IP header. Thus, a single IP
module could handle all versions of the Internet Protocol,
differentiating them by means of this field.

However, in practice different versions of IP are identified by a
different "Protocol Type" number in the link-layer protocol header.
For example, IPv4 datagrams are encapsulated in Ethernet frames using
a "Protocol Type" field of 0x0800, while IPv6 datagrams are
encapsulated in Ethernet frames using a "Protocol Type" field of
0x86DD [IANA2006a].

Therefore, if an IPv4 module receives a packet, the Version field
must be checked to be 4. If this check fails, the packet should be
silently dropped, and this event should be logged (e.g., a counter
could be incremented reflecting the packet drop).

3.2. IHL (Internet Header Length)

The IHL (Internet Header Length) indicates the length of the internet
header in 32-bit words (4 bytes). As the minimum datagram size is 20
bytes, the minimum legal value for this field is 5. Therefore, the
following check should be enforced:

IHL >= 5

If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented
reflecting the packet drop).

For obvious reasons, the Internet header cannot be larger than the
whole Internet datagram it is part of. Therefore, the following
check should be enforced:

IHL * 4 <= Total Length

If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented
reflecting the packet drop).

The above check allows for Internet datagrams with no data bytes in
the payload that, while nonsensical for virtually every protocol that
runs over IP, it is still legal.

3.3. TOS

Figure 2 shows the syntax of Differentiated Services field

The Differentiated Services Architecture is intended to enable
scalable service discrimination in the Internet without the need for
per-flow state and signaling at every hop [RFC2475]. RFC 2474
[RFC2474] defines a Differentiated Services Field (DS Field), which
is intended to supersede the original Type of Service field, defined by
RFC 791 [RFC0791], and updated by RFC 1349 [RFC1349]. field. Figure
5 shows the format of the field.

0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | D | T | R
+---+---+---+---+---+---+---+---+
| C DSCP | 0 CU |
+-----+-----+-----+-----+-----+-----+-----+-----+
+---+---+---+---+---+---+---+---+

Figure 2: Type Structure of Service field

+----------+----------------------------------------------+
| Bits 0-2 | Precedence |
+----------+----------------------------------------------+
| Bit 3 | 0 = Normal Delay, 1 = Low Delay |
+----------+----------------------------------------------+
| Bit 4 | 0 = Normal Throughput, 1 = High Throughput |
+----------+----------------------------------------------+
| Bit 5 | 0 = Normal Reliability, 1 = High Reliability |
+----------+----------------------------------------------+
| Bit 6 | 0 = Normal Cost, 1 = Minimize Monetary Cost |
+----------+----------------------------------------------+
| Bits 7 | Reserved for Future Use (must be zero) |
+----------+----------------------------------------------+

Table 1: TOS bits

+-----+-----------------+
| 111 | Network Control |
+-----+-----------------+
| 110 | Internetwork |
+-----+-----------------+
| 101 | CRITIC/ECP |
+-----+-----------------+
| 100 | Flash Override |
+-----+-----------------+
| 011 | Flash |
+-----+-----------------+
| 010 | Immediate |
+-----+-----------------+
| 001 | Priority |
+-----+-----------------+
| 000 | Routine |
+-----+-----------------+

Table 2: Precedence field the DS Field

The Type of Service field can be DSCP ("Differentiated Services CodePoint").is used to affect select the way in which
treatment the packet is treated by to receive within the systems of a network that process it.
Section 4.2.1 ("Precedence-ordered queue service") and Section 4.2.3
("Weak TOS") of this document describe Differentiated Services
Domain. The CU ("Currently Unused") field was, at the security implications of time the Type of Service
specification was issued, reserved for future use. The DSCP field in is
used to select a PHB, by matching against the forwarding of packets.

3.4. Total Length

The Total Length entire 6-bit field.

Considering that the DSCP field determines how a packet is treated
within a DS domain, an attacker send packets with a forged DSCP field
to perform a theft of service or even a Denial of Service attack. In
particular, an attacker could forge packets with a codepoint of the length
type '11x000' which, according to Section 4.2.2.2 of RFC 2474
[RFC2474], would give the datagram, measured in
bytes, including both packets preferential forwarding treatment
when compared with the IP header and PHB selected by the IP payload. Being codepoint '000000'. If
strict priority queuing were utilized, a 16-
bit field, it allows for datagrams of up to 65535 bytes. RFC 791
[RFC0791] states that all hosts should be prepared to receive
datagrams continuous stream of up to 576 bytes (whether they arrive as such
pockets could perform a whole, or in
fragments). However, most modern implementations can reassemble
datagrams Denial of at least 9 Kbytes.

Usually, a host will not send Service to other flows which have a remote peer an IP datagram larger
than 576 bytes, unless it is explicitly signaled that
DSCP of lower relative order.

As the remote peer DS field is able to receive such "large" datagrams (for example, by means incompatible with the original Type of
TCP's MSS option). However, systems Service
field, both DS domains and networks using the original Type of
Service field should assume that they may protect themselves by remarking the
corresponding field where appropriate, probably deploying remarking
boundary nodes. Nevertheless, care must be
sent datagrams larger than 576 bytes, regardless of whether they
signal their remote peers to do taken so or not. In fact, it is common for
NFS [RFC3530]implementations to send datagrams larger than 576 bytes,
even without explicit signaling that packets
received with an unrecognized DSCP do not cause the destination handling system can
receive such "large" datagram.

Additionally, see the discussion in Section 4.1 "Fragment reassembly"
regarding the possible packet sizes resulting from fragment
reassembly.

Implementations should be aware that the IP module could be handed a
packet larger than the value actually contained in the Total Length
field. Such
to malfunction.

3.4. Explicit Congestion Notification (ECN)

RFC 3168 [RFC3168] specifies a difference usually has mechanism for routers to do with legitimate padding
bytes at signal
congestion to hosts sending IP packets, by marking the link-layer protocol, but it could also be offending
packets, rather than discarding them. RFC 3168 defines the result of
malicious activity by an attacker. Furthermore, even when ECN
field, which utilizes the
maximum length CU unused field of an IP datagram is 65535 bytes, if the link-layer
technology DSCP field described
in use allows for payloads larger than 65535 bytes, an
attacker could forge such a large link-layer packet, meaning it for
the IP module. If Section 3.14 of this document. Figure 6 shows the IP module syntax of the receiving system were not
prepared to handle such an oversized link-layer payload, an
unexpected failure might occur. Therefore,
ECN field, together with the memory buffer DSCP field used by
the for Differentiated
Services.

0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+

Figure 3: The Differentiated Services and ECN fields in 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

As such, the Total Length ECN field of the IP packet it contains. defines four codepoints:

+-----------+-----------+
| ECN field | Codepoint |
+-----------+-----------+
| 00 | Not-ECT |
+-----------+-----------+
| 01 | ECT(1) |
+-----------+-----------+
| 10 | ECT(0) |
+-----------+-----------+
| 11 | CE |
+-----------+-----------+

Table 1: ECN codepoints

The IP module could also be handled security implications of ECN are discussed in detail in a packet that is smaller than the
actual IP packet size claimed by the Total Length field. This could
be used, for example, to produce an information leakage. Therefore, number
of Sections of RFC 3168. Of the following check should be performed:

LinkLayer.PayloadSize >= Total Length

If this check fails, possible threats discussed in the IP packet should be dropped, and this event
should
ECN specification, we believe that one that can be logged (e.g., a counter easily exploited
is that of host falsely indicating ECN-Capability.

An attacker could be incremented reflecting set the
packet drop). As ECT codepoint in the previous expression implies, packets it sends, to
signal the number of
bytes passed by network that the link-layer to endpoints of the IP module should contain at
least as many bytes as claimed by transport protocol are
ECN-capable. Consequently, when experiencing moderate congestion,
routers using active queue management based on RED would mark the Total Length field
packets (with the CE codepoint) rather than discard them. In the
same scenario, packets of competing flows that do not have the IP
header.

[US-CERT2002] is ECT
codepoint set would be dropped. Therefore, an example attacker would get
better network service than the competing flows.

However, if this moderate congestion turned into heavy congestion,
routers should switch to drop packets, regardless of whether the exploitation
packets have the ECT codepoint set or not.

A number of a forged IP Total
Length field to produce other threats could arise if an information leakage attack.

3.5. Identification (ID)

The Identification field is set by attacker was a man in the sending host to aid
middle (i.e., was in the
reassembly of fragmented datagrams. At any time, it needs to be
unique for each set middle of {Source Address, Destination Address,
Protocol}.

In many systems, the value used for this field is determined at path the
IP layer, on packets travel to get
to the destination host). For a protocol-independent basis. Many detailed discussion of those systems
also simply increment cases,
we urge the IP Identification field for each packet
they send.

This implementation strategy is inappropriate for a number reader to consult Section 16 of
reasons. First, if the Identification RFC 3168.

3.5. Total Length

The Total Length field is set on a protocol-
independent basis, it will wrap more often than necessary, and thus the implementation will be more prone to length of the problems discussed datagram, measured in
[Kent1987]
bytes, including both the IP header and [RFC4963].

Additionally, this implementation strategy opens the door IP payload. Being a 16-
bit field, it allows for datagrams of up to an
information leakage 65535 bytes. RFC 791
[RFC0791] states that can all hosts should be exploited prepared to in a number receive
datagrams of ways.
[Sanfilippo1998a] originally pointed out how this field could be
examined up to determine the packet rate at which a given system is
transmitting information. Later, [Sanfilippo1998b] described how 576 bytes (whether they arrive as a
system with such an implementation whole, or in
fragments). However, most modern implementations can be used to perform a stealth
port scan to a third (victim) host. [Sanfilippo1999] explained how
to exploit this implementation strategy to uncover the rules reassemble
datagrams of at least 9 Kbytes.

Usually, a
number of firewalls. [Bellovin2002] explains how the IP
Identification field can be exploited host will not send to count the number of systems
behind a NAT. [Fyodor2004] is remote peer an entire paper on most (if not all)
the ways to exploit the information provided by the Identification
field of the IP header.

3.5.1. Some workarounds implemented by the industry

As the IP Identification field datagram larger
than 576 bytes, unless it is only used for the reassembly of
datagrams, some operating systems (such as Linux) decided to set this
field to 0 in all packets explicitly signaled that have the DF bit set. This would, in
principle, avoid any type remote peer
is able to receive such "large" datagrams (for example, by means of information leakage.
TCP's MSS option). However, it was
detected systems should assume that some non-RFC-compliant middle-boxes fragmented packets
even if they had the DF bit set. In such a scenario, all datagrams
originally may be
sent with the DF bit set would all result in fragments
that would have an Identification field datagrams larger than 576 bytes, regardless of 0, which would lead whether they
signal their remote peers to
problems ("collision" of do so or not. In fact, it is common for
NFS [RFC3530]implementations to send datagrams larger than 576 bytes,
even without explicit signaling that the Identification number) destination system can
receive such "large" datagram.

o Additionally, see the discussion in Section 4.1 "Fragment
reassembly" regarding the reassembly
process.

Linux (and Solaris) later set possible packet sizes resulting from
fragment reassembly.

Implementations should be aware that the IP Identification field on module could be handed a per-
IP-address basis. This avoids some of
packet larger than the security implications of value actually contained in the IP Identification field, but not all. For example, systems
behind Total Length
field. Such a load balancer can still be counted.

3.5.2. Possible security improvements

Contrary difference usually has to common wisdom, do with legitimate padding
bytes at the IP Identification field does not need
to be system-wide unique for each packet, link-layer protocol, but has to it could also be unique for
each {Source Address, Destination Address, Protocol} tuple.

For instance, the TCP specification defines a generic send() function
which takes the IP ID as one result of its arguments.

We provide
malicious activity by an analysis of the possible security improvements that
could be implemented, based on whether the protocol using attacker. Furthermore, even when the
services
maximum length of an IP datagram is connection-oriented or connection-less.

Connection-oriented protocols

To avoid the security implications of the information leakage
described above, a pseudo-random number generator (PRNG) could be
used to set the IP Identification field on a {Source Address,
Destination Address} basis (for each connection-oriented transport
protocol).

[Klein2007] is a security advisory that describes a weakness in 65535 bytes, if the
pseudo random number generator (PRNG) link-layer
technology in use allows for payloads larger than 65535 bytes, an
attacker could forge such a large link-layer packet, meaning it for
the generation of IP module. If the IP Identification by a number module of operating systems.

While in theory a pseudo-random number generator could lead to
scenarios in which a given Identification number is used more than
once in the same time-span for datagrams that end up getting
fragmented (with the corresponding potential reassembly problems), in
practice this is unlikely receiving system were not
prepared to cause trouble.

By default, most implementations of connection-oriented protocols, handle such as TCP, implement some mechanism for avoiding fragmentation
(such as the Path-MTU Discovery mechanism described in [RFC1191]).
Thus, fragmentation will only take place sporadically, when a non-
RFC-compliant middle-box is placed somewhere along an oversized link-layer payload, an
unexpected failure might occur. Therefore, the path that memory buffer used by
the
packets travel to get IP module to store the destination host. Once the sending
system is signaled by the middle-box that it link-layer payload should reduce be allocated
according to the payload size
of reported by the packets it sends, fragmentation would be avoided. Also, for
reassembly problems link-layer, rather than
according to arise, the same Identification Total Length field should be
reused very frequently, and either strong of the IP packet reordering or it contains.

The IP module could also be handled a packet
loss should take place.

Nevertheless, regardless of what policy that is used for selecting smaller than the
Identification field, with
actual IP packet size claimed by the current link speeds fragmentation is
already bad enough to rely on it. A mechanism Total Length field. This could
be used, for avoiding
fragmentation example, to produce an information leakage. Therefore,
the following check should be implemented, instead.

Connectionless protocols

Connectionless protocols usually have these characteristics:

o lack of flow-control mechanisms,

o lack of packet sequencing mechanisms, and,

o lack of reliability mechanisms (such as "timeout and retransmit").

This basically means that performed:

LinkLayer.PayloadSize >= Total Length

If this check fails, the scenarios and/or applications for which
connection-less transport protocols are used assume that:

o Applications will be used in environments in which IP packet
reordering is very unlikely (such as Local Area Networks), as the
transport protocol itself does not provide data sequencing.

o The data transfer rates will be low enough that flow control will should be unnecessary.

o Packet loss is not important dropped, and probably also unlikely.

With these assumptions in mind, the Identification field could still this event
should be set according to logged (e.g., a pseudo-random number generator (PRNG). In counter could be incremented reflecting the
event a given Identification number was reused while
packet drop). As the first
instance of previous expression implies, the same number is still on the network, the first IP
datagram would be reassembled before the fragments of
bytes passed by the second IP
datagram get link-layer to their destination.

In the event this was not the case, IP module should contain at
least as many bytes as claimed by the reassembly Total Length field of fragments would
result in a corrupt datagram. While some existing work
[Silbersack2005] assumes that this error would be caught by some
upper-layer error detection code, the error detection code in
question (such as UDP's checksum) might be intended to detect single
bit errors, rather than data corruption arising from IP
header.

o [US-CERT2002] is an example of the replacement exploitation of a complete data block (as forged IP
Total Length field to produce an information leakage attack.

3.6. Identification (ID)

The Identification field is set by the case sending host to aid in corruption arising from
collision of IP Identification numbers).

In the case
reassembly of UDP, unfortunately some systems have been known fragmented datagrams. At any time, it needs to not
enable the UDP checksum by default. For most applications, packets
containing errors should be dropped. Probably the only application
that may benefit from disabling the checksum is streaming media, to
avoid dropping a complete sample
unique for a single-bit error. each set of {Source Address, Destination Address,
Protocol}.

In general, if IP Identification number collisions become an issue
for many systems, the application using value used for this field is determined at the connection-less protocol, then use of
IP layer, on a
different transport protocol (which hopefully avoids fragmentation)
should be considered.

It must be noted that an attacker could intentionally exploit
collisions protocol-independent basis. Many of those systems
also simply increment the IP Identification numbers to perform field for each packet
they send.

This implementation strategy is inappropriate for a Denial number of
Service attack, by sending forged fragments that would cause
reasons. First, if the
reassembly process to result in Identification field is set on a corrupt datagram that would either
be dropped by protocol-
independent basis, it will wrap more often than necessary, and thus
the transport protocol, or would incorrectly implementation will be handed more prone to the corresponding application. This issue is problems discussed in detail
in section 4.1 ("Fragment Reassembly").

3.6. Flags

The IP header contains 3 control bits, two of which are currently
used for the fragmentation
[Kent1987] and reassembly function.

As described by RFC 791, their meaning is:

Bit 0: reserved, must be zero

Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment

Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments

The DF bit is usually set to implement [RFC4963].

Additionally, this implementation strategy opens the Path-MTU Discovery (PMTUD)
mechanism described in [RFC1191]. However, it door to an
information leakage that can also be exploited
by an attacker to evade Network Intrusion Detection Systems. An
attacker could send in a number of ways.
[Sanfilippo1998a] originally pointed out how this field could be
examined to determine the packet rate at which a given system is
transmitting information. Later, [Sanfilippo1998b] described how a
system with the DF bit set such an implementation can be used to perform a system
monitored by stealth
port scan to a NIDS, and depending on the Path-MTU third (victim) host. [Sanfilippo1999] explained how
to exploit this implementation strategy to uncover the intended
recipient, rules of a
number of firewalls. [Bellovin2002] explains how the packet might IP
Identification field can be dropped by some intervening router
(because of being too big exploited to be forwarded without fragmentation),
without count the NIDS being aware number of it.

(still systems
behind a NAT. [Fyodor2004] is an entire paper on most (if not all)
the ways to be added)
(See Figure 3 in Page 13 of exploit the CPNI document)

Figure 3: NIDS evasion information provided by means of the Internet Protocol DF bit

In Figure 3, an attacker sends a 17914-byte datagram meant to the
victim host in Identification
field of the same figure. The attacker's packet probably
contains an overlapping IP fragment or an overlapping TCP segment,
aiming at "confusing" the NIDS, as described in [Ptacek1998]. The
packet is screened header.

3.6.1. Some workarounds implemented by the NIDS sensor at industry

As the network perimeter, which
probably reassembles IP fragments and TCP segments Identification field is only used for the purpose reassembly of
assessing the data transferred to and from the monitored systems.
However,
datagrams, some operating systems (such as the attacker's packet should transit a link with an MTU
smaller than 17914 bytes (1500 bytes in Linux) decided to set this example), the router
that encounters
field to 0 in all packets that this packet cannot be forwarded without
fragmentation (Router B) discards have the packet, and sends an ICMP
"fragmentation needed and DF bit set" error message to set. This would, in
principle, avoid any type of information leakage. However, it was
detected that some non-RFC-compliant middle-boxes fragmented packets
even if they had the source
host. DF bit set. In this such a scenario, all datagrams
originally sent with the NIDS may remain unaware DF bit set would all result in fragments
that the
screened packet never reached the intended destination, and thus get would have an incorrect picture Identification field of the data being transferred 0, which would lead to
problems ("collision" of the monitored
systems.

[Shankar2003] introduces Identification number) in the reassembly
process.

Linux (and Solaris) later set the IP Identification field on a technique named "Active Mapping" that
prevents evasion per-
IP-address basis. This avoids some of a NIDS by acquiring sufficient knowledge about the network being monitored, to assess which packets will arrive at security implications of
the intended recipient, and how they will IP Identification field, but not all. For example, systems
behind a load balancer can still be interpreted by it.

Some firewalls are known counted.

3.6.2. Possible security improvements

Contrary to drop packets that have both the MF (More
Fragments) and common wisdom, the DF (Don't fragment) bits set. While in principle
such a packet might seem nonsensical, there are a number of reasons IP Identification field does not need
to be system-wide unique for which non-malicious packets with these two bits set can each packet, but has to be found
in unique for
each {Source Address, Destination Address, Protocol} tuple.

o For instance, the TCP specification defines a network. First, they may exist as generic send()
function which takes the result IP ID as one of some middle-box
processing a packet its arguments.

We provide an analysis of the possible security improvements that was too large to
could be forwarded without
fragmentation. Instead of simply dropping implemented, based on whether the corresponding packet
and sending an ICMP error message to protocol using the source host, some middle-
boxes fragment
services of IP is connection-oriented or connection-less.

Connection-oriented protocols

To avoid the packet (copying security implications of the DF bit information leakage
described above, a pseudo-random number generator (PRNG) could be
used to set the IP Identification field on a {Source Address,
Destination Address} basis (for each fragment), and
also send an ICMP error message to connection-oriented transport
protocol).

o [Klein2007] is a security advisory that describes a weakness in
the originating system. Second,
some systems (notably Linux) set both pseudo random number generator (PRNG) in use for the MF and
generation of the DF bits IP Identification by a number of operating
systems.

While in theory a pseudo-random number generator could lead to
implement Path-MTU Discovery (PMTUD) for UDP. These
scenarios should
be taken into account when configuring firewalls and/or tuning
Network Intrusion Detection Systems (NIDS).

3.7. Fragment Offset

The Fragment Offset in which a given Identification number is used more than
once in the same time-span for datagrams that end up getting
fragmented (with the fragmentation and corresponding potential reassembly of
IP datagrams. It indicates where problems), in the original datagram the
fragment belongs, and
practice this is measured in units unlikely to cause trouble.

By default, most implementations of eight bytes. As connection-oriented protocols,
such as TCP, implement some mechanism for avoiding fragmentation
(such as the Path-MTU Discovery mechanism described in [RFC1191]).
Thus, fragmentation will only take place sporadically, when a
consequence, all fragments (except non-
RFC-compliant middle-box is placed somewhere along the last one), have path that the
packets travel to get to be aligned
on an 8-byte boundary. Therefore, if a packet has the MF flag set, destination host. Once the following check sending
system is signaled by the middle-box that it should be enforced:

(Total Length - IHL * 4) % 8 == 0

If reduce the packet does not pass this check, size
of the packets it should sends, fragmentation would be dropped, and
this event avoided. Also, for
reassembly problems to arise, the same Identification field should be logged (e.g., a counter could be incremented
reflecting the
reused very frequently, and either strong packet drop).

Given that Fragment Offset is a 13-bit field, it can hold a value reordering or packet
loss should take place.

Nevertheless, regardless of
up to 8191, which would correspond to an offset 65528 bytes within
the original (non-fragmented) datagram. As such, it what policy is possible for
a fragment to implicitly claim to belong to a datagram larger than
65535 bytes (the maximum size used for a legitimate IP datagram). Even
when the fragmentation mechanism would seem to allow fragments that
could reassemble into such large datagrams, selecting the intent of
Identification field, with the
specification current link speeds fragmentation is
already bad enough to allow rely on it. A mechanism for the transmission avoiding
fragmentation should be implemented, instead.

Connectionless protocols

Connectionless protocols usually have these characteristics:

o lack of datagrams flow-control mechanisms,

o lack of up to
65535 bytes. Therefore, if a given fragment would reassemble into a
datagram packet sequencing mechanisms, and,

o lack of more than 65535 bytes, the resulting datagram should be
dropped, reliability mechanisms (such as "timeout and this event should be logged (e.g., a counter could be
incremented reflecting the packet drop). To detect such a case, retransmit").

This basically means that the
following check should be enforced on all packets scenarios and/or applications for which
connection-less transport protocols are used assume that:

o Applications will be used in environments in which packet
reordering is very unlikely (such as Local Area Networks), as the
Fragment Offset contains a non-zero value:

Fragment Offset * 8 + (Total Length - IHL * 4) <= 65535

In the worst-case scenario,
transport protocol itself does not provide data sequencing.

o The data transfer rates will be low enough that flow control will
be unnecessary.

o Packet loss is not important and probably also unlikely.

With these assumptions in mind, the reassembled datagram Identification field could have a
size of up still
be set according to 131043 bytes.

Such a datagram would result when pseudo-random number generator (PRNG). In the first fragment has a Fragment
Offset of 0 and
event a Total Length of 65532, and given Identification number was reused while the second (and last)
fragment has a Fragment Offset of 8189 (65512 bytes), and a Total
Length of 65535. Assuming an IHL of 5 (i.e., a header length first
instance of 20
bytes), the reassembled same number is still on the network, the first IP
datagram would be 65532 + (65535 - 20) =
131047 bytes.

Additionally, reassembled before the IP module should implement all fragments of the necessary
measures to be able to handle such illegitimate reassembled
datagrams, so as second IP
datagram get to avoid them from overflowing their destination.

In the buffer(s) used
for event this was not the reassembly function.

[CERT1996c] and [Kenney1996] describe case, the exploitation reassembly of this issue
to perform fragments would
result in a Denial of Service (DoS) attack.

3.8. Time to Live (TTL)

The Time to Live (TTL) field has two functions: to bind the lifetime
of the corrupt datagram. While some existing work
[Silbersack2005] assumes that this error would be caught by some
upper-layer packets (e.g., TCP segments) and error detection code, the error detection code in
question (such as UDP's checksum) might be intended to prevent
packets detect single
bit errors, rather than data corruption arising from looping indefinitely in the network.

Originally, this field was meant to indicate maximum time replacement
of a datagram
was allowed to remain in complete data block (as is the internet system, case in units corruption arising from
collision of seconds.
As every internet module that processes a datagram must decrement the
TTL by at least one, IP Identification numbers).

o In the original definition case of the TTL field became
obsolete, and it must now be interpreted as a hop count.

Most UDP, unfortunately some systems allow the administrator to configure the TTL have been known to be used
for
not enable the UDP checksum by default. For most applications,
packets sent, with the default value usually being a power of
2. The recommended value for containing errors should be dropped. Probably the TTL field, as specified by only
application that may benefit from disabling the IANA checksum is 64 [IANA2006b]. This value reflects the assumed "diameter" of the
Internet, plus a margin
streaming media, to accommodate its growth.

The TTL field has avoid dropping a number of properties that are interesting from complete sample for a
security point of view. Given that the default value used single-
bit error.

In general, if IP Identification number collisions become an issue
for the
TTL is usually application using the connection-less protocol, then use of a power
different transport protocol (which hopefully avoids fragmentation)
should be considered.

It must be noted that an attacker could intentionally exploit
collisions of eight, chances are that, unless the
originating system has been explicitly tuned IP Identification numbers to use a non-default
value, if a packet arrives with perform a TTL Denial of 60,
Service attack, by sending forged fragments that would cause the packet was
originally sent with
reassembly process to result in a TTL of 64. In corrupt datagram that would either
be dropped by the same way, if a packet transport protocol, or would incorrectly be handed
to the corresponding application. This issue is
received with a TTL discussed in detail
in section 4.1 ("Fragment Reassembly").

3.7. Flags

The IP header contains 3 control bits, two of 120, chances which are that currently
used for the original packet had
a TTL of 128.

This discussion assumes there was no protocol scrubber, transparent
proxy, or some other middle-box that overwrites fragmentation and reassembly function.

As described by RFC 791, their meaning is:

Bit 0: reserved, must be zero

Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment
Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments

The DF bit is usually set to implement the TTL field Path-MTU Discovery (PMTUD)
mechanism described in [RFC1191]. However, it can also be exploited
by an attacker to evade Network Intrusion Detection Systems. An
attacker could send a
non-standard way, between packet with the originating DF bit set to a system
monitored by a NIDS, and depending on the point of Path-MTU to the
network in which intended
recipient, the packet was received.

Asserting the TTL with which a packet was originally sent might be dropped by the
source system can help some intervening router
(because of being too big to obtain valuable information. Among other
things, it may help in:

o Fingerprinting be forwarded without fragmentation),
without the operating system NIDS being used by the source host.

o Fingerprinting the physical device from which the packets
originate.

o Locating the source host in the network topology.

Additionally, it can be used aware of it.

(still to perform functions such as:

o Evading Network Intrusion Detection Systems.

o Improving the security be added)
(See Figure 3 in Page 13 of applications that make use the CPNI document)

Figure 4: NIDS evasion by means of the Internet Protocol (IP).

Fingerprinting the operating system in use by the source host

Different operating systems use DF bit

In Figure 3, an attacker sends a different default TTL for 17914-byte datagram meant to the
packets they send. Thus, asserting
victim host in the TTL with which a same figure. The attacker's packet was
originally sent will help to reduce probably
contains an overlapping IP fragment or an overlapping TCP segment,
aiming at "confusing" the number of possible operating
systems NIDS, as described in use [Ptacek1998]. The
packet is screened by the source host.

Fingerprinting NIDS sensor at the physical device from network perimeter, which
probably reassembles IP fragments and TCP segments for the packets originate

When several systems are behind a middle-box such as a NAT or a load
balancer, purpose of
assessing the TTL may help data transferred to count the number of systems behind and from the
middle-box. If each of monitored systems.
However, as the systems behind the middle-box use a
different default TTL for the packets they send, or they are located
in attacker's packet should transit a different place of the network topology, link with an attacker could
stimulate responses from MTU
smaller than 17914 bytes (1500 bytes in this example), the devices being fingerprinted, and each
response router
that arrives with a different TTL could encounters that this packet cannot be assumed to come
from a different device.

Of course, there are many other forwarded without
fragmentation (Router B) discards the packet, and much more precise techniques sends an ICMP
"fragmentation needed and DF bit set" error message to
fingerprint physical devices. Among drawbacks of the source
host. In this method, while
many systems differ in scenario, the default TTL they use for NIDS may remain unaware that the packets they
send, there are also many implementations which use
screened packet never reached the same default
TTL. Additionally, packets sent by a given device may take different
routes (e.g., due to load sharing or route changes), intended destination, and thus a given
packet may incorrectly be presumed get
an incorrect picture of the data being transferred to come from the monitored
systems.

o [Shankar2003] introduces a different device,
when in fact it just traveled technique named "Active Mapping" that
prevents evasion of a different route.

Locating the source host in NIDS by acquiring sufficient knowledge about
the network topology

The TTL field may also be used being monitored, to locate assess which packets will arrive
at the source system in intended recipient, and how they will be interpreted by it.

Some firewalls are known to drop packets that have both the
network topology [Northcutt2000].

+---+ +---+ +---+ +---+ +---+
| A |-----| R |------| R |----| R |-----| R |
+---+ +---+ +---+ +---+ +---+
/ | / \
/ | / \
/ | / +---+
/ +---+ +---+ +---+ | E |
/ | R |----| R |------| R |-- +---+
/ +---+ +---+\ +---+ \
/ / / \ \ \
/ ---- / +---+ \ \+---+
/ / / | F | \ | D |
+---+ +---+ +---+ \ +---|
| R |----------| R |-- \
+---+ +---+ \ \
| \ / \ +---+| +---+
| \ / ----| R |------| R |
| \ / +---+ +---+
+---+ \ +---+ +---+
| B | \| R |----| C |
+---+ +---+ +---+

Figure 4: Tracking a host by means of MF (More
Fragments) and the TTL field

Consider network topology DF (Don't fragment) bits set. While in principle
such a packet might seem nonsensical, there are a number of Figure 4. Assuming that an attacker
("F" reasons
for which non-malicious packets with these two bits set can be found
in a network. First, they may exist as the figure) is performing some type result of attack that requires
forging the Source Address (such as a TCP-based DoS reflection
attack), and some middle-box
processing a packet that was too large to be forwarded without
fragmentation. Instead of simply dropping the involved hosts are willing to cooperate corresponding packet
and sending an ICMP error message to
locate the attacking system.

Assuming that:

o All source host, some middle-
boxes fragment the packets A gets have a TTL of 61.

o All the packets B gets have a TTL of 61.

o All the packets C gets have a TTL of 61.

o All packet (copying the packets D gets have a TTL of 62.

Based on this information, DF bit to each fragment), and assuming that the system's default
value was not overridden, it would be fair
also send an ICMP error message to assume that the
original TTL of the packets was 64. With this information, the
number of hops between originating system. Second,
some systems (notably Linux) set both the attacker MF and each of the aforementioned
hosts can DF bits to
implement Path-MTU Discovery (PMTUD) for UDP. These scenarios should
be calculated. taken into account when configuring firewalls and/or tuning
Network Intrusion Detection Systems (NIDS).

3.8. Fragment Offset

The attacker is:

o Three hops away from A.

o Three hops away from B.

o Three hops away from C.

o Two hops away from D.

In Fragment Offset is used for the network setup fragmentation and reassembly of Figure 3, the only system that satisfies all
these conditions is
IP datagrams. It indicates where in the one marked as original datagram the "F".

The scenario described above
fragment belongs, and is for illustration purposes only. In
practice, there are a number measured in units of factors that may prevent this
technique from being successfully applied:

o Unless there is eight bytes. As a "large" number of cooperating systems, and
consequence, all fragments (except the
attacker is assumed last one), have to be no more than aligned
on an 8-byte boundary. Therefore, if a few hops away from these
a systems, packet has the number of "candidate" hosts will usually MF flag set,
the following check should be too
large for enforced:

(Total Length - IHL * 4) % 8 == 0

If the information to packet does not pass this check, it should be useful.

o The attacker may dropped, and
this event should be using logged (e.g., a non-default TTL value, or, what counter could be incremented
reflecting the packet drop).

Given that Fragment Offset is
worse, using a pseudo-random value for the TTL of the packets 13-bit field, it
sends.

o The packets sent by the attacker may take different routes, as can hold a
result value of a change in network topology, load sharing, etc., and
thus may lead
up to an incorrect analysis.

Evading Network Intrusion Detection Systems

The TTL field can be used 8191, which would correspond to evade Network Intrusion Detection
Systems. Depending on an offset 65528 bytes within
the position of original (non-fragmented) datagram. As such, it is possible for
a sensor relative fragment to implicitly claim to belong to the
destination host of the examined packet, the NIDS may get a different
picture from that got by the intended destination system. As an
example, a sensor may process datagram larger than
65535 bytes (the maximum size for a packet that will expire before
getting legitimate IP datagram). Even
when the fragmentation mechanism would seem to allow fragments that
could reassemble into such large datagrams, the destination host. A general counter-measure for this
type intent of attack the
specification is to normalize allow for the traffic that gets to an
organizational network. Examples transmission of such traffic normalization can
be found in [Paxson2001].

Improving the security of applications that make use datagrams of the Internet
Protocol (IP)

In some scenarios, the TTL field can be also used up to improve the
security of an application, by restricting the hosts that can
communicate with the
65535 bytes. Therefore, if a given application. For example, there are
applications for which the communicating systems are typically in the
same network segment (i.e., there are no intervening routers). Such
an application is the BGP (Border Gateway Protocol) between utilized
by two peer routers.

If both systems use fragment would reassemble into a TTL
datagram of 255 for all more than 65535 bytes, the packets they send to
each other, then resulting datagram should be
dropped, and this event should be logged (e.g., a check counter could be
incremented reflecting the packet drop). To detect such a case, the
following check should be enforced to require on all packets
meant for which the application in question to have
Fragment Offset contains a TTL of 255.

As all packets sent by systems that are not in non-zero value:

Fragment Offset * 8 + (Total Length - IHL * 4) <= 65535

In the same network
segment will worst-case scenario, the reassembled datagram could have a TTL smaller than 255, those packets will not pass
the check enforced by these two cooperating peers. This check
reduces the set
size of systems that may perform attacks against the
protected application (BGP in this case), thus mitigating up to 131043 bytes.

o Such a datagram would result when the attack
vectors described in [NISCC2004] first fragment has a
Fragment Offset of 0 and [Watson2004].

This same check is enforced for related ICMP error messages, with the
intent a Total Length of mitigating the attack vectors described in [NISCC2005] 65532, and
[I-D.ietf-tcpm-icmp-attacks].

The TTL field can be used in a similar way in scenarios in which the
cooperating systems either do not use second
(and last) fragment has a default TTL Fragment Offset of 255, or are
not in the same network segment 8189 (65512 bytes),
and a Total Length of 65535. Assuming an IHL of 5 (i.e., multi-hop peering). In that
case, a header
length of 20 bytes), the following check could reassembled datagram would be enforced:

TTL >= 255 65532 +
(65535 - DeltaHops

This means that 20) = 131047 bytes.

Additionally, the set of hosts from which packets will be accepted
for IP module should implement all the protected application will be reduced necessary
measures to those that are no
more than DeltaHops away. While for obvious reasons the level of
protection will be smaller than in the case of directly-connected
peers, the use of able to handle such illegitimate reassembled
datagrams, so as to avoid them from overflowing the TTL field buffer(s) used
for protecting multi-hop peering
still reduces the set reassembly function.

o [CERT1996c] and [Kenney1996] describe the exploitation of hosts that could potentially this
issue to perform a
number of attacks against the protected application.

This use Denial of the TTL Service (DoS) attack.

3.9. Time to Live (TTL)

The Time to Live (TTL) field has been officially documented by the IETF
under the name "Generalized TTL Security Mechanism" (GTSM) in
[RFC5082].

Some protocol scrubbers enforce a minimum value for two functions: to bind the TTL field lifetime
of the upper-layer packets they forward. It must be understood that depending on
the minimum TTL being enforced, (e.g., TCP segments) and depending on the particular
network setup, to prevent
packets from looping indefinitely in the protocol scrubber may actually help attackers network.

Originally, this field was meant to
fool indicate maximum time a datagram
was allowed to remain in the GTSM, by "raising" internet system, in units of seconds.
As every internet module that processes a datagram must decrement the
TTL by at least one, the original definition of the attacking packets.

3.9. Protocol

The Protocol TTL field indicates became
obsolete, and it must now be interpreted as a hop count.

Most systems allow the protocol encapsulated in administrator to configure the
internet datagram. The Protocol field may not only contain a value
corresponding TTL to an implemented protocol within be used
for the system, but also
a packets sent, with the default value corresponding to a protocol not implemented, or even usually being a power of
2. The recommended value
not yet assigned for the TTL field, as specified by the IANA [IANA2006c].

While in theory there should not be security implications from
is 64 [IANA2006b]. This value reflects the
use assumed "diameter" of any the
Internet, plus a margin to accommodate its growth.

The TTL field has a number of properties that are interesting from a
security point of view. Given that the default value in used for the protocol field, there have
TTL is usually a power of eight, chances are that, unless the
originating system has been security
issues in explicitly tuned to use a non-default
value, if a packet arrives with a TTL of 60, the past packet was
originally sent with systems that had problems when handling
packets with some specific protocol numbers [Cisco2003] [CERT2003].

3.10. Header Checksum

The Header Checksum field is an error detection mechanism meant to
detect errors in the IP header. While in principle there should not
be security implications arising from this field, it should be noted
that due to non-RFC-compliant implementations, the Header Checksum
might be exploited to detect firewalls and/or evade network intrusion
detection systems (NIDS).

[Ed3f2002] describes the exploitation a TTL of 64. In the TCP checksum for
performing such actions. As there same way, if a packet is
received with a TTL of 120, chances are internet routers known to not
check that the IP Header Checksum, and original packet had
a TTL of 128.

o This discussion assumes there might also be middle-boxes
(NATs, firewalls, etc.) not checking the IP checksum allegedly due to
performance reasons, similar malicious activity to was no protocol scrubber,
transparent proxy, or some other middle-box that overwrites the one described
TTL field in [Ed3f2002] might be performed with a non-standard way, between the IP checksum.

3.11. Source Address

The Source Address originating system
and the point of an IP datagram identifies the node from network in which the packet originated.

Strictly speaking, was received.

Asserting the Source Address of an IP datagram identifies TTL with which a packet was originally sent by the interface of
source system can help to obtain valuable information. Among other
things, it may help in:

o Fingerprinting the sending operating system being used by the source host.

o Fingerprinting the physical device from which the packet was sent,
(rather than packets
originate.

o Locating the originating "system"), as source host in the Internet
Architecture there's no concept of "node".

Unfortunately, network topology.

Additionally, it is trivial can be used to forge perform functions such as:

o Evading Network Intrusion Detection Systems.

o Improving the Source Address security of an applications that make use of the
Internet datagram. This has been exploited Protocol (IP).

3.9.1. Fingerprinting the operating system in use by the past source host

Different operating systems use a different default TTL for
performing the
packets they send. Thus, asserting the TTL with which a variety of DoS (Denial of Service) attacks [NISCC2004]
[RFC4987] [CERT1996a] [CERT1996b] [CERT1998a], and packet was
originally sent will help to impersonate as
other reduce the number of possible operating
systems in scenarios in which authentication was based on use by the
Source Address of source host.

3.9.2. Fingerprinting the sending system [daemon91996].

The extent to physical device from which these attacks can be successfully performed in
the Internet can be reduced through deployment of ingress/egress
filtering in the internet routers. [NISCC2006] is packets
originate

When several systems are behind a detailed guide
on ingress and egress filtering. [RFC3704] and [RFC2827] discuss
ingress filtering. [GIAC2000] discusses egress filtering.

Even when middle-box such as a NAT or a load
balancer, the obvious field on which TTL may help to perform checks for ingress/
egress filtering is count the Source Address and Destination Address fields number of systems behind the IP header, there are other occurrences
middle-box. If each of IP addresses on
which the same type of checks should be performed. One example is systems behind the IP addresses contained in middle-box use a
different default TTL for the payload packets they send, or they are located
in a different place of ICMP error messages, as
discussed in [I-D.ietf-tcpm-icmp-attacks] and [Gont2006].

There are a number of sanity checks that should be performed on the
Source Address of network topology, an IP datagram. Details can be found in Section
4.2 ("Addressing").

Additionally, there exist freely available tools attacker could
stimulate responses from the devices being fingerprinted, and each
response that allow
administrators arrives with a different TTL could be assumed to monitor which IP addresses come
from a different device.

o Of course, there are used with which MAC
addresses [LBNL2006]. This functionality is also included in many
Network Intrusion Detection Systems (NIDS).

It is also very important other and much more precise techniques
to understand that authentication should
never rely on the Source Address fingerprint physical devices. Among drawbacks of this method,
while many systems differ in the communicating systems.

3.12. Destination Address

The Destination Address of an IP datagram identifies default TTL they use for the destination
host to
packets they send, there are also many implementations which use
the same default TTL. Additionally, packets sent by a given
device may take different routes (e.g., due to load sharing or
route changes), and thus a given packet is meant may incorrectly be
presumed to come from a different device, when in fact it just
traveled a different route.

3.9.3. Locating the source host in the network topology

The TTL field may also be delivered.

Strictly speaking, used to locate the Destination Address of an IP datagram
identifies source system in the interface
network topology [Northcutt2000].

Figure 5: Tracking a host by means of the destination TTL field

Consider network interface, rather
than the destination "system", as topology of Figure 5. Assuming that an attacker
("F" in the Internet Architecture
there's no concept of "node".

There are a number figure) is performing some type of sanity checks attack that should be performed on requires
forging the
Destination Source Address (such as a TCP-based DoS reflection
attack), and some of an IP datagram. Details can be found in
Section 4.2 ("Addressing").

3.13. Options

According to RFC 791, IP options must be implemented by all IP
modules, both in the involved hosts and gateways (i.e., end-systems and
intermediate-systems).

There are two cases for willing to cooperate to
locate the format of an option: attacking system.

Assuming that:

o Case 1: All the packets A single byte gets have a TTL of option-type. 61.

o Case 2: An option-type byte, an option-length byte, and the actual
option-data bytes.

In the Case 2, the option-length byte counts the option-type byte and
the option-length byte, as well as the actual option-data bytes. All options except "End of Option List" (Type = 0) and "No Operation"
(Type = 1), are of Class 2.

The option-type has three fields:

o 1 bit: copied flag.

o 2 bits: option class.

o 5 bits: option number.

The copied flag indicates whether this option should be copied to all
fragments in the event the packet carrying it needs to be fragmented:

o 0 = not copied.

o 1 = copied.

The values for the option class are:

o 0 = control.

o 1 = reserved for future use. packets B gets have a TTL of 61.

o 2 = debugging and measurement. All the packets C gets have a TTL of 61.

o 3 = reserved for future use.

This format allows for All the creation packets D gets have a TTL of new options for 62.

Based on this information, and assuming that the extension system's default
value was not overridden, it would be fair to assume that the
original TTL of the Internet Protocol (IP).

Finally, packets was 64. With this information, the option
number identifies the syntax of hops between the rest attacker and each of the
option.

3.13.1. General issues with IP options aforementioned
hosts can be calculated.

The following subsections discuss security issues attacker is:

o Three hops away from A.

o Three hops away from B.

o Three hops away from C.

o Two hops away from D.

In the network setup of Figure 3, the only system that apply to satisfies all
IP options. The proposed checks should be performed in addition to
any option-specific checks proposed in
these conditions is the next sections.

3.13.1.1. Processing requirements

Router manufacturers tend to do IP option processing on one marked as the main
processor, rather than on line cards. Unless special care "F".

The scenario described above is taken,
this may be for illustration purposes only. In
practice, there are a security risk, as number of factors that may prevent this
technique from being successfully applied:

o Unless there is potential for overwhelming
the router with option processing.

To reduce the impact of these packets on the system performance, a
few counter-measures could be implemented:

o Rate-limit the "large" number of packets with IP options that are
processed by cooperating systems, and the system.

o Enforce
attacker is assumed to be no more than a limit on few hops away from these
a systems, the maximum number of options "candidate" hosts will usually be too
large for the information to be accepted on
a given internet datagram. useful.

o The first check avoids attacker may be using a flow non-default TTL value, or, what is
worse, using a pseudo-random value for the TTL of the packets with IP options to overwhelm it
sends.

o The packets sent by the system attacker may take different routes, as a
result of a change in question. network topology, load sharing, etc., and
thus may lead to an incorrect analysis.

3.9.4. Evading Network Intrusion Detection Systems

The second check avoids packets with
multiple IP options TTL field can be used to affect evade Network Intrusion Detection
Systems. Depending on the performance position of a sensor relative to the system.

3.13.1.2. Processing
destination host of the options by examined packet, the upper layer protocol

Section 3.2.1.8 of RFC 1122 [RFC1122] states NIDS may get a different
picture from that all of the IP options
received in IP datagrams must be passed intended destination system. As an example,
a sensor may process a packet that will expire before getting to the transport layer (or
destination host. A general counter-measure for this type of attack
is to
ICMP processing when normalize the datagram is traffic that gets to an ICMP message). Therefore,
care in option processing must organizational network.
Examples of such traffic normalization can be taken not only at found in [Paxson2001].

3.9.5. Improving the internet
layer, but security of applications that make use of the
Internet Protocol (IP)

In some scenarios, the TTL field can be also in every protocol module used to improve the
security of an application, by restricting the hosts that may end up processing can
communicate with the options included given application . For example, there are
applications for which the communicating systems are typically in an IP datagram.

3.13.1.3. General sanity checks on IP options

There the
same network segment (i.e., there are a number of sanity checks that should be performed on IP
options before further option processing no intervening routers). Such
an application is done. They help prevent the BGP (Border Gateway Protocol) between utilized
by two peer routers.

If both systems use a number TTL of potential security problems, including buffer overflows.
When these checks fail, the packet carrying 255 for all the option should be
dropped, and this event should be logged (e.g., packets they send to
each other, then a counter check could be
incremented enforced to reflect require all packets
meant for the packet drop).

RFC 1122 [RFC1122] recommends to send an ICMP "Parameter Problem"
message application in question to the originating system when have a packet is dropped because TTL of
a invalid value in a field, such as the cases discussed 255.

As all packets sent by systems that are not in the
following subsections. Sending such a message might help in
debugging some same network problems. However, it would also alert
attackers about the system that is dropping
segment will have a TTL smaller than 255, those packets because will not pass
the check enforced by these two cooperating peers. This check
reduces the set of systems that may perform attacks against the
invalid values
protected application (BGP in this case), thus mitigating the protocol fields.

We advice that systems default to sending an attack
vectors described in [NISCC2004] and [Watson2004].

o This same check is enforced for related ICMP "Parameter Problem" error message when a packet is dropped because messages, with
the intent of an invalid value mitigating the attack vectors described in
a protocol
[NISCC2005] and [I-D.ietf-tcpm-icmp-attacks].

The TTL field (e.g., as a result of dropping can be used in a packet due to the
sanity checks described similar way in this section). However, we recommend that scenarios in which the
cooperating systems provide either do not use a system-wide toggle default TTL of 255, or are
not in the same network segment (i.e., multi-hop peering). In that allows an administrator to
override
case, the default behavior so following check could be enforced:

TTL >= 255 - DeltaHops

This means that the set of hosts from which packets can will be silently dropped
due when an invalid value accepted
for the protected application will be reduced to those that are no
more than DeltaHops away. While for obvious reasons the level of
protection will be smaller than in a protocol field is encountered.

Option length
Section 3.2.1.8 the case of RFC 1122 explicitly states that directly-connected
peers, the IP layer must
not crash as use of the result TTL field for protecting multi-hop peering
still reduces the set of an option length hosts that is outside could potentially perform a
number of attacks against the
possible range, and mentions that erroneous option lengths have protected application.

This use of the TTL field has been
observed to put some IP implementations into infinite loops.

For options that belong to officially documented by the "Case 2" described IETF
under the name "Generalized TTL Security Mechanism" (GTSM) in
[RFC5082].

Some protocol scrubbers enforce a minimum value for the previous
section, TTL field of
the following check should packets they forward. It must be performed:

option-length >= 2

The value "2" accounts for understood that depending on
the option-type byte, minimum TTL being enforced, and depending on the option-
length byte.

This check prevents, among other things, loops in option processing
that particular
network setup, the protocol scrubber may arise from incorrect option lengths.

Additionally, while actually help attackers to
fool the option-length byte of IP options GTSM, by "raising" the TTL of "Case 2"
allows for the attacking packets.

3.10. Protocol

The Protocol field indicates the protocol encapsulated in the
internet datagram. The Protocol field may not only contain a value
corresponding to an option length of up implemented protocol within the system, but also
a value corresponding to 255 bytes, there is a limit on
legitimate option length imposed protocol not implemented, or even a value
not yet assigned by the syntax of the IP header.

For all options of "Case 2", the following check IANA [IANA2006c].

While in theory there should not be enforced:

option-offset + option-length <= IHL * 4

Where option-offset is the offset of security implications from the first byte
use of any value in the option
within protocol field, there have been security
issues in the IP header, past with the first byte of systems that had problems when handling
packets with some specific protocol numbers [Cisco2003] [CERT2003].

3.11. Header Checksum

The Header Checksum field is an error detection mechanism meant to
detect errors in the IP header being
assigned an offset of 0.

If a packet does not pass these checks, the corresponding packet header. While in principle there should not
be dropped, and security implications arising from this event field, it should be logged (e.g., a counter
could be incremented noted
that due to reflect non-RFC-compliant implementations, the packet drop).

The aforementioned check is meant to detect forged option-length
values that Header Checksum
might make an option overlap with the IP payload. This
would be particularly dangerous for those IP options which request
the processing systems exploited to write information into detect firewalls and/or evade network intrusion
detection systems (NIDS).

[Ed3f2002] describes the option-data area
(such as exploitation of the Record Route option), as it would allow TCP checksum for
performing such actions. As there are internet routers known to not
check the generation
of overflows.

Data types

Many IP options use pointer Header Checksum, and length fields. Care must there might also be taken as middle-boxes
(NATs, firewalls, etc.) not checking the IP checksum allegedly due to
performance reasons, similar malicious activity to the data type used for these fields one described
in the implementation. For
example, if an 8-bit signed data type were used to hold an 8-bit
pointer, then, pointer values larger than 128 [Ed3f2002] might mistakenly be
interpreted as negative numbers, and thus might lead to unpredictable
results.

3.13.2. Issues performed with specific options

3.13.2.1. End the IP checksum.

3.12. Source Address

The Source Address of an IP datagram identifies the node from which
the packet originated.

o Strictly speaking, the Source Address of an IP datagram identifies
the interface of the sending system from which the packet was
sent, (rather than the originating "system"), as in the Internet
Architecture there's no concept of Option List (Type = 0)

This option "node".

Unfortunately, it is used trivial to indicate forge the "end Source Address of options" in those cases an
Internet datagram. This has been exploited in which the end past for
performing a variety of options would not coincide with the end DoS (Denial of the
Internet Protocol Header.

IP systems are required Service) attacks [NISCC2004]
[RFC4987] [CERT1996a] [CERT1996b] [CERT1998a], and to ignore those options they do not
implement. Therefore, even impersonate as
other systems in those cases scenarios in which this option is
required, but is missing, IP systems should be able to process authentication was based on the
remaining bytes
Source Address of the IP header without any problems.

3.13.2.2. No Operation (Type = 1)

The no-operation option is basically meant to allow the sending system [daemon91996].

The extent to align subsequent options in, for example, 32-bit
boundaries.

This option does not have security implications.

3.13.2.3. Loose Source Record Route (LSRR) (Type = 131)

This option lets which these attacks can be successfully performed in
the originating system specify a number of
intermediate systems a packet must pass Internet can be reduced through to get to the
destination host. Additionally, deployment of ingress/egress
filtering in the route followed by internet routers. [NISCC2006] is a detailed guide
on ingress and egress filtering. [RFC3704] and [RFC2827] discuss
ingress filtering. [GIAC2000] discusses egress filtering.

o Even when the packet obvious field on which to perform checks for
ingress/egress filtering is
recorded in the option. The receiving host (end-system) must use Source Address and Destination
Address fields of the IP header, there are other occurrences of IP
addresses on which the
reverse same type of checks should be performed.
One example is the path IP addresses contained in the received LSRR option.

The LSSR option can be payload of help in debugging some network problems.
Some ISP (Internet Service Provider) peering agreements require
support for this option ICMP
error messages, as discussed in the routers within the peer [I-D.ietf-tcpm-icmp-attacks] and
[Gont2006].

There are a number of sanity checks that should be performed on the ISP.

The LSRR option has well-known security implications. Among other
things, the option
Source Address of an IP datagram. Details can be found in Section
4.2 ("Addressing").

Additionally, there exist freely available tools that allow
administrators to monitor which IP addresses are used to:

o Bypass firewall rules

o Reach otherwise unreachable internet systems

o Establish TCP connections with which MAC
addresses [LBNL2006]. This functionality is also included in a stealthy way

o Learn about many
Network Intrusion Detection Systems (NIDS).

It is also very important to understand that authentication should
never rely on the topology Source Address of a network

o Perform bandwidth-exhaustion attacks

Of these attack vectors, the one that has probably received least
attention is the use communicating systems.

3.13. Destination Address

The Destination Address of an IP datagram identifies the LSRR option destination
host to which the packet is meant to perform bandwidth
exhaustion attacks. The LSRR option can be used as delivered.

o Strictly speaking, the Destination Address of an amplification
method for performing bandwidth-exhaustion attacks, IP datagram
identifies the interface of the destination network interface,
rather than the destination "system", as an attacker
could make a packet bounce multiple times between in the Internet
Architecture there's no concept of "node".

There are a number of systems
by carefully crafting an LSRR option.

This is sanity checks that should be performed on the IPv4-version
Destination Address of the IPv6 amplification attack that was
widely publicized an IP datagram. Details can be found in 2007 [Biondi2007]. The only difference is that
Section 4.2 ("Addressing").

3.14. Options

According to RFC 791, IP options must be implemented by all IP
modules, both in hosts and gateways (i.e., end-systems and
intermediate-systems).

There are two cases for the maximum length format of an option:

o Case 1: A single byte of option-type.

o Case 2: An option-type byte, an option-length byte, and the IPv4 header (and hence actual
option-data bytes.

In the LSRR option)
limits Case 2, the amplification factor when compared to option-length byte counts the IPv6 counter-
part.

While option-type byte and
the LSSR option may be of help in debugging some network
problems, its security implications outweigh any legitimate use. option-length byte, as well as the actual option-data bytes.

All systems should, by default, drop IP packets that contain an LSRR
option, options except "End of Option List" (Type = 0) and should log "No Operation"
(Type = 1), are of Class 2.

The option-type has three fields:

o 1 bit: copied flag.

o 2 bits: option class.

o 5 bits: option number.

The copied flag indicates whether this event (e.g., a counter could option should be
incremented copied to reflect all
fragments in the event the packet drop). However, they should
provide a system-wide toggle carrying it needs to enable support be fragmented:

o 0 = not copied.

o 1 = copied.

The values for this the option class are:

o 0 = control.

o 1 = reserved for
those scenarios in which this option is required. Such system-wide
toggle should default to "off" (or "disable").

[OpenBSD1998] is a security advisory about an improper implementation future use.

o 2 = debugging and measurement.

o 3 = reserved for future use.

This format allows for the creation of such a system-wide in 4.4BSD kernels.

Section 3.3.5 new options for the extension
of RFC 1122 [RFC1122] states that a host may be able to
act as an intermediate hop in a source route, forwarding a source-
routed datagram to the next specified hop. We strongly discourage
host software from forwarding source-routed datagrams.

If processing Internet Protocol (IP).

Finally, the option number identifies the syntax of the rest of source-routed datagrams is explicitly enabled in a
system, the
option.

3.14.1. General issues with IP options

The following sanity subsections discuss security issues that apply to all
IP options. The proposed checks should be performed.

RFC 791 states that this option should appear, at most, once performed in a
given packet. Thus, if a packet is found addition to have more than one LSRR
option, it should be dropped, and this event should be logged (e.g.,
a counter could be incremented
any option-specific checks proposed in the next sections.

3.14.1.1. Processing requirements

Router manufacturers tend to reflect do IP option processing on the packet drop).
Therefore, hosts and routers should discard packets that contain more main
processor, rather than one LSRR option. Additionally, if a packet were found to have
both LSRR and SSRR options, it should be dropped, and on line cards. Unless special care is taken,
this event
should be logged (e.g., represents Denial of Service (DoS) risk, as there is potential
for overwhelming the router with option processing.

To reduce the impact of these packets on the system performance, a counter
few counter-measures could be incremented to reflect implemented:

o Rate-limit the
packet drop).

As many other number of packets with IP options, the LSSR contains a Length field options that
indicates the length of are
processed by the option. Given system.

o Enforce a limit on the format maximum number of the option,
the Length field should be checked options to be at least 3 (three):

LSRR.Length >= 3
If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., accepted on
a counter could be incremented given internet datagram.

The first check avoids a flow of packets with IP options to
reflect the packet drop).

Additionally, overwhelm
the following system in question. The second check should be performed on avoids packets with
multiple IP options to affect the Length
field:

LSRR.Offset + LSRR.Length < IHL *4

This check assures that performance of the option does not overlap with system.

3.14.1.2. Processing of the IP
payload (i.e., it does not go past options by the IP header). If upper layer protocol

Section 3.2.1.8 of RFC 1122 [RFC1122] states that all the packet
does not pass this check, it should be dropped, and this event should
be logged (e.g., a counter could IP options
received in IP datagrams must be incremented passed to reflect the packet
drop).

The Pointer is relative transport layer (or to this option. Thus,
ICMP processing when the minimum legal
value datagram is 4. an ICMP message). Therefore, the following check should
care in option processing must be performed.

LSRR.Pointer >= 4

If the packet does taken not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect only at the packet drop). Additionally, internet
layer, but also in every protocol module that may end up processing
the Pointer field should be options included in an IP datagram.

3.14.1.3. General sanity checks on IP options

There are a multiple number of 4. Consequently, the following check sanity checks that should be
performed:

LSRR.Pointer % 4 == 0

If performed on IP
options before further option processing is done. They help prevent
a number of potential security problems, including buffer overflows.
When these checks fail, the packet does not pass this check, it carrying the option should be
dropped, and this event should be logged (e.g., a counter could be
incremented to reflect the packet drop).

When a system receives

RFC 1122 [RFC1122] recommends to send an IP ICMP "Parameter Problem"
message to the originating system when a packet with is dropped because of
a invalid value in a field, such as the LSRR route option, cases discussed in the
following subsections. Sending such a message might help in
debugging some network problems. However, it
should check whether would also alert
attackers about the source route is empty or not. The option is
empty if:

LSRR.Pointer > LSRR.Length

In system that case, routing should be based on is dropping packets because of the Destination Address
field, and no further processing should be done on
invalid values in the LSRR option.

[Microsoft1999] protocol fields.

We advice that systems default to sending an ICMP "Parameter Problem"
error message when a packet is dropped because of an invalid value in
a security advisory about protocol field (e.g., as a vulnerability arising
from improper validation result of dropping a packet due to the LSRR.Pointer field.

If the address
sanity checks described in this section). However, we recommend that
systems provide a system-wide toggle that allows an administrator to
override the Destination Address default behavior so that packets can be silently dropped
due when an invalid value in a protocol field has been reached, and
the option is not empty, the next address in the source route
replaces the address in encountered.

Option length
Section 3.2.1.8 of RFC 1122 explicitly states that the Destination Address field.

The IP address layer must
not crash as the result of an option length that is outside the interface
possible range, and mentions that will be used erroneous option lengths have been
observed to forward this
datagram should be recorded put some IP implementations into infinite loops.

For options that belong to the LSRR. However, before writing "Case 2" described in the route data area, previous
section, the following check should be performed:

LSRR.Length - LSRR.Pointer

option-length >= 3 2

o The value "2" accounts for the option-type byte, and the option-
length byte.

This assures check prevents, among other things, loops in option processing
that may arise from incorrect option lengths.

Additionally, while the option-length byte of IP options of "Case 2"
allows for an option length of up to 255 bytes, there will is a limit on
legitimate option length imposed by the syntax of the IP header.

For all options of "Case 2", the following check should be at least enforced:

option-offset + option-length <= IHL * 4 bytes

Where option-offset is the offset of space in which to
record the first byte of the option
within the IP address. If header, with the first byte of the IP header being
assigned an offset of 0.

If a packet does not pass this check, it these checks, the corresponding packet
should be dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop).

An offset of "1" corresponds

The aforementioned check is meant to the detect forged option-length
values that might make an option type, that's why overlap with the
performed check is LSRR.Length - LSRR.Pointer >=3, IP payload. This
would be particularly dangerous for those IP options which request
the processing systems to write information into the option-data area
(such as the Record Route option), as it would allow the generation
of overflows.

Data types

Many IP options use pointer and not
LSRR.Length - LSRR.Pointer >=4.

The LSRR length fields. Care must be copied on fragmentation. This means that taken as
to the data type used for these fields in the implementation. For
example, if a
packet that carries an 8-bit signed data type were used to hold an 8-bit
pointer, then, pointer values larger than 128 might mistakenly be
interpreted as negative numbers, and thus might lead to unpredictable
results.

3.14.2. Issues with specific options

3.14.2.1. End of Option List (Type = 0)

This option is used to indicate the "end of options" in those cases
in which the end of options would not coincide with the end of the
Internet Protocol Header.

IP systems are required to ignore those options they do not
implement. Therefore, even in those cases in which this option is
required, but is missing, IP systems should be able to process the LSRR is fragmented, each
remaining bytes of the fragments
will have IP header without any problems.

3.14.2.2. No Operation (Type = 1)

The no-operation option is basically meant to go through the list of systems specified in allow the LSRR
option.

3.13.2.4. Strict sending
system to align subsequent options in, for example, 32-bit
boundaries.

This option does not have security implications.

3.14.2.3. Loose Source and Record Route (SSRR) (LSRR) (Type = 137) 131)

This option allows lets the originating system to specify a number of
intermediate systems a packet must pass through to get to the
destination host. Additionally, the route followed by the packet is
recorded in the option, and the destination option. The receiving host (end-system) must use the
reverse of the path contained in the received SSRR LSRR option.

This

The LSSR option can be of help in debugging some network problems.
Some ISP (Internet Service Provider) peering agreements require
support for this option in the routers within the peer of the ISP.

The LSRR option has well-known security implications. Among other
things, the option can be used to:

o Bypass firewall rules

o Reach otherwise unreachable internet systems

o Establish TCP connections in a stealthy way

o Learn about the topology of a network

o Perform bandwidth-exhaustion attacks
Of these attack vectors, the one that has probably received least
attention is similar the use of the LSRR option to perform bandwidth
exhaustion attacks. The LSRR option can be used as an amplification
method for performing bandwidth-exhaustion attacks, as an attacker
could make a packet bounce multiple times between a number of systems
by carefully crafting an LSRR option.

o This is the Loose Source and Record Route (LSRR)
option, with IPv4-version of the IPv6 amplification attack that was
widely publicized in 2007 [Biondi2007]. The only difference is
that in the case maximum length of SSRR, the route
specified in the option is IPv4 header (and hence the exact route LSRR
option) limits the packet must take
(i.e., no other intervening routers are allowed amplification factor when compared to be in the route).

The SSSR IPv6
counter-part.

While the LSSR option can may be of help in debugging some network problems.
Some ISP (Internet Service Provider) peering agreements require
problems, its security implications outweigh any legitimate use.

All systems should, by default, drop IP packets that contain an LSRR
option, and should log this event (e.g., a counter could be
incremented to reflect the packet drop). However, they should
provide a system-wide toggle to enable support for this option for
those scenarios in the routers within the peer of the ISP.

The SSRR which this option has well-known is required. Such system-wide
toggle should default to "off" (or "disable").

[OpenBSD1998] is a security implications. Among other
things, the option can advisory about an improper
implementation of such a system-wide toggle in 4.4BSD kernels.

Section 3.3.5 of RFC 1122 [RFC1122] states that a host may be used to:

o Bypass firewall rules

o Reach otherwise unreachable internet systems

o Establish TCP connections able to
act as an intermediate hop in a stealthy way

o Learn about source route, forwarding a source-
routed datagram to the topology next specified hop. We strongly discourage
host software from forwarding source-routed datagrams.

If processing of source-routed datagrams is explicitly enabled in a network
o Perform bandwidth-exhaustion attacks

Of these attack vectors,
system, the following sanity checks should be performed.

RFC 791 states that this option should appear, at most, once in a
given packet. Thus, if a packet is found to have more than one LSRR
option, it should be dropped, and this event should be logged (e.g.,
a counter could be incremented to reflect the one packet drop).
Therefore, hosts and routers should discard packets that has probably received least
attention is the use of the SSRR option contain more
than one LSRR option. Additionally, if a packet were found to perform bandwidth
exhaustion attacks. The have
both LSRR and SSRR option can options, it should be used as an amplification
method for performing bandwidth-exhaustion attacks, as an attacker
could make dropped, and this event
should be logged (e.g., a counter could be incremented to reflect the
packet bounce multiple times between drop).

As many other IP options, the LSSR contains a number Length field that
indicates the length of systems
by carefully crafting an LSRR the option.

This is Given the IPv4-version format of the IPv6 amplification attack that was
widely publicized in 2007 [Biondi2007]. The only difference is that option,
the maximum length for Length field should be checked to be at least 3 (three):

LSRR.Length >= 3

If the IPv4 header (and hence packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the SSRR option)
limits packet drop).

Additionally, the amplification factor when compared to following check should be performed on the IPv6 counter-
part.

While Length
field:

LSRR.Offset + LSRR.Length < IHL *4

This check assures that the SSSR option may be of help in debugging some network
problems, its security implications outweigh any legitimate use of
it.

All systems should, by default, drop does not overlap with the IP packets that contain an LSRR
option, and
payload (i.e., it does not go past the IP header). If the packet
does not pass this check, it should log be dropped, and this event should
be logged (e.g., a counter could be incremented to reflect the packet
drop). However, they should
provide a system-wide toggle to enable support for this option for
those scenarios in which this option

The Pointer is required. Such system-wide
toggle should default relative to "off" (or "disable").

[OpenBSD1998] is a security advisory about an improper implementation
of such a system-wide in 4.4BSD kernels.

In this option. Thus, the event processing of minimum legal
value is 4. Therefore, the SSRR option were explicitly enabled,
there are some sanity checks that following check should be performed.

RFC 791 states that this option should appear, at most, once in a
given packet. Thus, if a

LSRR.Pointer >= 4

If the packet is found to have more than one SSRR
option, does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). Also, if
a packet contains Additionally, the Pointer field should be
a combination multiple of SSRR and LSRR options, 4. Consequently, the following check should be
performed:

LSRR.Pointer % 4 == 0

If a packet does not pass this check, it should be dropped, and this
event should be logged (e.g., a counter could be incremented to
reflect the packet drop).

As the SSRR option is meant to specify the route

When a system receives an IP packet with the LSRR route option, it
should
follow from check whether the source to destination, use of more than one SSRR route is empty or not. The option
in a single packet would be nonsensical. Therefore, hosts and
routers is
empty if:

LSRR.Pointer > LSRR.Length

In that case, routing should check be based on the IP header Destination Address
field, and discard no further processing should be done on the packet if it
contains more than one SSRR option, or LSRR option.

o [Microsoft1999] is a combination security advisory about a vulnerability
arising from improper validation of LSRR the LSRR.Pointer field.

If the address in the Destination Address field has been reached, and SSRR
options.

As with many other IP options,
the SSRR option contains a Length
field that indicates is not empty, the length of next address in the option. Given source route
replaces the format address in the Destination Address field.

The IP address of the option, interface that will be used to forward this
datagram should be recorded into the length field LSRR. However, before writing
in the route data area, the following check should be checked to performed:

LSRR.Length - LSRR.Pointer >= 3

This assures that there will be at least 3:

SSRR.Length >= 3 4 bytes of space in which to
record the IP address. If the packet does not pass this check, it
should be dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop).

Additionally,

o An offset of "1" corresponds to the following option type, that's why the
performed check should is LSRR.Length - LSRR.Pointer >=3, and not
LSRR.Length - LSRR.Pointer >=4.

The LSRR must be performed copied on fragmentation. This means that if a
packet that carries the LSRR is fragmented, each of the fragments
will have to go through the list of systems specified in the LSRR
option.

3.14.2.4. Strict Source and Record Route (SSRR) (Type = 137)

This option allows the originating system to specify a number of
intermediate systems a packet must pass through to get to the
destination host. Additionally, the route followed by the packet is
recorded in the option, and the destination host (end-system) must
use the reverse of the path contained in the received SSRR option.

This option is similar to the Loose Source and Record Route (LSRR)
option, with the length
field:

SSRR.Offset + SSRR.Length < IHL *4

This check assures only difference that in the option does not overlap with case of SSRR, the IP
payload (i.e., it does not go past route
specified in the IP header). If option is the exact route the packet
does not pass this check, it should be dropped, and this event should must take
(i.e., no other intervening routers are allowed to be logged (e.g., a counter could in the route).

The SSSR option can be incremented to reflect of help in debugging some network problems.
Some ISP (Internet Service Provider) peering agreements require
support for this option in the packet
drop). routers within the peer of the ISP.

The Pointer field is relative SSRR option has the same security implications as the LSRR
option. Please refer to this option, Section Section 3.14.2.3 for a discussion of
such security implications.

As with the minimum legal
value being 4. Therefore, the following check should be performed:

SSRR.Pointer >= 4

If LSRR, while the packet does not pass this check, it should SSSR option may be dropped, of help in debugging
some network problems, its security implications outweigh any
legitimate use of it.

All systems should, by default, drop IP packets that contain an LSRR
option, and should log this event should be logged (e.g., a counter could be
incremented to reflect the packet drop).

Additionally, the Pointer field However, they should be
provide a multiple system-wide toggle to enable support for this option for
those scenarios in which this option is required. Such system-wide
toggle should default to "off" (or "disable").

[OpenBSD1998] is a security advisory about an improper
implementation of such a system-wide toggle in 4.4BSD kernels.

In the event processing of 4.
Consequently, the following check SSRR option were explicitly enabled,
the same sanity checks described for the LSRR option in
Section 3.14.2.3 should be performed:

SSRR.Pointer % 4 == 0

If a packet does not pass this check, it should performed on the SSRR option. Namely,
sanity checks shoudl be dropped, performed on the option length (SSRR.Length)
and this
event should be logged (e.g., a counter could be incremented to
reflect the packet drop). Pointer field (SSRR.Pointer).

If the packet passes the above aforementioned sanity checks, the receiving
system should determine whether the Destination Address of the packet
corresponds to one of its IP addresses. If does not, it should be
dropped, and this event should be logged (e.g., a counter could be
incremented to reflect the packet drop).

Contrary to the IP Loose Source and Record Route (LSRR) option,
the SSRR option does not allow in the route other routers than
those contained in the option. If the system implements the weak end-
system
end-system model, it is allowed for the system to receive a packet
destined to any of its IP addresses, on any of its interfaces. If
the system implements the strong end-system model, a packet
destined to it can be received only on the interface that
corresponds to the IP address contained in the Destination Address
field [RFC1122].

If the packet passes this check, the receiving system should
determine whether the source route is empty or not. The option is
empty if:

SSRR.Pointer > SSRR.Length

In that case, if the address in the destination field has not been
reached, the packet should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet
drop).

[Microsoft1999] is a security advisory about a vulnerability
arising from improper validation of the SSRR.Pointer field.

If the option is not empty, and the address in the Destination
Address field has been reached, the next address in the source route
replaces the address in the Destination Address field. This IP
address must be reachable without the use of any intervening router
(i.e., the address must belong to any of the networks to which the
system is directly attached). If that is not the case, the packet
should be dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop).

The IP address of the interface that will be used to forward this
datagram should be recorded into the SSRR. However, before doing
that, the following check should be performed:

SSRR.Length - SSRR.Pointer >=3

An offset of "1" corresponds to the option type, that's why the
performed check is SSRR.Length - SSRR.Pointer >=3, and not
SSRR.Length - SSRR.Pointer >=4.

This assures that there will be at least 4 bytes of space on which to
record the IP address. If the packet does not pass this check, it
should be dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop).

The SSRR option must be copied on fragmentation. This means that if
a packet that carries the SSRR is fragmented, each of the fragments
will have to go through the list of systems specified in the SSRR
option.

3.13.2.5.

3.14.2.5. Record Route (Type = 7)

This option provides a means to record the route that a given packet
follows.

The option begins with an 8-bit option code, which must be equal to
7. The second byte is the option length, which includes the option-
type byte, the option-length byte, the pointer byte, and the actual
option-data. The third byte is a pointer into the route data,
indicating the first byte of the area in which to store the next
route data. The pointer is relative to the option start.

RFC 791 states that this option should appear, at most, once in a
given packet. Therefore, if a packet has more than one instance of
this option, it should be dropped, and this event should be logged
(e.g., a counter could be incremented to reflect the packet drop).

Given the format of the option,

The same sanity checks performed for the Length field should be checked to
be at least 3:

RR.Length >= 3

If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop).

Additionally, Pointer
field of the following check LSRR and the SSRR options should be performed on the
Length
field:

RR.Offset + RR_Length < IHL *4

This check assures that the option does not overlap with the IP
payload (i.e., it does not go past the IP header). If the packet
does not pass this check, it should be dropped, field (RR.Length) and this event should
be logged (e.g., a counter could be incremented to reflect the packet
drop).

The pointer Pointer field is relative to this option, with (RR.Pointer) of the minimum legal
value being 4. Therefore, RR
option. And, as with the following check should be performed:

RR.Pointer >= 3

If LSRR and SSRR options, if the packet does
not pass this check, these checks it should be silently dropped, and this event should be
logged (e.g., a counter could be
incremented to reflect the packet drop).

Additionally, the Pointer field should be a multiple of 4.
Consequently, the following check should be performed:

RR.Pointer % 4 == 0 counter could be incremented to reflect the packet
drop).

When a system receives an IP packet with the Record Route option, it
should check whether there is space in the option to store route
information. The option is full if:

RR.Pointer > RR.Length

If the option is full, the datagram should be forwarded without
further processing of this option. If not, the following check
should be performed before writing any route data into the option:

RR.Pointer - RR.Length >= 3

If the packet does not pass this check, the packet should be
considered in error, and therefore should be dropped, and this event
should be logged (e.g., a counter could be incremented to reflect the
packet drop).

If the option is not full (i.e., RR.Pointer <= RR.Length), but
RR.Pointer - RR.Length < 4, it means that while there's space in
the option, there is not not enough space to store an IP address.
It is fair to assume that such an scenario will only occur when
the packet has been crafted.

If the packet passes this check, the IP address of the interface that
will be used to forward this datagram should be recorded into the
area pointed by the RR.Pointer, and RR.Pointer should then be
incremented by 4.

This option is not copied on fragmentation, and thus appears in the
first fragment only. If a fragment other than the one with offset 0
contains the Record Route option, it should be dropped, and this
event should be logged (e.g., a counter could be incremented to
reflect the packet drop).

3.13.2.6.

3.14.2.6. Stream Identifier (Type = 136)

The Stream Identifier option originally provided a means for the 16-
bit SATNET stream Identifier to be carried through networks that did
not support the stream concept.

However, as stated by Section 4.2.2.1 of RFC 1812 [RFC1812], this
option is obsolete. Therefore, it should be ignored by the
processing systems.

In the case of legacy systems still using this option, the length
field of the option should be checked to be 4. If the option does
not pass this check, it should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet
drop).

RFC 791 states that this option appears at most once in a given
datagram. Therefore, if a packet contains more than one instance of
this option, it should be dropped, and this event should be logged
(e.g., a counter could be incremented to reflect the packet drop).

3.13.2.7.

3.14.2.7. Internet Timestamp (Type = 68)

This option provides a means for recording the time at which each
system processed this datagram. The timestamp option has a number of
security implications. Among them are:

o It allows an attacker to obtain the current time of the systems
that process the packet, which the attacker may find useful in a
number of scenarios.

o It may be used to map the network topology, in a similar way to
the IP Record Route option.

o It may be used to fingerprint the operating system in use by a
system processing the datagram.

o It may be used to fingerprint physical devices, by analyzing the
clock skew.

Therefore, by default, the timestamp option should be ignored.

For those systems that have been explicitly configured to honor this
option, the rest of this subsection describes some sanity checks that
should be enforced on the option before further processing.

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-
type byte, the option-length byte, the pointer, and the overflow/flag
byte. The minimum legal value for the option-length byte is 4, which
corresponds to an Internet Timestamp option that is empty (no space
to store timestamps). Therefore, upon receipt of a packet that
contains an Internet Timestamp option, the following check should be
performed:

IT.Length >= 4

If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop).

Additionally, the following check should be performed on the option
length field:

IT.Offset + IT.Length < IHL *4

This check assures that the option does not overlap with the IP
payload (i.e., it does not go past the IP header). If the packet
does not pass this check, it should be dropped, and this event should
be logged (e.g., a counter could be incremented to reflect the packet
drop).

The pointer byte points to the first byte of the area in which the
next timestamp data should be stored. As its value is relative to
the beginning of the option, its minimum legal value is 5.
Consequently, the following check should be performed on a packet
that contains the Internet Timestamp option:

IT.Pointer >= 5

If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop).

The flag field has three possible legal values:

o 0: Record time stamps only, stored in consecutive 32-bit words.

o 1: Record each timestamp preceded with the internet address of the
registering entity.

o 3: The internet address fields of the option are pre-specified.
An IP module only registers its timestamp if it matches its own
address with the next specified internet address.

Therefore the following check should be performed:

IT.Flag == 0 || IT.Flag == 1 || IT.Flag == 3

If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop).

The timestamp field is a right-justified 32-bit timestamp in
milliseconds since UT. If the time is not available in milliseconds,
or cannot be provided with respect to UT, then any time may be
inserted as a timestamp, provided the high order bit of the timestamp
is set, to indicate this non-standard value.

According to RFC 791, the initial contents of the timestamp area must
be initialized to zero, or internet address/zero pairs. However,
internet systems should be able to handle non-zero values, possibly
discarding the offending datagram.

When an internet system receives a packet with an Internet Timestamp
option, it decides whether it should record its timestamp in the
option. If it determines that it should, it should then determine
whether the timestamp data area is full, by means of the following
check:

IT.Pointer > IT.Length

If this condition is true, the timestamp data area is full. If not,
there is room in the timestamp data area.

If the timestamp data area is full, the overflow byte should be
incremented, and the packet should be forwarded without inserting the
timestamp. If the overflow byte itself overflows, the packet should
be dropped, and this event should be logged (e.g., a counter could be
incremented to reflect the packet drop).

If timestamp data area is not full, then further checks should be
performed before actually inserting any data.

If the IT.Flag byte is 0, the following check should be performed:

IT.Length - IT.Pointer >= 3

If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). If the packet passes this check, there is
room for at least one 32-bit timestamp. The system's 32-bit
timestamp should be inserted at the area pointed by the pointer byte,
and the pointer byte should be incremented by four.

If the IT.Flag byte is 1, then the following check should be
performed:

IT.Length - IT.Pointer >= 7

If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). If the packet does pass this check, it
means there is space in the timestamp data area to store at least one
IP address plus the corresponding 32-bit timestamp. The IP address
of the system should be stored at the area pointed to by the pointer
byte, followed by the 32-bit system timestamp. The pointer byte
should then be incremented by 8.

If the flag byte is 3, then the following check should be performed:

IT.Length - IT.Pointer >= 7

If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). If it does, it means there is space in the
timestamp data area to store an IP address and store the
corresponding 32-bit timestamp. The system's timestamp should be
stored at the area pointed by IT.Pointer + 4. Then, the pointer byte
should be incremented by 8.

[Kohno2005] describes a technique for fingerprinting devices by
measuring the clock skew. It exploits, among other things, the
timestamps that can be obtained by means of the ICMP timestamp
request messages [RFC0791]. However, the same fingerprinting method
could be implemented with the aid of the Internet Timestamp option.

3.13.2.8.

3.14.2.8. Router Alert (Type = 148)

The Router Alert option is defined in RFC 2113 [RFC2113]. It has the
semantic "routers should examine this packet more closely". A packet
that contains a Router Alert option will not go through the router's
fast-path and will be processed in the router more slowly than if the
option were not set. Therefore, this option may impact the
performance of the systems that handle the packet carrying it.

According to the syntax of the option as defined in RFC 2113, the
following check should be enforced:

RA.Length == 4

If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). Furthermore, the following check should be
performed on the Value field:

RA.Value == 0

If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop).

As explained in RFC 2113, hosts should ignore this option.

3.13.2.9.

3.14.2.9. Probe MTU (Type =11)

This option is defined in RFC 1063 [RFC1063], and originally provided
a mechanism to discover the Path-MTU.

This option is obsolete, and therefore any packet that is received
containing this option should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet
drop).

3.13.2.10.

3.14.2.10. Reply MTU (Type = 12)

This option is defined in RFC 1063 [RFC1063], and originally provided
a mechanism to discover the Path-MTU.

3.13.2.11.

3.14.2.11. Traceroute (Type = 82)

This option is defined in RFC 1393 [RFC1393], and originally provided
a mechanism to trace the path to a host.

3.13.2.12.

3.14.2.12. DoD Basic Security Option (Type = 130)

This option is used by end-systems and intermediate systems of an
internet to [RFC1108]:

o Transmit from source to destination in a network standard
representation the common security labels required by computer
security models,

o Validate the datagram as appropriate for transmission from the
source and delivery to the destination, and,

o Ensure that the route taken by the datagram is protected to the
level required by all protection authorities indicated on the
datagram.

It is specified by RFC 1108 [RFC1108] (which obsoletes RFC 1038
[RFC1038]).

o RFC 791 [RFC0791] defined the "Security Option" (Type = 130),
which used the same option type as the DoD Basic Security option
discussed in this section. The "Security Option" specified in RFC
791 is considered obsolete by Section 4.2.2.1 of RFC 1812, and
therefore the discussion in this section is focused on the DoD
Basic Security option specified by RFC 1108 [RFC1108].

Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement
this option".

The DoD Basic Security Option is currently implemented in a number of
operating systems (e.g., [IRIX2008], [SELinux2008], [Solaris2008],
and [Cisco2008]), and deployed in a number of high-security networks.

RFC 1108 states that the option should appear at most once in a
datagram. Therefore, if more than one DoD Basic Security option
(BSO) appears in a given datagram, the corresponding datagram should
be dropped, and this event should be logged (e.g., a counter could be
incremented to reflect the packet drop).

RFC 1108 states that the option Length is variable, with a minimum
option Length of 3 bytes. Therefore, the following check should be
performed:

BSO.Length >= 3

If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop).

Systems that belong to networks in which this option is in use should
process the DoD Basic Security option contained in each packet as
specified in [RFC1108].

o Current deployments of the DoD Security Options have motivated the
proposal of a "Common Architecture Label IPv6 Security Option
(CALIPSO)" for the IPv6 protocol. [RFC1038].

3.13.2.13.

3.14.2.13. DoD Extended Security Option (Type = 133)

This option permits additional security labeling information, beyond
that present in the Basic Security Option (Section 3.13.2.12), to be
supplied in an IP datagram to meet the needs of registered
authorities. It is specified by RFC 1108 [RFC1108].

This option may be present only in conjunction with the DoD Basic
Security option. Therefore, if a packet contains a DoD Extended
Security option (ESO), but does not contain a DoD Basic Security
option, it should be dropped, and this event should be logged (e.g.,
a counter could be incremented to reflect the packet drop). It
should be noted that, unlike the DoD Basic Security option, this
option may appear multiple times in a single IP header.

RFC 1108 states that the option Length is variable, with a minimum
option Length of 3 bytes. Therefore, the following check should be
performed:

ESO.Length >= 3

If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop).

Systems that belong to networks in which this option is in use,
should process the DoD Extended Security option contained in each
packet as specified in RFC 1108 [RFC1108].

3.13.2.14.

3.14.2.14. Commercial IP Security Option (CIPSO) (Type = 134)

This option was proposed by the Trusted Systems Interoperability
Group (TSIG), with the intent of meeting trusted networking
requirements for the commercial trusted systems market place. It is
specified in [CIPSO1992] and [FIPS1994].

o The TSIG proposal was taken to the Commercial Internet Security
Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an
Internet-Draft was produced [CIPSO1992]. The Internet-Draft was
never published as an RFC, and the proposal was later standardized
by the U.S. National Institute of Standards and Technology (NIST)
as "Federal Information Processing Standard Publication 188"
[FIPS1994].

It is currently implemented in a number of operating systems (e.g.,
IRIX [IRIX2008], Security-Enhanced Linux [SELinux2008], and Solaris
[Solaris2008]), and deployed in a number of high-security networks.

o [Zakrzewski2002] and [Haddad2004] provide an overview of a Linux
implementation.

According to the option syntax specified in [CIPSO1992] the following
validation check should be performed:

CIPSO.Length >= 6

If a packet does not pass this check, it should be dropped, and this
event should be logged (e.g., a counter could be incremented to
reflect the packet drop).

Systems that belong to networks in which this option is in use should
process the CIPSO option contained in each packet as specified in
[CIPSO1992].

3.13.2.15.

3.14.2.15. Sender Directed Multi-Destination Delivery (Type = 149)

This option is defined in RFC 1770 [RFC1770], and originally provided
unreliable UDP delivery to a set of addresses included in the option.

This option is obsolete. If a received packet contains this option,
it should be dropped, and this event should be logged (e.g., a
counter could be incremented to reflect the packet drop).

3.14. Differentiated Services field

0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | CU |
+---+---+---+---+---+---+---+---+

Figure 5: Structure of the DS Field

The DSCP ("Differentiated Services CodePoint").is used to select the
treatment the packet is to receive within the Differentiated Services
Domain. The CU ("Currently Unused") field was, at the time the
specification was issued, reserved for future use. The DSCP field is
used to select a PHB, by matching against the entire 6-bit field.

This option is defined in RFC 1770 [RFC1770], and originally provided
unreliable UDP delivery to Section 4.2.2.2 a set of RFC 2474
[RFC2474], would give the packets preferential forwarding treatment
when compared with the PHB selected by addresses included in the codepoint '000000'. option.

This option is obsolete. If
strict priority queuing were utilized, a continuous stream of such
pockets could perform received packet contains this option,
it should be dropped, and this event should be logged (e.g., a Denial of Service
counter could be incremented to other flows which have a
DSCP of lower relative order.

As reflect the DS field is incompatible with packet drop).

3.15. TOS

Figure 2 shows the original Type syntax of Service
field, both DS domains and networks using the original Type of Service field should protect themselves field, as defined by remarking the
corresponding field where appropriate, probably deploying remarking
boundary nodes. Nevertheless, care must be taken so that packets
received with an unrecognized DSCP do not cause the handling system
to malfunction.

3.15. Explicit Congestion Notification (ECN)
RFC 3168 [RFC3168] specifies a mechanism for routers to signal
congestion to hosts sending IP packets, 791 [RFC0791], and updated by marking the offending
packets, rather than discarding them. RFC 3168 defines the ECN
field, which utilizes the CU unused field of the DSCP field described
in Section 3.14 1349 [RFC1349]. We provide a
discussion of this document. Figure obsoleted definition, legacy implementations might
still be using these semantics.

0 1 2 3 4 5 6 shows the syntax of the
ECN field, together with the DSCP 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | D | T | R | C | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+

Figure 6: Type of Service field used for Differentiated
Services.

+----------+----------------------------------------------+
| Bits 0-2 | Precedence |
+----------+----------------------------------------------+
| Bit 3 | 0 = Normal Delay, 1 2 3 = Low Delay |
+----------+----------------------------------------------+
| Bit 4 | 0 = Normal Throughput, 1 = High Throughput |
+----------+----------------------------------------------+
| Bit 5 | 0 = Normal Reliability, 1 = High Reliability |
+----------+----------------------------------------------+
| Bit 6 | 0 = Normal Cost, 1 = Minimize Monetary Cost |
+----------+----------------------------------------------+
| Bits 7
+-----+-----+-----+-----+-----+-----+-----+-----+ | DS FIELD, DSCP Reserved for Future Use (must be zero) | ECN FIELD
+----------+----------------------------------------------+

Table 2: TOS bits

+-----+-----------------+
|
+-----+-----+-----+-----+-----+-----+-----+-----+

Figure 6: The Differentiated Services and ECN fields in IP

As such, the ECN field defines four codepoints:

+-----------+-----------+ 111 | ECN field Network Control | Codepoint
+-----+-----------------+
|
+-----------+-----------+ 110 | 00 Internetwork | Not-ECT
+-----+-----------------+
|
+-----------+-----------+ 101 | 01 CRITIC/ECP | ECT(1)
+-----+-----------------+
|
+-----------+-----------+ 100 | 10 Flash Override | ECT(0)
+-----+-----------------+
|
+-----------+-----------+ 011 | 11 Flash | CE
+-----+-----------------+
|
+-----------+-----------+

Table 3: ECN codepoints

The security implications of ECN are discussed in detail in a number
of Sections of RFC 3168. Of the possible threats discussed in the
ECN specification, we believe that one that can be easily exploited
is that of host falsely indicating ECN-Capability.

An attacker could set the ECT codepoint in the packets it sends, to
signal the network that the endpoints of the transport protocol are
ECN-capable. Consequently, when experiencing moderate congestion,
routers using active queue management based on RED would mark the
packets (with the CE codepoint) rather than discard them. In the
same scenario, packets 010 | Immediate |
+-----+-----------------+
| 001 | Priority |
+-----+-----------------+
| 000 | Routine |
+-----+-----------------+

Table 3: Precedence field

The Type of competing flows that do not have the ECT
codepoint set would Service field can be dropped. Therefore, an attacker would get
better network service than the competing flows.

However, if this moderate congestion turned into heavy congestion,
routers should switch used to drop packets, regardless of whether the
packets have affect the ECT codepoint set or not.

A number of other threats could arise if an attacker was a man way in which the
middle (i.e., was in
packet is treated by the middle systems of a network that process it.
Section 4.2.1 ("Precedence-ordered queue service") and Section 4.2.3
("Weak TOS") of this document describe the path the packets travel to get
to security implications of
the destination host). For a detailed discussion Type of those cases,
we urge Service field in the reader to consult Section 16 forwarding of RFC 3168. packets.

4. Internet Protocol Mechanisms

4.1. Fragment reassembly

To accommodate networks with different Maximum Transmission Units
(MTUs), the Internet Protocol provides a mechanism for the
fragmentation of IP packets by end-systems (hosts) and/or
intermediate systems (routers). Reassembly of fragments is performed
only by the end-systems.

o [Cerf1974] provides the rationale for which packet reassembly is
not performed by intermediate systems.

During the last few decades, IP fragmentation and reassembly has been
exploited in a number of ways, to perform actions such as evading
Network Intrusion Detection Systems (NIDS), bypassing firewall rules,
and performing Denial of Service (DoS) attacks.

o [Bendi1998] and [Humble1998] are examples of the exploitation of
these issues for performing Denial of Service (DoS) attacks.
[CERT1997] and [CERT1998b] document these issues. [Anderson2001]
is a survey of fragmentation attacks. [US-CERT2001] is an example
of the exploitation of IP fragmentation to bypass firewall rules.
[CERT1999] describes the implementation of fragmentation attacks
in Distributed Denial of Service (DDoS) attack tools.

The problem with IP fragment reassembly basically has to do with the
complexity of the function, in a number of aspects:

o Fragment reassembly is a stateful operation for a stateless
protocol (IP). The IP module at the host performing the
reassembly function must allocate memory buffers both for
temporarily storing the received fragments, and to perform the
reassembly function. Attackers can exploit this fact to exhaust
memory buffers at the system performing the fragment reassembly.

o The fragmentation and reassembly mechanisms were designed at a
time in which the available bandwidths were very different from
the bandwidths available nowadays. With the current available
bandwidths, a number of interoperability problems may arise. And
these issues may be intentionally exploited by attackers to
perform Denial of Service (DoS) attacks.

o Fragment reassembly must usually be performed without any
knowledge of the properties of the path the fragments follow.
Without this information, hosts cannot make any educated guess on
how long they should wait for missing fragments to arrive.

o The fragment reassembly algorithm, as described by the IETF
specifications, is ambiguous, and allows for a number of
interpretations, each of which has found place in different TCP/IP
stack implementations.

o The reassembly process is somewhat complex. Fragments may arrive
out of order, duplicated, overlapping each other, etc. This
complexity has lead to numerous bugs in different implementations
of the IP protocol.

4.1.1. Security Implications of Fragment Reassembly

4.1.1.1. Problems related with memory allocation

When an IP datagram is received by an end-system, it will be
temporarily stored in system memory, until the IP module processes it
and hands it to the protocol machine that corresponds to the
encapsulated protocol.

In the case of fragmented IP packets, while the IP module may perform
preliminary processing of the IP header (such as checking the header
for errors and processing IP options), fragments must be kept in
system buffers until all fragments are received and are reassembled
into a complete internet datagram.

As mentioned above, the fact that the internet layer will not usually
have information about the characteristics of the path between the
system 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. Therefore, the specifications recommend to wait for a period
of time that will be acceptable for virtually all the possible
network scenarios in which the protocols might operate.
Specifically, RFC 1122 [RFC1122] states that the reassembly timeout
should be a fixed value between 60 and 120 seconds. If after waiting
for that period of time the remaining fragments have not yet arrived,
all the received fragments for the corresponding packet are
discarded.

o The original IP Specification, RFC 791 [RFC0791], states that
systems should wait for at least 15 seconds for the missing
fragments to arrive. Systems that follow the "Example Reassembly
Procedure" described in Section 3.2 of RFC 791 may end up using a
reassembly timer of up to 4.25 minutes, with minimum of 15
seconds. Section 3.3.2 ("Reassembly") of RFC 1122 corrected this
advice, stating that the reassembly timeout should be a fixed
value between 60 and 120 seconds.

However, the longer the system waits for the missing fragments to
arrive, the longer the corresponding system resources must be tied to
the corresponding packet. The amount of system memory is finite, and
even with today's systems, it can still be considered a scarce
resource.

An attacker could take advantage of the uncomfortable situation the
system performing fragment reassembly is in, by sending forged
fragments that will never reassemble into a complete datagram. That
is, an attacker would send many different fragments, with different
IP IDs, without ever sending all the necessary fragments that would
be needed to reassemble them into a full IP datagram. For each of
the fragments, the IP module would allocate resources and tie them to
the corresponding fragment, until any the reassembly timer for the
corresponding packet expires.

There are some implementation strategies which could increase the
impact of this attack. For example, upon receipt of a fragment, some
systems allocate a memory buffer that will be large enough to
reassemble the whole datagram. While this might be beneficial in
legitimate cases, this just amplifies the impact of the possible
attacks, as a single small fragment could tie up memory buffers for
the size of an extremely large (and unlikely) datagram. The
implementation strategy suggested in RFC 815 [RFC0815] leads to such
an implementation.

The impact of the aforementioned attack may vary depending on some
specific implementation details:

o If the system does not enforce limits on the amount of memory that
can be allocated by the IP module, then an attacker could tie all
system memory to fragments, at which point the system would become
unusable, probably crashing.

o If the system enforces limits on the amount of memory that can be
allocated by the IP module as a whole, then, when this limit is
reached, all further IP packets that arrive would be discarded,
until some fragments time out and free memory is available again.

o If the system enforces limits on the amount memory that can be
allocated for the reassembly of fragments (in addition to
enforcing a limit for the IP module as a whole), then, when this
limit is reached, all further fragments that arrive would be
discarded, until some fragment(s) time out and free memory is
available again.

4.1.2.

4.1.1.2. Problems that arise from the length of the IP Identification
field

The Internet Protocols are currently being used in environments that
are quite different from the ones in which they were conceived. For
instance, the availability of bandwidth at the time the Internet
Protocol was designed was completely different from the availability
of bandwidth in today's networks.

The Identification field is a 16-bit field that is used for the
fragmentation and reassembly function. In the event a datagram gets
fragmented, all the corresponding fragments will share the same
Identification number. Thus, the system receiving the fragments will
be 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
only one packet in the network with a given Identification number.
If not, an Identification number "collision" might occur, and the
receiving system might end up "mixing" fragments that correspond to
different IP datagrams which simply reused the same Identification
number.

For each group of fragments whose Identification numbers "collide",
the fragment reassembly will lead to corrupted packets. The IP
payload of the reassembled datagram will be handed to the
corresponding upper layer protocol, where the error will (hopefully)
be detected by some error detecting code (such as the TCP checksum)
and the packet will be discarded.

An attacker could exploit this fact to intentionally cause a system
to discard all or part of the fragmented traffic it gets, thus
performing a Denial of Service attack. Such an attacker would simply
establish a flow of fragments with different IP Identification
numbers, to trash all or part of the IP Identification space. As a
result, the receiving system would use the attacker's fragments for
the reassembly of legitimate datagrams, leading to corrupted packets
which would later (and hopefully) get dropped.

In most cases, use of a long fragment timeout will benefit the
attacker, as forged fragments will keep the IP Identification space
trashed for a longer period of time.

4.1.3.

4.1.1.3. Problems that arise from the complexity of the reassembly
algorithm

As IP packets can be duplicated by the network, and each packet may
take a different path to get to the destination host, fragments may
arrive not only out of order and/or duplicated, but also overlapping.
This means that the reassembly process can be somewhat complex, with
the corresponding implementation being not specifically trivial.

[Shannon2001] analyzes the causes and attributes of fragment traffic
measured in several types of WANs.

During the years, a number of attacks have exploited bugs in the
reassembly function of a number of operating systems, producing
buffer overflows that have led, in most cases, to a crash of the
attacked system.

4.1.4.

4.1.1.4. Problems that arise from the ambiguity of the reassembly
process

Network Intrusion Detection Systems (NIDSs) typically monitor the
traffic on a given network with the intent of identifying traffic
patterns that might indicate network intrusions.

In the presence of IP fragments, in order to detect illegitimate
activity at the transport or application layers (i.e., any protocol
layer above the network layer), a NIDS must perform IP fragment
reassembly.

In order to correctly assess the traffic, the result of the
reassembly function performed by the NIDS should be the same as that
of the reassembly function performed by the intended recipient of the
packets.

However, a number of factors make the result of the reassembly
process ambiguous:

o The IETF specifications are ambiguous as to what should be done in
the event overlapping fragments were received. Thus, in the
presence of overlapping data, the system performing the reassembly
function is free to either honor the first set of data received,
the latest copy received, or any other copy received in between.

o As the specifications do not enforce any specific fragment timeout
value, different systems may choose different values for the
fragment timeout. This means that given a set of fragments
received at some specified time intervals, some systems will
reassemble the fragments into a full datagram, while others may
timeout the fragments and therefore drop them.

o As mentioned before, as the fragment buffers get full, a Denial of
Service (DoS) condition will occur unless some action is taken.
Many systems flush part of the fragment buffers when some
threshold is reached. Thus, depending on fragment load, timing
issues, and flushing policy, a NIDS may get incorrect assumptions
about how (and if) fragments are being reassembled by their
intended recipient.

As originally discussed by [Ptacek1998], these issues can be
exploited by attackers to evade intrusion detection systems.

There exist freely available tools to forcefully fragment IP
datagrams so as to help evade Intrusion Detection Systems. Frag
router [Song1999] is an example of such a tool; it allows an attacker
to perform all the evasion techniques described in [Ptacek1998].
Ftester [Barisani2006] is a tool that helps to audit systems
regarding fragmentation issues.

4.1.5.

4.1.1.5. Problems that arise from the size of the IP fragments

One approach to fragment filtering involves keeping track of the
results of applying filter rules to the first fragment (i.e., the
fragment with a Fragment Offset of 0), and applying them to
subsequent fragments of the same packet. The filtering module would
maintain a list of packets indexed by the Source Address, Destination
Address, Protocol, and Identification number. When the initial
fragment is seen, if the MF bit is set, a list item would be
allocated to hold the result of filter access checks. When packets
with a non-zero Fragment Offset come in, look up the list element
with a matching Source Address/Destination Address/Protocol/
Identification and apply the stored result (pass or block). When a
fragment with a zero MF bit is seen, free the list element.
Unfortunately, the rules of this type of packet filter can usually be
bypassed. [RFC1858] describes the details of the involved technique.

4.1.6.

4.1.2. Possible security improvements

4.1.2.1. Memory allocation for fragment reassembly

A design choice usually has to be made as to how to allocate memory
to reassemble the fragments of a given packet. There are basically
two options:

o Upon receipt of the first fragment, allocate a buffer that will be
large enough to concatenate the payload of each fragment.

o Upon receipt of the first fragment, create the first node of a
linked list to which each of the following fragments will be
linked. When all fragments have been received, copy the IP
payload of each of the fragments (in the correct order) to a
separate buffer that will be handed to the protocol being
encapsulated in the IP payload.

While the first of the choices might seem to be the most straight-
forward, it implies that even when a single small fragment of a given
packet is received, the amount of memory that will be allocated for
that fragment will account for the size of the complete IP datagram,
thus using more system resources than what is actually needed.

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
received first, as that is the only packet from which the total size
of the IP datagram can be asserted. Otherwise, memory should be
allocated for largest possible packet size (65535 bytes).

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
number of fragments that at any time will be allowed in the system.
This will basically limit the resources spent on the reassembly
process, and prevent an attacker from trashing the whole system
memory.

Furthermore, the IP module should keep a different buffer for IP
fragments than for complete IP datagrams. This will basically
separate the effects of fragment attacks on non-fragmented traffic.
Most TCP/IP implementations, such as that in Linux and those in BSD-
derived systems, already implement this.

[Jones2002] contains an analysis about the amount of memory that may
be needed for the fragment reassembly buffer depending on a number of
network characteristics.

4.1.2.2. Flushing the fragment buffer

In the case of those attacks that aim to consume the memory buffers
used for fragments, and those that aim to cause a collision of IP
Identification numbers, there are a number of counter-measures that
can be implemented.

The IP module should enforce a limit on the amount of memory that can
be allocated for IP fragments, as well as a limit on the number of
fragments that at any time will be allowed in the system. This will
basically limit the resources spent on the reassembly process, and
prevent an attacker from trashing the whole system memory.

Additionally, the IP module should keep a different buffer for IP
fragments than for complete IP datagrams. This will basically
separate the effects of fragment attacks on non-fragmented traffic.
Most TCP/IP implementations, such as that in Linux and those in BSD-
derived systems, already implement this.

Even with these counter-measures in place, there is still the issue
of what to do when the buffer used for IP fragments get full.
Basically, if the fragment buffer is full, no instance of
communication that relies on fragmentation will be able to progress.

Unfortunately, there are not many options for reacting to this
situation. If nothing is done, all the instances of communication
that rely on fragmentation will experience a denial of service.
Thus, the only thing that can be done is flush all or part of the
fragment buffer, on the premise that legitimate traffic will be able
to make use of the freed buffer space to allow communication flows to
progress.

There are a number of factors that should be taken into consideration
when flushing the fragment buffer. First, if a fragment of a given
packet (i.e., fragment with a given Identification number) is
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
its fragments must be received by the system performing the
reassembly function, flushing only a subset of the fragments of a
given packet would keep the corresponding buffers tied to fragments
that would never reassemble into a complete datagram. Additionally,
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
fragments that get dropped, as such a behavior would probably cause a
selective Denial of Service (DoS) to the traffic flows to which that
set of fragments belong.

Many TCP/IP implementations define a threshold for the number of
fragments that, when reached, triggers a fragment-buffer flush. Some
systems flush 1/2 of the fragment buffer when the threshold is
reached. As mentioned before, the idea of flushing the buffer is to
create some free space in the fragment buffer, on the premise that
this will allow for new and legitimate fragments to be processed by
the IP module, thus letting communication survive the overwhelming
situation. On the other hand, the idea of flushing a somewhat large
portion of the buffer is to avoid flushing always the same set of
packets.

4.1.2.3. A more selective fragment buffer flushing strategy

One of the difficulties in implementing counter-measures for the
fragmentation attacks described in this document is that it is
difficult to perform validation checks on the received fragments.
For instance, the fragment on which validity checks could be
performed, the first fragment, may be not the first fragment to
arrive at the destination host.

Fragments can not only arrive out of order because of packet
reordering performed by the network, but also because the system (or
systems) that fragmented the IP datagram may indeed transmit the
fragments out of order. A notable example of this is the Linux
TCP/IP stack, which transmits the fragments in reverse order.

o This means that we cannot enforce checks on the fragments for
which we allocate reassembly resources, as the first fragment we
receive for a given packet may be some other fragment than the
first one (the one with an Fragment Offset of 0).

However, at the point in which we decide to free some space in the
fragment buffer, some refinements can be done to the flushing policy.
The first thing we would like to do is to stop different types of
traffic from interfering with each other. This means, in principle,
that we do not want fragmented UDP traffic to interfere with
fragmented TCP traffic. In order to implement this traffic
separation for the different protocols, a different fragment buffer
would be needed, in principle, for each of the 256 different
protocols that can be encapsulated in an IP datagram.

We believe a tradeoff is to implement two separate fragment buffers:
one for IP datagrams that encapsulate IPsec packets, and another for
the rest of the traffic. This basically means that traffic not
protected by IPsec will not interfere with those flows of
communication that are being protected by IPsec.

The processing of each of these two different fragment buffers would
be completely independent from each other. In the case of the IPsec
fragment buffer, when the buffer needs to be flushed, the following
refined policy could be applied:

o First, for each packet for which the IPsec header has been
received, check that the SPI field of the IPsec header corresponds
to an existing IPsec Security Association (SA), and probably also
check that the IPsec sequence number is valid. If the check
fails, drop all the fragments that correspond to this packet.

o Second, if the fragment buffer still needs to be flushed, drop all
the fragments that correspond to packets for which the full IPsec
header has not yet been received. The number of packets for which
this flushing is performed depends on the amount of free space
that needs to be created.

o Third, if after flushing packets with invalid IPsec information
(First step), and packets on which validation checks could not be
performed (Second step), there is still not enough space in the
fragment buffer, drop all the fragments that correspond to packets
that passed the checks of the first step, until the necessary free
space is created.

The rationale behind this policy is that, at the point of flushing
the fragment buffer, we prefer to keep those packets on which we
could successfully perform a number of validation checks, over those
packets on which those checks failed, or the checks could not even be
performed.

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
Denial of Service attack to communication flows being protected by
IPsec.

Unfortunately, some IP implementations (such as that in Linux
[Linux2006]), when performing fragmentation, send the corresponding
fragments in reverse order. In such cases, at the point of flushing
the fragment buffer, legitimate fragments will receive the same
treatment as the possible forged fragments.

This refined flushing policy provides an increased level of
protection against this type of resource exhaustion attack, while not
making the situation of out-of-order IPsec-secured traffic worse than
with the simplified flushing policy described in the previous
section.

4.1.2.4. Reducing the fragment timeout

RFC 1122 [RFC1122] states that the reassembly timeout should be a
fixed value between 60 and 120 seconds. The rationale behind these
long timeout values is that they should accommodate any path
characteristics, such as long-delay paths. However, it must be noted
that this timer is really measuring inter-fragment delays, or, more
specifically, fragment jitter.

If all fragments take paths of similar characteristics, the inter-
fragment delay will usually be, at most, a few seconds.
Nevertheless, even if fragments take different paths of different
characteristics, the recommended 60 to 120 seconds are, in practice,
excessive.

Some systems have already reduced the fragment timeout to 30 seconds
[Linux2006]. The fragment timeout could probably be further reduced
to approximately 15 seconds; although further research on this issue
is necessary.

It should be noted that in network scenarios of long-delay and high-
bandwidth (usually referred to as "Long-Fat Networks"), using a long
fragment timeout would likely increase the probability of collision
of IP ID numbers. Therefore, in such scenarios it is mandatory highly
desirable to avoid the use of fragmentation with techniques such as
PMTUD [RFC1191] or PLPMTUD [RFC4821].

4.1.2.5. Counter-measure for some IDS evasion techniques

[Shankar2003] introduces a technique named "Active Mapping" that
prevents evasion of a NIDS by acquiring sufficient knowledge about
the network being monitored, to assess which packets will arrive at
the intended recipient, and how they will be interpreted by it.
[Novak2005] describes some techniques that are applied by the Snort
NIDS to avoid evasion.

4.1.2.6. Counter-measure for firewall-rules bypassing

One of the classical techniques to bypass firewall rules involves
sending packets in which the header of the encapsulated protocol is
fragmented. Even when it would be legal (as far as the IETF
specifications are concerned) to receive such a packets, the MTUs of
the network technologies used in practice are not that small to
require the header of the encapsulated protocol to be fragmented.
Therefore, the system performing reassembly should drop all packets
which fragment the upper-layer protocol header, and this event should
be logged (e.g., a counter could be incremented to reflect the packet
drop). The necessary information to perform this check could be
stored by the IP module together with the rest of the upper-layer
protocol information.

Additionally, given that many middle-boxes such as firewalls create
state according to the contents of the first fragment of a given
packet, it is best that, in the event an end-system receives
overlapping fragments, it honors the information contained in the
fragment that was received first.

RFC 1858 [RFC1858] describes the abuse of IP fragmentation to bypass
firewall rules. RFC 3128 [RFC3128] corrects some errors in RFC 1858.

4.2. Forwarding

4.2.1. Precedence-ordered queue service

Section 5.3.3.1 of RFC 1812 [RFC1812] states that routers should
implement precedence-ordered queue service. This means that when a
packet is selected for output on a (logical) link, the packet of
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
strict precedence-ordered service.

Unfortunately, given that it is trivial to forge the IP precedence
field of the IP header, an attacker could simply forge a high
precedence number in the packets it sends, to illegitimately get
better network service. If precedence-ordered queued service is not
required in a particular network infrastructure, it should be
disabled, and thus all packets would receive the same type of
service, despite the values in their Type of Service or
Differentiated Services fields.

When Precedence-ordered queue service is required in the network
infrastructure, in order to mitigate the attack vector discussed in
the previous paragraph, edge routers or switches should be configured
to police and remark the Type of Service or Differentiated Services
values, according to the type of service at which each end-system has
been allowed to send packets.

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".
However, given the security implications of the Precedence field, it
is fair for routers, switches or other middle-boxes, particularly
those in the network edge, to overwrite the Type of Service (or
Differentiated Services) field of the packets they are forwarding,
according to a configured network policy.

Section 5.3.3.1 and Section 5.3.6 of RFC 1812 states that if
precedence-ordered queue service is implemented and enabled, the
router "MUST NOT discard a packet whose precedence is higher than
that of a packet that is not discarded". While this recommendation
makes sense given the semantics of the Precedence field, it is
important to note that it would be simple for an attacker to send
packets with forged high Precedence value to congest some internet
router(s), and cause all (or most) traffic with a lower Precedence
value to be discarded.

4.2.2. Weak Type of Service

Section 5.2.4.3 of RFC 1812 describes the algorithm for determining
the next-hop address (i.e., the forwarding algorithm). Bullet 3,
"Weak TOS", addresses the case in which routes contain a "type of
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 should be considered for forwarding that packet.
However, this means that among the longest match routes for a given
in packet are routes with some TOS other than the one contained in
the received packet, and no routes with the default TOS, the
corresponding packet would be dropped. This may or may not be a
desired behavior.

An alternative to this would be to, in the case among the "longest
match" routes there are only routes with non-default type of services
which do not match the TOS contained in the received packet, to use a
route with any other TOS. While this route would most likely not be
able to address the type of service requested by packet, it would, at
least, provide a "best effort" service.

It must be noted that Section 5.3.2 of RFC 1812 allows for routers
for not honoring the TOS field. Therefore, the proposed alternative
behavior is still compliant with the IETF specifications.

o While officially specified in the RFC series, TOS-based routing is
not widely deployed in the Internet.

4.2.3. Address Resolution

In the case of broadcast link-layer technologies, in order for a
system to transfer an IP datagram it must usually first map an IP
address to the corresponding link-layer address (for example, by
means of the ARP protocol [RFC0826]) . This means that while this
operation is being performed, the packets that would require such a
mapping would need to be kept in memory. This may happen both in the
case of hosts and in the case of routers.

This situation might be exploited by an attacker, which could send a
large amount of packets to a non-existent host which would supposedly
be directly connected to the attacked router. While trying to map
the corresponding IP address into a link-layer address, the attacked
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
function times out, depending on the policy implemented by the
attacked router, only the packet that triggered the call to the
mapping function might be dropped. In that case, the same operation
would be repeated for every packet destined to the non-existent host.
Depending on the timeout value for the mapping function, this
situation might lead to the router buffers to run out of free space,
with the consequence that incoming legitimate packets would have to
be dropped, or that legitimate packets already stored in the router's
buffers might get dropped. Both of these situations would lead
either to a complete Denial of Service, or to a degradation of the
network service.

One counter-measure to this problem would be to drop, at the point
the mapping function times out all the packets destined to the
address that timed out. In addition, a "negative cache entry" might
be kept in the module performing the matching function, so that for
some amount of time, the mapping function would return an error when
the IP module requests to perform a mapping for some address for
which the mapping has recently timed out.

o A common implementation strategy for routers is that when a packet
is received that requires an ARP request to be performed before
the packet can be forwarded, the packet is dropped and the router
is then engaged in the ARP procedure.

4.2.4. Dropping packets

In some scenarios, it may be necessary for a host or router to drop
packets from the output queue. In the event one of such packets
happens to be an IP fragment, and there were other fragments of the
same packet in the queue, those other fragments should also be
dropped. The rationale for this policy is that it is nonsensical to
spend system resources on those other fragments, because, as long as
one fragment is missing, it will be impossible for the receiving
system to reassemble them into a complete IP datagram.

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
subset of all the fragments of the packets were actually transferred
to the next hop.

4.3. Addressing

4.3.1. Unreachable addresses

It is important to understand that while there are some addresses
that are supposed to be unreachable from the public Internet (such as
those described in RFC 1918 [RFC1918], or the "loopback" address),
there are a number of tricks an attacker can perform to reach those
IP addresses that would otherwise be unreachable (e.g., exploit the
LSRR or SSRR IP options). Therefore, when applicable, packet
filtering should be performed at organizational network boundary to
assure that those addresses will be unreachable.

[RFC5735] provides a summary of special use IPv4 addresses.

4.3.2. Private address space

The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private internets:

o 10.0.0.0 - 10.255.255.255 (10/8 prefix)

o 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
o 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

Use of these address blocks is described in RFC 1918 [RFC1918].

Where applicable, packet filtering should be performed at the
organizational perimeter to assure that these addresses are not
reachable from outside the enterprise network.

4.3.3. Class D addresses (224/4 address block)

The Class D addresses correspond to the 224/4 address block, and are
used for Internet multicast. Therefore, if a packet is 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 incremented to
reflect the packet drop). Additionally, if an IP packet with a
multicast Destination Address is received for a connection-oriented
protocol (e.g., TCP), the packet should be dropped, and this event
should be logged (e.g., a counter could be incremented to reflect the
packet drop).

4.3.4. Class E addresses (240/4 address block)

The Class E addresses correspond to the 240/4 address block, and are
currently reserved for experimental use. As a result, a number of
implementations discard packets that contain a Class E address as the
Source Address or Destination Address.

However, there exists ongoing work to reclassify the Class E (240/4)
address block as usable unicast address spaces [Fuller2008a]
[I-D.fuller-240space] [I-D.wilson-class-e]. Therefore, we recommend
implementations to accept addresses in the 240/4 block as valid
addresses for the Source Address and Destination Address.

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.

4.3.5. Broadcast and multicast addresses, and connection-oriented
protocols

For connection-oriented protocols, such as TCP, shared state is
maintained between only two endpoints at a time. Therefore, if an IP
packet with a multicast (or broadcast) Destination Address is
received for a connection-oriented protocol (e.g., TCP), the packet
should be dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop).

4.3.6. Broadcast and network addresses

Originally, the IETF specifications did not permit IP addresses to
have the value 0 or -1 for any of the Host number, network number, or
subnet number fields, except for the cases indicated in Section
4.3.7. However, this changed fundamentally with the deployment of
Classless Inter-Domain Routing (CIDR) [RFC4632], as with CIDR a
system cannot know a priori what the subnet mask is for a particular
IP address.

Many systems now allow administrators to use the values 0 or -1 for
those fields. Despite that according to the IETF specifications
these addresses are illegal, modern IP implementations should
consider these addresses to be valid.

4.3.7. Special Internet addresses

RFC 1812 [RFC1812] discusses the use of some special internet
addresses, which is of interest to perform some sanity checks on the
Source Address and Destination Address fields of an IP packet. It
uses the following notation for an IP address:

{ <Network-prefix>, <Host-number> }

o RFC 1122 [RFC1122] contained a similar discussion of special
internet addresses, including some of the form { <Network-prefix>, <Subnet-
number>,
<Subnet-number>, <Host-number> }. However, as explained in
Section 4.2.2.11 of RFC 1812, in a CIDR world, the subnet number
is clearly an extension of the network prefix and cannot be
interpreted without the remainder of the prefix.

{0, 0}

This address means "this host on this network". It is meant to be
used only during the initialization procedure, by which the host
learns its own IP address.

If a packet is received with 0.0.0.0 as the Source Address for any
purpose other than bootstrapping, the corresponding packet should be
silently dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop). If a packet is
received with 0.0.0.0 as the Destination Address, it should be
silently dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop).

{0, Host number}

This address means "the specified host, in this network". As in the
previous case, it is meant to be used only during the initialization
procedure by which the host learns its own IP address. If a packet
is received with such an address as the Source Address for any
purpose other than bootstrapping, it should be dropped, and this
event should be logged (e.g., a counter could be incremented to
reflect the packet drop). If a packet is received with such an
address as the Destination Address, it should be dropped, and this
event should be logged (e.g., a counter could be incremented to
reflect the packet drop).

{-1, -1}

This address is the local broadcast address. It should not be used
as a source IP address. If a packet is received with 255.255.255.255
as the Source Address, it should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet
drop).

o Some systems, when receiving an ICMP echo request, for example,
will use the Destination Address in the ICMP echo request packet
as the Source Address of the response they send (in this case, an
ICMP echo reply). Thus, when such systems receive a request sent
to a broadcast address, the Source Address of the response will
contain a broadcast address. This should be considered a bug,
rather than a malicious use of the limited broadcast address.

{Network number, -1}

This is the directed broadcast to the specified network. As
recommended by RFC 2644 [RFC2644], routers should not forward
network-directed broadcasts. This avoids the corresponding network
from being utilized as, for example, a "smurf amplifier" [CERT1998a].

As noted in Section 4.3.6 of this document, many systems now allow
administrators to configure these addresses as unicast addresses for
network interfaces. In such scenarios, routers should forward these
addresses as if they were traditional unicast addresses.

In some scenarios a host may have knowledge about a particular IP
address being a network-directed broadcast address, rather than a
unicast address (e.g., that IP address is configured on the local
system as a "broadcast address"). In such scenarios, if a system can
infer the Source Address of a received packet is a network-directed
broadcast address, the packet should be dropped, and this event
should be logged (e.g., a counter could be incremented to reflect the
packet drop).

As noted in Section 4.3.6 of this document, with the deployment of
CIDR [RFC4632], it may be difficult for a system to infer whether a
particular IP address that does not belong to a directly attached
subnet is a broadcast address.

{127, any}

This is the internal host loopback address. Any packet that arrives
on any physical interface containing this address as the Source
Address, the Destination Address, or as part of a source route
(either LSRR or SSRR), should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet
drop).

For example, packets with a Destination Address in the 127.0.0.0/8
address block that are received on an interface other than loopback
should be silently dropped, and this event should be logged (e.g., a
counter could be incremented to reflect the packet drop). Packets
received on any interface other than loopback with a Source Address
corresponding to the system receiving the packet should also be
dropped, and this event should be logged (e.g., a counter could be
incremented to reflect the packet drop).

5. Security Considerations

This document discusses the security implications of the Internet
Protocol (IP), and discusses a number of implementation strategies
that help to mitigate a number of vulnerabilities found in the
protocol during the last 25 years or so.

6. Acknowledgements

The author would like to thank Alfred Hoenes, Joel Jaeggli, Bruno
Rohee, and Andrew Yourtchenko for providing valuable comments on
earlier versions of this document.

This document was written by Fernando Gont on behalf of the UK CPNI
(United Kingdom's Centre for the Protection of National
Infrastructure), and is heavily based on the "Security Assessment of
the Internet Protocol" [CPNI2008] published by the UK Centre for the
Protection of National Infrastructure (CPNI).

The author would like to thank Randall Atkinson, John Day, Juan
Fraschini, Roque Gagliano, Guillermo Gont, Martin Marino, Pekka
Savola, and Christos Zoulas for providing valuable comments on
earlier versions of [CPNI2008], on which this document is based.

The author would like to thank Randall Atkinson and Roque Gagliano,
who generously answered a number of questions.

Finally, the author would like to thank UK CPNI (formerly NISCC) for
their continued support.

7. References

7.1. Normative References

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.

[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.

[RFC1038] St. Johns, M., "Draft revised IP security option",
RFC 1038, January 1988.

[RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP
MTU discovery options", RFC 1063, July 1988.

[RFC1108] Kent, S., "U.S", RFC 1108, November 1991.

[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.

[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.

[RFC1349] Almquist, P., "Type of Service in the Internet Protocol
Suite", RFC 1349, July 1992.

[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393,
January 1993.

[RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi-
Destination Delivery", RFC 1770, March 1995.

[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.

[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.

[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts
in Routers", BCP 34, RFC 2644, August 1999.

[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.

[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.

[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
BCP 153, RFC 5735, January 2010.

7.2. Informative References

[Anderson2001]
Anderson, J., "An Analysis of Fragmentation Attacks",
Available at: http://www.ouah.org/fragma.html , 2001.

[Barisani2006]
Barisani, A., "FTester - Firewall and IDS testing tool",
Available at: http://dev.inversepath.com/trac/ftester ,
2001.

[Bellovin1989]
Bellovin, S., "Security Problems in the TCP/IP Protocol
Suite", Computer Communication Review Vol. 19, No. 2, pp.
32-48, 1989.

[Bellovin2002]
Bellovin, S., "A Technique for Counting NATted Hosts",
IMW'02 Nov. 6-8, 2002, Marseille, France, 2002.

[Bendi1998]
Bendi, "Boink exploit", http://www.insecure.org/sploits/
95.NT.fragmentation.bonk.html , 1998.

[Biondi2007]
Biondi, P. and A. Ebalard, "IPv6 Routing Header Security",
CanSecWest 2007 Security Conference http://www.secdev.org/
conf/IPv6_RH_security-csw07.pdf, 2007.

[CERT1996a]
CERT, "CERT Advisory CA-1996-01: UDP Port Denial-of-
Service Attack",
http://www.cert.org/advisories/CA-1996-01.html, 1996.

[CERT1996b]
CERT, "CERT Advisory CA-1996-21: TCP SYN Flooding and IP
Spoofing Attacks",
http://www.cert.org/advisories/CA-1996-21.html, 1996.

[CERT1996c]
CERT, "CERT Advisory CA-1996-26: Denial-of-Service Attack
via ping",
http://www.cert.org/advisories/CA-1996-26.html, 1996.

[CERT1997]
CERT, "CERT Advisory CA-1997-28: IP Denial-of-Service
Attacks", http://www.cert.org/advisories/CA-1997-28.html,
1997.

[CERT1998a]
CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of-
Service Attacks",
http://www.cert.org/advisories/CA-1998-01.html, 1998.

[CERT1998b]
CERT, "CERT Advisory CA-1998-13: Vulnerability in Certain
TCP/IP Implementations",
http://www.cert.org/advisories/CA-1998-13.html, 1998.

[CERT1999]
CERT, "CERT Advisory CA-1999-17: Denial-of-Service Tools",
http://www.cert.org/advisories/CA-1999-17.html, 1999.

[CERT2001]
CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in
TCP/IP Initial Sequence Numbers",
http://www.cert.org/advisories/CA-2001-09.html, 2001.

[CERT2003]
CERT, "CERT Advisory CA-2003-15 Cisco IOS Interface
Blocked by IPv4 Packet",
http://www.cert.org/advisories/CA-2003-15.html, 2003.

[CIPSO1992]
CIPSO, "COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)", IETF
Internet-Draft (draft-ietf-cipso-ipsecurity-01.txt), work
in progress , 1992.

[CIPSOWG1994]
CIPSOWG, "Commercial Internet Protocol Security Option
(CIPSO) Working Group", http://www.ietf.org/proceedings/
94jul/charters/cipso-charter.html, 1994.

[CPNI2008]
Gont, F., "Security Assessment of the Internet Protocol",
http://www.cpni.gov.uk/Docs/InternetProtocol.pdf, 2008.

[Cerf1974]
Cerf, V. and R. Kahn, "A Protocol for Packet Network
Intercommunication", IEEE Transactions on
Communications Vol. 22, No. 5, May 1974, pp. 637-648,
1974.

[Cisco2003]
Cisco, "Cisco Security Advisory: Cisco IOS Interface
Blocked by IPv4 packet", http://www.cisco.com/en/US/
products/products_security_advisory09186a00801a34c2.shtml,
2003.

[Cisco2008]
Cisco, "Cisco IOS Security Configuration Guide, Release
12.2", http://www.cisco.com/en/US/docs/ios/12_2/security/
configuration/guide/scfipso.html, 2003.

[Clark1988]
Clark, D., "The Design Philosophy of the DARPA Internet
Protocols", Computer Communication Review Vol. 18, No. 4,
1988.

[Ed3f2002]
Ed3f, "Firewall spotting and networks analisys with a
broken CRC", Phrack Magazine, Volume 0x0b, Issue 0x3c,
Phile #0x0c of 0x10 http://www.phrack.org/
issues.html?issue=60&id=12&mode=txt, 2002.

[FIPS1994]
FIPS, "Standard Security Label for Information Transfer",
Federal Information Processing Standards Publication. FIP
PUBS 188 http://csrc.nist.gov/publications/fips/fips188/
fips188.pdf, 1994.

[Fuller2008a]
Fuller, V., Lear, E., and D. Meyer, "240.0.0.0/4: The
Future Begins Now", Routing SIG Meeting, 25th APNIC Open
Policy Meeting, February 25 - 29 2008, Taipei, Taiwan http
://www.apnic.net/meetings/25/program/routing/
fuller-240-future.pdf, 2008.

[Fyodor2004]
Fyodor, "Idle scanning and related IP ID games",
http://www.insecure.org/nmap/idlescan.html, 2004.

[GIAC2000]
GIAC, "Egress Filtering v 0.2",
http://www.sans.org/y2k/egress.htm, 2000.

[Gont2006]
Gont, F., "Advanced ICMP packet filtering",
http://www.gont.com.ar/papers/icmp-filtering.html, 2006.

[Haddad2004]
Haddad, I. and M. Zakrzewski, "Security Distribution for
Linux Clusters", Linux
Journal http://www.linuxjournal.com/article/6943, 2004.

[Humble1998]
Gont, F., "Nestea exploit",
http://www.insecure.org/sploits/linux.PalmOS.nestea.html,
1998.

[I-D.fuller-240space]
Fuller, V., "Reclassifying 240/4 as usable unicast address
space", draft-fuller-240space-02 (work in progress),
March 2008.

[I-D.ietf-tcpm-icmp-attacks]
Gont, F., "ICMP attacks against TCP",
draft-ietf-tcpm-icmp-attacks-05
draft-ietf-tcpm-icmp-attacks-10 (work in progress),
June 2009.
January 2010.

[I-D.stjohns-sipso]
StJohns, M., "Common Architecture Label IPv6 Security
Option (CALIPSO)", draft-stjohns-sipso-11 (work in
progress), March 2009.

[I-D.templin-mtuassurance]
Templin, F., "Requirements for IP-in-IP Tunnel MTU
Assurance", draft-templin-mtuassurance-02 (work in
progress), October 2006.

[I-D.wilson-class-e]
Wilson, P., Michaelson, G., and G. Huston, "Redesignation
of 240/4 from "Future Use" to "Private Use"",
draft-wilson-class-e-02 (work in progress),
September 2008.

[IANA2006a]
Ether Types,
"http://www.iana.org/assignments/ethernet-numbers".

[IANA2006b]
IP Parameters,
"http://www.iana.org/assignments/ip-parameters".

[IANA2006c]
Protocol Numbers,
"http://www.iana.org/assignments/protocol-numbers".

[IRIX2008]
IRIX, "IRIX 6.5 trusted_networking(7) manual page", http:
//techpubs.sgi.com/library/tpl/cgi-bin/
getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/
cat7/trusted_networking.z, 2008.

[Jones2002]
Jones, R., "A Method Of Selecting Values For the
Parameters Controlling IP Fragment Reassembly", ftp://
ftp.cup.hp.com/dist/networking/briefs/ip_reass_tuning.txt,
2002.

[Kenney1996]
Kenney, M., "The Ping of Death Page",
http://www.insecure.org/sploits/ping-o-death.html, 1996.

[Kent1987]
Kent, C. and J. Mogul, "Fragmentation considered harmful",
Proc. SIGCOMM '87 Vol. 17, No. 5, October 1987, 1987.

[Klein2007]
Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
Predictable IP ID Vulnerability", http://
www.trusteer.com/files/
OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP
_ID_Vulnerability.pdf, 2007.

[Kohno2005]
Kohno, T., Broido, A., and kc. Claffy, "Remote Physical
Device Fingerprinting", IEEE Transactions on Dependable
and Secure Computing Vol. 2, No. 2, 2005.

[LBNL2006]
LBNL/NRG, "arpwatch tool", http://ee.lbl.gov/, 2006.

[Linux2006]
The Linux Project, "http://www.kernel.org".

[Microsoft1999]
Microsoft, "Microsoft Security Program: Microsoft Security
Bulletin (MS99-038). Patch Available for "Spoofed Route
Pointer" Vulnerability", http://www.microsoft.com/
technet/security/bulletin/ms99-038.mspx, 1999.

[NISCC2004]
NISCC, "NISCC Vulnerability Advisory 236929: Vulnerability
Issues in TCP",
http://www.uniras.gov.uk/niscc/docs/
re-20040420-00391.pdf, 2004.

[NISCC2005]
NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP:
Vulnerability Issues in ICMP packets with TCP payloads",
http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf,
2005.

[NISCC2006]
NISCC, "NISCC Technical Note 01/2006: Egress and Ingress
Filtering", http://www.niscc.gov.uk/niscc/docs/
re-20060420-00294.pdf?lang=en, 2006.

[Northcutt2000]
Northcut, S. and Novak, "Network Intrusion Detection - An
Analyst's Handbook", Second Edition New Riders Publishing,
2000.

[Novak2005]
Novak, "Target-Based Fragmentation Reassembly",
http://www.snort.org/reg/docs/target_based_frag.pdf,
2005.

[OpenBSD1998]
OpenBSD, "OpenBSD Security Advisory: IP Source Routing
Problem",
http://www.openbsd.org/advisories/sourceroute.txt, 1998.

[Paxson2001]
Paxson, V., Handley, M., and C. Kreibich, "Network
Intrusion Detection: Evasion, Traffic Normalization, and
End-to-End Protocol Semantics", USENIX Conference, 2001,
2001.

[Ptacek1998]
Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial
of Service: Eluding Network Intrusion Detection",
http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps,
1998.

[RFC0815] Clark, D., "IP datagram reassembly algorithms", RFC 815,
July 1982.

[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.

[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.

[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999.

[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.

[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.

[RFC3128] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack (RFC 1858)", RFC 3128, June 2001.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.

[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003.

[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.

[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, April 2006.

[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.

[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963, July 2007.

[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, August 2007.

[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007.

[SELinux2008]
Security Enhanced Linux, "http://www.nsa.gov/selinux/".

[Sanfilippo1998a]
Sanfilippo, S., "about the ip header id", Post to Bugtraq
mailing-list, Mon Dec 14
1998 http://www.kyuzz.org/antirez/papers/ipid.html, 1998.

[Sanfilippo1998b]
Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-
list http://www.kyuzz.org/antirez/papers/dumbscan.html,
1998.

[Sanfilippo1999]
Sanfilippo, S., "more ip id", Post to Bugtraq mailing-
list http://www.kyuzz.org/antirez/papers/moreipid.html,
1999.

[Shankar2003]
Shankar, U. and V. Paxson, "Active Mapping: Resisting NIDS
EvasionWithout
Evasion Without Altering Traffic",
http://www.icir.org/vern/papers/activemap-oak03.pdf,
2003.

[Shannon2001]
Shannon, C., Moore, D., and K. Claffy, "Characteristics of
Fragmented IP Traffic on Internet Links", 2001.

[Silbersack2005]
Silbersack, M., "Improving TCP/IP security through
randomization without sacrificing interoperability",
EuroBSDCon 2005 Conference http://www.silby.com/
eurobsdcon05/eurobsdcon_slides.pdf, 2005.

[Solaris2008]
Solaris Trusted Extensions - Labeled Security for Absolute
Protection, "http://www.sun.com/software/solaris/ds/
trusted_extensions.jsp#3", 2008.

[Song1999]
Song, D., "Frag router tool",
http://www.anzen.com/research/nidsbench/.

[US-CERT2001]
US-CERT, "US-CERT Vulnerability Note VU#446689: Check
Point FireWall-1 allows fragmented packets through
firewall if Fast Mode is enabled",
http://www.kb.cert.org/vuls/id/446689, 2001.

[US-CERT2002]
US-CERT, "US-CERT Vulnerability Note VU#310387: Cisco IOS
discloses fragments of previous packets when Express
Forwarding is enabled",
http://www.kb.cert.org/vuls/id/310387, 2002.

[Watson2004]
Watson, P., "Slipping in the Window: TCP Reset Attacks",
2004 CanSecWest Conference , 2004.

[Zakrzewski2002]
Zakrzewski, M. and I. Haddad, "Linux Distributed Security
Module", http://www.linuxjournal.com/article/6215, 2002.

[daemon91996]
daemon9, route, and infinity, "IP-spoofing Demystified
(Trust-Relationship Exploitation)", Phrack Magazine,
Volume Seven, Issue Forty-Eight, File 14 of
18 http://www.phrack.org/phrack/48/P48-14 , 1988.

Appendix A. Advice and guidance to vendors

Vendors are urged to contact CPNI (vulteam@cpni.gsi.gov.uk) if they
think they may be affected by the issues described in this document.
As the lead coordination center for these issues, CPNI is well placed
to give advice and guidance as required.

CPNI works extensively with government departments and agencies,
commercial organizations and the academic community to research
vulnerabilities and potential threats to IT systems especially where
they may have an impact on Critical National Infrastructure's (CNI).

Other ways to contact CPNI, plus CPNI's PGP public key, are available
at http://www.cpni.gov.uk .

Appendix B. Changes from previous versions of the draft (to be removed
by the RFC Editor before publishing this document as an
RFC)

B.1. Changes from draft-ietf-opsec-ip-security-01

o Addresses rest of the feedback received from Andrew Yourtchenko
(http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html)

o Addresses a very thorough review by Alfred Hoenes (sent off-list)

o Addresses feedback submitted by Joel Jaeggli (off-list)

o Addresses feedback submitted (off-list) by Bruno Rohee.

o Miscellaneous edits (centers expressions, fills missing graphics
with ASCII-art, etc.)

B.2. Changes from draft-ietf-opsec-ip-security-00

o Addresses part of the feedback received from Andrew Yourtchenko
(http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html)

B.2.

B.3. Changes from draft-gont-opsec-ip-security-01

o Draft resubmitted as draft-ietf, as a result of wg consensus on
adopting the document as an opsec wg item.

B.3.

B.4. Changes from draft-gont-opsec-ip-security-00

o Fixed author's affiliation.

o Added Figure 4. 5.

o Fixed a few typos.

o (no technical changes)

Author's Address

Fernando Gont
UK Centre for the Protection of National Infrastructure

Email: fernando@gont.com.ar
URI: http://www.cpni.gov.uk