RFC 5221

RFC 5221: Requirements for Address Selection Mechanisms 🎀

Okay bestie, this is RFC 5221 (Part 1 of 2) 💖 It's from the Network Working Group, it's Informational, and it's dated July 2008. The authors are A. Matsumoto (NTT), T. Fujisaki (NTT), R. Hiromi (Intec Netcore), and K. Kanayama (INTEC Systems). The title block doesn't list any RFC that it obsoletes or updates, so it stands on its own 🦋

Status of This Memo ✨

This memo gives information to the Internet community. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🌸

Abstract 💜

Okay so, the default address selection mechanism that RFC 3484 defines has some problematic cases, and it's giving communication failure 😭 This document lays out extra requirements that work alongside RFC 3484 to fix those problems 🔥

Table of Contents 🧚

   1. Introduction ....................................................2
   2. Requirements of Address Selection ...............................2
      2.1. Effectiveness ..............................................2
      2.2. Timing .....................................................2
      2.3. Dynamic Behavior Update ....................................3
      2.4. Node-Specific Behavior .....................................3
      2.5. Application-Specific Behavior ..............................3
      2.6. Multiple Interface .........................................3
      2.7. Central Control ............................................3
      2.8. Next-Hop Selection .........................................3
      2.9. Compatibility with RFC 3493 ................................4
      2.10. Compatibility and Interoperability with RFC 3484 ..........4
      2.11. Security ..................................................4
   3. Security Considerations .........................................4
      3.1. List of Threats Introduced by New Address-Selection
           Mechanism ..................................................4
      3.2. List of Recommendations in Which Security Mechanism
           Should Be Applied ..........................................5
   4. Normative References ............................................5

1. Introduction 🍓

RFC 3484 [RFC3484] is widely implemented in major OSs now, which is iconic 👑 But at a lot of sites the default address-selection rules aren't appropriate, and they cause a communication failure 💀 The problem statement (PS) document [RFC5220] lists the problematic cases that come from incorrect address selection.

RFC 3484 made the address-selection behavior of a host configurable, but typical users can't really use that 🙈 It's too complex, and most people don't know their network topologies. So an address-selection autoconfiguration mechanism is necessary, especially for unmanaged hosts of typical users. Main character energy for the autoconfig 🫶

This document has requirements for address-selection mechanisms that let hosts do appropriate address selection automatically ✨

2. Requirements of Address Selection 💅

Address-selection mechanisms have to fulfill the following eleven requirements. Eleven! Let's go 🔥

2.1. Effectiveness 🌈

The mechanism can modify RFC 3484 default address-selection behavior at nodes. As documented in the PS [RFC5220], the default rules defined in RFC 3484 don't work properly in some environments. So the mechanism has to be able to modify the address-selection behavior of a host and solve the problematic cases described in the PS document. Solve it, bestie 💖

2.2. Timing ⏰

Nodes can perform appropriate address selection when they select addresses.

If nodes need address-selection information to do appropriate address selection, then the mechanism has to provide a function for nodes to get the necessary information beforehand.

The mechanism should not degrade usability, and it should not enforce long address-selection processing time upon users. Forcing every consumer user to manipulate the address-selection policy table is usually not an acceptable solution, so in this case some kind of autoconfiguration mechanism is desirable 🎀

2.3. Dynamic Behavior Update 🦋

The address-selection behavior of nodes can be dynamically updated. When the network structure changes and the address-selection behavior has to change accordingly, a network administrator can modify the address-selection behavior of nodes ✨

2.4. Node-Specific Behavior 🧚

The mechanism can support node-specific address-selection behavior. Even when multiple nodes are on the same subnet, the mechanism should be able to give a method for the network administrator to make nodes behave differently. For example, each node may have a different set of assigned prefixes. In that case, the appropriate address-selection behavior may be different 🌸

2.5. Application-Specific Behavior 💜

The mechanism can support application-specific address-selection behavior, or it can be combined with an application-specific address-selection mechanism such as address-selection APIs 🍓

2.6. Multiple Interface 👑

The mechanism can support nodes equipped with multiple interfaces. It has to assume that nodes have multiple interfaces and make address selection work appropriately for them 💅

2.7. Central Control 🫶

The address-selection behavior of nodes can be centrally controlled. A site administrator or a service provider could determine, or have an effect on, the address-selection behavior at their users' hosts 🔥

2.8. Next-Hop Selection 🦋

The mechanism can control next-hop-selection behavior at hosts, or cooperate with other routing mechanisms such as routing protocols and RFC 4191 [RFC4191]. If the address-selection mechanism is used with a routing mechanism, the two mechanisms have to be able to work synchronously. They need to be in sync, no cap 💖

2.9. Compatibility with RFC 3493 🌈

The mechanism can allow an application that uses the basic socket interface defined in RFC 3493 [RFC3493] to work correctly. That means that with the basic socket interface, the application can select appropriate source and destination addresses and communicate with the destination host ✨ This requirement doesn't necessarily mean that OS protocol stack and socket libraries shouldn't be changed 🎀

2.10. Compatibility and Interoperability with RFC 3484 🌸

The mechanism is compatible with RFC 3484. RFC 3484 is widely implemented now, so it's preferable that a new address-selection mechanism doesn't conflict with the address-selection mechanisms defined in RFC 3484 🧚

If the solution mechanism changes or replaces the address-selection mechanism defined in RFC 3484, interoperability has to be retained. That means a host with the new solution mechanism and a host with the mechanism of RFC 3484 have to be interoperable. Both hosts need to get along, bestie 🫶

2.11. Security 💀

The mechanism works without any security problems. Possible security threats are described in the Security Considerations section of this document 🙈

3. Security Considerations 💀

This section is serious, so bestie, pay attention 😭 Security considerations keep their full weight here.

3.1. List of Threats Introduced by New Address-Selection Mechanism 🚨

There will be some security incidents when the requirements described in Section 2 are combined into a protocol. In particular, there are 3 types of threats: leakage, hijacking, and denial of service.

1. Leakage: Malicious nodes may tap in to collect the network policy information and leak it to unauthorized parties.
2. Hijacking: Nodes may be hijacked by malicious injection of illegitimate policy information. RFC 3484 defines both a source and destination selection algorithm. An attacker able to inject malicious policy information could redirect packets sent by a victim node to an intentionally chosen server that would scan the victim node's activities to find vulnerable code. Once vulnerable code is found, the attacker can take control of the victim node. This is the scariest one, no cap 😱
3. Denial of Service: This is an attack on the ability of nodes to communicate in the absence of the address-selection policy. An attacker could launch a flooding attack on the controller to stop it from delivering the address-selection policy information to nodes, which would stop those nodes from communicating appropriately 💔

3.2. List of Recommendations in Which Security Mechanism Should Be Applied 🛡️

The address-selection mechanism should be given the security services listed below. It's preferable that these security services are provided through existing protocols, such as IPsec (e.g., IPsec) 🔐

1. Integrity of the network policy information itself and of the messages exchanged in the protocol. This is a countermeasure against leakage, hijacking, and denial of service 💖
2. Authentication and authorization of the parties involved in the protocol. This is a countermeasure against Leakage and Hijacking 🫶

Intellectual Property ✨

okay so this section is the IETF being super clear that it's not taking a side on IP stuff 💅 🫶 It takes no position on whether any Intellectual Property Rights (or other rights) that someone might claim over the tech in this doc are valid or how far they reach. It also doesn't say whether licenses for those rights exist or are available, and it doesn't claim it went looking for any of them either 🙈 If you want the rules on how rights work for RFC documents, check out BCP 78 and BCP 79 📜

Next, bestie, if you want copies of IPR disclosures that were sent to the IETF Secretariat, or any assurances that licenses will be available, or the results of anyone trying to get a general license or permission to use those proprietary rights as an implementer or user of this spec, you can find it all in the IETF online IPR repository at http://www.ietf.org/ipr 🔍✨

And the IETF is literally asking everyone 🙋‍♀️ If you know of any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard, please let them know. Send it to ietf-ipr@ietf.org 💌 It's giving "we want to hear from you" energy 🦋