RFC 3374

🎀 RFC 3374: Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network ✨

Okay bestie, so this is RFC 3374 💖 It came out in September 2002 and it's marked as Informational, which means it's sharing info with the Internet community and not setting a standard 🫶 The main author is J. Kempf, Ed., and it's from the Network Working Group 💅 The title block doesn't list anything it obsoletes or updates, so it isn't replacing or changing any other RFCs 🌸

Status of this Memo 📜

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🦋

Copyright Notice ©️

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🌈

Okay so in IP access networks that support host mobility, the routing paths between the host and the network may change frequently and rapidly 🏃‍♀️ Sometimes the host may set up certain context transfer candidate services on subnets that get left behind when the host moves. Some examples are Authentication, Authorization, and Accounting (AAA), header compression, and Quality of Service (QoS) 💀

Here's the tea: for the host to get those services on the new subnet, the host must explicitly re-establish each service by running the necessary signaling flows from scratch. Sometimes that would seriously slow down how fast the mobile host gets set up on the new subnet 😭 The alternative is to move the information about the existing state of these services, or context, over to the new subnet. That's called "context transfer" ✨ This document talks about why context transfer is so desirable for making IP mobility feel seamless 🫶

Table of Contents 📚

1.0   Introduction................................................2
2.0   Reference Definitions.......................................3
3.0   Scope of the Context Transfer Problem.......................3
4.0   The Need for Context Transfer...............................4
4.1   Fast Context Transfer-candidate Service Re-establishment....4
4.1.1 Authentication, Authorization, and Accounting (AAA).........4
4.1.2 Header Compression..........................................5
4.1.3 Quality of Service (QoS)....................................6
4.2   Interoperability............................................6
5.0   Limitations on Context Transfer.............................7
5.1   Router Compatibility........................................7
5.2   Requirement to Re-initialize Service from Scratch...........7
5.3   Suitability for the Particular Service......................7
5.4   Layer 2 Solutions Better....................................7
6.0   Performance Considerations..................................8
7.0   Security Considerations.....................................8
8.0   Recommendations.............................................9
9.0   Acknowledgements............................................9
10.0  References.................................................10
11.0  Complete List of Authors' Addresses........................12
12.0  Full Copyright Statement...................................14

1.0 Introduction 🌷

Okay so in networks with mobile hosts, the routing path through the network often has to change so the host's IP traffic can reach its new point of access 🛣️ Changing the basic routing path is the job of an IP mobility protocol, like Mobile IPv4 [1] and Mobile IPv6 [2]. But real time services like VoIP telephony, video, etc. in a mobile environment really depend on keeping the impact of this traffic redirection as small as possible 📞 While the new routing path is being set up, the nodes along that new path have to be ready to give the IP packets similar routing treatment to what they got on the old path. It's giving "no interruptions" energy 🎀

In a lot of cases, how a network routes a host's IP packets is controlled by a bunch of context transfer candidate services that shape how the host's packets get treated 👑 For example, whether a host is allowed to get any routing at all out of its local subnet might depend on whether it successfully did an AAA exchange with a network access server at some point in the past 🔐 Setting these services up the first time creates a certain amount of related state in the network, and it can take a pretty big chunk of time for the protocol exchanges. If the host has to re-establish those services the same way it set them up the first time, delay-sensitive real time traffic may get seriously messed up 😬

So the alternative is to transfer enough information about the context transfer candidate service state, or context, to the new subnet, so the services can be re-established quickly instead of making the mobile host set them up from scratch ⚡ Transferring service context may be really helpful for keeping the impact of host mobility low on things like AAA, header compression, QoS, policy, and possibly sub-IP protocols and services such as PPP 🧚 At a minimum, context transfer can be used to copy the configuration information needed to set up the respective protocols and services. On top of that, it may also be able to copy state information, which lets stateful protocols and services at the new node turn on along the new path with less delay and less signaling overhead 💅

In this document, a case is made for why the Seamoby Working Group should look into context transfer 🔥

2.0 Reference Definitions 📖

Context

The information on the current state of a service required to re-establish the service on a new subnet without having to perform the entire protocol exchange with the mobile host from scratch.

Context Transfer

The movement of context from one router or other network entity to another as a means of re-establishing specific services on a new subnet or collection of subnets.

Context Transfer Candidate Service

A service that is a candidate for context transfer. In this document, only services that are concerned with the forwarding treatment of packets, such as QoS and security, or involve granting or denying the mobile host access to the network, such as AAA, are considered to be context transfer candidate services.

3.0 Scope of the Context Transfer Problem 🔍

Okay so this document is only looking at re-establishing services for a mobile host that are, in some sense, related to how the host's packets get forwarded or whether the host can get network access 🦋 It's not about actually re-establishing routing information. Routing changes caused by mobility are the domain of the IP mobility protocol. Also, transferring context for application-level services, like the ones tied to the mobile host's HTTP proxy, is not covered in this document 🙈 That said, a generic context transfer protocol for moving the context of services related to forwarding treatment or network access may also work for application-level services as well ✨

Here's the key question for whether a service is a context transfer candidate: can you get a "correct" context transfer for that service in a given implementation and deployment? Correct means you end up with the same context at the new access router as you would have gotten if the mobile host had gone through a protocol exchange with the access router from scratch 💖 For some services, the situations where context transfer can lead to correctness might be super limited [11] 💀

4.0 The Need for Context Transfer 💜

There are two basic motivations for context transfer:

1. The primary motivation, as mentioned in the introduction, is the need to quickly re-establish context transfer candidate services without making the mobile host explicitly run all the protocol flows for those services from scratch 🏎️
2. An additional motivation is to provide an interoperable solution that works for any Layer 2 radio access technology 🌍

These points get more detail in the following subsections.

4.1 Fast Context Transfer-candidate Service Re-establishment ⚡

As mentioned in the introduction, there are a bunch of context transfer candidate services that could use a context transfer solution 🌟 In this section, three representative services get a look. The consequences of not having a context transfer solution are examined, to show why we need one 🫶

4.1.1 Authentication, Authorization, and Accounting (AAA) 🔐

One of the most compelling uses of context transfer is making it easier to re-authenticate the mobile host and re-establish its authorization for network access on a new subnet 🎀 You do this by transferring the AAA context from the mobile host's previous AAA server to another one. That way the mobile host can keep its access on the new subnet without having to redo an AAA exchange with the new subnet's AAA server 🙌 Naturally, a security association between the AAA servers is necessary so the mobile host's sensitive authentication information can be transferred securely 🔒

Without context transfer, there are two ways that can currently be used for AAA:

1. Layer 2 mechanisms, such as EAP [3] in PPP [4] or 802.1x [5], can be used to redo the initial protocol exchange, or possibly to update it. Right now, there's no general Layer 3 mechanism for running an AAA exchange between a host and an AAA server in the network 😤
2. If the mobile host is using Mobile IPv4 (but not Mobile IPv6 currently), the host can use the AAA registration keys [6] extension for Mobile IPv4 to set up a security association with the new Foreign Agent 🦋

Since 2) is piggybacked on the Mobile IPv4 signaling, the performance is less likely to be an issue, but 2) is not a general solution 🙈 The performance of 1) is likely to be way lower than what's needed to keep good real time stream performance 😭

4.1.2 Header Compression 🗜️

In [7], protocols are described for efficiently compressing IP headers so that big headers don't have to get sent over low bandwidth radio network links 📡 Setting up header compression usually takes 1 to 4 exchanges between the last hop router and the mobile host, using full or partially compressed headers, before full compression is available 🌀 During that time, the mobile host sees an effective drop in the application-available bandwidth, equal to the uncompressed header information sent over the air 📉 Limiting the uncompressed traffic needed to set up full header compression on a new last hop router helps keep enough application-available bandwidth for real time streams, especially for IPv6 where the headers are bigger 🧚

Context transfer can help here by letting the network entity doing header compression, usually the last hop router, transfer the header compression context to the new router 🫶 The timing has to be arranged so the header context gets transferred from the old router as soon as the mobile host stops receiving packets through the old router, and gets installed on the new router before any packets are delivered to or forwarded from the mobile host 💅✨

4.1.3 Quality of Service (QoS) 💅

okay so QoS is where things get extra 🫶 Significant QoS protocol exchanges between the mobile host and routers in the network may be needed to set up the mobile host's initial QoS treatment for its packets. How that should actually happen is still an active topic of investigation in the IETF 🔍 For the existing QoS approaches (Diffsrv and Intsrv), preliminary studies found that rebuilding QoS from scratch on a new subnet can be sooo time consuming for Mobile IP, and other mobility protocols may struggle too 😭

Transferring the mobile host's QoS context from the old network to the new one could help QoS come back faster on the new subnet ✨ But for end-to-end QoS mechanisms, transferring context at the last hop router may not be enough to fully re-initialize the mobile host's QoS treatment 🧚 Some additional routers along the path between the mobile host and the corresponding node may also need to be involved.

4.2 Interoperability 🦋

A big concern for seamless handover is that different Layer 2 radio protocols may each come up with their own context transfer solutions 💀 There's ongoing work in 3GPP [8] and IEEE [9] to define such solutions. These are mainly designed to move Layer 2-related context over a wired IP network between two radio access networks or two radio access points. The designs can include extensibility features that would let Layer 3 context be transferred too, and [10] is a case in point, for example.

If Layer 2 protocols were widely adopted as an optimization for Layer 3 context transfer, seamless mobility would be hard to achieve for a mobile host with Layer 2 network interfaces that support multiple radio protocols 🥺 Basically, you'd need a gateway or translator between the Layer 2 protocols. Otherwise, if no translator were available, the mobile host would have to fully re-initialize its context transfer-candidate services on the new radio network in order to hand over between two access technologies.

A general Layer 3 context transfer solution may also be useful for Layer 2 protocols that don't define their own context transfer protocol. Looking into that is outside the scope of the Seamoby Working Group, though, since it depends on the details of the particular Layer 2 protocol 📝

5.0 Limitations on Context Transfer 🚧

Context transfer isn't always the best move for re-establishing context transfer-candidate services on a new subnet 🙅 There are some limits on when it's actually useful, and they're covered in the subsections below.

5.1 Router Compatibility 🔌

Context transfer between two routers only works if the receiving router supports the same context transfer-candidate services as the sending router. That doesn't mean the two have to be identical in their implementation, or even have identical capabilities 🤷 A router that can't make use of received context should refuse the transfer. That ends up being no different from a mobile host handover without context transfer, and it shouldn't be treated as an error or failure 💖

5.2 Requirement to Re-initialize Service from Scratch 🔁

The main motivation for context transfer assumes that quickly re-establishing the same level of context transfer-candidate service on the new subnet is what everyone wants. But sometimes the device or the access network would rather re-establish or re-negotiate the level of service 🌈 For example, if the mobile host crosses administrative domains where the operational policies change, negotiating a different level of service may be required.

5.3 Suitability for the Particular Service 🎯

Context transfer assumes it's faster to set up the service by transferring context than by starting from scratch. That might not be true for certain types of service, like multicast or "push" information services 📡

5.4 Layer 2 Solutions Better 🥇

Context transfer is an enhancement meant to improve the handover performance of Layer 3 context transfer-candidate services. Plenty of networks already support handover at Layer 2, within and between subnets. So Layer 3 context transfer may not provide a significant improvement over Layer 2 solutions, even for Layer 3 context, if the handover is happening between two subnets that support the same Layer 2 radio access technology 💅

6.0 Performance Considerations 📈

The whole point of context transfer is to sustain the context transfer-candidate services being provided to a mobile host's traffic during handover 🎀 It's essentially an enhancement to IP mobility, and it ultimately has to result in an improvement in handover performance. A context transfer solution must provide performance that is equal to or better than re-initializing the context transfer-candidate service between the mobile host and the network from scratch. Otherwise, context transfer is of no benefit 💀

7.0 Security Considerations 🔐

Security gets full seriousness here, bestie 🚨 Read this part carefully.

Any context transfer standard must provide a mechanism for adequately securing the context transfer process, and a recommendation to deploy security, as is typically the case for Internet standards. Some general considerations for context transfer security include:

• Information privacy: the context may contain information which the end user or network operator would prefer to keep hidden from unauthorized viewers 🙈
• Transfer legitimacy: a false or purposely corrupted context transfer could have a severe impact upon the operation of the receiving router, and therefore could potentially affect the operation of the access network itself. The potential threats include denial of service and theft of service attacks 😱
• Security preservation: part of the context transfer may include information pertinent to a security association established between the mobile host and another entity on the network. For this security association to be preserved during handover, the transfer of the security context must include the appropriate security measures 🔑

It is expected that the measures used to secure the transport of information between peers (e.g., IPSEC [10]) in an IP network should be sufficient for context transfer. However, given the above considerations, there may be reason to provide for additional security measures beyond the available IETF solutions.

Since context transfer requires a trust relationship between network entities, the compromise of only one of the network entities that transfer context may be sufficient to reduce the security of the whole system, if for example the context transferred includes encryption keying material. When the host moves from the compromised network entity to an uncompromised network entity in the presence of context transfer, the compromised context may be used to decrypt the communication channel. When context transfer is not used, a compromise of only one network entity only gives access to what that network entity can see. When the mobile host moves to an uncompromised network entity in the absence of context transfer, security can be re-established at the new entity. However, to the extent that context transfer happens primarily between routers, the security of context transfer will depend on the security of the routers. Any compromise of security on a router that affects context transfer may also lead to other, equally serious disruptions in network traffic 🧨

The context transfer investigation must identify any novel security measures required for context transfer that exceed the capabilities of the existing or emerging IETF solutions 🕵️

8.0 Recommendations 🗺️

The following steps are recommended for Seamoby:

• Investigation into candidate router-related services for context and an analysis of the transfer requirements for each candidate;
• The development of a framework and protocol(s) that will support the transfer of context between the routing nodes of an IP network.

The context transfer solution must inter-work with existing and emerging IP protocols, in particular, those protocols supporting mobility in an IP network ✨

9.0 Acknowledgements 🫶

The editor would like to thank the Seamoby CT design team (listed at the end of the document as co-authors), who were largely responsible for the initial content of this document, for their hard work. Special shoutout to Gary Kenward, who shepherded the document through its initial versions 👑

10.0 References 📚

[1] Perkins, C., "IP Mobility Support", RFC 3220, January 2002.

[2] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in Progress.

[3] Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.

[4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

[5] IEEE Std. P802.1X/D11, "Standard for Port based Network Access Control", March 2001.

[6] Perkins, C., and P. Calhoun, "AAA Registration Keys for Mobile IP", Work in Progress.

[7] Borman, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L., Hakenberg, R., Koren T., Le, K., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.

[8] 3GPP TR 25.936 V4.0.0, "Handovers for Real Time Services from PS Domain," 3GPP, March 2001.

[9] IEEE Std. 802.11f/D2.0, "Draft Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation," July 2001.

[10] Kent, S. and Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[11] Aboba, B. and M. Moore, "A Model for Context Transfer in IEEE 802", Work in Progress.

11.0 Complete List of Authors' Addresses ✨

okay so this is the squad roster 🫶 every single author's contact info, all in one place, and I'm not gonna skip a single one bestie 💅

O. Henrik Levkowetz 🌸

A Brand New World
Osterogatan 1
S-164 28 Kista
SWEDEN

Phone: +46 8 477 9942
EMail: henrik@levkowetz.com

Pat R. Calhoun 🎀

Black Storm Networks
110 Nortech Parkway
San Jose  CA 95134
USA

Phone: +1 408-941-0500
EMail: pcalhoun@bstormnetworks.com

James Kempf 🦋

NTT DoCoMo USA Laboratories
181 Metro Drive, Suite 300
San Jose, CA 95110
USA

Phone: 408-451-4711
EMail: kempf@docomolabs-usa.com

Gary Kenward 💜

Nortel Networks
3500 Carling Avenue
Nepean, Ontario  K2G 6J8
CANADA

Phone: +1 613-765-1437
EMail: gkenward@nortelnetworks.com

Hamid Syed 🍓

Nortel Networks
100 Constellation Crescent
Nepean  Ontario K2G 6J8
CANADA

Phone: +1 613 763-6553
EMail: hmsyed@nortelnetworks.com

Jukka Manner 🧚

Department of Computer Science
University of Helsinki
P.O. Box 26 (Teollisuuskatu 23)
FIN-00014 Helsinki
FINLAND

Phone: +358-9-191-44210
EMail: jmanner@cs.helsinki.fi

Madjid Nakhjiri 🌈

Motorola
1501 West Shure Drive
Arlington Heights  IL 60004
USA

Phone: +1 847-632-5030
EMail: madjid.nakhjiri@motorola.com

Govind Krishnamurthi ⭐

Communications Systems Laboratory, Nokia Research Center
5 Wayside Road
Burlington  MA 01803
USA

Phone: +1 781 993 3627
EMail: govind.krishnamurthi@nokia.com

Rajeev Koodli 🦋

Communications Systems Lab, Nokia Research Center
313 Fairchild Drive
Mountain View  CA 94043
USA

Phone: +1 650 625 2359
EMail: rajeev.koodli@nokia.com

Kulwinder S. Atwal 🌸

Zucotto Wireless Inc.
Ottawa  Ontario K1P 6E2
CANADA

Phone: +1 613 789 0090
EMail: kulwinder.atwal@zucotto.com

Michael Thomas 💖

Cisco Systems
375 E Tasman Rd
San Jose  CA 95134
USA

Phone: +1 408 525 5386
EMail: mat@cisco.com

Mat Horan 🫧

COM DEV Wireless Group
San Luis Obispo  CA 93401
USA

Phone: +1 805 544 1089
EMail: mat.horan@comdev.cc

Phillip Neumiller 💅

3Com Corporation
1800 W. Central Road
Mount Prospect  IL 60056
USA

EMail: phil_neumiller@3com.com

---

12.0 Full Copyright Statement 🎀

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Acknowledgement 🙈

Funding for the RFC Editor function is currently provided by the Internet Society.