RFC 4218
Threats Relating to IPv6 Multihoming Solutions
RFC 4218: Threats Relating to IPv6 Multihoming Solutions 🦋
okay so this is RFC 4218 🎀 It's Informational, which means it's just giving info to the internet community 🌸 and it does not specify an Internet standard of any kind. It was written by E. Nordmark (Sun Microsystems) and T. Li, and it's dated October 2005. It doesn't obsolete or update anything, since the header has no line for either one ✨
Status of This Memo ✨
okay so this memo is literally just info for the internet community 💅 it's not a standard of any kind, and distribution is unlimited, so share it with whoever 🫶
Copyright Notice 🌈
Copyright (C) The Internet Society (2005). 💜
Abstract 🌸
okay so this doc lists security threats tied to IPv6 multihoming 🔥 and multihoming can open up new ways to redirect packets to different, unintended IP addresses 😭
the goal is to look at how IPv6 multihoming solutions might make the internet less secure 🙈 we're not poking at one specific proposed solution, we're looking at threats that come with all of them. the threats here build on what was found and discussed as part of the Mobile IPv6 work 🧚
Table of Contents 🍓
1. Introduction ....................................................2
1.1. Assumptions ................................................3
1.2. Authentication, Authorization, and Identifier Ownership ....4
2. Terminology .....................................................5
3. Today's Assumptions and Attacks .................................6
3.1. Application Assumptions ....................................6
3.2. Redirection Attacks Today ..................................8
3.3. Packet Injection Attacks Today .............................9
3.4. Flooding Attacks Today ....................................10
3.5. Address Privacy Today .....................................11
4. Potential New Attacks ..........................................13
4.1. Cause Packets to Be Sent to the Attacker ..................13
4.1.1. Once Packets Are Flowing ...........................13
4.1.2. Time-Shifting Attack ...............................14
4.1.3. Premeditated Redirection ...........................14
4.1.4. Using Replay Attacks ...............................15
4.2. Cause Packets to Be Sent to a Black Hole ..................15
4.3. Third Party Denial-of-Service Attacks .....................16
4.3.1. Basic Third Party DoS ..............................17
4.3.2. Third Party DoS with On-Path Help ..................18
4.4. Accepting Packets from Unknown Locators ...................19
4.5. New Privacy Considerations ................................20
5. Granularity of Redirection .....................................20
6. Movement Implications? .........................................22
7. Other Security Concerns ........................................23
8. Security Considerations ........................................24
9. Acknowledgements ...............................................24
10. Informative References ........................................25
Appendix A: Some Security Analysis ................................271. Introduction ✨
okay so the goal of IPv6 multihoming is to let a site use multiple connections to the global Internet 🌐 without having a specific entry for that site showing up in the global routing table 💅 a good solution should let hosts use multiple attachments at the same time, or switch between attachment points on the fly when something fails, and none of that should mess with the transport and application layer protocols 🔥
the big worry with letting that kind of "rehoming" happen is what we call redirection attacks 😭 that's when packets get sent somewhere that doesn't match what the transport and/or application layer protocol thinks the peer is. these attacks threaten confidentiality, integrity, and availability 🙈 an attacker could read a flow by redirecting it to a spot where they have a packet recorder 👀 or, instead of recording, they could change the packets and forward them to the real destination, which wrecks the integrity of the data stream 💀 and honestly, the attacker can also just redirect a flow to cause a denial of service 🚫
this doc was written with multihoming solutions in mind that split network identity from network location 🧩 whether or not that split brings in a brand new identifier name space. but the split isn't required for every threat, so this taxonomy might apply to other approaches too 🌸 this doc isn't meant to examine any single proposed solution. it's meant as a tool for discussing and evaluating them 🎀 by cataloging known threats, we help make sure every proposal deals with all of the threats that exist 🫶
because this doc doesn't analyze a particular solution, it's inherently incomplete 🥺 a real solution would need its own threat analysis, especially in these areas:
- If the solution makes the split between locators and identifiers, then most application security mechanisms should be tied to the identifier, not to the locator. Therefore, work would be needed to understand how attacks on the identifier mechanism affect security, especially attacks on the mechanism that would bind locators to identifiers. 🔐
- How does the solution apply multihoming to IP multicast? Depending on how this is done, there might be specific threats relating to multicast that need to be understood. This document does not discuss any multicast-specific threats. 📡
- Connection-less transport protocols probably need more attention. They are already difficult to secure, even without a locator/identifier split. 🫠
1.1. Assumptions 🧠
okay so this threat analysis doesn't assume security has been applied to other security-relevant parts of the Internet, like DNS and routing protocols 🙃 but it does assume that at some point, at least parts of the Internet will be running with security for that key infrastructure ✨ with that in mind, it matters that a multihoming solution doesn't become the weakest link at that point. this is still true even if insecure DNS is the weakest link today 💅
this doc also doesn't assume that application protocols are protected by strong security today or in the future 🥹 it's still useful to assume that application protocols that care about integrity and/or confidentiality apply the relevant end-to-end security measures, like IPsec, TLS, and/or application layer security 🔒
to keep things simple, this doc assumes an on-path attacker can see packets, modify packets and send them out, and block packets from being delivered 🕵️♀️ this is a simplification, because there might be ways (like monitoring capability in switches) that let authenticated and authorized users observe packets without being able to send or block them 👀
in some cases it might make sense to tell on-path attackers apart. some can monitor packets and maybe also inject them, without being able to block packets from passing through 🧃
on-path attackers that only need to monitor might get lucky and find a non-switched Ethernet in the path, or use capacitive or inductive coupling to listen on a copper wire 🔌 but if the attacker is on an Ethernet that's on the path, switched or not, they can also use Address Resolution Protocol/Neighbor Discovery (ARP/ND) spoofing to get access to the packet flow, which lets them block too 😈 and if the attacker has access to the wire, they can just place a device on the wire to block 🙅♀️ other on-path attacks would be ones that gain control of a router or a switch (or gain control of one of the endpoints), and those would most likely allow blocking as well 💀
so the strongest case we currently know of where monitoring is easier than blocking is when switches and routers have monitoring capabilities (for network management or for lawful intercept) and an attacker might bypass the authentication and authorization checks for those capabilities 🫣 however, this doc makes the simplifying assumption to treat all on-path attackers the same, by assuming such an attacker can monitor, inject, and block packets 🧩 a security analysis of a particular proposal can benefit from not making this assumption, and can look at how on-path attackers with different capabilities can generate different attacks that might not exist on today's Internet 🔍
the doc assumes an off-path attacker can neither see packets between the peers (since it isn't on the path) nor block them from being delivered 🌙 off-path attackers can, in general, send packets with arbitrary IP source addresses and content, but those packets might get blocked if ingress filtering [INGRESS] is applied 🚧 so it's important to look at the multihoming impact on security both with and without ingress filtering 🎀
1.2. Authentication, Authorization, and Identifier Ownership 🔑
the overall problem space can be described using different terminology 🌸
one way to describe it is that you first have to authenticate the peer, and then verify that the peer is authorized to control the locators used for a particular identifier 🧐 that's correct, but it might put too much emphasis on the authorization part 🙈 here, authorization is conceptually very simple: each host (each identifier) is authorized to control which locators are used for itself 💖
so there's a different way to say the same thing ✨ if the peer can somehow prove it owns the identifier, and the communication is bound to the identifier (and not the locator), then the peer is allowed to control the locators used with that identifier 🫶 this framing is the one used in [OWNER] 📚
both ways of looking at the problem, and so both sets of terminology, are useful when you're trying to understand the problem space and the threats 👑
2. Terminology 📖✨
Okay bestie, let's get our vocab straight before we go any further 💅 Here's what each term means in this doc:
- link: a communication facility or medium where nodes can talk at the link layer, which is the layer right below IPv6 🔗 Examples are Ethernets (simple or bridged), PPP links, X.25, Frame Relay, or ATM networks, and Internet (or higher) layer "tunnels" like tunnels over IPv4 or IPv6 itself 🚇
- interface: a node's attachment to a link 🔌
- address: an IP layer name that has topological significance (so it's a locator!) and also identifies an interface 🏠 An interface can have multiple addresses. Normally an address uniquely identifies an interface, but there are exceptions: the same unicast address can be assigned to multiple interfaces on the same node, and an anycast address can be assigned to different interfaces on different nodes 🤯
- locator: an IP layer topological name for an interface or a set of interfaces 📍 There can be multiple locators per interface.
- identifier: an IP layer identifier for an IP layer endpoint (a stack name in [NSRG]), basically the thing people usually call a "host" 🖥️ The transport endpoint name depends on the transport protocol and would typically include the IP identifier plus a port number. There might be a use for having multiple identifiers per stack/per host. An identifier keeps working no matter what state any one interface is in 💪
- address field: the source and destination address fields in the IPv6 header. As IPv6 is currently specified, these fields carry "addresses". If identifiers and locators get separated, these fields will contain locators 🗂️
- FQDN: Fully Qualified Domain Name [FYI18] 🌐
3. Today's Assumptions and Attacks 🕵️♀️
The two juiciest parts of security for multihoming solutions are (1) the assumptions that transport layer and application layer protocols make about the identifiers they see, and (2) the attacks that already exist for messing with the identity/location relationship 👀
3.1. Application Assumptions 🤝
Okay so, on the Internet today, the initiating part of an application either starts with a FQDN, which it looks up in the DNS, or already has an IP address from somewhere 🧭 For the FQDN to do an IP address lookup, the application is basically placing trust in the DNS. Once it has the IP address, it places trust in the routing system to deliver packets to that address 🚚 Applications that use security mechanisms, like IPSEC or TLS, can bind an address or FQDN to cryptographic keying material 🔐 Compromising the DNS and/or routing system can result in packets being dropped or delivered to an attacker in such cases, but since the attacker doesn't have the keying material, the application won't trust the attacker, and the attacker can't decrypt what it receives 🙅♀️
At the responding (non-initiating) end of communication today, the security configurations used by different applications fall into roughly five classes 🎀 A single application might use different classes of configurations for different types of communication.
The first class is the set of public content servers 📰 These systems give data to any and all systems and aren't really concerned with confidentiality, since they make their content available to everyone 🌍 They are interested in data integrity and denial of service attacks though. Having someone manipulate the results of a search engine, for example, or stop certain systems from reaching a search engine, would be a serious security issue 😱
The second class of security configurations uses existing IP source addresses from outside of their immediate local site as a means of authentication, without any form of verification 🙈 Today, with source IP address spoofing and TCP sequence number guessing as rampant attacks [RFC1948], these applications are basically opening themselves up to public connectivity and relying on other systems, like firewalls, for overall security 🧱 We do not consider this class of configurations in this document, because they are in any case fully open to all forms of network layer spoofing 💀
The third class of security configurations receives existing IP source addresses but tries some verification using the DNS, effectively using the FQDN for access control 🪪 (This is typically done by performing a reverse lookup from the IP address, followed by a forward lookup, and verifying that the IP address matches one of the addresses returned from the forward lookup.) These applications are already subject to a number of attacks using techniques like source address spoofing and TCP sequence number guessing, since an attacker who knows this is the case can simply create a DoS attack using a forged source address that has authentic DNS records 😤 In general this class of security configurations is strongly discouraged, but it is probably important that a multihoming solution doesn't introduce any new and easier ways to perform such attacks 🚫 However, we note that some people think we should treat this class the same as the second class of security configurations 🤔
The fourth class of security configurations uses cryptographic security techniques to provide both a strong identity for the peer and data integrity, with or without confidentiality 🛡️ Such systems are still potentially vulnerable to denial of service attacks that could be introduced by a multihoming solution 😬
Finally, the fifth class of security configurations uses cryptographic security techniques but without strong identity, such as opportunistic IPsec 🧩 So data integrity, with or without confidentiality, is provided when communicating with an unknown/unauthenticated principal. Just like the first class above, these applications can't perform access control based on network layer information, since they don't know the identity of the peer 🙃 However, they might perform access control using higher-level notions of identity. The availability of IPsec (and similar solutions) together with channel bindings allows protocols (which, on their own, are vulnerable to man-in-the-middle (MITM) attacks) to operate with a high level of confidentiality in the security of the identification of the peer ✨ A typical example is the Remote Direct Data Placement Protocol (RDDP), which, when used with opportunistic IPsec, works well if channel bindings are available 🧚 Channel bindings provide a link between the IP-layer identification and the application protocol identification 🔗
A variant of the fifth class is made up of those that use "leap-of-faith" during some initial communication 🪂 They don't provide strong identities, except where subsequent communication is bound to the initial communication, which gives strong assurance that the peer is the same as during the initial communication 🫶
The fifth class is important, and its security properties must be preserved by a multihoming solution 🔥
The requirement for a multihoming solution is that security be no worse than it is today in all situations 💜 So mechanisms that provide confidentiality, integrity, or authentication today should keep providing those properties in a multihomed environment 🌈
3.2. Redirection Attacks Today 🎭
This section lists some of the redirection attacks that are possible in today's Internet 📝
If routing can be compromised, packets for any destination can be redirected to any location 😭 This can be done by injecting a long prefix into global routing, which makes the longest match algorithm deliver packets to the attacker 🏃♀️
Similarly, if DNS can be compromised, and a change can be made to an advertised resource record so that it advertises a different IP address for a hostname, that effectively takes over the hostname 💀 More detailed information about threats relating to DNS is in [DNS-THREATS] 📚
Any system along the path from the source to the destination host can be compromised and used to redirect traffic 🛤️ Systems may be added to the best path to accomplish this. Further, even systems on multi-access links that don't provide security can be used to redirect traffic off of the normal path 🙀 For example, ARP and ND spoofing can be used to attract all traffic for the legitimate next hop across an Ethernet. And since the vast majority of applications rely on DNS lookups, if DNSsec is not deployed, attackers on the path between the host and the DNS servers can also cause redirection by modifying the responses from the DNS servers 🕸️
In general, the above attacks only work when the attacker is on the path at the time it's performing the attack 🏃 However, in some cases it's possible for an attacker to create a DoS attack that lasts at least some time after the attacker has moved off the path ⏳ An example of this is an attacker that uses ARP or ND spoofing while on path to either insert itself or send packets to a black hole (a non-existent L2 address). After the attacker moves away, the ARP/ND entries stay in the caches of the neighboring nodes for some amount of time (a minute or so in the case of ARP). This results in packets continuing to be black-holed until the ARP entry is flushed 🕳️
Finally, the hosts that terminate the connection themselves can also be compromised and can perform functions that the end user never intended 😤
All of the above protocol attacks are the subject of ongoing work to secure them (DNSsec, security for BGP, Secure ND), and they are not considered further within this document 🔧 The goal for a multihoming solution is not to solve these attacks. Rather, it's to avoid adding to this list of attacks 🫡
3.3. Packet Injection Attacks Today 💉✨
okay so bestie, in today's Internet the transport protocols like TCP and SCTP run on top of IP, and they use IP addresses as the identifiers for the conversation 🦋. Without ingress filtering [INGRESS], the IP layer lets the sender put in any source address it wants 🙈. That means transport protocols and applications need some protection against malicious senders shoving bogus packets into the stream between two peers 💅. If that protection gets bypassed, an attacker can cause harm without even needing to redirect the return packets 💀.
There are different levels of protection across transport protocols 🌸. For example, in general TCP packets have to contain a sequence number that falls inside the receiver's window before they get accepted 🎀. If the TCP initial sequence numbers are random, it's super hard for an off-path attacker to guess a sequence number close enough to land in the window and inject a packet into an existing connection 😭. How hard it is depends on the size of the available window, whether the port numbers are also predictable, and the lifetime of the connection 🧚. Also, there's ongoing work to strengthen TCP's protection against this whole class of attacks [TCPSECURE] 🔥. SCTP has a stronger mechanism with the verification tag, and an off-path attacker would need to guess this random 32-bit number 👑. Of course, IPsec gives cryptographically strong mechanisms that stop attackers, on-path or off-path, from injecting packets once the security associations are established 🔐💖.
When ingress filtering sits between the potential attacker and the path between the communicating peers, it can stop the attacker from using the peer's IP address as the source 🛡️. In that case the packet injection fails in today's Internet 🙌.
We don't expect a multihoming solution to improve the existing prevention against packet injection 🤷♀️. But we do have to look carefully at whether a multihoming solution makes packet injection easier, because wanting the peer to be reachable at multiple locators, and maybe a dynamic set of locators, could lead to solutions that make packet injection easier even when ingress filtering is in place 🚨.
3.4. Flooding Attacks Today 🌊
In today's Internet there are several ways for an attacker to use a redirection mechanism to launch DoS attacks that are hard to trace back to them 🕵️♀️. One example is using protocols that cause reflection, with or without amplification [PAXSON01] 🪞.
Reflection without amplification can happen when an attacker sends a TCP SYN packet to a well-known server with a spoofed source address, and the resulting TCP SYN ACK packet gets sent to that spoofed source address 😳.
Devices on the path between two communicating entities can also launch DoS attacks 👀. Those attacks might not seem interesting today, but we need to understand them better so we can figure out whether a multihoming solution might enable new types of DoS attacks 🧐.
For example, today if A is talking to B, then A can try to overload the path from B to A 🙃. If TCP is used, A could do this by sending ACK packets for data it hasn't received yet (but suspects B has already sent), so B sends at a rate that causes persistent congestion on the path towards A 😵💫. This would seem self-destructive, though, since A would only make its own corner of the network suffer by overloading the path from the Internet towards A 🤦♀️.
A more interesting case is when A is talking to B and X is on the path between them. X might be able to fool B into sending packets toward A faster than A (and the path between A and X) can handle 😱. For instance, if TCP is used, X can craft TCP ACK packets that claim to come from A, which can get B to use a congestion window big enough to cause persistent congestion toward A 🌪️. And if X can suppress the packets from A to B, it can also stop A from sending any explicit "slow down" packets to B 🛑. In other words, X can disable any flow or congestion control mechanism, such as Explicit Congestion Notification [ECN] 🥴. Similar attacks can presumably be launched using protocols that carry streaming media by forging that protocol's notion of acknowledgement and feedback 🎬.
The sneaky part of this type of attack is that A will just think B is faulty, since B's flow and congestion control mechanisms don't seem to be working 🫠. Figuring out that the stream of ACK packets is coming from X and not from A might be tricky, since the rate of ACK packets might be pretty low 🔍. This type of attack might not be common today because, with ingress filtering in place, X has to stay on the path to keep the DoS attack going 🧱. And without ingress filtering, an attacker would either need to be on the path at first and then move away, or be able to set up the communication "blind," meaning without seeing the return traffic (which, for TCP, means guessing the initial sequence number) 🙈🎲.
The danger is that adding multihoming redirection mechanisms might remove the constraint that the attacker has to stay on the path. Today, with no multihoming support, using end-to-end strong security at a protocol level at (or below) this "ACK" processing would prevent this type of attack. But if a multihoming solution is provided underneath IPsec, that prevention mechanism might not exist anymore 😰🚨.
So the challenge for multihoming solutions is to not create additional types of attacks in this area, and to not make existing types of attacks significantly easier 💪💜.
3.5. Address Privacy Today 🕶️
In today's Internet there's limited ability to track a host as it moves around, because in some cases, like dialup connectivity, the host gets a different IPv4 address every time it connects 📞. But with broadband like DSL or cable becoming more common, it's getting more likely that a host keeps the same IPv4 address over time 📶. If a host moves around today, say by visiting WiFi hotspots, it gets a different IPv4 address at each location 🗺️.
Also, a super common practice in IPv4 today is some form of address translation, whether or not the site is multihomed 🎭. This basically hides the identity of the specific host inside a site, so only the site can be identified from its IP address 🏠.
When you want connectivity to stay up while a host moves around, whether with layer 2 technology or Mobile IPv4, the IPv4 address stays the same during the move (otherwise the connections would break) 🔗. So right now there's kind of a trade-off between seamless connectivity during movement and better address privacy ⚖️.
Today, when a site is multihomed to multiple ISPs, the usual setup uses a single IP address prefix with all the ISPs 📡. Because of that, it's possible to track that the same host is communicating through all of those ISPs 👯♀️.
However, when a host (not a site) is multihomed to several ISPs, like through a General Packet Radio Service (GPRS) connection and a wireless hot spot, the host gets different IP addresses on each interface 📱. The multihoming work is focused on site multihoming, but if the solution should also apply to host multihoming, the privacy impact needs to be considered for that case too 🧐💅.
IPv6 stateless address auto-configuration makes IP address management easier, but it raises some concerns because the Ethernet address is encoded in the low-order 64 bits of the IPv6 address 😬. That could be used to track a host as it moves around the network, across different ISPs and so on 🕵️. IPv6 specifies temporary addresses [RFC3041], which let applications choose whether they need long-lived IPv6 addresses or want the extra privacy of temporary ones 🦋🫶.
Since there's no address privacy in site multihoming setups today, the main "do no harm" concerns are making sure hosts that move around still get the same ability as in today's Internet to choose between seamless connectivity and better address privacy 💖. Introducing multihoming support should also keep the same choice we have in IPv6 with temporary addresses 🌈.
When we think about privacy threats, it helps to separate attacks from on-path entities watching packets go by from attacks by the communicating peer 👀. It's probably doable to stop on-path entities from correlating a host's multiple IP addresses ✨. But because the peer has to be told multiple IP addresses so it can switch to a different one when communication fails, the host has a harder time preventing its multiple addresses from being correlated 🥺. Still, using multiple pseudonyms for a host should be able to address this case 🎭🌸.
4. Potential New Attacks 🚨
This section covers the additional attacks that have been found from an architecture where hosts can change their topological connection to the network in the middle of a transport session without interruption 🦋. We're still framing this in the context where topological locators may be independent of the host identifiers used by transport and application layer protocols 🧩. Some of these attacks might not apply if traditional addresses are used 🤷♀️. This section assumes each host has multiple locators and that there's some mechanism for finding the locators for a correspondent host 🗝️. We don't assume anything about how those mechanisms work 🙈. Instead, this list helps us figure out which properties those mechanisms need in order to prevent these redirection attacks 💅.
Depending on what the redirection attack is trying to do, we split the attacks into several types 🍓.
4.1. Cause Packets to Be Sent to the Attacker 🎯
An attacker might want to receive the flow of packets, for example to inspect and/or modify the payload, or to run cryptographic analysis on cryptographically protected payloads, using redirection attacks 🕵️♀️.
Note that these attacks are always possible today if an attacker is on the path between two communicating parties, and a multihoming solution can't remove that threat 😤. So most of these concerns are about off-path attackers 🧠.
4.1.1. Once Packets Are Flowing 🌊
This might be seen as the "classic" redirection attack 👑.
While A and B are communicating, X might send packets to B and claim: "Hi, I'm A, send my packets to my new location," where that location is really X's location 😈.
"Standard" solutions to this include requiring that the host asking for the redirection be verified as the same host that originally set up the communication 🔐. But the burden of that verification must not be onerous, or the redirection requests themselves could be used as a DoS attack 🙅♀️.
To prevent this type of attack, a solution would need some mechanism that B can use to verify whether a locator belongs to A before B starts using that locator, and B has to be able to do this when multiple locators are assigned to A 💖✨.
4.1.2. Time-Shifting Attack ⏰
okay so "time-shifting attack" is the name for when an attacker does its damage after it's already left the path 🫠. It was on the path at some point, snooping and/or modifying packets, and then later, once it's no longer on the path, it launches the attack. Sneaky, bestie 🕵️♀️
In today's Internet, you can't pull this off to redirect packets 🙅♀️. BUT, for a while after it moves away, the attacker can still cause a DoS attack. It can leave a bogus ARP entry in the nodes on the path, or forge TCP Reset packets, since it saw the TCP Initial Sequence Numbers while it was still on the path. Main character villain arc 💀
It would be reasonable to require that a multihoming solution limit the ability to redirect and/or DoS traffic to a few minutes after the attacker has moved off the path ⏳✨
4.1.3. Premeditated Redirection 🪤
This one is a variant of the above, where the attacker "installs" itself before communication even starts 😤
Say the attacker X can predict that A and B will talk soon. Then X can tell B: "Hi, I'm A and I'm at this location". So when A later tries to talk to B, will B believe it's really A? 🤔 Like, will it just vibe with it?
If the solution to the classic redirection attack is based on "prove you are the same as initially", then A is going to fail that check, because X started the communication first 💔
Depending on the details of a specific proposed solution, this type of attack could either cause redirection (so the packets meant for A get sent to X) or cause DoS (where A can't talk to B because it can't prove it's the same host as X). Either way, it's giving chaos 🌪️
To prevent this, the check on whether a locator belongs to the peer can't just be based on whoever made contact first 🚫🙅♀️
4.1.4. Using Replay Attacks 🔁
Okay, so the multihoming problem doesn't inherently involve any topological movement, but it's still useful to think about site renumbering combined with multihoming 🗺️ In that case, a host's set of locators changes every time its site renumbers. And at some point after a renumbering event, the old locator prefix might get reassigned to some other site 😬
This potentially gives an attacker the power to replay whatever protocol mechanism was used to tell a host about a peer's locators. The host would then be led to believe that the old locator (set) should still be used, even long after the renumbering happened 🫣 This is similar to the risk of replaying Binding Updates in [MIPv6], but the time scale is very different. Mobile IPv6 might see movements every second, whereas site renumbering followed by reassignment of the site locator prefix might take weeks or months 🗓️
So, to prevent these replay attacks, the protocol used to verify which locators can be used with a particular identifier needs some replay protection mechanism 🛡️
Also, you have to be careful about how replay protection interacts with the administrative act of reassigning a locator 👀 If the identifier and locator relationship is distributed across the network, you'd need to make sure all the old information has been completely purged from the network before any reassignment. Note that this does not require an explicit mechanism 🙌 It can instead be handled by locator reuse policy and careful timeouts of locator information ⏲️
4.2. Cause Packets to Be Sent to a Black Hole 🕳️
This is also a variant of the classic redirection attack 🫶 The difference is that the new location is a locator that is nonexistent or unreachable. So the effect is that sending packets to the new locator gets them dropped by the network somewhere along the way 📉
You'd expect that solutions which prevent the earlier redirection attacks would also prevent this one as a side effect 🤞 But it still makes sense to include it here for completeness. Mechanisms that prevent a redirection attack to the attacker should also prevent redirection to a black hole 💅
4.3. Third Party Denial-of-Service Attacks 💥
An attacker can use its redirection ability to overload an unrelated third party 😭 For instance, if A and B are communicating, the attacker X might be able to convince A to send the packets meant for B to some third node C. Honestly, that might seem harmless at first, since X could just flood C with packets directly. But there are a few aspects of these attacks that are genuinely concerning 🙃
The first is that the attacker might be able to completely hide its identity and location 🥷 It might be enough for X to send and receive a few packets to A to do the redirection, and A might not keep any state on who asked for the redirection to C's location. And even if A did keep that state, it probably wouldn't be easily available to C. So once C is the victim of a DoS attack, C can't work out who the attacker was 😵
The second concern is about bandwidth. With a direct DoS attack from X to C, the attacker is limited by the bandwidth of its own path towards C. But if the attacker can fool another host, like A, into redirecting its traffic to C, then the bandwidth is limited by the path from A towards C instead 📈 If A is a high-capacity Internet service and X has slow (e.g., dialup) connectivity, that difference could be huge. So, in effect, this could be similar to packet amplifying reflectors in [PAXSON01] 🪞🔊
The third, and final, concern is that if an attacker only needs a few packets to convince one host to flood a third party, then it wouldn't be hard to convince lots of hosts to flood the same third party 🫠 That means this could be used for Distributed Denial-of-Service attacks 🌐
A third party DoS attack might target the resources of one particular host (like C in the example above). Or it might target the network infrastructure towards a particular IP address prefix, by overloading the routers or links, even though there's no host at the address being targeted 🚧
In today's Internet, the ability to pull off this type of attack is pretty limited 🙌 To start communication, the attacker will in most cases need to be able to receive some packets from the peer. (The potential exception is techniques that combine this with TCP-sequence-number-guessing techniques.) On top of that, to the extent that parts of the Internet use ingress filtering [INGRESS], even if the communication could be initiated, it wouldn't be possible to sustain it by sending ACK packets with spoofed source addresses from an off-path attacker 🛑
If this type of attack can't be prevented, there might be mitigation techniques that can be used. For instance, for TCP, a partial defense can be built by having TCP slow-start triggered when the destination locator changes 🐢 (Folks might argue that, separately from security, this would be the correct action for congestion control, since TCP might not have any congestion-related information about the new path implied by the new locator 🤷♀️) Presumably the same approach can be applied to other transport protocols that perform different forms of (TCP-friendly) congestion control, even though some of them might not adapt as quickly as TCP 🏃♀️
But since all congestion-controlled protocols probably need to react somehow to the path change implied by a locator change, it makes sense to think about 3rd party DoS attacks when designing how specific transport protocols should react to a locator change 🧠 However, this would only be a partial solution. It would probably take several packets and roundtrips before the transport protocol stops transmitting, so an attacker could still use this as a reflector with packet amplification 😩 That's why the multihoming mechanism probably needs some form of defense against third party DoS attacks, in addition to the help we can get from the transport protocols 🛡️💖
4.3.1. Basic Third Party DoS 🎯
Let's assume X is on a slow link anywhere in the Internet 🐌 B is on a fast link (gigabits; e.g., a media server), and A is the victim 🥺
X could flood A directly, but it's limited by its low bandwidth. However, if X can establish communication with B and ask B to send it a high-speed media stream, then X can presumably fake the "acknowledgements/feedback" that B needs to blast out packets at full speed 🚀 So far, this only hurts X and the path between X and the Internet. But if X could also tell B "I'm at A's locator", then X has effectively used the redirection capability in multihoming to amplify its DoS capability. Which is a serious source of concern 🚨
One could imagine some rather simple techniques to prevent such attacks. For instance, before sending to a new peer locator, you could do a clear text exchange with the claimed new locator, of the form "Are you X?", resulting in "Yes, I'm X.". This would be enough for the simplest of attacks 🫧 However, as we'll see below, more sophisticated attacks are possible 👀✨
4.3.2. Third Party DoS with On-Path Help 🧚
okay so this one is the sneaky upgrade 😈 the setup is the same as last time, but now the attacker X has a bestie Y sitting on the path between A and B:
----- ----- -----
| A |--------| Y |--------| B |
----- ----- -----
/
/
/
/
/
/
-----
| X |
-----with the simple fix from the last section, all Y might need to do is fake a response to the "Are you X?" packet 💅 after that, Y might not even be needed, because X could keep the data flowing toward A by generating the ACK packets itself 🫠 which makes Y way harder to detect. it's giving invisible 👻
furthermore, if X isn't the actual end system but is an attacker sitting between some node C and B, then X can claim to be C, and no finger can be pointed at X either 🙈
----- ----- -----
| A |--------| Y |--------| B |
----- ----- -----
/
/
/
/
/
/
----- -----
| C |-------| X |
----- -----so with two attackers on different paths, there might be no trace of who did the redirection to the 3rd party once the redirection has happened 🕵️♀️
a specific case of this is when X=Y, and X is located on the same LAN as B 🎀
okay now the fixes 🔧 one potential way to make these attacks harder is to use the last received (and verified) source locator as the destination locator. that way, when X sends the ACK packets (whether it claims to be X or C), the packet flow from B would switch back towards X/C, which would end up being an attack similar to what can be performed on today's Internet 😬
another way to make it harder is to perform periodic verifications that the peer is still available at the locator, instead of just one check when the new locator is received ⏰
a third way that a multihoming solution might address this is to make sure B will only accept locators that can be authenticated as synonymous with the original correspondent 🫶 it must be possible to securely ensure that these locators form an equivalence class. so in the first example, not only does X need to assert that it is A, but A needs to assert that it is X 🤯
4.4. Accepting Packets from Unknown Locators 🚪
the multihoming solution space doesn't only affect the destination of packets, it also raises the question of which sources packets should be accepted from 🤔 it's possible to build a multihoming solution that lets traffic be recognized as coming from the same peer, even if there's a previously unknown locator in the source address field. the real question is whether we want to let packets from unverified sources get passed on to transport and application layer protocols 👀
in the current Internet, an attacker can't inject packets with arbitrary source addresses into a session if ingress filtering is present, so allowing packets with unverified sources in a multihoming solution would fail our "no worse than what we have now" litmus test 🧪 however, ingress filtering deployment is far from universal, and it typically wouldn't prevent spoofing of addresses in the same subnet, so requiring rejection of packets from unverified locators might be too stringent 😤
an example of the current state is the ability to inject RST packets into existing TCP connections 💥 when there's no ingress filtering in the network, the TCP endpoints need to sort that out themselves. however, deploying ingress filtering helps in today's Internet, since an attacker is limited in the set of source addresses it can use 🛡️
a factor to take into account when figuring out the "requirement level" for this is that when IPsec is used on top of the multihoming solution, IPsec will reject such spoofed packets 🔒 (note that this is different from the redirection attack cases, where even with IPsec an attacker could potentially cause a DoS attack 🙃)
there might also be a middle ground where arbitrary attackers are prevented from injecting packets by using the SCTP verification tag type of approach [SCTP] 🎟️ (this is a clear-text tag which is sent to the peer, which the peer is expected to include in each subsequent packet.) such an approach doesn't prevent packet injection from on-path attackers (since they can observe the verification tag), but neither does ingress filtering 👀
4.5. New Privacy Considerations 🪪
while introducing identifiers can be really helpful, since they provide ways to identify hosts across events where their IP address(es) might change, there's a risk that these mechanisms get abused to track the identity of the host over long periods of time 😬 whether that's using the same (set of) ISP(s) or moving between different network attachment points. designers of multihoming solutions need to be aware of this concern 🧐
introducing the multihoming capability inherently means the communicating peers need to know multiple locators for each other, so they can be resilient to failures of some paths/locators 🛤️ and if the multihoming signaling protocol doesn't provide privacy, it might be possible for 3rd parties on the path to discover many or all the locators assigned to a host 😰 which would increase the privacy exposure compared to a multihomed host today 💔
for instance, a solution could address this by allowing each host to have multiple identifiers at the same time, and perhaps even changing the set of identifiers that are used over time 🦋 such an approach could be analogous to what is done for IPv6 addresses in [RFC3041] ✨
5. Granularity of Redirection 🔍
different multihoming solutions might approach the problem at different layers in the protocol stack 🥞 for instance, there have been proposals for a shim layer inside IP, as well as transport layer approaches 🧩 the former would have the capability to redirect an IP address, while the latter might be constrained to only redirect a single transport connection 🎯 this difference might be important when it comes to understanding the security impact 💭
for instance, premeditated attacks might have quite different impact in the two cases. in an IP-based multihoming solution, a successful premeditated redirection could be due to the attacker connecting to a server and claiming to be 'A', which would result in the server retaining some state about 'A', which it received from the attacker 😈 later, when the real 'A' tries to connect to the server, the existence of this state might mean that 'A' fails to communicate, or that its packets are sent to the attacker 💀 but if the same scenario is applied to a transport-layer approach, the state created due to the attacker would perhaps be limited to the existing transport connection 🙌 so while this might prevent the real 'A' from connecting to the server while the attacker is connected (if they happen to use the same transport port number), most likely it would not affect 'A's ability to connect after the attacker has disconnected ✨
a particular aspect of the granularity question is the direction question 🧭 will the created state be used for communication in the reverse direction of the one it was created for? for instance, if the attacker 'X' suspects that 'A' will connect to 'B' in the near future, can X connect to A and claim to be B, and then have that later make A connect to the attacker instead of to the real B? 😱
note that transport layer approaches are limited to the set of "transport" protocols that the implementation makes aware of multihoming 📦 in many cases there would be "transport" protocols that are unknown to the multihoming capability of the system, such as applications built on top of UDP 🤷♀️ to understand the impact of the granularity question on security, one would also need to understand how such applications/protocols would be handled 🧠
a property of transport granularity is that the amount of work performed by a legitimate host is proportional to the number of transport connections it creates that use the multihoming support, since each such connection would require some multihoming signaling 📈 and the same is true for the attacker 😤 this means an attacker could presumably do a premeditated attack for all TCP connections to port 80 from A to B, by setting up 65,536 (for all TCP source port numbers) connections to server B and causing B to think those connections should be directed to the attacker, and keeping those TCP connections open 😭 any attempt to make legitimate communication more efficient (e.g., by being able to signal for multiple transport connections at a time) would provide as much relative benefit for an attacker as for the legitimate hosts 💅
the issue isn't only about the space (granularity), but also about the lifetime component in the results of a multihoming request ⏳ in a transport-layer approach, the multihoming state would presumably be destroyed when the transport state is deleted as part of closing the connection 🗑️ but an IP-layer approach would have to rely on some timeout or garbage collection mechanisms, perhaps combined with some new explicit signaling, to remove the multihoming state 🫠 the coupling between the connection state and multihoming state in the transport-layer approach might make it more expensive for the attacker, since it needs to keep the connections open 💰
in summary, there are issues we don't yet understand well about granularity and reuse of the multihoming state 🌈✨
6. Movement Implications? ✨
okay so when nothing moves around, we kinda know what the security needs are 🧚 Something sitting on the path can be a MITM on today's Internet, and a multihoming solution doesn't have to make that any more secure. not its job 💅
but ngl it gets way trickier when hosts are moving around 😭 like, a host might be on the path for a tiny moment because it drove past an 802.11 hotspot. so the question is: would we be worried if that drive-by (lots of people call it a "time-shifting" attack) let the temporarily on-path host act as a MITM for future communication? 👀 depending on the solution, that could actually happen if the attacker gets a multihoming state created in various peer hosts while they're on the path, and that state just hangs around in the peers for a while 💀
the answer isn't obvious even without any new multihoming support, honestly. we don't have much experience with hosts that are moving around and able to attack things while they move. Mobile IPv6 [MIPv6] took a conservative approach here: it limits the effect of drive-by attacks to the maximum lifetime of the binding, which is set to a few minutes ⏱️ very sensible, very iconic
with multihoming support it gets even more complicated, because we explicitly want a host to be present at multiple locators at the same time 🦋 so there might be a need to tell apart two things: a host moving between different locators, and a host sending packets with different source locators because it's present at multiple locators with no topological movement at all. different vibes, different rules 🌈
also, the multihoming solutions that have been discussed range from drive-by attacks being impossible (for instance, because of a strong binding to a separate identifier, as in HIP, or because of relying on the relative security of the DNS for forward plus reverse lookups, as in NOID) 🔐 all the way to first-come/first-serve systems (WIMP is an example with a separate ID space, and a MAST approach with a PBK is an example without a separate ID space). those first-come/first-serve ones let the first host that uses an ID/address claim it with no time limit at all 😳 that's a big ol' yikes 💀
7. Other Security Concerns 🎀
the protocol mechanisms added as part of a multihoming solution shouldn't introduce any new DoS in the mechanisms themselves 🛡️ and in particular, we need to be really careful not to:
- create state on the first packet in an exchange, since that could result in state consumption attacks similar to the TCP SYN flooding attack 😤
- do much work on the first packet in an exchange (like expensive verification) 🥵
there's kind of a chicken-and-egg situation here 🐣 because you'd ideally avoid doing work or creating state until the peer has been verified, but verification will probably need some state and some work to happen first. avoiding all work doesn't seem possible, but good protocol design can often delay state creation until verification is complete ✨ that's the move
one approach solutions might look into is to defer verification until there appears to be two different hosts (or two different locators for the same host) that want to use the same identifier. in that case, you'd need to check whether a combo of impersonation and DoS attack could be used to stop the impersonation from being discovered 🕵️♀️ scandalous, I know
another possible approach is to establish communications first, and then do the verification in parallel with normal data transfers. redirection would only be permitted once verification was complete, but before that point, data could move in a normal, non-multihomed way 🍓 low-key genius
finally, the new protocol mechanisms should be protected against spoofed packets (at least from off-path sources) and replayed packets 🔒 non-negotiable, bestie
8. Security Considerations 💀
in section 3, the document covered existing protocol-based redirection attacks. but there are also non-protocol redirection attacks 🙈 an attacker who can get physical access to any of these can redirect packets too:
- the copper/fiber somewhere in the path,
- a router or L2 device in the path, or
- one of the end systems
this could be possible through things like physical break-ins or bribing staff who have access to the physical infrastructure 😬 those attacks are out of scope for this discussion, but they're worth keeping in mind when you're figuring out what it costs an attacker to pull off any protocol-based attack against multihoming solutions. making protocol-based attacks way more expensive than break-ins/bribery might be overkill 🤷♀️ (main character energy, but make it realistic)
9. Acknowledgements 🫶
this document was originally produced by a MULTI6 design team made up of (in alphabetical order): Iljitsch van Beijnum, Steve Bellovin, Brian Carpenter, Mike O'Dell, Sean Doran, Dave Katz, Tony Li, Erik Nordmark, and Pekka Savola. iconic squad 👑
much of the awareness of these threats came from the work on Mobile IPv6 [MIPv6, NIKANDER03, AURA02] 💜
as the document evolved, MULTI6 WG participants kept contributing. in particular: Masataka Ohta brought up privacy concerns related to stable identifiers 🌸 the suggestion to discuss transport versus IP granularity came from Marcelo Bagnulo, who also contributed text to Appendix B 🦋 and many editorial clarifications came from Jari Arkko ✨
10. Informative References 📚
[NSRG]Lear, E. and R. Droms, "What's In A Name: Thoughts from the NSRG", Work in Progress, September 2003.[MIPv6]Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.[AURA02]Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", Work in Progress, March 2002.[NIKANDER03]Nikander, P., T. Aura, J. Arkko, G. Montenegro, and E. Nordmark, "Mobile IP version 6 Route Optimization Security Design Background", Work in Progress, December 2003.[PAXSON01]V. Paxson, "An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks", Computer Communication Review 31(3), July 2001.[INGRESS]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.[SCTP]Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.[RFC3041]Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.[DNS-THREATS]Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.[FYI18]Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996.[ECN]Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.[OWNER]Nikander, P., "Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World", Security Protocols 9th International Workshop, Cambridge, UK, April 25-27 2001, LNCS 2467, pages 12-26, Springer, 2002.[RFC1948]Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.[PBK]Scott Bradner, Allison Mankin, Jeffrey Schiller, "A Framework for Purpose-Built Keys (PBK)", Work in Progress, June 2003.[NOID]Erik Nordmark, "Multihoming without IP Identifiers", Work in Progress, July 2004.[HIP]Pekka Nikander, "Considerations on HIP based IPv6 multi-homing", Work in Progress, July 2004.[WIMP]Jukka Ylitalo, "Weak Identifier Multihoming Protocol (WIMP)", Work in Progress, June 2004.[CBHI]Iljitsch van Beijnum, "Crypto Based Host Identifiers", Work in Progress, February 2004.[TCPSECURE]M. Dalal (ed), "Transmission Control Protocol security considerations", Work in Progress, November 2004.
Appendix A: Some Security Analysis 🕵️♀️✨
okay so bestie, let's talk about the threats. when you look at the multihoming proposals next to all those threats, there seem to be two separate things you have to handle for redirection:
- Redirection of existing communication 💌
- Redirection of an identity before any communication 🪪
that split exists because identifiers get used in two different ways. the first way is for:
- Initially establishing communication, like looking up an FQDN to find something that gets passed to a connect() or sendto() API call 📞
- Comparing whether a peer entity is the same peer entity as in some previous communication 👯
- Using the identity of the peer for future communication ("callbacks") in the reverse direction, or to refer to a 3rd party ("referrals") 🔁
the second way is being able to redirect existing communication so it uses a different locator. ngl this is giving two completely different vibes 💅
the first class seems to be about who owns the identifier. proving the "ownership" of the identifier should be enough to be authorized to control which locators get used to reach it 👑
the second class is more ephemeral. to redirect existing communication to some other locator, it seems like it's enough to prove the entity is the same one that started the communication. you can think of this as proving you own some context, and that context gets set up around the time the communication starts 🦋
now, preventing unauthorized redirection of existing communication can be handled by a whole bunch of approaches. they're all based on setting up some kind of security material at the start of communication, and then later using that material's existence so one end can prove to the other that it's still the same. an example is Purpose Built Keys [PBK]. you can imagine different versions of these schemes with different complexity, performance, and security, like an anonymous Diffie-Hellman exchange, the reverse hash chains presented in [WIMP], or even a clear-text token exchanged at the initial communication 🔐
BUT the mechanisms for stopping unauthorized use of an identifier can be super different 🙈
one way to stop premeditated redirection is to just not introduce a new identifier name space 🙅♀️. instead you rely on existing name space(s), a trusted third party, and a sufficiently secure way to access that third party, as in [NOID]. this approach leans on the third party (DNS in the case of NOID) as its foundation. in terms of multihoming state creation, premeditated redirection in this case is as easy or as hard as redirecting an IP address today. basically it depends on the return-routability check that comes with a roundtrip of communication, which verifies that the routing system delivers packets to the IP address in question 🛣️
another option is crypto-based identifiers, like [HIP] or crypto-generated addresses as in [CBHI]. both of these rely on public-key crypto to prevent premeditated attacks 🔑✨. sometimes you can also dodge the problem by having one end use ephemeral identifiers, the way the initiator does in [WIMP]. this avoids premeditated redirection by detecting that some other entity is using the same identifier at the peer, and then switching to a different ephemeral ID 🦎. ephemeral identifiers can be a bit of a headache for applications, for instance because of callbacks or referrals. but for the end that has the ephemeral identifier, you can skirt around premeditated attacks (assuming the solution has a robust way to pick a new identifier when one is already in use or stolen) 🧚
⚠️ bestie, watch out: the security analysis above only holds if the solution really does have that robust way to pick a new identifier when one is in use or stolen.
okay, so assuming the problem can't be skirted by using ephemeral identifiers, there seem to be 3 types of approaches for establishing some form of identity ownership 🧐:
- A trusted third party, which states that a given identity is reachable at a given set of locators, so the endpoint reached at one of these locators is the owner of the identity 🏛️
- Crypto-based identifiers or crypto-generated addresses, where the public/private key pair can be used to prove that the identifier was generated by the node knowing the private key (or by another node whose public key hashes to the same value) 🗝️
- A static binding, as currently defined in IP. here you trust that the routing system will deliver packets to the owner of the locator, and since the locator and the identity are one and the same, you prove identity ownership as a sub-product 🎀
a solution would need to combine elements that protect against both premeditated and ongoing communication redirection 🧩. this can be done in several ways, and the current set of proposals doesn't seem to contain every useful combination. for instance, the HIP CBID property could be used to prevent premeditated attacks, while the WIMP hash chains could be used to prevent ongoing redirection. and there are probably other interesting combinations too 🌈
a related, but maybe separate, question is whether the solution protects against man-in-the-middle attacks by on-path attackers. some schemes, such as [HIP] and [NOID], do. BUT given that an on-path attacker can see and modify the data traffic whether or not it can modify the multihoming signaling, this level of protection seems like overkill 🙄. protecting the data traffic against on-path MITM can be done separately, using IPsec, TLS, etc. 🔒
finally, preventing third party DoS attacks is conceptually simpler 💖. it would be enough to somehow verify that the peer is actually reachable at the new locator before sending a large number of packets to that locator 📦🚫
just like redirection attacks are conceptually prevented by proving, at some level, the ownership of the identifier or the ownership of the communication context, third party DoS attacks are conceptually prevented by showing that the endpoint is authorized to use a given locator 🫶
the currently known approaches for showing that kind of authorization are:
- Return routability. that is, if an endpoint is capable of receiving packets at a given locator, it's because it is authorized to do so. this relies on routing being reasonably hard to subvert to deliver packets to the wrong place. while this might be the case when routing protocols are used with reasonable security mechanisms and practices, it isn't the case on a single link, where ARP and Neighbor Discovery can be easily spoofed 😱
- Trusted third party. a third party establishes that a given identity is authorized to use a given set of locators (for instance, the DNS) 📖
Authors' Addresses 💌
Erik Nordmark
Sun Microsystems, Inc.
17 Network Circle
Mountain View, CA 94025
USA
Phone: +1 650 786 2921
Fax: +1 650 786 5896
EMail: erik.nordmark@sun.com
Tony Li
EMail: Tony.Li@tony.liFull Copyright Statement 📜
Copyright (C) The Internet Society (2005).
this document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights 💜.
this document and the information contained herein are provided on an "AS IS" basis. the disclaimer itself is kind of intense, so here it is word for word:
THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🧾
the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on the extent to which any license under such rights might or might not be available. it also doesn't claim to have made any independent effort to identify any such rights. info about the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📚.
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr 🔗.
the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. please send that information to the IETF at ietf-ipr@ietf.org 📬.
Acknowledgement 🎉
funding for the RFC Editor function is currently provided by the Internet Society 🌸
📦 where this page comes from
- ietf: rfc4218 2005-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms