RFC 6274
Security Assessment of the Internet Protocol Version 4
RFC 6274: Security Assessment of the Internet Protocol Version 4 🦋
okay bestie, let's get into it 💖 this one is from July 2011, written by F. Gont from the UK's CPNI (Centre for the Protection of National Infrastructure) 🇬🇧. It's Informational, so it's not a Standards Track spec, just a security check-up on IPv4 that's giving serious expert energy ✨
The header doesn't list anything it obsoletes or updates, so it's a standalone doc 🌸 It's ISSN 2070-1721 too, if you're keeping track 📚
Abstract ✨
so the vibe here is: this doc is a security assessment 🔍 It looks at the IETF specs for Internet Protocol version 4, plus a bunch of mechanisms and policies that popular IPv4 implementations actually use 💅 It's based on a project by the UK's Centre for the Protection of National Infrastructure (CPNI), so yes, the research is serious 🫶
Status of This Memo 🎀
this one is not an Internet Standards Track spec. It's published for informational purposes only 📖
It is an IETF product though 💜 it represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for an Internet Standard, though. See Section 2 of RFC 5741 for the details 🧚
For the current status, errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6274 🌈
Copyright Notice 🌸
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 💖
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the day it was published. Please read these carefully, bestie, because they spell out your rights and restrictions for this document 📜
Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're also provided without warranty, as described in the Simplified BSD License 🫶
Table of Contents 🦋
1. Preface .........................................................4
1.1. Introduction ...............................................4
1.2. Scope of This Document .....................................6
1.3. Organization of This Document ..............................7
2. The Internet Protocol ...........................................7
3. Internet Protocol Header Fields .................................8
3.1. Version ....................................................9
3.2. IHL (Internet Header Length) ..............................10
3.3. Type of Service (TOS) .....................................10
3.3.1. Original Interpretation ............................10
3.3.2. Standard Interpretation ............................12
3.3.2.1. Differentiated Services Field .............12
3.3.2.2. Explicit Congestion Notification (ECN) ....13
3.4. Total Length ..............................................14
3.5. Identification (ID) .......................................15
3.5.1. Some Workarounds Implemented by the Industry .......16
3.5.2. Possible Security Improvements .....................17
3.5.2.1. Connection-Oriented Transport Protocols ...17
3.5.2.2. Connectionless Transport Protocols ........18
3.6. Flags .....................................................19
3.7. Fragment Offset ...........................................21
3.8. Time to Live (TTL) ........................................22
3.8.1. Fingerprinting the Operating System in Use
by the Source Host .................................24
3.8.2. Fingerprinting the Physical Device from
which the Packets Originate ........................24
3.8.3. Mapping the Network Topology .......................24
3.8.4. Locating the Source Host in the Network Topology ...25
3.8.5. Evading Network Intrusion Detection Systems ........26
3.8.6. Improving the Security of Applications That
Make Use of the Internet Protocol (IP) .............27
3.8.7. Limiting Spread ....................................28
3.9. Protocol ..................................................28
3.10. Header Checksum ..........................................28
3.11. Source Address ...........................................29
3.12. Destination Address ......................................30
3.13. Options ..................................................30
3.13.1. General Issues with IP Options ....................31
3.13.1.1. Processing Requirements ..................31
3.13.1.2. Processing of the Options by the
Upper-Layer Protocol .....................32
3.13.1.3. General Sanity Checks on IP Options ......32
3.13.2. Issues with Specific Options ......................34
3.13.2.1. End of Option List (Type=0) ..............34
3.13.2.2. No Operation (Type=1) ....................34
3.13.2.3. Loose Source and Record Route
(LSRR) (Type=131) ........................34
3.13.2.4. Strict Source and Record Route
(SSRR) (Type=137) ........................37
3.13.2.5. Record Route (Type=7) ....................39
3.13.2.6. Stream Identifier (Type=136) .............40
3.13.2.7. Internet Timestamp (Type=68) .............40
3.13.2.8. Router Alert (Type=148) ..................43
3.13.2.9. Probe MTU (Type=11) (Obsolete) ...........44
3.13.2.10. Reply MTU (Type=12) (Obsolete) ..........44
3.13.2.11. Traceroute (Type=82) ....................44
3.13.2.12. Department of Defense (DoD)
Basic Security Option (Type=130) ........45
3.13.2.13. DoD Extended Security Option
(Type=133) ..............................46
3.13.2.14. Commercial IP Security Option
(CIPSO) (Type=134) ......................47
3.13.2.15. Sender Directed
Multi-Destination Delivery (Type=149) ...47
4. Internet Protocol Mechanisms ...................................48
4.1. Fragment Reassembly .......................................48
4.1.1. Security Implications of Fragment Reassembly .......49
4.1.1.1. Problems Related to Memory Allocation .....49
4.1.1.2. Problems That Arise from the
Length of the IP Identification Field .....51
4.1.1.3. Problems That Arise from the
Complexity of the Reassembly Algorithm ....52
4.1.1.4. Problems That Arise from the
Ambiguity of the Reassembly Process .......52
4.1.1.5. Problems That Arise from the Size
of the IP Fragments .......................53
4.1.2. Possible Security Improvements .....................53
4.1.2.1. Memory Allocation for Fragment
Reassembly ................................53
4.1.2.2. Flushing the Fragment Buffer ..............54
4.1.2.3. A More Selective Fragment Buffer
Flushing Strategy .........................55
4.1.2.4. Reducing the Fragment Timeout .............57
4.1.2.5. Countermeasure for Some NIDS
Evasion Techniques ........................58
4.1.2.6. Countermeasure for Firewall-Rules
Bypassing .................................58
4.2. Forwarding ................................................58
4.2.1. Precedence-Ordered Queue Service ...................58
4.2.2. Weak Type of Service ...............................59
4.2.3. Impact of Address Resolution on Buffer Management ..60
4.2.4. Dropping Packets ...................................61
4.3. Addressing ................................................61
4.3.1. Unreachable Addresses ..............................61
4.3.2. Private Address Space ..............................61
4.3.3. Former Class D Addresses (224/4 Address Block) .....62
4.3.4. Former Class E Addresses (240/4 Address Block) .....62
4.3.5. Broadcast/Multicast Addresses and
Connection-Oriented Protocols ......................62
4.3.6. Broadcast and Network Addresses ....................63
4.3.7. Special Internet Addresses .........................63
5. Security Considerations ........................................65
6. Acknowledgements ...............................................65
7. References .....................................................66
7.1. Normative References ......................................66
7.2. Informative References ....................................681. Preface ✨
1.1. Introduction
okay so, the TCP/IP protocols were cooked up in a super chill environment, nothing like the hostile internet we live on now 🌸 but they worked so well that people adopted them early in production, and now the world's economy kinda depends on them 💅
ngl, a lot of textbooks and articles spread the myth that the Internet protocols were designed for warfare 🙈 but the top goal for the Defense Advanced Research Projects Agency (DARPA) Internet Program was sharing big service machines on the ARPANET [Clark1988]. So a lot of protocol specs only focus on the operational side of things and totally overlook their security implications 😭
While the Internet has evolved since it began, its building blocks are still basically the same core protocols the ARPANET adopted more than two decades ago ✨ During the last twenty years, loads of vulnerabilities turned up in the TCP/IP stacks of various systems. Some came from flaws in certain implementations and only affected a handful of systems, while others came from flaws in the protocols themselves and affected virtually every implementation [Bellovin1989]. Even in the last couple of years, researchers were still digging into security problems in the core protocols [RFC5927] [Watson2004] [NISCC2004] [NISCC2005] 👀
The discovery of these vulnerabilities led a number of CSIRTs (Computer Security Incident Response Teams) and vendors to publish reports 📣 which helped raise awareness about the threats and the best mitigations known at the time. The downside? The documentation of these protocol vulnerabilities got spread across a huge number of documents, and they're sometimes hard to track down 🥲
For some reason, a lot of the security community's effort on the Internet protocols never turned into official documents (RFCs) issued by the IETF (Internet Engineering Task Force) 💔 This basically meant that "known" security problems weren't always addressed by every vendor. On top of that, vendors often shipped quick "fixes" for protocol flaws without carefully analyzing how effective they were or how they'd affect interoperability [Silbersack2005] 🫠
Because the IETF hasn't adopted these fixes, any system built in the future from the official TCP/IP specifications could reincarnate security flaws that have already hit our communication systems in the past. Not iconic at all 💀
Making a secure TCP/IP implementation is really hard right now, partly because there isn't a single document that works as a security roadmap for the protocols 🗺️ Implementers have to find the relevant documentation themselves and tell apart the advice that's correct from the advice that's misleading, which is based on inaccurate or wrong assumptions.
There's a clear need for a companion document to the IETF specifications: one that discusses the security aspects and implications of the protocols, identifies the possible threats, discusses the possible countermeasures, and analyzes how effective they are 🎀
This document is the result of an assessment of the IETF specifications of the Internet Protocol version 4 (IPv4) from a security point of view. Possible threats were identified and, where possible, countermeasures were proposed ✨ Many implementation flaws that led to security vulnerabilities are referenced too, in the hope that future implementations won't run into the same problems. This document doesn't stop at a security assessment of the relevant IETF specifications either. It also assesses common implementation strategies found in the real world 💅
Lots of IP implementations have been hit by so-called "packet-of-death" vulnerabilities, where a single specially crafted packet makes the IP implementation crash or otherwise misbehave 💥 In most cases the attack packet is simply malformed. In other cases it's well-formed but exercises a rarely used path through the IP stack. Well-designed IP implementations should protect against these attacks, so this document describes a number of sanity checks that are expected to prevent most of the "packet-of-death" attack vectors mentioned above. If an IP implementation turns out to be vulnerable to one of these attacks, administrators must resort to mitigating them with packet filtering 🛡️
This document also analyzes the security implications of changes in the operational environment since the Internet Protocol was designed 👀 For example, it looks at how the Internet Protocol could be exploited to evade Network Intrusion Detection Systems (NIDSs) or to circumvent firewalls.
This document doesn't aim to be the final word on the security of the Internet Protocol (IP) 🙅♀️ Instead, it aims to raise awareness about the many security threats based on IP that have been faced in the past, that we're facing now, and that we may still have to deal with later. It gives advice for the secure implementation of the Internet Protocol (IP), and it also shares insights about the security aspects of the protocol that may help the Internet operations community 🌈
Feedback from the community is more than encouraged, so this document can be as accurate as possible and stay updated as new threats are discovered 🦋
This document is heavily based on the "Security Assessment of the Internet Protocol" [CPNI2008], released by the UK Centre for the Protection of National Infrastructure (CPNI), available at http://www.cpni.gov.uk/Products/technicalnotes/3677.aspx.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📜
1.2. Scope of This Document
There are a number of protocols that affect how IP systems operate, but this document focuses only on the specifications of the Internet Protocol (IP) 🎯 For example, routing and bootstrapping protocols are considered out of scope for this project 🙅♀️
The following IETF RFCs were selected as the primary sources for the assessment:
- RFC 791, "INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION" (45 pages).
- RFC 815, "IP DATAGRAM REASSEMBLY ALGORITHMS" (9 pages).
- RFC 919, "BROADCASTING INTERNET DATAGRAMS" (8 pages).
- RFC 950, "Internet Standard Subnetting Procedure" (18 pages)
- RFC 1112, "Host Extensions for IP Multicasting" (17 pages)
- RFC 1122, "Requirements for Internet Hosts -- Communication Layers" (116 pages).
- RFC 1812, "Requirements for IP Version 4 Routers" (175 pages).
- RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" (20 pages).
- RFC 2475, "An Architecture for Differentiated Services" (36 pages).
- RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP" (63 pages).
- RFC 4632, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan" (27 pages).
1.3. Organization of This Document
This document is basically organized into two parts: "Internet Protocol header fields" and "Internet Protocol mechanisms" 🧩 The first part analyzes each field of the Internet Protocol header, identifies their security implications, and discusses possible countermeasures for the identified threats. The second part analyzes the security implications of the mechanisms implemented by the Internet Protocol 💜
2. The Internet Protocol
The Internet Protocol (IP) provides a basic data transfer function for passing data blocks called "datagrams" from a source host to a destination host, across any intervening networks 🚀 It also provides some functions that are useful for interconnecting heterogeneous networks, such as fragmentation and reassembly.
The "datagram" has a few characteristics that make it convenient for interconnecting systems [Clark1988]:
- It eliminates the need for connection state within the network, which improves the survivability characteristics of the network 🌟
- It provides a basic data transport service that can be used as a building block for other transport services (reliable data transport services, etc.) 🧱
- It represents the minimum network service assumption, which enables IP to 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, as specified in [RFC0791].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Options ] | [ Padding ] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Internet Protocol Header FormatEven though the minimum IP header size is 20 bytes, an IP module might be handed an (illegitimate) "datagram" of less than 20 bytes 🙃 So, before doing any processing of the IP header fields, the following check should be performed by the IP module on the packets handed over by the link layer:
LinkLayer.PayloadSize >= 20where LinkLayer.PayloadSize is the length (in octets) of the datagram passed from the link layer to the IP layer.
If the packet doesn't pass this check, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 📉
The following subsections contain further sanity checks that should be performed on IP packets ✨
3.1. Version ✨
okay so the Version field is a 4-bit field 💖 It tells you which version of the Internet Protocol (IP) the packet is, and that basically decides the syntax of the whole packet 🎀 For IPv4, this field MUST be 4. Non-negotiable, bestie 💅
when a link-layer protocol de-multiplexes a packet to an Internet module, it does that using a Protocol Type field in the data-link packet header 🦋
in theory, different IP versions could live on the same network by sharing the same Protocol Type at the link layer and just using a different value in the Version field of the IP header ✨ so one IP module could handle every version and tell them apart by checking this field 🧚
in practice though, it's not really like that 😭 different IP versions get identified by a different Protocol Type number in the link-layer header (EtherType, if we're talking Ethernet). for example, IPv4 datagrams get wrapped in Ethernet frames with an EtherType of 0x0800, and IPv6 datagrams use an EtherType of 0x86DD [IANA_ET] 🌈
so, if an IPv4 module receives a packet, the Version field MUST be checked to be 4 🔥 if that check fails, the packet SHOULD be silently dropped, and the event SHOULD be logged (like, a counter could go up to show the drop) 🙈 and if an implementation skips this check, an attacker could put a different value in the Version field and maybe slip past NIDSs that pick which pattern-matching rules to use based on that field 💀 not okay!!
if the link layer uses a specific "Protocol Type" value for IPv4 packets (Ethernet does this), a node SHOULD check that IPv4 packets get de-multiplexed to the IPv4 module whenever that value was used in the Protocol Type field 🍓 if a packet fails this check, it SHOULD be silently dropped 🫶
An attacker could encapsulate IPv4 packets using other link-layer "Protocol Type" values to try to subvert link-layer Access Control Lists (ACLs) and/or for tampering with NIDSs. 😭 this one is seriously sneaky, so don't skip the check!!
3.2. IHL (Internet Header Length) 💜
the IHL (Internet Header Length) field tells you how long the Internet header is, measured in 32-bit words (4 bytes each) 🌸 there are a few sanity checks you should run on IHL so that possible packet-of-death vulnerabilities get avoided. main character energy for security 👑
since the minimum datagram size is 20 bytes, the minimum legal value for this field is 5 ✨ so this check SHOULD be enforced:
IHL >= 5if the packet doesn't pass that check, it SHOULD be dropped, and the event SHOULD be logged (again, a counter could be incremented to reflect the drop) 🙈
obviously, the Internet header can't be bigger than the whole Internet datagram it belongs to 🧠 so this check SHOULD be enforced too:
IHL * 4 <= Total LengthThis needs to refer to the size of the datagram as specified by the sender in the Total Length field, since link layers might have added some padding (see Section 3.4). 🎀 so use the Total Length the sender wrote down, not whatever the link layer padded it up to!
if the packet fails this one, it SHOULD be dropped, and the event SHOULD be logged 🥺
and fyi, this check still lets through datagrams with zero data bytes in the payload. those are nonsensical for basically every protocol that runs over IP, but they're still legal 🤷♀️💅
3.3. Type of Service (TOS) 🦋
3.3.1. Original Interpretation 🕰️
so this is the OG version of the Type of Service field, from RFC 791 [RFC0791] and updated by RFC 1349 [RFC1349] 🌈 it was superseded way back, but some deployed implementations still assume it, so you'll want to know it. here's the layout:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | D | T | R | C | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+Figure 2: Type of Service Field (Original Interpretation)
+----------+----------------------------------------------+
| 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: Semantics of the TOS Bits
+-----+-----------------+
| 111 | Network Control |
+-----+-----------------+
| 110 | Internetwork |
+-----+-----------------+
| 101 | CRITIC/ECP |
+-----+-----------------+
| 100 | Flash Override |
+-----+-----------------+
| 011 | Flash |
+-----+-----------------+
| 010 | Immediate |
+-----+-----------------+
| 001 | Priority |
+-----+-----------------+
| 000 | Routine |
+-----+-----------------+Table 2: Semantics of the Possible Precedence Field Values
the Type of Service field can change how a packet gets treated by the systems that process it along the network 🚀 Section 4.2.1 ("Precedence-Ordered Queue Service") and Section 4.2.2 ("Weak Type of Service") of this document cover the security implications of using it to forward packets 🔐
3.3.2. Standard Interpretation 🎀
3.3.2.1. Differentiated Services Field 💅
the Differentiated Services Architecture is built to give scalable service discrimination across the Internet, without needing per-flow state and signaling at every hop [RFC2475] ✨ RFC 2474 [RFC2474] redefined the IP "Type of Service" octet and introduced the Differentiated Services Field (DS Field) 🦋 here's what it looks like:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | CU |
+---+---+---+---+---+---+---+---+Figure 3: Revised Structure of the Type of Service Field (RFC 2474)
the DSCP ("Differentiated Services CodePoint") picks the treatment a packet gets inside a Differentiated Services Domain 🌸 the CU ("Currently Unused") field was, when the spec came out, reserved for future use. the DSCP field selects a PHB (Per-Hop Behavior) by matching against the entire 6-bit field 🧚
okay now the security part, and it's a big one 😭 since the DSCP decides how a packet is treated inside a DS domain, an attacker could send packets with a forged DSCP to steal service or even run a Denial-of-Service (DoS) attack 💀 specifically, an attacker could forge packets with a codepoint of the type 11x000. according to Section 4.2.2.2 of RFC 2474 [RFC2474], those packets would get preferential forwarding compared to the PHB picked by codepoint 000000 🔥 and if strict priority queuing were in use, a nonstop stream of those packets could DoS other flows that have a DSCP of lower relative order 🙈
and because the DS field doesn't play nicely with the original Type of Service field, both DS domains and networks still using the original field SHOULD protect themselves by remarking the corresponding field where it makes sense, probably by deploying remarking boundary nodes 🛡️ but care MUST be taken so that packets with an unrecognized DSCP don't make the handling system malfunction 🫶
3.3.2.2. Explicit Congestion Notification (ECN) 🚦✨
okay so bestie, this one is about routers being polite 🫶. Instead of just yeeting packets when the road gets crowded, a router can mark them so the endpoints know there's congestion. That's the whole ECN vibe. [RFC3168] is the spec that defines this mechanism, and it uses the CU field that [RFC2474] already defined 💅. Here's the current layout of the IP Type of Service field, with the DSCP field for Differentiated Services and the ECN field sitting right at the end:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+Figure 4: The Differentiated Services and ECN Fields in IP 🎀
So the ECN field has four codepoints, and honestly they're iconic 👑:
+-----------+-----------+
| ECN field | Codepoint |
+-----------+-----------+
| 00 | Not-ECT |
+-----------+-----------+
| 01 | ECT(1) |
+-----------+-----------+
| 10 | ECT(0) |
+-----------+-----------+
| 11 | CE |
+-----------+-----------+
Table 3: ECN CodepointsECN is an end-to-end transport protocol mechanism 🦋. It's based on routers telling the endpoints what's happening as a packet flow passes through them. Routers need to handle this on the fast path, so the ECN field lives at a fixed spot in the IP header 🧚. But here's the catch: its use has to be negotiated at the transport layer, and the accumulated congestion notifications have to be sent back to the sending node using transport protocol means. So ECN support has to be specified per transport protocol. Not one-size-fits-all, bestie 💅.
[RFC6040] specifies how the Explicit Congestion Notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. 🌈
Security time, and I'm not playing around 😭. The ECN security stuff is discussed in detail in several Sections of RFC 3168. Of all the threats in the ECN spec, we believe the one that's super easy to exploit is a host falsely claiming ECN-Capability 🙈.
Here's the drama 🍓. An attacker could set the ECT codepoint on the packets it sends, which tells the network "hey, my endpoints are ECN-capable." So when there's moderate congestion, routers using active queue management based on Random Early Detection (RED) would mark those packets with CE instead of dropping them. Meanwhile, competing flows that don't have the ECT codepoint set would get dropped. Therefore, the attacker gets better network service than the competing flows. Not fair, periodt 💀.
However, if that moderate congestion turns into heavy congestion, routers should switch to dropping packets, regardless of whether or not they have the ECT codepoint set ⭐.
A bunch of other threats could show up if an attacker was a man in the middle, meaning they were sitting in the middle of the path the packets take to reach the destination host 👀. For a detailed discussion of those cases, we urge the reader to consult Section 16 of RFC 3168 🫶.
There's also ongoing work in the research community and the IETF to define alternate semantics for the CU/ECN field of the IP TOS octet (see [RFC5559], [RFC5670], and [RFC5696]) 🔥. The application of these methods MUST be confined to tightly administered domains, and on exit from such domains, all packets need to be (re-)marked with ECN semantics. Let's keep the drama inside the walls, okay? 🏰
3.4. Total Length 📏
The Total Length field is the length of the datagram, measured in bytes, including both the IP header and the IP payload. Being a 16-bit field, it allows for datagrams of up to 65535 bytes. [RFC0791] says all hosts SHOULD be prepared to receive datagrams of up to 576 bytes, whether they arrive whole or in fragments. But most modern implementations can reassemble datagrams of at least 9 Kbytes, so the vibes have upgraded 🚀.
Usually, a host will not send a remote peer an IP datagram larger than 576 bytes, unless it's been explicitly signaled that the remote peer can receive such "large" datagrams (for example, through TCP's Maximum Segment Size (MSS) option) 🎀. However, systems SHOULD assume that they may receive datagrams larger than 576 bytes, whether or not they signal their remote peers to do so. Honestly, it's super common for Network File System (NFS) [RFC3530] implementations to send datagrams larger than 576 bytes, even without explicit signaling that the destination can handle such "large" datagrams 🙃.
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 👀. That difference usually comes from legitimate padding bytes at the link-layer protocol, but it could also be the result of malicious activity by an attacker 😈. Even when the maximum length of an IP datagram is 65535 bytes, if the link-layer technology allows payloads larger than 65535 bytes, an attacker could forge a large link-layer packet and mean it for the IP module. If the receiving system's IP module isn't ready to handle that oversized link-layer payload, an unexpected failure might occur 💥. So the memory buffer the IP module uses to store the link-layer payload SHOULD be allocated according to the payload size reported by the link layer, not according to the Total Length field of the IP packet it contains.
The IP module could also be handed a packet smaller than the actual IP packet size claimed by the Total Length field. This could be used, for example, to produce an information leakage 🫣. So the following check SHOULD be performed:
LinkLayer.PayloadSize >= Total LengthIf this check fails, the IP packet SHOULD be dropped, and the event SHOULD be logged (e.g., a counter could be incremented to reflect the packet drop) 📝. As the expression above implies, the number of bytes passed by the link layer to the IP module SHOULD contain at least as many bytes as the Total Length field of the IP header claims.
[US-CERT2002] is an example of the exploitation of a forged IP Total Length field to produce an information leakage attack. 🕵️♀️
3.5. Identification (ID) 🆔
The Identification field is set by the sending host to help reassemble fragmented datagrams. At any time, it MUST be unique for each set of {Source Address, Destination Address, Protocol} 🔑.
In many systems, the value for this field is determined at the IP layer, on a protocol-independent basis. Lots of those systems also just increment the IP Identification field for each packet they send 😬.
This implementation strategy is inappropriate for a number of reasons 🙅♀️. Firstly, if the Identification field is set on a protocol-independent basis, it wraps more often than necessary, so the implementation is more prone to the problems discussed in [Kent1987] and [RFC4963]. Secondly, this strategy opens the door to an information leakage that can be exploited in a number of ways 🚪.
[Sanfilippo1998a] describes how the Identification field can be leveraged to determine the packet rate at which a given system is transmitting information. Later, [Sanfilippo1998b] described how a system with such an implementation can be used to perform a stealth port scan on a third (victim) host 🕶️. [Sanfilippo1999] explained how to exploit this implementation strategy to uncover the rules of a number of firewalls 🧱. [Bellovin2002] explains how the IP Identification field can be exploited to count the number of systems behind a NAT 🔢. And [Fyodor2004] is an entire paper on most (if not all) of the ways to exploit the information in the Identification field of the IP header 📚.
Section 4.1 contains a discussion of the security implications of the IP fragment reassembly mechanism, which is the primary "consumer" of this field. 🍽️
3.5.1. Some Workarounds Implemented by the Industry 🛠️
As the IP Identification field is only used for the reassembly of datagrams, some operating systems (such as Linux) decided to set this field to 0 in all packets that have the DF bit set. In principle, this avoids any type of information leakage. However, it was detected that some non-RFC-compliant middle-boxes fragmented packets even when they had the DF bit set. In that scenario, all datagrams originally sent with the DF bit set would result in fragments with an Identification field of 0, which leads to problems ("collision" of the Identification number) in the reassembly process 😵💫.
Linux (and Solaris) later set the IP Identification field on a per-IP-address basis. This avoids some of the security implications of the IP Identification field, but not all. For example, systems behind a load balancer can still be counted 🙄.
3.5.2. Possible Security Improvements 🔐
Contrary to common wisdom, the IP Identification field does NOT need to be system-wide unique for each packet. It just has to be unique for each {Source Address, Destination Address, Protocol} tuple 💜.
For instance, the TCP specification defines a generic send() function that takes the IP ID as one of its arguments. 🧠
We provide an analysis of the possible security improvements that could be implemented, based on whether the protocol using the services of IP is connection-oriented or connection-less. ✨
3.5.2.1. Connection-Oriented Transport Protocols
okay so, to dodge the info leaks I just talked about 🙈, you could use a pseudo-random number generator (PRNG) to set the IP Identification field on a {Source Address, Destination Address} basis, for each connection-oriented transport protocol 💅
[RFC4086] has the tea on how to generate pseudo-random numbers ✨
[Klein2007] is a security advisory about a weakness in the PRNG a bunch of operating systems used to generate the IP Identification 💀
in theory, a PRNG could lead to a case where the same Identification number gets used more than once in the same time span for datagrams that end up getting fragmented (with the reassembly problems that come with it) 😭 but in practice, it's unlikely to cause trouble, so don't panic 🫶
most implementations of connection-oriented protocols, like TCP, already have some mechanism for avoiding fragmentation, such as the Path-MTU Discovery mechanism described in [RFC1191] 🎀 so fragmentation only happens if a non-RFC-compliant middle-box that still fragments packets even when the DF bit is set sits somewhere along the path to the destination host 🙄 once the middle-box signals the sending system (with an ICMP "fragmentation needed and DF bit set" error message) that it should shrink the packets it sends, fragmentation gets avoided ✨ also, for reassembly problems to show up, the same Identification value would have to get reused really often, and either strong packet reordering or packet loss would also need to happen 🌸
ngl, no matter what policy you use to pick the Identification field, fragmentation is already rough with today's link speeds (aka very likely to cause fragment reassembly errors), so you shouldn't rely on it 😤 instead, you should implement a mechanism for avoiding fragmentation, like [RFC1191] or [RFC4821] 👑
3.5.2.2. Connectionless Transport Protocols
connectionless transport protocols often have these vibes:
- lack of flow-control mechanisms,
- lack of packet sequencing mechanisms, and/or,
- lack of reliability mechanisms (such as "timeout and retransmit").
basically, the scenarios and/or apps that use connectionless transport protocols assume that:
- Applications will be used in environments in which packet reordering is very unlikely (such as Local Area Networks), as the transport protocol itself does not provide data sequencing. 🧚
- The data transfer rates will be low enough that flow control will be unnecessary. 🍓
- Packet loss is can be tolerated and/or is unlikely. 🦋
with those assumptions in mind, the Identification field could still be set according to a pseudo-random number generator (PRNG) ✨
[RFC4086] has the tea on how to generate pseudo-random numbers 💖
if a given Identification number got reused while the first instance of that same number was still on the network, the first IP datagram would get reassembled before the fragments of the second IP datagram reached their destination 🫠
and if that wasn't the case, reassembling the fragments would result in a corrupt datagram 😬 some existing work [Silbersack2005] assumes this error would get caught by some upper-layer error detection code, but the error detection code in question (like UDP's checksum) might not be able to reliably detect data corruption caused by swapping in a complete data block (which is exactly what happens when IP Identification numbers collide) 🙃
in the case of UDP, some systems have been known to not turn on the UDP checksum by default, unfortunately 😩 for most apps, packets with errors should get dropped by the transport layer and not handed to the application 🌈 a small number of applications might actually benefit from turning the checksum off, like streaming media where you'd rather not drop a whole sample over a single-bit error, and UDP tunneling apps where the payload (aka the inner packet) is already protected by its own transport checksum or other error detection mechanism 🎧
overall, if IP Identification number collisions become a problem for an application using a connectionless protocol, the application designers should consider using a different transport protocol (one that hopefully avoids fragmentation) 💅
it must be noted that an attacker could on purpose exploit IP Identification collisions to run a DoS attack 🚨 by sending forged fragments, they could make the reassembly process produce a corrupt datagram that either gets dropped by the transport protocol or gets wrongly handed to the corresponding application 💀 this issue is discussed in detail in Section 4.1 ("Fragment Reassembly") 🔥
3.6. Flags
the IP header has 3 control bits, and two of them are currently used for the fragmentation and reassembly function 🎀
as described by RFC 791, their meaning is:
- Bit 0: reserved, must be zero (i.e., reserved for future standardization) 🌸
- Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment 🫶
- Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments ✨
the DF bit is usually set to implement the Path-MTU Discovery (PMTUD) mechanism described in [RFC1191] 💖 but attackers can also exploit it to evade Network Intrusion Detection Systems 😈 an attacker could send a packet with the DF bit set to a system watched by a NIDS, and depending on the Path-MTU to the intended recipient, some router in the middle might drop the packet (because it's too big to forward without fragmenting) without the NIDS ever knowing 👀
+---+
| H |
+---+ Victim host
|
Router A | MTU=1500
|
+---+ +---+ +---+
| R |-----| R |---------| R |
+---+ +---+ +---+
| MTU=17914 Router B
+---+ |
| S |-----+
+---+ |
|
NIDS Sensor |
|
_ ___/---\______ Attacker
/ \_/ \_ +---+
/ Internet |---------| H |
\_ __/ +---+
\__ __ ___/ <------
\___/ \__/ 17914-byte packet
DF bit set
Figure 5: NIDS Evasion by Means of the Internet Protocol DF Bitin Figure 3, an attacker sends a 17914-byte datagram meant for the victim host in the same figure 🕵️♀️ the attacker's packet probably contains an overlapping IP fragment or an overlapping TCP segment, aiming to "confuse" the NIDS, as described in [Ptacek1998] 🌀 the NIDS sensor at the network perimeter screens the packet, and it probably reassembles IP fragments and TCP segments so it can check the data going to and from the monitored systems 🧐 but since the attacker's packet should cross a link with an MTU smaller than 17914 bytes (1500 bytes in this example), the router that hits this packet can't forward it without fragmenting (Router B), so it discards the packet and sends an ICMP "fragmentation needed and DF bit set" error message to the source host 😱 in this setup, the NIDS might never notice the screened packet didn't reach the intended destination, and so it ends up with a wrong picture of the data moving to the monitored systems 🙈
[Shankar2003] introduces a technique called "Active Mapping" that stops NIDS evasion by learning enough about the monitored network to figure out which packets will reach the intended recipient and how that recipient will interpret them 🧠
some firewalls are known to drop packets that have both the MF (More Fragments) and DF (Don't Fragment) bits set 🚫 while that might seem nonsensical in principle, there are a bunch of reasons non-malicious packets with both bits set can show up on a network 💁♀️ first, they can come from a middle-box processing a packet that was too big to forward without fragmenting. Instead of just dropping the packet and sending an ICMP error message to the source host, some middle-boxes fragment it (copying the DF bit to each fragment) and send an ICMP error message to the originating system 🧩 second, some systems (notably Linux) set both the MF and DF bits to implement Path-MTU Discovery (PMTUD) for UDP 🐧 these scenarios should be taken into account when configuring firewalls and/or tuning NIDSs 🔧
Section 4.1 contains a discussion of the security implications of the IP fragment reassembly mechanism 🛡️✨
3.7. Fragment Offset ✨
Okay bestie, the Fragment Offset is the field that handles fragmenting and reassembling IP datagrams 🧩 It tells you where in the original datagram payload this fragment's payload belongs, and it's measured in units of eight bytes 📏 So every fragment except the last one has to be aligned on an 8-byte boundary 🫶 That means if a packet has the MF flag set, you gotta run this check:
(Total Length - IHL * 4) % 8 == 0If the packet fails that check, it should be dropped, and the event should be logged (for example, a counter could go up to reflect the packet drop) 📉
Fragment Offset is a 13-bit field, so the biggest value it can hold is 8191, which corresponds to an offset of 65528 bytes within the original (non-fragmented) datagram 🤯 That means a fragment can implicitly claim to belong to a datagram bigger than 65535 bytes, which is the maximum size for a legitimate IP datagram. Even when the fragmentation mechanism would seem to allow fragments that reassemble into those huge datagrams, the actual intent of the spec is to allow transmission of datagrams up to 65535 bytes only 🚫 So if a given fragment would reassemble into a datagram of more than 65535 bytes, the resulting datagram should be dropped and logged (again, a counter works great) 💅 To catch this, run the following check on all packets where Fragment Offset is a non-zero value:
Fragment Offset * 8 + (Total Length - IHL * 4) + IHL_FF * 4 <= 65535where IHL_FF is the IHL field of the first fragment (the one with a Fragment Offset of 0).
If a fragment doesn't pass this check, it should be dropped.
If IHL_FF isn't available yet because the first fragment hasn't arrived, you can do a preliminary, less rigid test by assuming IHL_FF == IHL. The test then simplifies to:
Fragment Offset * 8 + Total Length <= 65535Once the first fragment is received, the full sanity check described earlier should be applied, if that fragment contains "don't copy" options. 🎀
In the worst-case scenario, an attacker could craft IP fragments such that the reassembled datagram ends up as a datagram of 131043 bytes. 😭
Such a datagram would result when the first fragment has a Fragment Offset of 0 and a Total Length of 65532, and the second (and last) fragment has a Fragment Offset of 8189 (65512 bytes), and a Total Length of 65535. Assuming an IHL of 5 (i.e., a header length of 20 bytes), the reassembled datagram would be 65532 + (65535 - 20) = 131047 bytes.
On top of that, the IP module should implement all the necessary measures to handle these illegitimate reassembled datagrams, so they don't overflow the buffer(s) used for the reassembly function. 🛡️
[CERT1996c] and [Kenney1996] describe how this issue can be exploited to perform a DoS attack. 💀
Section 4.1 contains a discussion of the security implications of the IP fragment reassembly mechanism. 🔥
3.8. Time to Live (TTL) ✨
The Time to Live (TTL) field has two main jobs: bounding the lifetime of upper-layer packets (like TCP segments), and stopping packets from looping forever around the network 🔁
Originally, this field was meant to indicate the maximum time a datagram was allowed to hang around in the Internet system, measured in seconds ⏱️ But every Internet module that processes a datagram has to decrement the TTL by at least one, so the original definition became obsolete, and in practice it's interpreted as a hop count (see Section 5.3.1 of [RFC1812]). 🦋
Most systems let the admin configure the TTL used for packets they originate, and the default is usually a power of 2, or 255 (e.g., see [Arkin2000]). The recommended value for the TTL field, as specified by the IANA, is 64 [IANA_IP_PARAM]. This value reflects the assumed "diameter" of the Internet, plus a margin to accommodate its growth. 🌈
The TTL field has a bunch of properties that are very interesting from a security point of view 👀 Since the default TTL is usually either a power of two or 255, chances are that unless the originating system was explicitly tuned to a non-default value, if a packet arrives with a TTL of 60, it was originally sent with a TTL of 64. In the same way, if a packet arrives with a TTL of 120, chances are the original packet had a TTL of 128. 🧠
This discussion assumes there was no protocol scrubber, transparent proxy, or other middle-box that overwrites the TTL field in a non-standard way between the originating system and the point in the network where the packet was received. 🙈
Figuring out the TTL a packet was originally sent with can help get some valuable information. Among other things, it may help with:
- Fingerprinting the originating operating system.
- Fingerprinting the originating physical device.
- Mapping the network topology.
- Locating the source host in the network topology.
- Evading Network Intrusion Detection Systems.
But it can also be used for important stuff like:
- Improving the security of applications that make use of the Internet Protocol (IP).
- Limiting spread of packets.
3.8.1. Fingerprinting the Operating System in Use by the Source Host 💻
Different operating systems use different default TTLs for the packets they send. So asserting the TTL a packet was originally sent with helps heuristics cut down the number of possible operating systems in use by the source host. Just know that since most systems only use a handful of default values, the granularity of OS fingerprinting this technique gives you is negligible 😅 Also, these defaults may be configurable (system-wide or per protocol), and managed systems may use those options for operational purposes and to defeat fingerprinting heuristics. 🙃
3.8.2. Fingerprinting the Physical Device from which the Packets Originate 📱
When several systems sit behind a middle-box like a NAT or a load balancer, the TTL may help count how many systems are back there 🕵️ If each system behind the middle-box uses a different default TTL for the packets it sends, or each system is located at a different distance in the network topology, an attacker could stimulate responses from the devices being fingerprinted, and responses arriving with different TTL values could be assumed to come from different devices.
Of course, there are many other (and much more precise) techniques to fingerprint physical devices. One weakness of this method is that, while many systems differ in the default TTL value they use, there are also many implementations that use the same default TTL value. Additionally, packets sent by a given device may take different routes (e.g., due to load sharing or route changes), so a given packet may incorrectly be presumed to come from a different device, when in fact it just traveled a different route. 🗺️
However, these defaults may be configurable (system-wide or per protocol), and managed systems may use such opportunities for operational purposes and to defeat the capability of fingerprinting heuristics. 💅
3.8.3. Mapping the Network Topology 🗺️
An originating host can set the TTL field of the packets it sends to progressively increasing values in order to elicit an ICMP error message from the routers that decrement each packet's TTL to zero. That way it can figure out the IP addresses of the routers on the path to the packet's destination 🧭 This procedure has traditionally been used by the traceroute tool. 🧚
3.8.4. Locating the Source Host in the Network Topology 📍
The TTL field may also be used to locate the source system in the network topology [Northcutt2000]. 🕵️♀️
+---+ +---+ +---+ +---+ +---+
| A |-----| R |------| R |----| R |-----| R |
+---+ +---+ +---+ +---+ +---+
/ | / \
/ | / \
/ | / +---+
/ +---+ +---+ +---+ | E |
/ | R |----| R |------| R |-- +---+
/ +---+ +---+\ +---+ \
/ / / \ \ \
/ ---- / +---+ \ \+---+
/ / / | F | \ | D |
+---+ +---+ +---+ \ +---|
| R |----------| R |-- \
+---+ +---+ \ \
| \ / \ +---+| +---+
| \ / ----| R |------| R |
| \ / +---+ +---+
+---+ \ +---+ +---+
| B | \| R |----| C |
+---+ +---+ +---+Wait, the art above isn't exact. Please see below, because the original figure is copied verbatim and must stay character-for-character:
+---+ +---+ +---+ +---+ +---+
| A |-----| R |------| R |----| R |-----| R |
+---+ +---+ +---+ +---+ +---+
/ | / \
/ | / \
/ | / +---+
/ +---+ +---+ +---+ | E |
/ | R |----| R |------| R |-- +---+
/ +---+ +---+\ +---+ \
/ / / \ \ \
/ ---- / +---+ \ \+---+
/ / / | F | \ | D |
+---+ +---+ +---+ \ +---|
| R |----------| R |-- \
+---+ +---+ \ \
| \ / \ +---+| +---+
| \ / ----| R |------| R |
| \ / +---+ +---+
+---+ \ +---+ +---+
| B | \| R |----| C |
+---+ +---+ +---+
Figure 6: Tracking a Host by Means of the TTL FieldConsider the network topology of Figure 6. Assume an attacker ("F" in the figure) is performing some type of attack that requires forging the Source Address (such as a TCP-based DoS reflection attack), and some of the involved hosts are willing to cooperate to locate the attacking system. 🕵️♀️🔍
Assuming that:
- All the packets A gets have a TTL of 61.
- All the packets B gets have a TTL of 61.
- All the packets C gets have a TTL of 61.
- All the packets D gets have a TTL of 62.
Based on this info, and assuming the system's default value wasn't overridden, it would be fair to assume the original TTL of the packets was 64. With that, the number of hops between the attacker and each of those hosts can be calculated 🧮
The attacker is:
- Four hops away from A.
- Four hops away from B.
- Four hops away from C.
- Four hops away from D.
In the network setup of Figure 3, the only system that satisfies all these conditions is the one marked as the "F". 🎯
The scenario above is for illustration purposes only. In practice, a number of factors may prevent this technique from working:
- Unless there is a "large" number of cooperating systems, and the attacker is assumed to be no more than a few hops away from these systems, the number of "candidate" hosts will usually be too large for the information to be useful. 🙄
- The attacker may be using a non-default TTL value or, what's worse, a pseudo-random value for the TTL of the packets it sends. 😤
- The packets sent by the attacker may take different routes, as a result of a change in network topology, load sharing, etc., and thus may lead to an incorrect analysis. 🌀
3.8.5. Evading Network Intrusion Detection Systems 🕵️♀️
okay so the TTL field can actually be used to dodge Network Intrusion Detection Systems (NIDSs) 😭. Depending on where a sensor sits compared to the destination host of the packet it's examining, the NIDS can end up with a totally different picture than the destination actually gets. 🙈 For example, a sensor might process a packet that expires before it ever reaches the destination host. The general fix for this kind of attack is to normalize the traffic that enters an organizational network, and [Paxson2001] has examples of how that traffic normalization works. The OpenBSD Packet Filter is a packet filter that includes TTL-normalization functionality [OpenBSD-PF], so it's giving prevention 💅.
3.8.6. Improving the Security of Applications That Make Use of the Internet Protocol (IP) 🛡️
ngl this one is so clever 😍. In some scenarios, the TTL field can also make an application more secure by restricting which hosts are allowed to talk to it [RFC5082]. Take applications where the communicating systems are usually on the same network segment, meaning there are no routers in between. BGP (Border Gateway Protocol) is one of these, used by two peer routers that are usually sharing a link medium. 🌐
If both systems use a TTL of 255 for all the packets they send to each other, then a check can be enforced that requires every packet meant for the application to have a TTL of 255. ✨
Packets from systems that aren't on the same network segment will have a TTL smaller than 255, so those packets won't pass the check that the two cooperating peers enforce. 🚫 This check shrinks the set of systems that can attack the protected application (BGP in this case), which mitigates the attack vectors described in [NISCC2004] and [Watson2004]. 💪
This same check is enforced for related ICMP error messages too, with the goal of mitigating the attack vectors described in [NISCC2005] and [RFC5927]. 🧚
The TTL field can be used in a similar way when the cooperating systems are not on the same network segment (this is called multi-hop peering) 🦋. In that case, the following check can be enforced:
TTL >= 255 - DeltaHopsThis means the set of hosts whose packets get accepted for the protected application is reduced to those that are no more than DeltaHops away. Obviously the protection won't be as strong as it is for directly connected peers, but using the TTL field to protect multi-hop peering still shrinks the set of hosts that could potentially carry out a number of attacks against the protected application. 🫶
The IETF officially documented this use of the TTL field under the name "Generalized TTL Security Mechanism" (GTSM) in [RFC5082]. 📜
Some protocol scrubbers enforce a minimum TTL value on the packets they forward. 🫣 Depending on that minimum TTL and on the particular network setup, the protocol scrubber may actually help attackers fool the GTSM by "raising" the TTL of the attacking packets. Yikes 💀.
3.8.7. Limiting Spread 🌸
The originating host sets the TTL field to a small value (frequently 1, for link-scope services) so it artificially limits the (topological) distance the packet is allowed to travel. 🧁 This is suggested in Section 4.2.2.9 of RFC 1812 [RFC1812], and further discussion of the technique can be found in RFC 1112 [RFC1112]. 📚
3.9. Protocol 🎀
The Protocol field indicates the protocol encapsulated in the Internet datagram. 🎁 It can contain a value for a protocol the system processing the packet actually implements, but it can also hold a value for a protocol that isn't implemented, or even a value that the IANA hasn't assigned yet [IANA_PROT_NUM]. Wild, right? 🤯
In theory, using any value in the protocol field shouldn't cause security problems. 🤷♀️ But there have been security issues in the past with systems that struggled to handle packets with certain specific protocol numbers [Cisco2003] [CERT2003]. Not ideal bestie 😬.
A host (i.e., end-system) that receives an IP packet encapsulating a Protocol it does not support should drop the corresponding packet, log the event, and possibly send an ICMP Protocol Unreachable (type 3, code 2) error message. 🚫📝
3.10. Header Checksum 🧮
The Header Checksum field is an error-detection mechanism meant to catch errors in the IP header. ✅ In principle there shouldn't be security implications from this field, but it's worth noting that, because of non-RFC-compliant implementations, the Header Checksum might be exploited to detect firewalls and/or evade NIDSs. 👀
[Ed3f2002] describes how the TCP checksum can be exploited to do exactly that. Some Internet routers are known not to check the IP Header Checksum, and there might also be middle-boxes (NATs, firewalls, etc.) that don't check the IP checksum, allegedly for performance reasons. 🐢 Because of that, similar malicious activity to the one described in [Ed3f2002] might be carried out using the IP checksum. 😈
3.11. Source Address 📍
The Source Address of an IP datagram identifies the node the packet originated from. 🗺️
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"), because the Internet Architecture has no concept of "node address". 🤓
Unfortunately, it's trivial to forge the Source Address of an Internet datagram, because consistent "egress filtering" near the edge of the network is apparently lacking 🫠. This has been exploited in the past to carry out a variety of DoS attacks [NISCC2004] [RFC4987] [CERT1996a] [CERT1996b] [CERT1998a], and to impersonate other systems in scenarios where authentication was based on the Source Address of the sending system [daemon91996]. Major yikes.
The extent to which these attacks can succeed on the Internet can be reduced by deploying ingress/egress filtering in Internet routers. [NISCC2006] is a detailed guide to ingress and egress filtering. [RFC2827] and [RFC3704] discuss ingress filtering, [GIAC2000] discusses egress filtering, and [SpooferProject] measures the Internet's susceptibility to forged Source Address IP packets. 📊
Even though the obvious fields to check for ingress/egress filtering are the Source Address and Destination Address fields of the IP header, other occurrences of IP addresses should get the same checks too. One example is the IP addresses contained in the payload of ICMP error messages, as discussed in [RFC5927] and [Gont2006]. 🧐
There are a number of sanity checks that should be performed on the Source Address of an IP datagram. Details can be found in Section 4.3 ("Addressing"). ✅
Also, freely available tools let administrators monitor which IP addresses are used with which MAC addresses [LBNL2006], and many NIDSs include this functionality too. 🔍
It's also super important to understand that authentication should never rely solely on the Source Address used by the communicating systems. 🔐🚨
3.12. Destination Address 🎯
The Destination Address of an IP datagram identifies the destination host the packet is meant to be delivered to. 💌
Strictly speaking, the Destination Address of an IP datagram identifies the interface of the destination network interface, rather than the destination "system", because the Internet Architecture has no concept of "node address". 🤓
There are a number of sanity checks that should be performed on the Destination Address of an IP datagram. Details can be found in Section 4.3 ("Addressing"). 💅
3.13. Options ⚙️
According to RFC 791 [RFC791], IP options must be implemented by all IP modules, both in hosts and gateways (i.e., end-systems and intermediate-systems). 🧩 That means the general rules for assembling, parsing, and processing IP options must be implemented too. RFC 791 defines a set of options that "must be understood", but this set has been updated by RFC 1122 [RFC1122], RFC 1812 [RFC1812], and other documents. Section 3.13.2 of this document describes, for each option type, the current understanding of the implementation requirements. IP systems are required to ignore options they do not implement. 🙈
It should be noted that while a number of IP options have been specified, they are generally only used for troubleshooting purposes (except for the Router Alert option and the different Security options). 🔧
There are two cases for the format of an option:
- Case 1: A single byte of option-type.
- Case 2: An option-type byte, an option-length byte, and the actual option-data bytes.
In Case 2, the option-length byte counts the option-type byte and the option-length byte, as well as the actual option-data bytes. 🔢
All current and future options except End of Option List (Type = 0) and No Operation (Type = 1) are of Class 2. 🎀
The option-type has three fields:
- 1 bit: copied flag.
- 2 bits: option class.
- 5 bits: option number.
This format allows new options to be created for extending the Internet Protocol (IP), and lets intermediate-systems that don't "understand" them treat them transparently, under direction of the first three functional parts. 🦋
The copied flag indicates whether this option should be copied to all fragments if the packet carrying it needs to be fragmented:
- 0 = not copied.
- 1 = copied.
The values for the option class are:
- 0 = control.
- 1 = reserved for future use.
- 2 = debugging and measurement.
- 3 = reserved for future use.
Finally, the option number identifies the syntax of the rest of the option. 🧾
[IANA_IP_PARAM] contains the list of currently assigned IP option numbers. It should be noted that IP systems are required to ignore those options they do not implement. 📋
3.13.1. General Issues with IP Options 🧠
The following subsections discuss security issues that apply to all IP options. The proposed checks should be performed in addition to any option-specific checks proposed in the next sections. 💖
3.13.1.1. Processing Requirements 🏋️♀️
Router manufacturers tend to do IP option processing on the main processor rather than on line cards. Unless special care is taken, this is a DoS risk, because the router can potentially be overwhelmed by option processing. 😱
To reduce the impact these packets have on system performance, a few countermeasures could be implemented:
- Rate-limit the number of packets with IP options that are processed by the system.
- Enforce a limit on the maximum number of options to be accepted on a given Internet datagram.
The first check stops a flow of packets with IP options from overwhelming the system in question. The second check stops packets with many IP options from hurting the system's performance. 🫶✨
3.13.1.2. Processing of the Options by the Upper-Layer Protocol 💌
okay so Section 3.2.1.8 of RFC 1122 [RFC1122] says that all the IP options received in IP datagrams must be passed to the transport layer (or to ICMP processing when the datagram is an ICMP message) 🫶 which means option handling isn't just the Internet layer's job. every protocol module that might end up processing the options in an IP datagram needs to be careful too, bestie 💅
3.13.1.3. General Sanity Checks on IP Options ✨
there are a bunch of sanity checks that should be performed on IP options before any further option processing happens 🧹 they help prevent a number of potential security problems, including buffer overflows 😭 when a check fails, the packet carrying the option should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop).
RFC 1122 [RFC1122] recommends sending an ICMP "Parameter Problem" message to the originating system when a packet gets dropped because of an invalid value in a field, like the cases in the subsections below. ngl this can really help with debugging some network problems 🔍 but it also tells attackers which system is dropping packets because of the invalid values in the protocol fields 👀 not it!!
our advice is that systems default to sending an ICMP "Parameter Problem" error message when a packet is dropped because of an invalid value in a protocol field (e.g., as a result of dropping a packet due to the sanity checks described in this section). however, we recommend that systems provide a system-wide toggle that lets an administrator override that default, so packets can be silently dropped when an invalid value in a protocol field is encountered. 🎀
Option length
Section 3.2.1.8 of RFC 1122 explicitly states that the IP layer must not crash because of an option length outside the possible range. it also mentions that erroneous option lengths have been observed to put some IP implementations into infinite loops 💀
For options that belong to the "Case 2" described in the previous section, the following check should be performed:
option-length >= 2The value "2" accounts for the option-type byte and the option-length byte.
this check prevents, among other things, loops in option processing that may arise from incorrect option lengths 🔁
additionally, while the option-length byte of IP options of "Case 2" allows for an option length of up to 255 bytes, there's a limit on legitimate option length set by the space available for options in the IP header 📏
for all options of "Case 2", the following check should be enforced:
option-offset + option-length <= IHL * 4where option-offset is the offset of the first byte of the option within the IP header, with the first byte of the IP header being assigned an offset of 0.
this check makes sure the option doesn't claim to extend beyond the IP header. if the packet doesn't pass, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 🚫
the check is meant to catch forged option-length values that might make an option overlap with the IP payload. this would be especially dangerous for IP options that ask the processing systems to write information into the option-data area (like the Record Route option), because it would allow overflows 🙈
Data types
many IP options use pointer and length fields, so care must be taken with the data type used for these fields in the implementation. for example, if an 8-bit signed data type were used to hold an 8-bit pointer, pointer values larger than 128 might be mistakenly read as negative numbers, which could lead to unpredictable results 🌀
3.13.2. Issues with Specific Options 🧩
3.13.2.1. End of Option List (Type=0) 🏁
this option is used to signal the "end of options" when the end of the options wouldn't line up with the end of the Internet Protocol header. octets in the IP header after the "End of Option List" are padding. the originator should set them to 0, and receiving nodes must ignore them 🧼
that said, an originating node could instead fill the leftover space in the Internet header with No Operation options (see Section 3.13.2.2). the End of Option List option allows slightly more efficient parsing on receiving nodes, so packet originators should prefer it 🏆 all IP systems are required to understand both encodings 🫶
3.13.2.2. No Operation (Type=1) 🫧
the No Operation option is basically there so the sending system can line up subsequent options on, for example, 32-bit boundaries. it can also be used at the end of the options (see Section 3.13.2.1) 🎀
with a single exception (see Section 3.13.2.13), this is the only IP option defined so far that can appear multiple times in a single IP packet 🔢
this option does not have security implications 💖
3.13.2.3. Loose Source and Record Route (LSRR) (Type=131) 🛣️
this option lets the originating system specify a number of intermediate systems a packet must pass through on its way to the destination host. the route the packet takes also gets recorded in the option. the receiving host (end-system) must use the reverse of the path contained in the received LSRR option 🔄
the LSSR option can be a real help when debugging some network problems. some ISP (Internet Service Provider) peering agreements even require support for this option in the routers within the ISP's peer 🤝
the LSRR option has well-known security implications 🚨 among other things, it can be used to:
- Bypass firewall rules 🧱
- Reach otherwise unreachable Internet systems 🕳️
- Establish TCP connections in a stealthy way 🥷
- Learn about the topology of a network 🗺️
- Perform bandwidth-exhaustion attacks 🌊
of these attack vectors, the one that has probably gotten the least attention is using the LSRR option for bandwidth-exhaustion attacks 😳 the LSRR option can act as an amplification method for bandwidth-exhaustion attacks, because an attacker could make a packet bounce multiple times between a number of systems by carefully crafting an LSRR option 🏓
this is the IPv4 version of the IPv6 amplification attack that was widely publicized in 2007 [Biondi2007]. the only difference is that the maximum length of the IPv4 header (and therefore the LSRR option) limits the amplification factor compared to the IPv6 counterpart.
while the LSSR option may help with debugging, 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 in those scenarios where it's required. that 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.
Section 3.3.5 of RFC 1122 [RFC1122] states that a host may be able to act as an intermediate hop in a source route, forwarding a source-routed datagram to the next specified hop. we strongly discourage host software from forwarding source-routed datagrams 🙅♀️
if processing of source-routed datagrams is explicitly enabled in a system, the following sanity checks should be performed 🧐
RFC 791 states that this option should appear, at most, once in a given packet. so if a packet contains more than one LSRR option, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop). packets containing a combination of LSRR and SSRR options should also be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 🚫
like all the other IP options of "Case 2", the LSSR contains a Length field that indicates the length of the option. given the format of the option, the Length field should be checked to have a minimum value of three and be 3 (3 + n*4):
LSRR.Length % 4 == 3 && LSRR.Length != 0if the packet doesn't pass this check, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 📉
the Pointer is relative to this option, so the minimum legal value is 4. therefore, the following check should be performed:
LSRR.Pointer >= 4if the packet doesn't pass this check, it should be dropped, and the 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, so the following check should be performed:
LSRR.Pointer % 4 == 0if a packet doesn't pass this check, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 🧮
when a system receives an IP packet with the LSRR option that passes the checks above, it should check whether the source route is empty. the option is empty if:
LSRR.Pointer > LSRR.Lengthin that case, routing should be based on the Destination Address field, and no further processing should be done on the LSRR option 🧭
[Microsoft1999] is a security advisory about a vulnerability that arises from improper validation of the LSRR.Pointer field.
if the address in the Destination Address field has been reached and the option isn't empty, the next address in the source route replaces the address in the Destination Address field. the IP address of the interface that will be used to forward this datagram is recorded in its place in the LSRR.Data field. then LSRR.Pointer is incremented by 4 🔢
note that the sanity checks for the LSRR.Length and LSRR.Pointer fields described above make sure that if the option isn't empty, there will be (4*n) octets in the option. that means there will be at least one IP address to read, plus enough room to record the IP address of the interface that will be used to forward this datagram 🧠
the LSRR must be copied on fragmentation. this means that if a packet carrying the LSRR gets fragmented, each of the fragments will have to go through the list of systems specified in the LSRR option 🧩
3.13.2.4. Strict Source and Record Route (SSRR) (Type=137)
Okay bestie, SSRR is giving "you are NOT taking the scenic route" 💅. This option lets the originating system list a bunch of intermediate-systems that a packet has to pass through to reach the destination host 🗺️. The route the packet actually took gets recorded in the option too, and the destination host (end-system) has to use the reverse of the path from the received SSRR option 🔄.
It's basically LSRR's stricter sibling 💀. The only difference is that with SSRR, the route in the option is the exact route the packet has to take, so no other intervening routers are allowed to sneak in 🙅♀️.
The SSSR option can be super helpful for debugging some network problems 🔍. Some ISP (Internet Service Provider) peering agreements even require support for this option in the routers within the peer of the ISP 🤝.
The SSRR option has the same security implications as the LSRR option. Check Section 3.13.2.3 for the full tea on that ☕.
As with LSRR, the SSSR option might help with debugging, but its security implications outweigh any legit use of it 😭🚨.
Here's the default vibe: all systems should, by default, drop IP packets that contain an SSRR option, and they should log the event (e.g., a counter could be incremented to reflect the packet drop) 🛑. But they should also provide a system-wide toggle to enable support for this option for the scenarios where it's actually required 🔧. That 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. 🙈
If processing of the SSRR option has been explicitly enabled, the same sanity checks described for the LSRR option in Section 3.13.2.3 should be performed on the SSRR option 🧐. Namely, sanity checks should be performed on the option length (SSRR.Length) and the pointer field (SSRR.Pointer).
If the packet passes those sanity checks, the receiving system should figure out whether the Destination Address of the packet matches one of its IP addresses 👀. If it doesn't, the packet should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 📉.
Contrary to the IP Loose Source and Record Route (LSRR) option, the SSRR option does not allow in the route other routers than those contained in the option. If the system implements the weak end-system model, it's allowed 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 only be received on the interface that corresponds to the IP address 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.LengthIn that case, if the address in the destination field hasn't been reached yet, the packet should be dropped, and the 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 🔁. The IP address of the interface that will be used to forward this datagram gets recorded in its place in the source route (SSRR.Data field) 📝. Then, SSRR.Pointer is incremented by 4 ➕.
Note that the sanity checks for the SSRR.Length and SSRR.Pointer fields described above ensure that if the option is not empty, there will be (4*n) octets in the option. That means there will be at least one IP address to read, and enough room to record the IP address of the interface that will be used to forward this datagram 💖.
The SSRR option must be copied on fragmentation 🧩. This means that if a packet carrying the SSRR is fragmented, each of the fragments will have to go through the list of systems specified in the SSRR option 🫠.
3.13.2.5. Record Route (Type=7)
This option is all about recording the route a given packet follows 📜✨.
The option starts with an 8-bit option code, which is 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, pointing at the first byte of the area where the next route data gets stored 👉. The pointer is relative to the option start 🎯.
RFC 791 says this option should appear at most once in a given packet 🙅♀️. So if a packet has more than one instance of this option, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 🗑️.
The same sanity checks done on the Length and Pointer fields of the LSRR and SSRR options should be done on the Length field (RR.Length) and the Pointer field (RR.Pointer) of the RR option 🧼. Just like with LSRR and SSRR, if the packet doesn't pass these checks, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 🚫.
When a system receives an IP packet with the Record Route option that passes the checks above, it should check whether there's space in the option to store route information 🔍. The option is full if:
RR.Pointer > RR.LengthIf the option is full, the datagram should be forwarded without any further processing of this option 🏃♀️.
If the option is not full (i.e., RR.Pointer <= RR.Length), the IP address of the interface that will be used to forward this datagram should be recorded into the area pointed to by RR.Pointer, and then RR.Pointer should be incremented by 4 📍.
This option is not copied on fragmentation, so it only appears in the first fragment 1️⃣. If a fragment other than the one with offset 0 contains the Record Route option, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 🧾.
The Record Route option can be exploited to learn about the topology of a network 👀. However, the limited space in the IP header limits how useful this option is for that purpose if the target network is several hops away 🫣.
3.13.2.6. Stream Identifier (Type=136)
The Stream Identifier option was originally a way to carry the 16-bit SATNET stream Identifier through networks that didn't support the stream concept 🛰️.
However, as Section 4.2.2.1 of RFC 1812 [RFC1812] states, this option is obsolete 🪦. Therefore, it must be ignored by processing systems 🙈.
For legacy systems that still use this option, the length field of the option should be checked to be 4 📐. If the option doesn't pass this check, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 🗑️.
RFC 791 says this option appears at most once in a given datagram 💅. So if a packet contains more than one instance of this option, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 🫶.
3.13.2.7. Internet Timestamp (Type=68) ⏰
okay so this option lets every system that handles the datagram write down when it processed it 🕰️ and bestie, it's lowkey a security nightmare 😭 It comes with a few problems:
- It lets an attacker find out the current time on the systems that process the packet, which can be super useful to them in a bunch of scenarios.
- It can be used to map the network topology, kinda like the IP Record Route option.
- It can be used to fingerprint the operating system running on a system that processes the datagram.
- It can be used to fingerprint physical devices by analyzing their clock skew.
So by default, the timestamp option should be ignored 🙅♀️ For systems that have been explicitly configured to honor it, the rest of this subsection covers some sanity checks that should be enforced on the option before any further processing 🧐
The option starts with an option-type byte, which must be equal to 68. The second byte is the option-length, which counts the option-type byte, the option-length byte, the pointer, and the overflow/flag byte. The smallest legal option-length is 4, which is an Internet Timestamp option that's empty (no space to store timestamps). So when a packet with an Internet Timestamp option shows up, this check should be performed:
IT.Length >= 4If the packet doesn't pass, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 📉
The Pointer is an index within this option, counting the option type octet as octet #1. It points to the first byte of the area where the next timestamp data should be stored, so the minimum legal value is 5 🎯 Since the only change to the Pointer that RFC 791 allows is incrementing it by 4 or 8, the following checks should be performed, depending on the Flag value (see below) 💅
If IT.Flag is equal to 0, this check should be performed:
IT.Pointer %4 == 1 && IT.Pointer != 1If the packet doesn't pass this check, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop).
Otherwise, this sanity check should be performed on the option:
IT.Pointer % 8 == 5If the packet doesn't pass this check, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop).
The flag field has three possible legal values 🚩
- 0: Record time stamps only, stored in consecutive 32-bit words.
- 1: Record each timestamp preceded with the Internet address of the registering entity.
- 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.
So this check should be performed:
IT.Flag == 0 || IT.Flag == 1 || IT.Flag == 3If the packet doesn't pass, it should be dropped, and the 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 UTC ⏱️ If the time isn't available in milliseconds, or can't be provided with respect to UTC, then any time may be inserted as a timestamp, as long as the high-order bit of the timestamp is set. That's how it flags the value as non-standard 🏳️🌈
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, and they might discard 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 decides yes, it should then check whether the timestamp data area is full, using this check:
IT.Pointer > IT.LengthIf this condition is true, the timestamp data area is full. If not, there's 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 the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 💀
If the timestamp data area is not full, then processing continues as follows. (Note that the checks on IT.Pointer above make sure there's room for another entry in the option ✨)
- If IT.Flag is 0, then the system's 32-bit timestamp is stored into the area pointed to by the pointer byte, and the pointer byte is incremented by 4.
- If IT.Flag is 1, then the IP address of the system is stored into the area pointed to by the pointer byte, followed by the 32-bit system timestamp, and the pointer byte is incremented by 8.
- Otherwise (IT.Flag is 3), if the IP address in the first 4 bytes pointed to by IT.Pointer matches one of the IP addresses assigned to an interface of the system, then the system's timestamp is stored into the area pointed to by IT.Pointer + 4, and the pointer byte is incremented by 8 🦋
[Kohno2005] describes a technique for fingerprinting devices by measuring the clock skew. It exploits, among other things, the timestamps that can be obtained by means of the ICMP timestamp request messages [RFC0791]. However, the same fingerprinting method could be implemented with the aid of the Internet Timestamp option 👀
3.13.2.8. Router Alert (Type=148) 🚨
The Router Alert option is defined in RFC 2113 [RFC2113], and later updates to it have been clarified by RFC 5350 [RFC5350]. It contains a 16-bit Value governed by an IANA registry (see [RFC5350]) 📋 The Router Alert option has the semantic "routers should examine this packet more closely, if they participate in the functionality denoted by the Value of the option" 🧠
According to the syntax of the option as defined in RFC 2113, the following check should be enforced, if the router supports this option:
RA.Length == 4If the packet doesn't pass this check, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop).
A packet that has a Router Alert option with an option value matching functionality supported by an active module in the router won't go through the router's fast-path. Instead, it gets processed in the router's slow path, handed over for closer inspection to the modules that registered the matching option value 🐢 So this option may impact the performance of the systems that handle the packet carrying it ⚡
[ROUTER-ALERT] analyzes the security implications of the Router Alert option, and identifies controlled environments in which the Router Alert option can be used safely. 🔐
As explained in RFC 2113 [RFC2113], hosts should ignore this option 🙈
3.13.2.9. Probe MTU (Type=11) (Obsolete) 🪦
This option was defined in RFC 1063 [RFC1063], and originally provided a mechanism to discover the Path-MTU 📏
This option is obsolete, so any packet that is received containing this option should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 🗑️
3.13.2.10. Reply MTU (Type=12) (Obsolete) 🪦
This option is defined in RFC 1063 [RFC1063], and originally provided a mechanism to discover the Path-MTU 📏
This option is obsolete, so any packet that is received containing this option should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 🗑️
3.13.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 🧭
The Traceroute option was specified as "experimental", and it was never deployed on the public Internet 🧪 So any packet that is received containing this option should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 🙅♀️
3.13.2.12. Department of Defense (DoD) Basic Security Option (Type=130) 🎖️
This option is used by Multi-Level-Secure (MLS) end-systems and intermediate-systems in specific environments to [RFC1108]:
- Transmit from source to destination, in a network standard representation, the common security labels required by computer security models,
- Validate the datagram as appropriate for transmission from the source and delivery to the destination, and
- Ensure that the route taken by the datagram is protected to the level required by all protection authorities indicated on the datagram.
It is specified by RFC 1108 [RFC1108] (which obsoletes RFC 1038 [RFC1038]) 📜
RFC 791 [RFC0791] defined the "Security Option" (Type=130), which used the same option type as the DoD Basic Security option discussed in this section. The "Security Option" specified in RFC 791 is considered obsolete by Section 3.2.1.8 of RFC 1122, so the discussion in this section focuses 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], [SELinux2009], [Solaris2007], and [Cisco2008]), and it's deployed in a number of high-security networks 🏰
Systems that belong to networks where this option is in use should process the DoD Basic Security option contained in each packet as specified in [RFC1108] 🤝
RFC 1108 states that the option should appear at most once in a datagram. So if more than one DoD Basic Security option (BSO) appears in a given datagram, the corresponding datagram should be dropped, and the 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. So the following check should be performed:
BSO.Length >= 3If the packet doesn't pass this check, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop).
Current deployments of the security options described in this section and the two subsequent sections have motivated the specification of a "Common Architecture Label IPv6 Security Option (CALIPSO)" for the IPv6 protocol [RFC5570]. 🌟
3.13.2.13. DoD Extended Security Option (Type=133) 🎀
okay so the DoD Extended Security option is the bonus labeling pack 🏷️ it lets extra security labeling info ride along in an IP datagram, beyond what the Basic Security option (Section 3.13.2.13) carries, so registered authorities get exactly what they need. it's specified in [RFC1108] and the detail is giving 💅
this option can only show up alongside the DoD Basic Security option 🫶 so if a packet has a DoD Extended Security option (ESO) but no DoD Basic Security option, it should be dropped, and that event should be logged (e.g., a counter could be incremented to reflect the packet drop) 💀 the twist is that, unlike the Basic Security option, this one can appear multiple times in a single IP header ✨
systems that belong to networks where this option is in use should process the DoD Extended Security option in each packet as specified in [RFC1108] 🦋
ngl the length is the fun part 🙈 [RFC1108] says the option Length is variable, with a minimum option Length of 3 bytes. so the following check should be performed:
ESO.Length >= 3if the packet doesn't pass this check, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 🍓
3.13.2.14. Commercial IP Security Option (CIPSO) (Type=134) 💜
this one was proposed by the Trusted Systems Interoperability Group (TSIG) 🧚 to meet trusted networking requirements for the commercial trusted systems marketplace. it's specified in [CIPSO1992] and [FIPS1994] ✨
the TSIG proposal went to the Commercial Internet Security Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an Internet-Draft got produced [CIPSO1992]. the Internet-Draft was never published as an RFC, but 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's already running in a bunch of operating systems (e.g., IRIX [IRIX2008], Security-Enhanced Linux [SELinux2009], and Solaris [Solaris2007]) 🌈 and it's deployed in a number of high-security networks, which is so main character energy 🔥
[Zakrzewski2002] and [Haddad2004] give an overview of a Linux implementation 🌸
systems that belong to networks where this option is in use should process the CIPSO option in each packet as specified in [CIPSO1992] 🫶
according to the option syntax in [CIPSO1992], the following validation check should be performed:
CIPSO.Length >= 6if a packet doesn't pass this check, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 😭
3.13.2.15. Sender Directed Multi-Destination Delivery (Type=149) 🦋
this option is defined in [RFC1770] and originally gave unreliable UDP delivery to a set of addresses included in the option 🫧
this option is obsolete 🥀 if a received packet contains it, the packet should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 🙅♀️
4. Internet Protocol Mechanisms 🌸
4.1. Fragment Reassembly 🧩
okay so IP can fragment packets so they fit networks with different Maximum Transmission Units (MTUs) 📦 it's done by end-systems (hosts) and/or intermediate-systems (routers) 🛣️ but reassembly is only done by the end-systems, and that split is iconic 👑
[Cerf1974] explains why packet reassembly isn't done by intermediate-systems 🤓
over the last few decades, IP fragmentation and reassembly has been exploited in a bunch of ways, like evading NIDSs, bypassing firewall rules, and performing DoS attacks 💀
[Bendi1998] and [Humble1998] are examples of these issues being used for DoS attacks. [CERT1997] and [CERT1998b] document these issues. [Anderson2001] is a survey of fragmentation attacks. [US-CERT2001] is an example of IP fragmentation being used to bypass firewall rules. [CERT1999] describes how fragmentation attacks ended up in Distributed Denial-of-Service (DDoS) attack tools 🙈
the problem with IP fragment reassembly is basically about complexity, and it shows up in a few ways:
- Fragment reassembly is a stateful operation for a stateless protocol (IP). The IP module at the host doing reassembly has to allocate memory buffers both for temporarily storing the received fragments and for doing the reassembly itself. Attackers can exploit this to exhaust memory buffers at the system doing the fragment reassembly 😱
- The fragmentation and reassembly mechanisms were designed back when the available bandwidths were very different from today's. With current bandwidths, a number of interoperability problems may arise, and attackers may intentionally exploit these issues to perform DoS attacks 📉
- Fragment reassembly usually has to happen without any knowledge of the properties of the path the fragments follow. without that info, hosts can't make any educated guess about how long to wait for missing fragments to arrive 🕰️
- The fragment reassembly algorithm, as described by the IETF specifications, is ambiguous and allows a number of interpretations, each of which has shown up in different TCP/IP stack implementations 🌀
- 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 to Memory Allocation 🧠
when an IP datagram is received by an end-system, it's temporarily stored in system memory until the IP module processes it and hands it to the protocol machine for the encapsulated protocol 📬
for fragmented IP packets, the IP module may do preliminary processing of the IP header (such as checking the header for errors and processing IP options), but fragments must be kept in system buffers until all fragments are received and reassembled into a complete Internet datagram 🧃
as mentioned above, the Internet layer usually won't have information about the characteristics of the path between the system and the remote host, so no educated guess can be made about how long to wait for the other fragments to arrive 🤷♀️ so the specifications recommend waiting for a period of time that's acceptable for virtually all the possible network scenarios the protocols might operate in. after that time has elapsed, all the received fragments for the corresponding incomplete packet are discarded 🗑️
the original IP Specification, RFC 791 [RFC0791], states that systems should wait for at least 15 seconds for the missing fragments to arrive. systems that follow the "Example Reassembly Procedure" described in Section 3.2 of RFC 791 may end up using a reassembly timer of up to 4.25 minutes, with a 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 missing fragments, the longer the corresponding system resources stay tied to that packet 😩 system memory is finite, and even with today's systems it can still be considered a scarce resource 💎
an attacker could take advantage of this uncomfortable situation by sending forged fragments that will never reassemble into a complete datagram 😈 that means an attacker would send many different fragments, with different IP IDs, without ever sending all the necessary fragments to reassemble them into a full IP datagram. for each fragment, the IP module would allocate resources and tie them to that fragment until the reassembly timer for the corresponding packet expires 🫠
some implementation strategies could make this attack hit harder 👀 for example, when a fragment arrives, some systems allocate a memory buffer large enough to reassemble the whole datagram. while that might be handy in legit cases, it just amplifies the impact of possible attacks, since a single small fragment could tie up buffers for the size of an extremely large (and unlikely) datagram 🎈 the implementation strategy suggested in RFC 815 [RFC0815] leads to exactly this kind of implementation 🚨
the impact of this attack can vary depending on some specific implementation details:
- If the system doesn't 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, perhaps crashing 💥
- If the system enforces limits on the amount of memory that can be allocated by the IP module as a whole, then, once that limit is reached, all further IP packets that arrive would be discarded until some fragments time out and free up memory again 🚫
- If the system enforces limits on the amount memory that can be allocated for the reassembly of fragments, then, once that limit is reached, all further fragments that arrive would be discarded until some fragment(s) time out and free up memory again 🧹
4.1.1.2. Problems That Arise from the Length of the IP Identification Field
okay so the Internet Protocols are running in environments that are super different from the ones they were dreamed up in 🌸 like, the bandwidth available when IP was designed is a totally different vibe from the bandwidth we have in today's networks 💅
The Identification field is a 16-bit field that handles the fragmentation and reassembly stuff 🎀 When a datagram gets fragmented, all the fragments share the same {Source Address, Destination Address, Protocol, Identification number} four-tuple 🦋 That's how the receiving system knows they all belong to the same IP datagram. At any given point in time, there can be at most only one packet in the network with a given four-tuple ✨ If not, an Identification number "collision" can happen, and the receiver might end up "mixing" fragments from different datagrams that just reused the same Identification number 😭
Example time, bestie 👇 Sending over a 1 Gbit/s path a continuous stream of (UDP) packets of roughly 1 kb size, all getting fragmented into two equally sized fragments of 576 octets each (minimum reassembly buffer size), would repeat the IP Identification values within less than 0.65 seconds (assuming roughly 10% link layer overhead). With shorter packets that still get fragmented, this number could easily drop below 0.4 seconds. With a single IP packet dropped in this short time frame, packets would start getting reassembled wrongly, and continuously, for that whole interval, until an error detection and recovery algorithm at an upper layer lets the application back out 💀
For each group of fragments whose Identification numbers "collide," the fragment reassembly leads to corrupted packets. The IP payload of the reassembled datagram gets handed to the corresponding upper-layer protocol, where the error will (hopefully) be caught by some error detecting code (like the TCP checksum), and the packet gets discarded 🫶
Now the scary part 🙈 An attacker could exploit this to intentionally make a system discard all or part of the fragmented traffic it gets, which is a DoS attack. The attacker would just set up a flow of fragments with different IP Identification numbers to trash all or part of the IP Identification space 👑 Then the receiving system would use the attacker's fragments in the reassembly of legitimate datagrams, leading to corrupted packets that would later (and hopefully) get dropped.
In most cases, using a long fragment timeout benefits the attacker, because forged fragments keep the IP Identification space trashed for a longer period of time 😤
4.1.1.3. Problems That Arise from the Complexity of the Reassembly Algorithm
Okay so IP packets can be duplicated by the network, and each packet may take a different path to reach the destination host. That means fragments can arrive not only out of order and/or duplicated, but also overlapping 🌀 The reassembly process ends up being kind of complex, and implementing it is not specifically trivial 🧠
[Shannon2001] analyzes the causes and attributes of fragment traffic measured in several types of WANs 📊
Over the years, a bunch of attacks have exploited bugs in the reassembly function of several operating systems. These produced buffer overflows that, in most cases, led to a crash of the attacked system 💥
4.1.1.4. Problems That Arise from the Ambiguity of the Reassembly Process
Network Intrusion Detection Systems (NIDSs) usually monitor the traffic on a given network, looking for traffic patterns that might point to network intrusions 👀
When there are IP fragments around, a NIDS has to do IP fragment reassembly in order to detect illegitimate activity at the transport or application layers (aka any protocol layer above the network layer) 🔍
To correctly assess the traffic, the result of the reassembly function performed by the NIDS should be the same as the result of the reassembly function performed by the intended recipient of the packets ✨
But here's the tea ☕ a number of factors make the result of the reassembly process ambiguous:
- The IETF specifications are ambiguous about what should be done when overlapping fragments are received. So, with overlapping data, the system doing the reassembly is free to honor either the first set of data received, the latest copy received, or any other copy received in between 🤷♀️
- The specifications don't enforce any specific fragment timeout value, so 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 them into a full datagram, while others may time out the fragments and drop them 🕰️
- As mentioned before, when the fragment buffers get full, a DoS condition will occur unless some action is taken. Many systems flush part of the fragment buffers when some threshold is reached. So, 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 are freely available tools that forcefully fragment IP datagrams to help evade Intrusion Detection Systems. Frag router [Song1999] is an example of such a tool, and it lets an attacker perform all the evasion techniques described in [Ptacek1998] 😈 Ftester [Barisani2006] is a tool that helps audit systems for fragmentation issues 🛠️
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 (aka the fragment with a Fragment Offset of 0), and then 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 and the MF bit is set, a list item gets allocated to hold the result of the filter access checks. When packets with a non-zero Fragment Offset come in, the module looks up the list element with a matching Source Address/Destination Address/Protocol/Identification and applies the stored result (pass or block). When a fragment with a zero MF bit is seen, the list element gets freed 🧹
Unfortunately, the rules of this type of packet filter can usually be bypassed 😩 [RFC1858] describes the details of the technique involved.
4.1.2. Possible Security Improvements
4.1.2.1. Memory Allocation for Fragment Reassembly
Okay, so a design choice usually has to be made about how to allocate memory to reassemble the fragments of a given packet. There are basically two options 🧩
- Upon receipt of the first fragment, allocate a buffer that will be large enough to concatenate the payload of each fragment.
- Upon receipt of the first fragment, create the first node of a linked list that each of the following fragments will be linked to. When all fragments have been received, copy the IP payload of each fragment (in the correct order) to a separate buffer that gets handed to the protocol being encapsulated in the IP payload.
The first option might seem the most straightforward 🙄 but even when a single small fragment of a given packet is received, the memory allocated for that fragment accounts for the size of the complete IP datagram. So it uses more system resources than what is actually needed 📦
Also, the only situation in which the actual size of the whole datagram is known is when the last fragment of the packet is received first, since that's the only packet that can tell you the total size of the IP datagram. Otherwise, memory should be allocated for the 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, plus a limit on the number of fragments allowed in the system at any time. This basically caps the resources spent on the reassembly process and stops an attacker from trashing the whole system memory 🛡️
The IP module should also keep a different buffer for IP fragments than for complete IP datagrams. This basically separates the effects of fragment attacks from non-fragmented traffic 🧱 Most TCP/IP implementations, like the one in Linux and those in BSD-derived systems, already do this 🐧
[Jones2002] analyzes 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 🧹
Okay so, for the attacks that try to eat up the memory buffers used for fragments, and the ones that try to make IP Identification numbers collide, there are a bunch of countermeasures that can be put in place 🛡️
Even with all those countermeasures, there's still the problem of what happens when the buffer pool used for IP fragments gets full 😭. Basically, if the fragment buffer is full, no communication that relies on fragmentation can make any progress 🙈.
Sadly, there aren't many good options for reacting to this. If nothing is done, every instance of communication that relies on fragmentation ends up with a denial of service 💀. So the only thing left to do is flush all or part of the fragment buffer 🧹, on the idea that legitimate traffic will be able to use the freed space so its communication flows can keep going ✨.
There are a few factors to think about when flushing the fragment buffers 👀. First, if one fragment of a given packet (that is, a fragment with a given Identification number) gets flushed, then all the other fragments that belong to the same datagram should be flushed too 🫶. Here's why: for a packet to be reassembled, all of its fragments have to be received by the system doing the reassembly. So if you only flush some of a packet's fragments, the buffers holding the rest stay tied up with fragments that could never reassemble into a complete datagram 😩.
Second, you have to be careful that when later flushes happen, it's not always the same set of fragments getting dropped 🙅♀️. That behaviour would probably cause a selective DoS to the traffic flows those fragments belong to 💅.
Lots of TCP/IP implementations define a threshold for the number of fragments that, once reached, triggers a fragment-buffer flush 🚨. Some systems flush 1/2 of the fragment buffer when that threshold is hit 🍓. As mentioned before, the whole point of flushing is to make some free space in the fragment buffer, on the premise that this lets new and legitimate fragments get processed by the IP module, so communication can survive the overwhelming situation 🦋. On the flip side, flushing a somewhat large portion of the buffer is meant to avoid always flushing the same set of packets 🌈.
4.1.2.3. A More Selective Fragment Buffer Flushing Strategy 👑
One of the struggles with countering the fragmentation attacks described throughout Section 4.1 is that it's hard to validate the fragments you receive 🥺. For example, the fragment you'd most want to check, the first fragment, might not be the first one to show up at the destination host 🙃.
Fragments can arrive out of order not only because the network reorders packets, but also because the system (or systems) that fragmented the IP datagram might send the fragments out of order to begin with 🌀. A notable example is the Linux TCP/IP stack, which transmits the fragments in reverse order 🐧.
This means we can't enforce checks on the fragments before we allocate reassembly resources for them, since the first fragment we receive for a given packet could be any fragment other than the first one (the one with a Fragment Offset of 0) 😵💫.
BUT! At the point where we decide to free some space in the fragment buffer, we can refine the flushing policy 💡. The first thing we want is to stop different types of traffic from messing with each other 🙅♀️. In principle, that means we don't want fragmented UDP traffic interfering with fragmented TCP traffic 🚫. To get that separation across the different protocols, you'd in principle need a different fragment buffer pool for each of the 256 protocols that can be encapsulated in an IP datagram 🤯.
We think a good trade-off is to have two separate fragment buffers 🤝: one for IP datagrams that encapsulate IPsec packets, and another for everything else. Basically, traffic not protected by IPsec won't interfere with the flows that are protected by IPsec 🔐.
The two fragment buffer pools would be processed completely independently of each other 🧩. For the IPsec fragment buffer pool, when the buffers need flushing, the following refined policy could be applied 📋:
- First, for each packet whose IPsec header has been received, check that the Security Parameters Index (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.
- Second, if more fragment buffers still need 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.
- Third, if after flushing packets with invalid IPsec information (First step), and packets on which validation checks could not be performed (Second step), there's 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 reasoning behind this policy is that, when flushing fragment buffers, we'd rather keep packets we could successfully run a number of validation checks on, over packets where those checks failed or couldn't even be performed 💖.
By checking both the IPsec SPI and the IPsec sequence number, it's virtually impossible for an off-path attacker to launch a DoS attack against communication flows protected by IPsec 🛡️✨.
Unfortunately, some IP implementations (like the one in Linux [Linux]) send the corresponding fragments in reverse order when they fragment. In those cases, when the fragment buffer gets flushed, legitimate fragments get the same treatment as the possibly forged ones 😬.
This refined flushing policy gives an increased level of protection against this kind of resource exhaustion attack 💪, while not making things worse for out-of-order IPsec-secured traffic than the simplified flushing policy from the previous section does 🌸.
4.1.2.4. Reducing the Fragment Timeout ⏰
RFC 1122 [RFC1122] says the reassembly timeout should be a fixed value between 60 and 120 seconds 🕰️. The reasoning behind those long timeout values is that they should accommodate any path characteristics, like long-delay paths 🛰️. But here's the tea: this timer is really measuring inter-fragment delays, or more specifically, fragment jitter 🍵.
If all the fragments take paths with similar characteristics, the inter-fragment delay will usually be, at most, a few seconds ⚡. Even if fragments take paths with different characteristics, though, the recommended 60 to 120 seconds are, in practice, excessive 😤.
Some systems have already reduced the fragment timeout to 30 seconds [Linux] 🐧. The fragment timeout could probably be reduced further, to approximately 15 seconds, although further research on this issue is necessary 🔬.
It should be noted that in network scenarios with long delay and high bandwidth (usually called "Long-Fat Networks"), using a long fragment timeout would likely increase the probability of collision of IP ID numbers 💥. So in those scenarios it is highly desirable to avoid the use of fragmentation with techniques such as PMTUD [RFC1191] or PLPMTUD [RFC4821] 🙏.
4.1.2.5. Countermeasure for Some NIDS Evasion Techniques 🕵️
[Shankar2003] introduces a technique named "Active Mapping" that prevents evasion of a NIDS by acquiring enough knowledge about the monitored network to work out which packets will reach the intended recipient, and how that recipient will interpret them 🗺️. [Novak2005] describes some techniques that the Snort [Snort] NIDS applies to avoid evasion 🐍.
4.1.2.6. Countermeasure for Firewall-Rules Bypassing 🚧
One of the classic techniques for bypassing firewall rules involves sending packets in which the header of the encapsulated protocol is fragmented 🎭. Even though it would be legal (as far as the IETF specifications are concerned) to receive such packets, the MTUs of the network technologies used in practice aren't small enough to require the header of the encapsulated protocol to be fragmented (see [RFC2544], for example) 📏. Therefore, the system performing reassembly should drop all packets which fragment the upper-layer protocol header, and this event should be logged (for example, a counter could be incremented to reflect the packet drop) 📝.
Additionally, since lots of middle-boxes such as firewalls create state according to the contents of the first fragment of a given packet, it's 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 💅
Okay so Section 5.3.3.1 of RFC 1812 [RFC1812] says routers should implement precedence-ordered queue service. When a packet gets picked for output on a (logical) link, the packet with the highest precedence that's queued for that link is the one that gets sent. Section 5.3.3.2 of RFC 1812 also tells routers to default to maintaining strict precedence-ordered service 🎀.
Ngl this is where it gets messy 😭. It's super trivial to forge the IP precedence field in an IP header, so an attacker could just stamp a high precedence number on their packets and sneakily get better network service 🙈. If precedence-ordered queue service isn't required in a particular network infrastructure, it should be disabled, so every packet gets the same type of service no matter what's in their Type of Service or Differentiated Services fields 🫶.
When precedence-ordered queue service is required in the network infrastructure, edge routers or switches should be configured to police and remark the Type of Service or Differentiated Services values, based on the type of service each end-system has been allowed to send with. That's how you mitigate the attack vector we just talked about 🔥.
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". Still, given the security implications of the Precedence field, it's fair for routers, switches, or other middle-boxes (especially the ones at the network edge) to overwrite the Type of Service (or Differentiated Services) field of the packets they forward, according to a configured network policy. This is the specified behavior for DS domains [RFC2475] 💜.
Sections 5.3.3.1 and 5.3.6 of RFC 1812 state 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". That totally makes sense given what the Precedence field means, but it's important to note that it would be simple for an attacker to send packets with a forged high Precedence value to congest some internet router(s) and cause all (or most) traffic with a lower Precedence value to get 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, which is the forwarding algorithm. Bullet 3, "Weak TOS", covers the case where routes have a "type of service" attribute. It says that if a packet has 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. Here's the catch though: if the longest match routes for a packet include routes with some TOS other than the one in the packet, and there are no routes with the default TOS, the packet gets dropped. That may or may not be what you want, bestie 🤷♀️.
An alternative for when the "longest match" routes only have non-default types of service that don't match the TOS in the received packet is to just use a route with any other TOS. That route probably won't give the packet the type of service it asked for, but it at least provides a "best effort" service ✨.
It must be noted that Section 5.3.2 of RFC 1812 allows routers to not honor the TOS field. So the proposed alternative behavior is still compliant with the IETF specifications 🫶.
While officially specified in the RFC series, TOS-based routing is not widely deployed in the Internet.
4.2.3. Impact of Address Resolution on Buffer Management 🧚
With broadcast link-layer technologies, a system usually has to map an IP address to the matching link-layer address before it can transfer an IP datagram (for example, by means of the Address Resolution Protocol (ARP) [RFC0826]). While that mapping is happening, the packets that need it have to be kept in memory. This can happen for both hosts and routers 🍓.
This is totally exploitable 😭. An attacker could send a huge amount of packets to a non-existent host that's supposedly directly connected to the attacked router. While the router tries to map that IP address into a link-layer address, it keeps every packet that needs that link-layer address in memory. When the mapping function times out, depending on the policy the router uses, only the packet that triggered the mapping call might get dropped. In that case, the same operation repeats for every packet headed to the non-existent host. Depending on the timeout value for the mapping function, the router can run out of free buffer space. That means incoming legitimate packets have to be dropped, or legitimate packets already stored in the buffers might get dropped. Both of these situations lead either to a complete DoS or to degraded network service 💔.
One countermeasure is to drop, at the point the mapping function times out, all the packets destined to the address that timed out. You could also keep a "negative cache entry" in the module performing the matching function, so that for some amount of time, the mapping function returns an error whenever the IP module asks to map an address whose mapping recently timed out 🛡️.
A common implementation strategy for routers is that when a packet arrives that requires an ARP resolution before it can be forwarded, the packet is dropped and the router is then engaged in the ARP procedure.
4.2.4. Dropping Packets 🗑️
Sometimes a host or router needs to drop packets from the output queue. If one of those 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 reason is that it's nonsensical to spend system resources on them, because as long as one fragment is missing, the receiving system can never reassemble them into a complete IP datagram 🧩.
Some systems have been known to drop just a subset of the fragments of a given datagram. That leads to a denial-of-service condition, since only a subset of the fragments actually made it to the next hop 😩.
4.3. Addressing 🌸
4.3.1. Unreachable Addresses 👀
It's important to understand that some addresses are supposed to be unreachable from the public Internet (like the private IP addresses described in RFC 1918 [RFC1918], or the "loopback" address). But there are a bunch of tricks an attacker can use to reach those addresses anyway (e.g., exploiting the LSRR or SSRR IP options). So when applicable, packet filtering should be performed at the private network boundary to make sure those addresses stay unreachable.
Similarly, link-local unicast addresses [RFC3927] and multicast addresses with limited scope (link- and site-local addresses) should not be accessible from outside the proper network boundaries, and they should not be passed across those boundaries.
[RFC5735] gives you 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:
10.0.0.0 - 10.255.255.255(10/8 prefix)172.16.0.0 - 172.31.255.255(172.16/12 prefix)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 so these addresses aren't reachable from outside the private network where they're employed 🔒.
4.3.3. Former Class D Addresses (224/4 Address Block) 🎀
The former Class D addresses correspond to the 224/4 address block, and they're used for Internet multicast. So 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). Also, if an IP packet with a multicast Destination Address is received for a connection-oriented protocol (e.g., TCP), the packet should be dropped (see Section 4.3.5), and this event should be logged too (e.g., a counter could be incremented) 💅.
4.3.4. Former Class E Addresses (240/4 Address Block) 🧪
The former Class E addresses correspond to the 240/4 address block, and they're currently reserved for experimental use. As a result, most routers discard packets that contain a "Class" E address as the Source Address or Destination Address. If a packet is received with a 240/4 address as the Source Address and/or the Destination Address, the packet should be dropped and this event should be logged (e.g., a counter could be incremented to reflect the packet drop) 💀.
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/Multicast Addresses and Connection-Oriented Protocols 🤝
For connection-oriented protocols, such as TCP, shared state is maintained between only two endpoints at a time. So 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 (shorthand for all bits set to 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], because with CIDR a system can't know a priori what the subnet mask is for a particular IP address 🌈.
Many systems now let administrators use the values 0 or -1 for those fields. Even though, according to the original IETF specifications, these addresses are illegal, modern IP implementations should consider these addresses to be valid ✨.
4.3.7. Special Internet Addresses 🦋✨
okay so RFC 1812 [RFC1812] talks about some special Internet addresses, and this is super useful for doing sanity checks on the Source Address and Destination Address fields of an IP packet 💅. It writes an IP address like this:
{ <Network-prefix>, <Host-number> }the length of the network prefix is usually implied by the network mask assigned to the IP interface you're looking at 🎀.
RFC 1122 [RFC1122] had a similar chat about special Internet addresses, including some of the form { <Network-prefix>, <Subnet-number>, <Host-number> }. BUT as Section 4.2.2.11 of RFC 1812 explains, in a CIDR world the subnet number is clearly an extension of the network prefix and you can't tell it apart from the rest of the prefix 🙈.
{0, 0}this one means "this host on this network" 🌸. It's only meant to be used during the initialization procedure, which is when the host figures out its own IP address.
If a packet shows up with 0.0.0.0 as the Source Address for any reason other than bootstrapping, it should be silently dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 💀. If a packet shows up with 0.0.0.0 as the Destination Address, it should be silently dropped too, and that event should be logged (e.g., a counter could be incremented to reflect the packet drop) 😭.
{0, Host number}this one means "the specified host, in this network" 🧚. Same deal as before: it's only meant for the initialization procedure where the host learns its own IP address. If a packet arrives with an address like this as the Source Address for any purpose other than bootstrapping, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 🫶. If a packet arrives with an address like this as the Destination Address, it should be dropped, and the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 💜.
{-1, -1}this 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 the event should be logged (e.g., a counter could be incremented to reflect the packet drop) 🍓.
Some systems, when they get an ICMP echo request for example, will copy the Destination Address from that ICMP echo request packet and use it as the Source Address of the response they send (in this case, an ICMP echo reply). So when those systems receive a request sent to a broadcast address, the Source Address of the reply ends up containing 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 keeps the corresponding network from being used as, for example, a "smurf amplifier" [CERT1998a] 🛡️.
As noted in Section 4.3.6 of this document, lots of systems now let administrators configure these addresses as unicast addresses for network interfaces 🌈. In those scenarios, routers should forward these addresses as if they were traditional unicast addresses 🦄.
In some scenarios, a host may know that a particular IP address is 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 those scenarios, if a system can infer that the Source Address of a received packet is a network-directed broadcast address, the packet should be dropped, and the 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 hard for a system to tell whether a particular IP address that doesn't belong to a directly attached subnet is a broadcast address 🤷♀️.
{127.0.0.0/8, any}this is the internal host loopback address 🔁. Any packet that arrives on any physical interface with this address as the Source Address, the Destination Address, or as part of a source route (either LSRR or SSRR), should be dropped 🚨.
For example, packets with a Destination Address in the 127.0.0.0/8 address block that arrive on an interface other than loopback should be silently dropped 🙅. Packets received on any interface other than loopback with a Source Address matching the system receiving the packet should also be dropped 💅.
In all the above cases, when a packet is dropped, the 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 a number of implementation strategies that help mitigate a bunch of vulnerabilities found in the protocol over the last 25 years or so 💀🔥. It's giving "this has been around forever and people keep finding new ways to break it" energy, no cap 😭.
6. Acknowledgements 🫶🎀
The author wishes to thank Alfred Hoenes for providing very thorough reviews of earlier versions of this document, which led to tons of improvements 🌟.
The author would like to thank Jari Arkko, Ron Bonica, Stewart Bryant, Adrian Farrel, Joel Jaeggli, Warren Kumari, 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 CPNI in 2008 🇬🇧✨.
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], which this document is based on 🙌.
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.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[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.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 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.
[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.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007.
[RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the
IPv4 and IPv6 Router Alert Options", RFC 5350,
September 2008.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
BCP 153, RFC 5735, January 2010.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, November 2010.7.2. Informative References
[Anderson2001]
Anderson, J., "An Analysis of Fragmentation Attacks",
2001, <http://www.ouah.org/fragma.html>.
[Arkin2000]
Arkin, "IP TTL Field Value with ICMP (Oops - Identifying
Windows 2000 again and more)", 2000,
<http://ofirarkin.files.wordpress.com/2008/11/
ofirarkin2000-06.pdf>.
[Barisani2006]
Barisani, A., "FTester - Firewall and IDS testing tool",
2001, <http://dev.inversepath.com/trac/ftester>.
[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, "Bonk exploit", 1998,
<http://www.insecure.org/sploits/
95.NT.fragmentation.bonk.html>.
[Biondi2007]
Biondi, P. and A. Ebalard, "IPv6 Routing Header Security",
CanSecWest 2007 Security Conference, 2007,
<http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>.[CERT1996a] CERT, "CERT Advisory CA-1996-01: UDP Port Denial-of-Service Attack", 1996, http://www.cert.org/advisories/CA-1996-01.html.
[CERT1996b] CERT, "CERT Advisory CA-1996-21: TCP SYN Flooding and IP Spoofing Attacks", 1996, http://www.cert.org/advisories/CA-1996-21.html.
[CERT1996c] CERT, "CERT Advisory CA-1996-26: Denial-of-Service Attack via ping", 1996, http://www.cert.org/advisories/CA-1996-26.html.
[CERT1997] CERT, "CERT Advisory CA-1997-28: IP Denial-of-Service Attacks", 1997, http://www.cert.org/advisories/CA-1997-28.html.
[CERT1998a] CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of-Service Attacks", 1998, http://www.cert.org/advisories/CA-1998-01.html.
[CERT1998b] CERT, "CERT Advisory CA-1998-13: Vulnerability in Certain TCP/IP Implementations", 1998, http://www.cert.org/advisories/CA-1998-13.html.
[CERT1999] CERT, "CERT Advisory CA-1999-17: Denial-of-Service Tools", 1999, http://www.cert.org/advisories/CA-1999-17.html.
[CERT2003] CERT, "CERT Advisory CA-2003-15: Cisco IOS Interface Blocked by IPv4 Packet", 2003, http://www.cert.org/advisories/CA-2003-15.html.
[CIPSO1992] CIPSO, "COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)", Work in Progress, 1992.
[CIPSOWG1994] CIPSOWG, "Commercial Internet Protocol Security Option (CIPSO) Working Group", 1994, http://www.ietf.org/proceedings/94jul/charters/cipso-charter.html.
[CPNI2008] Gont, F., "Security Assessment of the Internet Protocol", 2008, http://www.cpni.gov.uk/Docs/InternetProtocol.pdf.
[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", 2003, http://www.cisco.com/en/US/products/products_security_advisory09186a00801a34c2.shtml.
[Cisco2008] Cisco, "Cisco IOS Security Configuration Guide, Release 12.2", 2003, http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfipso.html.
[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 analysis with a broken CRC", Phrack Magazine, Volume 0x0b, Issue 0x3c, Phile #0x0c of 0x10, 2002, http://www.phrack.org/issues.html?issue=60&id=12&mode=txt.
[FIPS1994] FIPS, "Standard Security Label for Information Transfer", Federal Information Processing Standards Publication. FIP PUBS 188, 1994, http://csrc.nist.gov/publications/fips/fips188/fips188.pdf.
[Fyodor2004] Fyodor, "Idle scanning and related IP ID games", 2004, http://www.insecure.org/nmap/idlescan.html.
[GIAC2000] GIAC, "Egress Filtering v 0.2", 2000, http://www.sans.org/y2k/egress.htm.
[Gont2006] Gont, F., "Advanced ICMP packet filtering", 2006, http://www.gont.com.ar/papers/icmp-filtering.html.
[Haddad2004] Haddad, I. and M. Zakrzewski, "Security Distribution for Linux Clusters", Linux Journal, 2004, http://www.linuxjournal.com/article/6943.
[Humble1998] Humble, "Nestea exploit", 1998, http://www.insecure.org/sploits/linux.PalmOS.nestea.html.
[IANA_ET] IANA, "Ether Types", http://www.iana.org/assignments/ethernet-numbers.
[IANA_IP_PARAM] IANA, "IP Parameters", http://www.iana.org/assignments/ip-parameters.
[IANA_PROT_NUM] IANA, "Protocol Numbers", http://www.iana.org/assignments/protocol-numbers.
[IRIX2008] IRIX, "IRIX 6.5 trusted_networking(7) manual page", 2008, http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/cat7/trusted_networking.z.
[Jones2002] Jones, R., "A Method Of Selecting Values For the Parameters Controlling IP Fragment Reassembly", 2002, ftp://ftp.cup.hp.com/dist/networking/briefs/ip_reass_tuning.txt.
[Kenney1996] Kenney, M., "The Ping of Death Page", 1996, http://www.insecure.org/sploits/ping-o-death.html.
[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", 2007, http://www.trusteer.com/files/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf.
[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", 2006, http://ee.lbl.gov/.
[Linux] Linux Kernel Organization, "The Linux Kernel Archives", http://www.kernel.org.
[Microsoft1999] Microsoft, "Microsoft Security Program: Microsoft Security Bulletin (MS99-038). Patch Available for "Spoofed Route Pointer" Vulnerability", 1999, http://www.microsoft.com/technet/security/bulletin/ms99-038.mspx.
[NISCC2004] NISCC, "NISCC Vulnerability Advisory 236929: Vulnerability Issues in TCP", 2004, http://www.cpni.gov.uk.
[NISCC2005] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: Vulnerability Issues in ICMP packets with TCP payloads", 2005, http://www.gont.com.ar/advisories/index.html.
[NISCC2006] NISCC, "NISCC Technical Note 01/2006: Egress and Ingress Filtering", 2006, http://www.cpni.gov.uk.
[Northcutt2000] Northcut, S. and Novak, "Network Intrusion Detection - An Analyst's Handbook", Second Edition New Riders Publishing, 2000.
[Novak2005] Novak, "Target-Based Fragmentation Reassembly", 2005, http://www.snort.org/assets/165/target_based_frag.pdf.
[OpenBSD-PF] Sanfilippo, S., "PF: Scrub (Packet Normalization)", 2010, ftp://ftp.openbsd.org/pub/OpenBSD/doc/pf-faq.pdf.
[OpenBSD1998] OpenBSD, "OpenBSD Security Advisory: IP Source Routing Problem", 1998, http://www.openbsd.org/advisories/sourceroute.txt.
[Paxson2001] Paxson, V., Handley, M., and C. Kreibich, "Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics", USENIX Conference, 2001.
[Ptacek1998] Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial of Service: Eluding Network Intrusion Detection", 1998, http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps.
[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.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 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.
[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.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009.
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, July 2009.
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009.
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline Encoding and Transport of Pre-Congestion Information", RFC 5696, November 2009.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[ROUTER-ALERT] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", Work in Progress, June 2011.
[SELinux2009] NSA, "Security-Enhanced Linux", http://www.nsa.gov/research/selinux/.
[Sanfilippo1998a] Sanfilippo, S., "about the ip header id", Post to Bugtraq mailing-list, Mon Dec 14 1998, http://www.kyuzz.org/antirez/papers/ipid.html.
[Sanfilippo1998b] Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 1998, http://www.kyuzz.org/antirez/papers/dumbscan.html.
[Sanfilippo1999] Sanfilippo, S., "more ip id", Post to Bugtraq mailing-list, 1999, http://www.kyuzz.org/antirez/papers/moreipid.html.
[Shankar2003] Shankar, U. and V. Paxson, "Active Mapping: Resisting NIDS Evasion Without Altering Traffic", 2003, http://www.icir.org/vern/papers/activemap-oak03.pdf.
[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, 2005, http://www.silby.com/eurobsdcon05/eurobsdcon_slides.pdf.
[Snort] Sourcefire, Inc., "Snort", http://www.snort.org.
[Solaris2007] Oracle, "ORACLE SOLARIS WITH TRUSTED EXTENSIONS", 2007, http://www.oracle.com/us/products/servers-storage/solaris/solaris-trusted-ext-ds-075583.pdf.
[Song1999] Song, D., "Frag router tool", http://www.monkey.org/~dugsong/fragroute/.
[SpooferProject] MIT ANA, "Spoofer Project", 2010, http://spoofer.csail.mit.edu/index.php.
[US-CERT2001] US-CERT, "US-CERT Vulnerability Note VU#446689: Check Point FireWall-1 allows fragmented packets through firewall if Fast Mode is enabled", 2001, http://www.kb.cert.org/vuls/id/446689.
[US-CERT2002] US-CERT, "US-CERT Vulnerability Note VU#310387: Cisco IOS discloses fragments of previous packets when Express Forwarding is enabled", 2002.
[Watson2004] Watson, P., "Slipping in the Window: TCP Reset Attacks", CanSecWest Conference, 2004.
[Zakrzewski2002] 💜 Zakrzewski, M. and I. Haddad, "Linux Distributed Security Module", 2002, http://www.linuxjournal.com/article/6215.
[daemon91996] 🌸 daemon9, route, and infinity, "IP-spoofing Demystified (Trust-Relationship Exploitation)", Phrack Magazine, Volume Seven, Issue Forty-Eight, File 14 of 18, 1988, http://www.phrack.org/issues.html?issue=48&id=14&mode=txt.
Author's Address 🎀
Fernando Gont 💅
UK Centre for the Protection of National Infrastructure 🦋
EMail: fernando@gont.com.ar 💖
URI: http://www.cpni.gov.uk ✨
📦 where this page comes from
- ietf: rfc6274 2011-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms