RFC 7126

Recommendations on Filtering of IPv4 Packets Containing IPv4 Options

📅 published February 2014, from ietf

RFC 7126: Recommendations on Filtering of IPv4 Packets Containing IPv4 Options ✨

Okay bestie, here's the title block, so you know what you're dealing with 🎀

  • Number: RFC 7126
  • Title: Recommendations on Filtering of IPv4 Packets Containing IPv4 Options
  • Authors: F. Gont (UTN-FRH / SI6 Networks), R. Atkinson (Consultant), C. Pignataro (Cisco)
  • Category: Best Current Practice, BCP: 186
  • ISSN: 2070-1721
  • Date: February 2014 🌸
  • Obsoletes / Updates: none listed in the title block 🙈

Abstract 💜

So this doc gives advice on filtering IPv4 packets based on the IPv4 options they carry. It also talks about the operational and interoperability fallout of dropping packets just because of the options inside them. Iykyk, it's a whole thing 💅

Status of This Memo 📋

This memo documents an Internet Best Current Practice 🦋

It's a product of the Internet Engineering Task Force (IETF), and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more on BCPs, check Section 2 of RFC 5741.

Want the current status, any errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc7126 ✨

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🔥

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Terminology and Conventions Used in This Document . . . .   3
  1.2.  Operational Focus . . . . . . . . . . . . . . . . . . . .   4
2.  IP Options  . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  General Security Implications of IP Options . . . . . . . . .   5
  3.1.  Processing Requirements . . . . . . . . . . . . . . . . .   5
4.  Advice on the Handling of Packets with Specific IP Options  .   7
  4.1.  End of Option List (Type = 0) . . . . . . . . . . . . . .   7
  4.2.  No Operation (Type = 1) . . . . . . . . . . . . . . . . .   7
  4.3.  Loose Source and Record Route (LSRR) (Type = 131) . . . .   8
  4.4.  Strict Source and Record Route (SSRR) (Type = 137)  . . .  10
  4.5.  Record Route (Type = 7) . . . . . . . . . . . . . . . . .  11
  4.6.  Stream Identifier (Type = 136) (obsolete) . . . . . . . .  12
  4.7.  Internet Timestamp (Type = 68)  . . . . . . . . . . . . .  13
  4.8.  Router Alert (Type = 148) . . . . . . . . . . . . . . . .  14
  4.9.  Probe MTU (Type = 11) (obsolete)  . . . . . . . . . . . .  15
  4.10. Reply MTU (Type = 12) (obsolete)  . . . . . . . . . . . .  16
  4.11. Traceroute (Type = 82)  . . . . . . . . . . . . . . . . .  16
  4.12. DoD Basic Security Option (Type = 130)  . . . . . . . . .  17
  4.13. DoD Extended Security Option (Type = 133) . . . . . . . .  20
  4.14. Commercial IP Security Option (CIPSO) (Type = 134)  . . .  22
  4.15. VISA (Type = 142) . . . . . . . . . . . . . . . . . . . .  23
  4.16. Extended Internet Protocol (Type = 145) . . . . . . . . .  24
  4.17. Address Extension (Type = 147)  . . . . . . . . . . . . .  25
  4.18. Sender Directed Multi-Destination Delivery (Type = 149) .  25
  4.19. Dynamic Packet State (Type = 151) . . . . . . . . . . . .  26
  4.20. Upstream Multicast Pkt. (Type = 152)  . . . . . . . . . .  26
  4.21. Quick-Start (Type = 25) . . . . . . . . . . . . . . . . .  27
  4.22. RFC3692-Style Experiment (Types = 30, 94, 158, and 222) .  28
  4.23. Other IP Options  . . . . . . . . . . . . . . . . . . . .  29
5.  Security Considerations . . . . . . . . . . . . . . . . . . .  31
6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  31
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  31
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .  31
  7.2.  Informative References  . . . . . . . . . . . . . . . . .  32

1. Introduction 🌈

Okay so this doc is all about filtering IPv4 packets based on the IPv4 options they contain. Various protocols might use IPv4 options to some extent, so dropping packets based on their options can mess with how those protocols work. That's why this doc tries to cover the operational and interoperability implications of dropping them. It also lays out what a network operator might do in typical enterprise or Service Provider environments. Bonus: it draws on and is partly derived from [RFC6274], which the operational community also reviewed 🧚

Now, the data shows there's a current, widespread practice of blocking IPv4 optioned packets. There are a bunch of plausible ways to cut down the potential harm from these packets while still letting some option semantics through. One approach is to allow specific options that are expected or needed, with a default deny. Another is to deny the unneeded options and default to allow. A third is to allow end-to-end semantics by ignoring options and treating packets as un-optioned while they're in transit. Experiments and available data tend to back up the first or third approaches as more realistic 📊 You can see some of the current state of affairs around dropping packets with IP options in [MEDINA] and [FONSECA]. Also, [BREMIER-BARR] points out that the deployed Internet already has lots of routers that don't process IP options 💀

Another thing: this doc gives advice on dropping packets on a "per IP option type" basis, but not every device (routers, security gateways, and firewalls) can do it at that granularity. And even when the functionality exists, an operator might want a dropping policy with a coarser granularity than "per IP option type", as mentioned above 🎀

Finally, when intermediate systems don't need to process IP options, a common approach is to just ignore the options and process those packets as if they had no IP options at all ✨

1.1. Terminology and Conventions Used in This Document 📖

The terms "fast path", "slow path", and related relative terms ("faster path" and "slower path") are loosely defined as in Section 2 of [RFC6398].

Because this doc is so security-focused, we deliberately include some historical citations. The goal is to explicitly keep and show the history, and to clear up ambiguity and confusion. Periodt 💅

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 [RFC2119].

1.2. Operational Focus 🫶

Every recommendation in this doc was made to optimize for operational community consensus, as best the authors could work out. That meant not only accepting feedback from public lists, but also taking off-list feedback from people at various network operators (e.g., Internet Service Providers, content providers, educational institutions, commercial firms). Community energy 👑

2. IP Options 🦋

IP options let you extend the Internet Protocol. As specified in [RFC0791], an option can have one of two formats:

  • Case 1: A single byte of option-type.
  • Case 2: An option-type byte, an option-length byte, and the actual option-data bytes.

IP options of Case 1 look like this:

+-+-+-+-+-+-+-+-+- - - - - - - - -
|  option-type  |  option-data
+-+-+-+-+-+-+-+-+- - - - - - - - -

For Case 1 options, the length is implicitly specified by the option-type byte.

IP options of Case 2 look like this:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
|  option-type  | option-length |  option-data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

In this case, the option-length byte counts the option-type byte, the option-length byte, and 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. Slay 💖

The option-type has three fields:

  • 1 bit: copied flag.
  • 2 bits: option class.
  • 5 bits: option number.

The copied flag tells you whether this option should be copied to all fragments if the packet carrying it needs fragmenting:

  • 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.

This format makes room for new options to extend the Internet Protocol (IP) ✨

Finally, the option number identifies the syntax of the rest of the option 🧠

The "IP OPTION NUMBERS" registry [IANA-IP] has the list of the currently assigned IP option numbers 📋

3. General Security Implications of IP Options 🔐

3.1. Processing Requirements 🎀

Okay so, back in the day, most IP routers ran everything on one general-purpose CPU 🥹. That same little brain also handled network management traffic (like SNMP), configuration commands (like the command line interface), routing protocols (like RIP, OSPF, BGP, and IS-IS), and other control protocols (like RSVP and ICMP). Packet filtering that was turned on for the router or a router interface usually landed on that CPU too. A router built this way can have a big Distributed Denial-of-Service (DDoS) attack risk 😭. If a flood of IPv4 packets carrying IPv4 options overwhelms the router's control plane (like that CPU), things get messy fast.

From about 1995 onwards, more and more routers started using silicon built for IP packet processing (that's Field-Programmable Gate Array (FPGA) and Application-Specific Integrated Circuit (ASIC) stuff ✨). This split forwarding off from the router's other jobs, and it's giving resilience 💪. These designs tend to hold up better against the kinds of DDoS attacks you might see on the global public Internet. Depending on implementation and configuration details, a router with a silicon packet-forwarding engine can handle a lot of IP packets with IP options without hurting its forwarding rates or its control plane (like the general-purpose CPU). Some implementations have one simple config knob that forwards every packet with IP options at wire-speed in silicon, as if those options weren't there ("ignore options & forward"). Others can do wire-speed silicon-based filtering, which means they can selectively drop packets with certain options ("drop"), ignore the options on packets with certain other options and forward them ("ignore options & forward"), and process the options on packets with different ones ("process option & forward") while the packet is being forwarded. That processing can happen on a general-purpose CPU or in custom logic like an FPGA or ASIC 🧚.

Broadly speaking, any IP packet that needs the router's general-purpose CPU can be a DDoS risk to that CPU, and therefore to the router itself 🙈. At present, though, you really have to understand the specific architecture and engineering of the router in question before you can judge the operational security risk of a given packet type or IP option type. It's all about the details, bestie 💅.

Operators are urged to think about what potential IP routers can do for IP option filtering and handling when they make deployment decisions in the future 🔮.

More considerations for protecting the control plane from packets containing IP options can be found in [RFC6192] 📚.

Last but not least, this document isn't just for operators. It also gives advice to router, security gateway, and firewall implementers on providing the ability to filter packets at different granularities 🌈. That means both a "per IP option type" granularity (for maximum flexibility) and coarser filters (to keep configuration complexity down) 💖.

4. Advice on the Handling of Packets with Specific IP Options ✨

The subsections below describe each IP option that has been specified so far. They also cover possible interoperability implications if packets containing those options get dropped, plus specific advice on whether to drop packets with each option in a typical enterprise or Service Provider environment 🦋.

4.1. End of Option List (Type = 0) 🌸

4.1.1. Uses

This option signals the "end of options" in cases where the end of options wouldn't line up with the end of the Internet Protocol header 🙌.

4.1.2. Option Specification

Specified in RFC 791 [RFC0791] 📜.

4.1.3. Threats

No specific security issues are known for this IPv4 option 🫶.

4.1.4. Operational and Interoperability Impact if Blocked

Packets with any IP options are likely to include an End of Option List 👀. So if you drop packets containing this option, it's very likely you're blocking legitimate traffic 😭.

4.1.5. Advice

Routers, security gateways, and firewalls SHOULD NOT drop packets because they contain this option 🙅‍♀️💖.

4.2. No Operation (Type = 1) 🍓

4.2.1. Uses

The no-operation option basically exists so the sending system can line up subsequent options on, for example, 32-bit boundaries 📏.

4.2.2. Option Specification

Specified in RFC 791 [RFC0791] 📜.

4.2.3. Threats

No specific security issues are known for this IPv4 option 🫶.

4.2.4. Operational and Interoperability Impact if Blocked

Packets with any IP options are likely to include a No Operation option 👀. So if you drop packets containing this option, it's very likely you're blocking legitimate traffic 😭.

4.2.5. Advice

Routers, security gateways, and firewalls SHOULD NOT drop packets because they contain this option 🙅‍♀️💖.

4.3. Loose Source and Record Route (LSRR) (Type = 131) 🦋

RFC 791 says this option should appear at most once in a given packet 🧐. So if a packet has more than one LSRR option, it should be dropped, and the event should be logged (for example, a counter could go up to reflect the drop). Packets that combine LSRR and SSRR options should also be dropped, and that event should be logged too (again, a counter could track the drop) 📊.

4.3.1. Uses

This option lets the originating system specify a number of intermediate systems a packet must pass through to reach the destination host 🗺️. The route the packet actually follows gets recorded in the option too. The receiving host (end-system) must use the reverse of the path in the received LSRR option 🔁.

The LSSR option can be a real help when debugging some network problems 🔧. Some Internet Service Provider (ISP) peering agreements even require support for this option in the routers within the ISP's peer 🤝.

4.3.2. Option Specification

Specified in RFC 791 [RFC0791] 📜.

4.3.3. Threats

The LSRR option has well-known security implications [RFC6274] 🚨. Among other things, the option 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 work as an amplification method for these attacks, because an attacker could craft an LSRR option that makes a packet bounce multiple times between a number of systems 🏓.

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 hence the LSRR option) limits the amplification factor when compared to the IPv6 counterpart. 🤓

On top of that, some implementations have been found to skip proper sanity checks on the LSRR option, which led to security issues 💀. These specific issues are believed to be solved in all modern implementations ✅.

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

Finally, some systems were known for offering a system-wide toggle to enable support for this option, for those scenarios where the option is required 🔘. The catch is that improper implementation of that toggle made those systems support the LSRR option even when they were explicitly configured not to 😤.

[OpenBSD1998] is a security advisory about an improper implementation of such a system-wide toggle in 4.4BSD kernels. This issue was resolved in later versions of the corresponding operating system. 💜

4.3.4. Operational and Interoperability Impact if Blocked

Network troubleshooting techniques that may use the LSRR option (like ping or traceroute with the right arguments) would break when the LSRR option is involved 💔. (Ping and traceroute without IPv4 options aren't affected 🙌.) Still, it's worth noting that using the LSRR option for troubleshooting is practically impossible, thanks to widespread dropping of packets that contain the option 🫠.

4.3.5. Advice

Routers, security gateways, and firewalls SHOULD implement an option-specific configuration knob to choose one of three behaviors: drop packets with this option, forward packets as if they didn't contain this IP option, or process and forward packets with this option as per [RFC0791] 🎛️. The default setting for this knob SHOULD be "drop", and the default setting MUST be documented 📝.

Heads up, though: treating packets with LSRR as if they didn't contain this option can send them to a different device than the one originally intended 👀. With appropriate ingress filtering, this shouldn't open an attack vector into the infrastructure 🛡️. Even so, it could result in traffic that never reaches the originally intended destination 😬. Dropping these packets prevents unnecessary network traffic, and it doesn't make end-to-end communication any worse 💅.

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

4.4.1. Uses

This option lets the originating system specify a number of intermediate systems a packet must pass through to reach the destination host 🗺️. The route the packet actually follows gets recorded in the option, and the destination host (end-system) must use the reverse of the path in the received SSRR option 🔁.

This option is similar to the Loose Source and Record Route (LSRR) option, with one big difference: with SSRR, the route in the option is the exact route the packet has to take, so no other intervening routers are allowed on the path 🎯.

The SSRR option can be a real help when debugging some network problems 🔧. Some ISP peering agreements require support for this option in the routers within the ISP's peer 🤝.

4.4.2. Option Specification

Specified in RFC 791 [RFC0791] 📜.

4.4.3. Threats

The SSRR option has the same security implications as the LSRR option 👯. Check out Section 4.3 for a discussion of those security implications 📖.

4.4.4. Operational and Interoperability Impact if Blocked

Network troubleshooting techniques that may use the SSRR option (like ping or traceroute with the right arguments) would break when the SSRR option is involved 💔. (Ping and traceroute without IPv4 options aren't affected 🙌.) Still, it's worth noting that using the SSRR option for trouble-shooting is practically impossible, thanks to widespread dropping of packets that contain the option 🫠.

4.4.5. Advice

okay bestie, routers, security gateways, and firewalls SHOULD implement an option-specific configuration knob 🎛️ so the admin can pick the vibe for SSRR packets: drop them, forward them as if they never had this IP option, or process and forward them as per [RFC0791]. The default setting for this knob SHOULD be "drop", and the default setting MUST be documented 📝

Please note 🫶 that treating SSRR packets as if they didn't have this option can send them to a different device than the one originally intended. With proper ingress filtering, this should not open an attack vector into the infrastructure. It could still mean traffic that never reaches the intended destination. Dropping these packets stops pointless traffic, and it doesn't make end-to-end communication any worse ✨

4.5. Record Route (Type = 7)

4.5.1. Uses

this option gives you a way to record the route a given packet follows 🗺️

4.5.2. Option Specification

Specified in RFC 791 [RFC0791] 📜

4.5.3. Threats

ngl this one is a little spicy 🌶️ it can be exploited to map a network's topology. The good news is the limited space in the IP header limits how useful it is for that 🙈

4.5.4. Operational and Interoperability Impact if Blocked

troubleshooting techniques that use the RR option (like ping with the RR option) would break when the RR option is used 💔 Ping without IPv4 options is not impacted, tho 🙌 It should be noted that it's basically impossible to use these techniques anyway, because packets that contain RR options get dropped everywhere 😭

4.5.5. Advice

Routers, security gateways, and firewalls SHOULD implement an option-specific configuration knob 🎛️ to choose whether packets with this option are dropped, forwarded as if they did not contain this IP option, or processed and forwarded as per [RFC0791]. The default setting for this knob SHOULD be "drop", and the default setting MUST be documented 📝

4.6. Stream Identifier (Type = 136) (obsolete)

the Stream Identifier option originally let the 16-bit SATNET stream Identifier travel through networks that didn't support the stream concept 🛰️

However, as stated by Section 3.2.1.8 of RFC 1122 [RFC1122] and Section 4.2.2.1 of RFC 1812 [RFC1812], this option is obsolete. Therefore, it must be ignored by the processing systems. See also [IANA-IP] and [RFC6814] 💀

RFC 791 says this option appears at most once in a given datagram. 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) 🧾

4.6.1. Uses

this option is obsolete, and there's no current use for it 🪦

4.6.2. Option Specification

Specified in RFC 791 [RFC0791], and deprecated in RFC 1122 [RFC1122] and RFC 1812 [RFC1812]. This option has been formally obsoleted by [RFC6814] 📚

4.6.3. Threats

no specific security issues are known for this IPv4 option 🫧

4.6.4. Operational and Interoperability Impact if Blocked

none 🫶

4.6.5. Advice

Routers, security gateways, and firewalls SHOULD drop IP packets containing a Stream Identifier option 🚫

4.7. Internet Timestamp (Type = 68)

4.7.1. Uses

this option records the time at which each system (or a specified set of systems) processed the datagram. It may optionally record the addresses of the systems providing the timestamps ⏰

4.7.2. Option Specification

Specified by RFC 791 [RFC0791] 📜

4.7.3. Threats

the timestamp option has a bunch of security implications [RFC6274] 👀 Among them:

  • It lets an attacker get the current time of the systems that process the packet, which the attacker may find useful in a number of scenarios.
  • It may be used to map the network topology, similar to the IP Record Route option.
  • It may be used to fingerprint the operating system in use by a system processing the datagram.
  • It may be used to fingerprint physical devices by analyzing the clock skew.

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

4.7.4. Operational and Interoperability Impact if Blocked

troubleshooting techniques that use the Internet Timestamp option (like ping with the Timestamp option) would break when the Timestamp option is used 💔 Ping without IPv4 options is not impacted. It should be noted that these techniques are virtually impossible to use anyway, because packets with Internet Timestamp options get dropped widely 😭

4.7.5. Advice

Routers, security gateways, and firewalls SHOULD drop IP packets containing an Internet Timestamp option 🚫

4.8. Router Alert (Type = 148)

4.8.1. Uses

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" 🚨

4.8.2. Option Specification

the Router Alert option is defined in RFC 2113 [RFC2113], and later updates to it were clarified by RFC 5350 [RFC5350]. It contains a 16-bit Value governed by an IANA registry (see [RFC5350]) 🧮

4.8.3. Threats

the security implications of the Router Alert option are discussed in detail in [RFC6398]. Basically, the option might be exploited to perform a DoS attack by exhausting CPU resources at the processing routers 🔥

4.8.4. Operational and Interoperability Impact if Blocked

applications that use the Router Alert option (like RSVP [RFC2205]) would break 💔

4.8.5. Advice

This option SHOULD be allowed only in controlled environments, where it can be used safely. [RFC6398] identifies some such environments. In unsafe environments, packets containing this option SHOULD be dropped 🛡️

A given router, security gateway, or firewall has no way of knowing a priori whether this option is valid in its operational environment. So routers, security gateways, and firewalls SHOULD, by default, ignore the Router Alert option. Additionally, they SHOULD have a configuration setting that governs their reaction when they see packets containing the Router Alert option. This configuration setting SHOULD allow honoring and processing the option, ignoring the option, or dropping packets containing it ⚙️

4.9. Probe MTU (Type = 11) (obsolete)

4.9.1. Uses

this option originally gave a mechanism to discover the Path-MTU. It has been declared obsolete 🪦

4.9.2. Option Specification

this option was originally defined in RFC 1063 [RFC1063] and was obsoleted with RFC 1191 [RFC1191]. It's now obsolete, since RFC 1191 obsoletes RFC 1063 without using IP options 📜

4.9.3. Threats

this option is obsolete. It could have been exploited to make a host set its Path MTU (PMTU) estimate to an inordinately low or an inordinately high value, which would cause performance problems 🐢

4.9.4. Operational and Interoperability Impact if Blocked

none 🫶

This option is NOT employed with the modern "Path MTU Discovery" (PMTUD) mechanism [RFC1191], which uses special ICMP messages (Type 3, Code 4) together with the IP DF bit. Packetization Layer PMTUD (PLPMTUD) [RFC4821] can perform PMTUD without the need for any special packets. 🧚

4.9.5. Advice

Routers, security gateways, and firewalls SHOULD drop IP packets that contain a Probe MTU option 🚫

4.10. Reply MTU (Type = 12) (obsolete)

4.10.1. Uses

this option originally gave a mechanism to discover the Path-MTU. It's now obsolete 🪦

4.10.2. Option Specification

this option was originally defined in RFC 1063 [RFC1063] and was obsoleted with RFC 1191 [RFC1191]. It's now obsolete, since RFC 1191 obsoletes RFC 1063 without using IP options 📜

4.10.3. Threats

this option is obsolete. It could have been exploited to make a host set its PMTU estimate to an inordinately low or an inordinately high value, which would cause performance problems 🐢

4.10.4. Operational and Interoperability Impact if Blocked

none 🫶

This option is NOT employed with the modern "Path MTU Discovery" (PMTUD) mechanism [RFC1191], which uses special ICMP messages (Type 3, Code 4) together with the IP DF bit. PLPMTUD [RFC4821] can perform PMTUD without the need of any special packets. 🧚

4.10.5. Advice

Routers, security gateways, and firewalls SHOULD drop IP packets that contain a Reply MTU option 🚫

4.11. Traceroute (Type = 82)

4.11.1. Uses

this option originally gave a mechanism to trace the path to a host 🧭

4.11.2. Option Specification

this option was originally specified by RFC 1393 [RFC1393] as "experimental", and it was never widely deployed on the public Internet. It has been formally obsoleted by [RFC6814] 🧪

4.11.3. Threats

this option is obsolete. Because it required each router in the path to do special processing and send an ICMP message, it could have been exploited to perform a DoS attack by exhausting CPU resources at the processing routers 🔥

4.11.4. Operational and Interoperability Impact if Blocked

none 🫶

4.11.5. Advice

Routers, security gateways, and firewalls SHOULD drop IP packets that contain a Traceroute option 🚫

4.12. DoD Basic Security Option (Type = 130)

4.12.1. Uses

this option [RFC1108] is used by Multi-Level Secure (MLS) end-systems and intermediate systems in specific environments to:

  • transmit the common security labels required by computer security models [Landwehr81] from source to destination, in a network standard representation,
  • 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 🔐

The DoD Basic Security Option (BSO) was implemented in IRIX [IRIX2008] and is currently implemented in a number of operating systems (e.g., Security-Enhanced Linux [SELinux2008], Solaris [Solaris2008], and Cisco IOS [Cisco-IPSO]). It's also currently deployed in a number of high-security networks, which are typically either in physically secure locations, protected by military/governmental communications security equipment, or both 🛡️

These networks are usually built with commercial off-the-shelf (COTS) IP routers and Ethernet switches, but they aren't normally interconnected with the global public Internet. MLS systems are way more widely deployed now than when the then-IESG decided to remove IPSO (IP Security Options) from the IETF Standards Track. Since nearly all MLS systems also support IPSO BSO and IPSO ESO, this option is believed to have more deployment now than when the IESG removed it from the IETF Standards Track. [RFC5570] describes a similar option recently defined for IPv6 and goes way deeper into how sensitivity label options are used in real-world deployments 🌈

4.12.2. Option Specification ✨

okay so this one is specced by RFC 1108 [RFC1108], which obsoleted RFC 1038 [RFC1038]. and RFC 1038 had itself obsoleted the Security Option from RFC 791 [RFC0791] 🎀

the history is kind of a whole saga 🧚. RFC 791 [RFC0791] defined the "Security Option" (Type = 130), and it used the same option type number as the DoD Basic Security option we're talking about here. then RFC 1038 [RFC1038] reworked the IP security options, and RFC 1108 [RFC1108] came along and obsoleted it. the RFC 791 "Security Option" is now considered obsolete by Section 3.2.1.8 of RFC 1122 [RFC1122] and Section 4.2.2.1 of RFC 1812 [RFC1812], so this section is focused on the DoD Basic Security option from RFC 1108 [RFC1108] 💅

Section 4.2.2.1 of RFC 1812 says routers "SHOULD implement [this option]" 🫶

some private IP networks treat per-interface selective filtering of packets as a big deal for operational security 🔒. the filtering is based on (a) whether an IPSO option is present (that includes BSO and ESO) and (b) what that IPSO option actually says. the newer IPv6 Common Architecture Label IPv6 Security Option (CALIPSO) spec goes into more detail on this, though it's written for IPv6 [RFC5570] 🌸

these private networks are usually built from both commercial and open-source gear, like hosts, guards, firewalls, switches, routers, and so on 🧰. some commercial IP routers support this option, and so do some IP routers built on top of MLS operating systems (for example, Trusted Solaris [Solaris2008] or Security-Enhanced Linux [SELinux2008]) 💜

for example, lots of Cisco routers running Cisco IOS can selectively filter packets carrying IP Security Options (IPSO), with per-interface granularity. that's been around in many Cisco routers since the early 1990s [Cisco-IPSO-Cmds] 🦋. some government-sector products also reportedly support IP Security Options (IPSO), like CANEWARE [RFC4949] 🇺🇸

the IPSO Basic Security Option is also covered in the "IPsec Configuration Policy Information Model" [RFC3585] and the "IPsec Security Policy Database Configuration MIB" [RFC4807] 📋. Section 4.6.1 of the IP Security Domain of Interpretation [RFC2407] supports labeled IPsec security associations that are compatible with the IP Security Options 🍓. (Note: RFC 2407 was obsoleted by [RFC4306], which was then obsoleted by [RFC5996]. the paperwork never stops 😭)

4.12.3. Threats ✨

presence of this option in a packet doesn't create any specific new threat all by itself 🙈. packets with this option ought not normally be seen on the global public Internet 🌈

4.12.4. Operational and Interoperability Impact if Blocked ✨

okay this part is important 😭. if packets with this option get blocked, or if the option gets stripped from the packet on the way from source to destination, the packet is likely to be dropped by the receiver because it isn't labeled properly 💀

sometimes the receiver does get the packet, but it attaches the wrong sensitivity label to the data, because the BSO was stripped by an intermediate router or firewall 🙈. that's a problem either way. the data can get handled as more sensitive than it really is ("upgrading"), or as less sensitive than it really is ("downgrading") 🚨

4.12.5. Advice ✨

a given IP router, security gateway, or firewall has no way to know a priori what environment it's been deployed into 🤷‍♀️. even closed IP deployments usually use the exact same commercial routers, security gateways, and firewalls that the public Internet uses 💅

here's the logic. operational problems happen where this option is needed and either the option gets dropped or the IP packets carrying it get dropped. but nothing bad happens when the option is carried in environments where it isn't needed. so the default configuration SHOULD NOT (a) modify or remove this IP option or (b) drop an IP packet just because it contains this option 🫶

a given IP router, security gateway, or firewall MAY be configured to drop this option, or to drop IP packets containing this option, in an environment known not to use this option 🧚

for auditing reasons, routers, security gateways, and firewalls SHOULD be capable of logging the number of packets containing the BSO on a per-interface basis 📊. also, routers, security gateways, and firewalls SHOULD be capable of dropping packets based on BSO presence as well as BSO values 🔥

4.13. DoD Extended Security Option (Type = 133) 🎀

4.13.1. Uses ✨

this option lets extra security labeling information get supplied in an IP datagram, on top of what the Basic Security Option (Section 4.12) already carries, so it can meet the needs of registered authorities 👑

4.13.2. Option Specification ✨

the DoD Extended Security Option (ESO) is specified by RFC 1108 [RFC1108] 💖

some private IP networks treat per-interface selective filtering of packets as important for operational security. it's based on (a) whether an IPSO option is present (that includes BSO and ESO) and (b) what that IPSO option's contents are 🔒. the IPv6 CALIPSO option spec discusses this in more detail, though it's written for an IPv6 context [RFC5570] 🌸

these private networks are usually built from commercial and open-source products (hosts, guards, firewalls, switches, routers, and so on) 🧰. some commercial IP routers support this option, and so do some IP routers built on top of MLS operating systems (for example, Trusted Solaris [Solaris2008] or Security-Enhanced Linux [SELinux2008]) 💜

many Cisco routers running Cisco IOS support selectively filtering packets carrying IP Security Options (IPSO) with per-interface granularity 🦋. that's been in many Cisco routers since the early 1990s [Cisco-IPSO-Cmds]. some government sector products reportedly support IP Security Options (IPSO) too, like CANEWARE [RFC4949] 🇺🇸

support for the IPSO Extended Security Option is also included in the "IPsec Configuration Policy Information Model" [RFC3585] and the "IPsec Security Policy Database Configuration MIB" [RFC4807]. Section 4.6.1 of the IP Security Domain of Interpretation [RFC2407] includes support for labeled IPsec security associations compatible with the IP Security Options 🍓

4.13.3. Threats ✨

presence of this option in a packet doesn't create any specific new threat by itself 🙈. packets with this option ought not normally be seen on the global public Internet 🌈

4.13.4. Operational and Interoperability Impact if Blocked ✨

if packets with this option are blocked, or the option gets stripped from the packet during transmission from source to destination, the packet is likely to be dropped by the receiver because it isn't properly labeled 💀

in some cases the receiver gets the packet but attaches an incorrect sensitivity label to the data, because the ESO was stripped by an intermediate router or firewall 🙈. that can make the data handled as more sensitive than it really is ("upgrading") or less sensitive than it really is ("downgrading"). either one is problematic 🚨

4.13.5. Advice ✨

a given IP router, security gateway, or firewall has no way to know a priori what environment it's been deployed into 🤷‍♀️. even closed IP deployments generally use exactly the same commercial routers, security gateways, and firewalls that are used on the public Internet 💅

operational problems happen where this option is needed and either the option gets dropped or the IP packets carrying it get dropped. no harm comes from carrying the option where it isn't needed. so the default configuration SHOULD NOT (a) modify or remove this IP option or (b) drop an IP packet just because it contains this option 🫶

a given IP router, security gateway, or firewall MAY be configured to drop this option, or to drop IP packets containing this option, in an environment known not to use this option 🧚

for auditing reasons, routers, security gateways, and firewalls SHOULD be capable of logging the number of packets containing the ESO on a per-interface basis 📊. also, routers, security gateways, and firewalls SHOULD be capable of dropping packets based on ESO presence as well as ESO values 🔥

4.14. Commercial IP Security Option (CIPSO) (Type = 134) 🦋

4.14.1. Uses ✨

this option was proposed by the Trusted Systems Interoperability Group (TSIG), to meet trusted networking requirements for the commercial trusted systems marketplace 💼

it was implemented in IRIX [IRIX2008] and is currently implemented in a number of operating systems (for example, Security-Enhanced Linux [SELinux2008] and Solaris [Solaris2008]). it's also currently deployed in a number of high-security networks 🔐

4.14.2. Option Specification ✨

this option is specified in [CIPSO] and [FIPS1994]. there are zero known IP router implementations of CIPSO 😭. several MLS operating systems support CIPSO, generally the same ones that support IPSO 💜

the TSIG proposal was taken to the Commercial Internet Security Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an Internet-Draft was produced [CIPSO]. that 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] 🌟

4.14.3. Threats ✨

presence of this option in a packet doesn't create any specific new threat by itself 🙈. packets with this option ought not normally be seen on the global public Internet 🌈

4.14.4. Operational and Interoperability Impact if Blocked ✨

if packets with this option are blocked, or the option gets stripped from the packet during transmission from source to destination, the packet is likely to be dropped by the receiver because it isn't properly labeled 💀

in some cases the receiver gets the packet but attaches an incorrect sensitivity label to the data, because the CIPSO was stripped by an intermediate router or firewall 🙈. that can make the data handled as more sensitive than it really is ("upgrading") or less sensitive than it really is ("downgrading"). either one is problematic 🚨

4.14.5. Advice ✨

because of this option's design, with variable syntax and variable length, it isn't practical to support specialized filtering using the CIPSO information 🧩. no routers or firewalls are known to support this option 😭. however, routers, security gateways, and firewalls SHOULD NOT by default modify or remove this option from IP packets, and SHOULD NOT by default drop packets just because they contain this option 🫶

for auditing reasons, routers, security gateways, and firewalls SHOULD be capable of logging the number of packets containing the CIPSO on a per-interface basis 📊. also, routers, security gateways, and firewalls SHOULD be capable of dropping packets based on CIPSO presence 🔥

4.15. VISA (Type = 142) 🎀

4.15.1. Uses

okay so this option was part of an experiment at the University of Southern California (USC) and it never got widely deployed 🌸

4.15.2. Option Specification

the original option spec isn't publicly available 🙈 this option has been formally obsoleted by [RFC6814].

4.15.3. Threats

not possible to determine (other than the general security implications of IP options discussed in Section 3), since the spec isn't public 🔍

4.15.4. Operational and Interoperability Impact if Blocked

none! 💖

4.15.5. Advice

Routers, security gateways, and firewalls SHOULD drop IP packets that contain this option ✨

4.16. Extended Internet Protocol (Type = 145) 🦋

4.16.1. Uses

the EIP option came from one of the proposals submitted during the IP Next Generation (IPng) efforts to tackle IPv4 address exhaustion 🧚

4.16.2. Option Specification

specified in [RFC1385]. this option has been formally obsoleted by [RFC6814] 💅

4.16.3. Threats

this option is obsolete 🕰️ it was used (or was intended to be used) to signal that a packet that looked like an IPv4 packet actually contained a different protocol. that opened up the possibility that an IPv4 node which simply ignored this option would process a received packet in a way that didn't match what the sender meant 😭 there are no known threats arising from this option, other than the general security implications of IP options discussed in Section 3.

4.16.4. Operational and Interoperability Impact if Blocked

none 🌈

4.16.5. Advice

Routers, security gateways, and firewalls SHOULD drop packets that contain this option 🚫

4.17. Address Extension (Type = 147) 🌷

4.17.1. Uses

the Address Extension option was introduced by one of the proposals submitted during the IPng efforts to address the problem of IPv4 address exhaustion 🌍

4.17.2. Option Specification

specified in [RFC1475]. this option has been formally obsoleted by [RFC6814] 🫶

4.17.3. Threats

there are no known threats arising from this option, other than the general security implications of IP options discussed in Section 3 🛡️

4.17.4. Operational and Interoperability Impact if Blocked

none 🍓

4.17.5. Advice

Routers, security gateways, and firewalls SHOULD drop packets that contain this option 💜

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

4.18.1. Uses

this option originally provided unreliable UDP delivery to a set of addresses included in the option 📨

4.18.2. Option Specification

this option is specified in RFC 1770 [RFC1770]. it has been formally obsoleted by [RFC6814] 📜

4.18.3. Threats

this option could have been exploited for bandwidth-amplification in DoS attacks 💀 not a vibe.

4.18.4. Operational and Interoperability Impact if Blocked

none ✨

4.18.5. Advice

Routers, security gateways, and firewalls SHOULD drop IP packets that contain a Sender Directed Multi-Destination Delivery option 🙅‍♀️

4.19. Dynamic Packet State (Type = 151) 🔮

4.19.1. Uses

the Dynamic Packet State option was used to specify the Dynamic Packet State (DPS) in the context of the differentiated services architecture 💫

4.19.2. Option Specification

the Dynamic Packet State option was specified in [DIFFSERV-DPS]. the aforementioned document was meant to be published as "Experimental", but it never made it into an RFC 🥲 this option has been formally obsoleted by [RFC6814].

4.19.3. Threats

possible threats include theft of service and denial of service 🚨 however, we note that this option has never been widely implemented or deployed 🙌

4.19.4. Operational and Interoperability Impact if Blocked

none 🎀

4.19.5. Advice

Routers, security gateways, and firewalls SHOULD drop packets that contain this option 🧱

4.20. Upstream Multicast Pkt. (Type = 152) 📡

4.20.1. Uses

this option was meant to solve the problem of doing upstream forwarding of multicast packets on a multi-access LAN 🎯

4.20.2. Option Specification

this option was originally specified in [BIDIR-TREES]. it was never formally standardized in the RFC series and was never widely implemented and deployed 🫠 its use was obsoleted by [RFC5015], which employs a control-plane mechanism to solve the problem of doing upstream forwarding of multicast packets on a multi-access LAN 🛠️ this option has been formally obsoleted by [RFC6814].

4.20.3. Threats

this option is obsolete 🗑️ a router that ignored this option instead of processing it as specified in [BIDIR-TREES] could have forwarded multicast packets to an unintended destination 😬

4.20.4. Operational and Interoperability Impact if Blocked

none 🌸

4.20.5. Advice

Routers, security gateways, and firewalls SHOULD drop packets that contain this option 💅

4.21. Quick-Start (Type = 25) 🏎️

4.21.1. Uses

this IP Option is used in the specification of Quick-Start for TCP and IP. it's an experimental mechanism that lets transport protocols, working together with routers, figure out an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period) [RFC4782] ⚡

4.21.2. Option Specification

specified in RFC 4782 [RFC4782], on the "Experimental" track 🧪

4.21.3. Threats

Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two kinds of attacks 👀

  • attacks to increase the routers' processing and state load, and,
  • attacks with bogus Quick-Start Requests to temporarily tie up available Quick-Start bandwidth, preventing routers from approving Quick-Start Requests from other connections.

4.21.4. Operational and Interoperability Impact if Blocked

the Quick-Start functionality would be disabled, and additional delays in TCP's connection establishment (for example) could be introduced. (Please see Section 4.7.2 of [RFC4782].) we note, however, that Quick-Start has been proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet [RFC4782] 🌐

4.21.5. Advice

a given router, security gateway, or firewall system has no way of knowing a priori whether this option is valid in its operational environment 🤷‍♀️ so routers, security gateways, and firewalls SHOULD, by default, ignore the Quick-Start option 🙈 additionally, routers, security gateways, and firewalls SHOULD have a configuration setting that governs their reaction when packets containing the Quick-Start option show up 🎛️ this configuration setting SHOULD allow them to honor and process the option, ignore the option, or drop packets containing this option. the default configuration is to ignore the Quick-Start option ✨

We note that if routers in a given environment do not implement and enable the Quick-Start mechanism, only the general security implications of IP options (discussed in Section 3) would apply 🫶

4.22. RFC3692-Style Experiment (Types = 30, 94, 158, and 222) 🧬

Section 2.5 of RFC 4727 [RFC4727] allocates an option number with all defined values of the "copy" and "class" fields for RFC3692-style experiments. this results in four distinct option type codes: 30, 94, 158, and 222 🔢

4.22.1. Uses

it's only appropriate to use these values in explicitly configured experiments. they MUST NOT be shipped as defaults in implementations 🚫

4.22.2. Option Specification

specified in RFC 4727 [RFC4727] in the context of RFC3692-style experiments 📘

4.22.3. Threats

no specific security issues are known for this IPv4 option 🙌

4.22.4. Operational and Interoperability Impact if Blocked

none 🌷

4.22.5. Advice

Routers, security gateways, and firewalls SHOULD have configuration knobs for IP packets that contain RFC3692-style Experiment options, to select between "ignore & forward" and "drop & log". otherwise, no legitimate experiment using these options will be able to traverse any IP router 🛣️

special care needs to be taken in the case of "drop & log" ⚠️ devices SHOULD count the number of packets dropped, but the logging of drop events SHOULD be limited so as not to overburden device resources 📊

the aforementioned configuration knob SHOULD default to "drop & log" 🔒

4.23. Other IP Options 🌟

4.23.1. Specification

unrecognized IP options are to be ignored 🙈 Section 3.2.1.8 of RFC 1122 [RFC1122] specifies this behavior as follows:

The IP and transport layer MUST each interpret those IP options that they understand and silently ignore the others.

additionally, Section 4.2.2.6 of RFC 1812 [RFC1812] specifies it as follows:

A router MUST ignore IP options which it does not recognize.

this document adds that unrecognized IP options MAY also be logged 📝

further, routers, security gateways, and firewalls MUST provide the ability to log drop events of IP packets containing unrecognized or obsolete options 🧾

a number of additional options are listed in the "IP OPTION NUMBERS" IANA registry [IANA-IP] as of the time this document was last edited. specifically:

Copy Class Number Value Name
---- ----- ------ ----- -------------------------------------------
   0     0     10    10 ZSU    - Experimental Measurement
   1     2     13   205 FINN   - Experimental Flow Control
   0     0     15    15 ENCODE - ???
   1     0     16   144 IMITD  - IMI Traffic Descriptor
   1     0     22   150        - Unassigned (Released 18 Oct. 2005)

the ENCODE option (type 15) has been formally obsoleted by [RFC6814] 🧩

4.23.2. Threats

the lack of open specifications for these options makes it impossible to evaluate their security implications 🕵️‍♀️

4.23.3. Operational and Interoperability Impact if Blocked

the lack of open specifications for these options makes it impossible to evaluate the operational and interoperability impact if packets containing these options are blocked 🤔

4.23.4. Advice

Routers, security gateways, and firewalls SHOULD have configuration knobs for IP packets containing these options (or other options not recognized) to select between "ignore & forward" and "drop & log" 🎛️

Section 4.23.1 points out that [RFC1122] and [RFC1812] specify that unrecognized IP options MUST be ignored 📣 however, the previous paragraph states that routers, security gateways, and firewalls SHOULD have a configuration option for dropping and logging IP packets containing unrecognized options 😳 while it is acknowledged that this advice contradicts the previous RFCs' requirements, the advice in this document reflects current operational reality 🌍

special care needs to be taken in the case of "drop & log" ⚠️ devices SHOULD count the number of packets dropped, but the logging of drop events SHOULD be limited so as not to overburden device resources 📊

5. Security Considerations 🔐

This document provides advice on the filtering of IP packets that contain IP options. dropping such packets can help to mitigate the security issues that arise from use of different IP options 🛡️ many of the IPv4 options listed in this document are deprecated and cause no operational impact if dropped. however, dropping packets containing IPv4 options that are in use can cause real operational problems in deployed networks 😵 therefore, the practice of dropping all IPv4 packets containing one or more IPv4 options without careful consideration is not recommended 🙅‍♀️💖

6. Acknowledgements ✨

okay so the authors gave a huge shoutout to their reviewers, bestie 🫶 they thanked (in alphabetical order) Ron Bonica, C. M. Heard, Merike Kaeo, Panos Kampanakis, Suresh Krishnan, Arturo Servin, SM, and Donald Smith for giving thorough reviews and valuable comments 💅. Merike Kaeo even contributed text that got used in this document, which is so iconic 🌸.

The authors also thanked various network operations folks who gave feedback on earlier versions but didn't want their names in the doc. Main character energy of being behind the scenes 🦋.

Part of this document is initially based on "Security Assessment of the Internet Protocol" [CPNI2008], which came out of a project Fernando Gont ran on behalf of UK CPNI (formerly NISCC). Fernando wants to thank UK CPNI (formerly NISCC) for their continued support 💖.

7. References ✨

7.1. Normative References

The normative references are the ones you really need to read to implement this stuff, so take them seriously 📚🔥.

  • [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 💜
  • [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. 💜
  • [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. 💜
  • [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. 💜
  • [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 💜
  • [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. 💜
  • [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007. 💜
  • [RFC6398] Le Faucheur, F., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, October 2011. 💜
  • [RFC6814] Pignataro, C. and F. Gont, "Formally Deprecating Some IPv4 Options", RFC 6814, November 2012. 💜

7.2. Informative References

These are the extra reads for when you want to go deeper, no cap 🤓✨.

Authors' Addresses ✨

Here's where to find the authors, bestie 💌.

  • Fernando Gont, UTN-FRH / SI6 Networks, Evaristo Carriego 2644, Haedo, Provincia de Buenos Aires 1706, Argentina. Phone: +54 11 4650 8472. EMail: fgont@si6networks.com. URI: http://www.si6networks.com 🦋
  • RJ Atkinson, Consultant, McLean, VA 22103, USA. EMail: rja.lists@gmail.com 🌸
  • Carlos Pignataro, Cisco Systems, Inc., 7200-12 Kit Creek Road, Research Triangle Park, NC 27709, USA. EMail: cpignata@cisco.com 💖
📦 where this page comes from