RFC 4449

RFC 4449: Securing Mobile IPv6 Route Optimization Using a Static Shared Key ✨

Okay bestie, this one is by Charles E. Perkins from Nokia Research Center, and it's a Standards Track doc from June 2006 💖 It's all about locking down Mobile IPv6 route optimization with a static shared key, so it's basically a cheaper, faster security option. 🦋

---

Status of This Memo 📋

This document specifies an Internet standards track protocol for the Internet community, and it literally asks for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Copyright Notice ©️

Copyright (C) The Internet Society (2006). 💜

Abstract 🧚

A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates. Basically they set up some info ahead of time so they can whip up a key later and use it to approve Binding Updates ✨

Table of Contents 💅

1. Introduction ....................................................1
2. Applicability Statement .........................................2
3. Precomputing a Binding Management Key (Kbm) .....................3
4. Security Considerations .........................................4
5. Acknowledgement .................................................5
6. References ......................................................5
   6.1. Normative References .......................................5
   6.2. Informative References .....................................6

---

1. Introduction 🌸

Okay so this spec brings in a low-latency security option for protecting the signaling behind route optimization in Mobile IPv6 🦋 The default mechanism from [1] runs a periodic return routability test to check two things: that the mobile node is actually allowed to use a specific home address, and that the care-of address it claims is legit. That default needs zero configuration and no trusted entities beyond the mobile node's home agent, which is honestly very chill 😭

The mechanism in this document is different, though. It needs a shared secret set up between the mobile node and its correspondent node 🔑 Because of that, the messages for the routability tests can be skipped, and the latency drops a LOT. The right to use a specific home address is also guaranteed in a stronger way than in [1] ✨ The catch is that it's only useful where you can do that preconfiguration, and it's only safe where the mobile nodes can be trusted not to misbehave, since the claimed care-of addresses never get verified 💀

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. Everything else uses terms already defined in [1] 🧚

2. Applicability Statement 💖

This mechanism is useful when all of these conditions are met 🎀

• The mobile node and the correspondent node are administered within the same domain.
• The correspondent node has good reason to trust the mobile node's actions. Specifically, it needs to be certain the mobile node won't launch flooding attacks against a third party, as described in [5] 😳
• The configuration effort is acceptable. Users MUST be able to generate or select a sufficiently good value for Kcn (see [3]) 🔐
• There's a desire to get higher efficiency or greater assurance about the correctness of the home address offered through this mechanism ⭐
• This mechanism is only used for authenticating Binding Update messages (and not, e.g., data), so the total traffic volume stays low (see RFC 4107 [4], and the discussion in section 4) 🍓

This mechanism can also be useful for software development, testing, and diagnostics related to mobility signaling 🧪

Generally speaking, the trust level the correspondent node needs before it enables a precomputable Kbm with a mobile node is usually found in relatively small, closed groups of users who personally know each other, or who have some outside basis for trustworthy interactions 🫶 A typical example is inside a corporation or between specific users. It's typically NOT possible in the general Internet, because manually configuring the correspondent nodes takes way too much effort 😩 It's also typically not possible at a public network operator, because of the trustworthiness requirements placed on mobile nodes 🙈

3. Precomputing a Binding Management Key (Kbm) 🔮

Okay, so a mobile node and a correspondent node may preconfigure data useful for creating a Binding Management Key (Kbm). That key can then be used to authorize binding management messages, especially Binding Update and Binding Acknowledgement messages ✨ The data is:

• A shared key (Kcn) used to generate keygen tokens, at least 20 octets long 🗝️
• A nonce for use when generating the care-of keygen token 🌙
• A nonce for use when generating the home keygen token 🌙

The keygen tokens MUST be generated from Kcn and the nonces, as specified in the Mobile IPv6 [1] return routability procedure 💅 Likewise, the binding management key Kbm must then be generated from the keygen tokens in the same way as specified in Mobile IPv6 [1] 🦋 The preconfigured data is tied to the mobile node's home address. Kcn MUST be generated with sufficient randomness (see RFC 4086 [3]) 🎲

Replay protection for Binding Update messages using a Kbm computed from the preconfigured data depends on the value of the Sequence Number field in the Binding Update 🔁 If the correspondent node doesn't keep info about the recently used values of that field, a malicious node could replay old Binding Update messages and trick the correspondent node into routing toward an old care-of address 😱 That's why a correspondent node using a precomputable Kbm also MUST keep track of the most recent value of the Sequence Number field of Binding Update messages using that precomputable Kbm value. For example, it can commit it to stable storage 💾

Replay protection is literally the whole ballgame here, so don't skip the sequence number tracking. 🚨

When a Binding Update is going to be authenticated using such a precomputable binding key (Kbm), the Binding Authorization Data suboption MUST be present 🎀 The Nonce Indices option SHOULD NOT be present. If it IS present, the nonce indices supplied SHOULD be ignored, and they are NOT included in the calculation for the authentication data, which is performed exactly as specified in [1] 🧚

---

(Part 1 of 2! Section 4 and everything after it are coming up in part 2 🫶)

Full Copyright Statement 🎀

Copyright (C) The Internet Society (2006) 💖

This doc is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights 🦋

The doc and everything in it are handed over "AS IS" 🫶 The contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the IETF all say NO to warranties, express or implied 🙅‍♀️ That includes no promise that using the info won't infringe anyone's rights, and no implied warranties of merchantability or fitness for a particular purpose 💀

Intellectual Property ✨

Okay so the IETF is not picking a side on whether any Intellectual Property Rights (or other rights) that might be claimed around the tech in this doc are valid, how far they reach, or whether any license for them is even available 🌸 They also aren't saying they've done any independent digging to find those rights 🕵️‍♀️ If you want the procedures for rights in RFC docs, check BCP 78 and BCP 79 📚

Copies of IPR disclosures sent to the IETF Secretariat 💌 and any assurances of licenses that might be available 🎟️ or the results of any attempt to get a general license or permission for implementers or users to use those proprietary rights for this spec can all be grabbed from the IETF's online IPR repository at http://www.ietf.org/ipr 🧚

The IETF invites anyone interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard 🔥 Send that info to the IETF at ietf-ipr@ietf.org 💜

Acknowledgement

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 🫶✨