RFC 3154
Requirements and Functional Architecture for an IP Host Alerting Protocol
RFC 3154: Requirements and Functional Architecture for an IP Host Alerting Protocol 🎀
Okay bestie, the header facts first 💅 This is RFC 3154, dated August 2001, written by J. Kempf, C. Castelluccia, P. Mutaf, N. Nakajima, Y. Ohba, R. Ramjee, Y. Saifullah, B. Sarikaya, and X. Xu. It's Informational, which means it gives info to the Internet community and does not specify an Internet standard of any kind. Distribution is unlimited. The header doesn't list anything it obsoletes or updates, so nothing to track there ✨
Status of this Memo
This memo gives info to 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 (2001). All Rights Reserved. 💜
Abstract
This document lays out an architecture and a set of requirements for supporting alerting of hosts that are in dormant mode 🌸 The goal is to guide the development of an IP protocol for alerting dormant IP mobile hosts, which people usually call paging.
Table of Contents
1. Introduction ...................................................3
2. Terminology ....................................................3
3. Security Considerations ........................................3
3.1. DoS Amplification .........................................3
3.2. Queue Overflow ............................................4
3.3. Selective DoS against Hosts ...............................4
4. Requirements ...................................................5
4.1. Impact on Power Consumption ...............................5
4.2. Scalability ...............................................5
4.3. Control of Broadcast/Multicast/Anycast ....................5
4.4. Efficient Signaling for Inactive Mode .....................6
4.5. No Routers ................................................6
4.6. Multiple Dormant Modes ....................................6
4.7. Independence of Mobility Protocol .........................6
4.8. Support for Existing Mobility Protocols ...................6
4.9. Dormant Mode Termination ..................................6
4.10. Network Updates ...........................................6
4.11. Efficient Utilization of L2 ...............................7
4.12. Orthogonality of Paging Area and Subnets ..................7
4.13. Future L3 Paging Support ..................................7
4.14. Robustness Against Failure of Network Elements ............7
4.15. Reliability of Packet Delivery ............................7
4.16. Robustness Against Message Loss ...........................7
4.17. Flexibility of Administration .............................7
4.18. Flexibility of Paging Area Design .........................8
4.19. Availability of Security Support ..........................8
4.20. Authentication of Paging Location Registration ............8
4.21. Authentication of Paging Area Information .................8
4.22. Authentication of Paging Messages .........................8
4.23. Paging Volume .............................................8
4.24. Parsimonious Security Messaging ...........................8
4.25. Noninterference with Host's Security Policy ...............8
4.26. Noninterference with End-to-end Security ..................9
4.27. Detection of Bogus Correspondent Nodes ....................9
5. Functional Architecture ........................................9
5.1. Functional Entities .......................................9
5.2. Interfaces ...............................................10
5.3. Functional Architecture Diagram ..........................12
6. Acknowledgements ..............................................12
7. References ....................................................13
8. Authors' Addresses ............................................13
9. Full Copyright Statement ......................................161. Introduction ✨
Okay so in [1], they wrote a problem statement explaining why we even want an IP protocol for alerting hosts in dormant mode, which people call paging 💖 In this document, they put together a set of requirements to guide building an IP paging protocol. Based on those requirements, they came up with an architecture that shows how the logical functional entities involved relate to each other 🧚
2. Terminology 🌈
Please see [1] for the definitions of the terms used to describe paging. On top of that, this document defines the following terms:
- Wide Casting - Either broadcasting or multicasting.
- Inactive Mode - The host is no longer listening for any packets, not even periodically, and not sending packets. The host may be in a powered off state, it may have shut down all interfaces to drastically conserve power, or it may be out of range of a radio access point.
3. Security Considerations 🔥
An IP paging protocol introduces new security issues. This section talks about the security issues that matter when you're writing requirements for an IP paging protocol, and yes, it's a lot, but it's important 😭
3.1. DoS Amplification
A DoS (Denial-of-Service) or DDoS (Distributed DoS) attack generally means flooding a target network with bogus IP packets to degrade network performance at victim nodes and/or routers. It can get so bad that the network can't be used at all. Right now there's no preventive solution against these attacks, and the impacts can be very important 💀
A DoS attacker usually profits from a so-called "amplifier" to make their attack do more damage. Paging can serve as a DoS amplifier for an attacker 🙈
An attacker (a malicious correspondent node) can send large numbers of packets pretending to come from different (bogus) correspondent nodes and aimed at large numbers of hosts in inactive and dormant modes. The paging agent then amplifies this attack, because it wide casts paging messages over a paging area, which means more than one network gets flooded. Honestly the damage can be even worse on wireless networks, which already struggle with scarce radio bandwidth 😩
An attacker can also sort out a host which:
- sends periodic messages declaring that it is in dormant mode,
- never replies to paging requests.
That host could be the attacker's own node, or a second node taking part in the attack. Because of behavior 1 above, that node is never in inactive mode. So the attacker can send large numbers of packets to that host, which keeps saying it's in dormant mode but never answers paging messages. The impact is the same as above, except this time the attack gets amplified indefinitely 🌪️
3.2. Queue Overflow
For reliability reasons, the paging protocol may need to make provisions for a paging queue, where a paging request is buffered until the requested host replies by sending a location registration message 📬
An attacker can abuse that by sending large numbers of packets with different (bogus) correspondent node addresses, all aimed at one or more inactive hosts. Those packets get buffered in the paging queue. Since the hosts are inactive, the paging queue can overflow fast, which blocks incoming traffic from legitimate correspondent nodes. As a result, all registered dormant hosts may be inaccessible for a while, and the attacker can re-launch the attack in a continuous fashion 😤
An attacker working together with a bogus host that fails to respond to pages can also overflow the buffering that holds packets for dormant mode hosts. If the attacker keeps sending packets while the dormant mode host fails to reply, the buffer can overflow 🫠
3.3. Selective DoS against Hosts
The following vulnerabilities already exist without IP paging. They're included here anyway, because they can affect how the IP paging protocol works correctly 🧐
These vulnerabilities can be exploited by an attacker to eliminate a particular host. That in turn can be used as a stepping stone to launch other attacks 🚨
Forced Battery Consumption
An attacker can frequently send packets to a host to keep that host from switching to dormant mode. As a result, the host may quickly run out of battery 🔋
Bogus Paging Areas
An attacker can periodically emit malicious packets to confuse one or more hosts about where they actually are. Right now there's no efficient way to authenticate such packets 😬
With IP paging, these packets may also contain bogus paging area information. When a host receives one, it may move and send a location registration message pointing to a non-existing or wrong paging area. The functional entities of the IP paging protocol may loose contact with the host.
More importantly, this attack can be used to sort out a host that shows behaviors 1 and 2 described in Section 3.1 👀
Bogus Paging Agents
An attacker can wide cast fake paging messages while pretending to be a paging agent. The impacts will be similar to the ones described in Sections 4.1 and 4.3.1. However, depending on how the IP paging protocol is designed, additional harm may be caused 🙀
4. Requirements 💅
The following requirements are identified for the IP paging protocol. Here they come, no notes 🍓
4.1. Impact on Power Consumption
The IP paging protocol MUST minimize impact on the Host's dormant mode operation, in order to minimize excessive power drain 🔋
4.2. Scalability
The IP paging protocol MUST be scalable to millions of Hosts. Millions, bestie 😳
4.3. Control of Broadcast/Multicast/Anycast
The protocol SHOULD provide a filter mechanism that lets a Host, before entering dormant mode, filter which broadcast/multicast/anycast packets active a page. This stops the Host from waking up out of dormant mode for all broadcast/multicast/anycast traffic 🛑
4.4. Efficient Signaling for Inactive Mode
The IP paging protocol SHOULD provide a mechanism for the Tracking Agent to determine whether the Host is in inactive mode, so it doesn't page a host that's completely unreachable 📡
4.5. No Routers
Since the basic issues involved in handling mobile routers aren't well understood, and since mobile routers haven't shown a requirement for paging, the IP paging protocol MAY NOT support routers. However, the IP paging protocol MAY support a router acting as a Host 🧠
4.6. Multiple Dormant Modes
Hosts can have multiple possible dormant modes, so the IP paging protocol MUST work with different implementations of dormant mode on the Host 🌸
4.7. Independence of Mobility Protocol
Okay so the IETF might support multiple mobility protocols in the future, and paging could be valuable even to hosts that don't support any mobility protocol. That's why the IP paging protocol MUST be designed so it has no dependence on the underlying mobility protocol, or on any mobility protocol at all 🦋 The protocol SHOULD specify and provide support for a mobility protocol, if the Host supports one ✨
4. Requirements (continued) ✨
4.8. Support for Existing Mobility Protocols
okay so the IP paging protocol MUST specify the binding to the existing IP mobility protocols, namely mobile IPv4 [2] and mobile IPv6 [3] 🫶 and it SHOULD make use of existing registration support too. it's giving teamwork with what's already out there 🤝💜
4.9. Dormant Mode Termination
bestie, when a page comes in (with or without an L3 packet riding along), the Host MUST execute the steps in its mobility protocol to re-establish a routable L3 link with the Internet. 🔥 the dormant era ends here, periodt 💅
4.10. Network Updates
ngl this one is so important 🥺 locating a dormant mode mobile means the network needs a rough idea of where the Host is. so the IP paging protocol SHOULD provide the network a way for the Paging Agent to inform a dormant mode Host what paging area it is in, and the IP paging protocol SHOULD provide a means whereby the Host can inform the Target Agent when it changes paging area. the IP paging protocol MAY additionally provide a way for the Host to inform the Tracking Agent what paging area it is in at some indeterminate point prior to entering dormant mode. 🧚📍
4.11. Efficient Utilization of L2
lowkey obsessed with this one 🌸 a lot of existing wireless link protocols already support paging at L2, and those protocols are often super intertwined with the Host's dormant mode support. so the IP paging protocol SHOULD provide support to efficiently utilize an L2 paging protocol if one is available. ✨
4.12. Orthogonality of Paging Area and Subnets
the vibe here is "mix and match" 🦋 the IP paging protocol MUST allow an arbitrary mapping between subnets and paging areas. no hard rules, just freedom 💖
4.13. Future L3 Paging Support
looking ahead, future dormant mode and wireless link protocols may be designed to use IP more efficiently 🚀 so the IP paging protocol SHOULD NOT require L2 support for paging. we're future-proofing, bestie 🔮
4.14. Robustness Against Failure of Network Elements
the IP paging protocol MUST be designed to be robust with respect to failure of network elements involved in the protocol. 🛡️ its self-healing characteristics SHOULD NOT be any worse than existing routing protocols. we are not doing worse than the routing protocols, that's the whole bar 💅
4.15. Reliability of Packet Delivery
the IP paging protocol MUST be designed so that packet delivery is reliable to a high degree of probability. 🎀 this does not necessarily mean that a reliable transport protocol is required, so no panicking about that 🙈
4.16. Robustness Against Message Loss
the IP paging protocol MUST be designed to be robust with respect to loss of messages. messages can get lost, so the protocol has to be ready for it 🫶
4.17. Flexibility of Administration
the IP paging protocol SHOULD provide a way to flexibly auto-configure Paging Agents, so there's less admin work to keep a wireless network with paging running 🧚✨ less babysitting, more slaying 💅
4.18. Flexibility of Paging Area Design
the IP paging protocol MUST be flexible in supporting different types of paging areas 🌈 for example, fixed paging areas, where a fixed set of bases stations belong to the paging area for all Hosts, and customized paging areas, where the set of base stations is customized for each Host. both are valid, iykyk 🍓
4.19. Availability of Security Support
the IP paging protocol MUST have available authentication and encryption functionality at least equivalent to that provided by IPSEC [5]. 🔐 security is not optional, bestie 💜
4.20. Authentication of Paging Location Registration
the IP paging protocol MUST provide mutually authenticated paging location registration. this insulates against replay attacks and avoids the danger of malicious nodes registering for paging. 🚫👀 nobody sneaks onto the guest list 🎀
4.21. Authentication of Paging Area Information
the IP paging protocol MUST provide a mechanism for authenticating paging area information distributed by the Paging Agent. 📡 the info has to be verified, no cap 🧢❌
4.22. Authentication of Paging Messages
the IP paging protocol MUST provide a mechanism for authenticating L3 paging messages sent by the Paging Agent to dormant mode Hosts. it also MUST support the use of L2 security mechanisms, so implementations that take advantage of L2 paging can also be secured. 🔒🦋 everybody gets secured, no exceptions
4.23. Paging Volume
the IP paging protocol SHOULD be able to handle large numbers of paging requests without denying access to any legitimate Host, nor degrading its performance. 📈 big crowds, zero drama 👑
4.24. Parsimonious Security Messaging
the security of the IP paging protocol SHOULD NOT call for additional power consumption while the Host is in dormant mode, nor require excessive message exchanges. 🔋 security should not drain the battery, that's just rude 💀
4.25. Noninterference with Host's Security Policy
the IP paging protocol MUST NOT impose any limitations on a Host's security policies. hands off the Host's policies 🙌🌸
4.26. Noninterference with End-to-end Security
the IP paging protocol MUST NOT impose any limitations on a Host's ability to conduct end-to-end security. 🤍 same energy as above: paging doesn't get to boss end-to-end security around ✨
4.27. Detection of Bogus Correspondent Nodes
the IP paging protocol SHOULD make provisions for detecting and ignoring bogus correspondent nodes before paging messages are wide cast on behalf of the correspondent node. 🕵️♀️ catching the fakes before they start the party 🎉
5. Functional Architecture 🏗️
okay so this section develops a functional architecture that describes the logical functional entities involved in IP paging and the interfaces between them. just a heads up, the logical architecture makes absolutely no commitment to any physical implementation of these functional entities whatsoever 🙅♀️ a physical implementation may merge particular functional entities. for example, the Paging Agent, Tracking Agent, and Dormant Monitoring Agent may all be merged into one in a particular physical implementation. the purpose of the functional architecture is to identify the relevant system interfaces upon which protocol development may be required, but not to mandate that protocol development will be required on all. 🧩💖
5.1. Functional Entities
the functional architecture has the following elements, and they're all lowkey iconic 👑
Host - The Host (H) is a standard IP host in the sense of [4]. The Host may be connected to a wired IP backbone through a wireless link over which IP datagrams are exchanged (mobile usage pattern), or it may be connected directly to a wired IP network, either intermittently (nomadic usage pattern) or constantly (wired usage pattern). The Host may support some type of IP mobility protocol (for example, mobile IP [2] [3]). The Host is capable of entering dormant mode in order to save power (see [1] for a detailed discussion of dormant mode). The Host also supports a protocol allowing the network to awaken it from dormant mode if a packet arrives. This protocol may be a specialized L2 paging channel, or it may be a time-slotted dormant mode in which the Host periodically wakes up and listens to L2 for IP traffic; the details of the L2 implementation are not important. A dormant Host is also responsible for determining when its paging area has changed, and for responding to changes in paging area by directly or indirectly informing the Tracking Agent about its location. Since routers are presumed not to require dormant mode support, a Host is never a router. 💻✨
Paging Agent - The Paging Agent is responsible for alerting the Host when a packet arrives and the Host is in dormant mode. Alerting of the Host proceeds through a protocol that is peculiar to the L2 link and to the Host's dormant mode implementation, though it may involve IP if supported by the L2. Additionally, the Paging Agent maintains paging areas by periodically wide casting information over the Host's link to identify the paging area. The paging area information may be wide cast at L2, or it may also involve IP. Each paging area is served by a unique Paging Agent. 📣🌈
Tracking Agent - The Tracking Agent is responsible for tracking a Host's location while it is in dormant mode or active mode, and for determining when the Host enters inactive mode. It receives updates from a dormant Host when the Host changes paging area. When a packet arrives for the Host at the Dormant Monitoring Agent, the Tracking Agent is responsible for notifying the Dormant Monitoring Agent, upon request, what Paging Agent is in the Host's last reported paging area. There is a one to one mapping between a Host and a Tracking Agent. 🗺️🦋
Dormant Monitoring Agent - The Dormant Monitoring Agent detects the delivery of packets to a Host that is in Dormant Mode (and thus does not have an active L2 connection to the Internet). It is the responsibility of the Dormant Monitoring Agent to query the Tracking Agent for the last known Paging Agent for the Host, and to inform the Paging Agent to page the Host. Once the Paging Agent has reported that a routable connection to the Internet exists to the Host, the Dormant Monitoring Agent arranges for delivery of the packet to the Host. In addition, the Host or its Tracking Agent may select a Dormant Monitoring Agent for a Host when the Host enters dormant mode, and periodically as the Host changes paging area. 👀💜
5.2. Interfaces 🔌
okay so the functional architecture gives us a list of interfaces, and bestie, this part is so important 💅 the interfaces between functional entities that get squished into one single network element need zero protocol development, so no extra work there 🙌
Host - Paging Agent (H-PA) 🎀 this interface carries two kinds of traffic:
- Wide casting of paging area information from the Paging Agent.
- The Paging Agent alerting the Host when the Dormant Monitoring Agent tells it a packet has arrived.
Host - Tracking Agent (H-TA) 🦋 this one carries:
- The Host telling the Tracking Agent when it has changed paging area, and, optionally, prior to entering dormant mode, in what paging area it is located.
- Optionally, the Host informs the Tracking Agent at a planned transition to inactive mode.
Dormant Monitoring Agent - Tracking Agent (DMA-TA) 🧚 the DMA-TA interface is a whole group chat of reports:
- A report from the Dormant Monitoring Agent to the Tracking Agent that a packet has arrived for a dormant Host for which no route is available.
- A report from the Tracking Agent to the Dormant Monitoring Agent giving the Paging Agent to contact in order to page the Host.
- A report from the Tracking Agent to the Dormant Monitoring Agent that a Host has entered inactive mode, if not provided directly by the Host.
- A report from the Tracking Agent to the Dormant Monitoring Agent that a Host has entered dormant mode, if not provided directly by the Host.
Dormant Monitoring Agent - Paging Agent (DMA-PA) 💜 this is where the paging actually happens:
- A request from the Dormant Monitoring Agent to the Paging Agent to page a particular Host in dormant mode because a packet has arrived for the Host.
- Negative response indication from the Paging Agent if the Host does not respond to a page.
- Positive response from the Paging Agent indication if the Host does respond to a page.
- Delivery of the packet to the Host.
Host - Dormant Monitoring Agent (H-DMA) 🌸 the last one, and it's giving registration vibes:
- The Host registers to the Dormant Monitoring Agent prior to entering dormant mode, (if needed) with filtering information on which broadcast/multicast/anycast packets trigger a page.
- The Host informs the Dormant Monitoring Agent, when it directly deregisters from the Dormant Monitoring Agent due to a change from dormant mode to active or inactive mode.
5.3. Functional Architecture Diagram 🗺️
okay here's the functional architecture and interfaces all mapped out, and honestly it's giving diagram-core 😭
+------+ H-TA +----------+
| Host | <----------------------> | Tracking |
+------+ | Agent |
^ ^ +----------+
| | H-DMA ^
| +------------------------------+ |
| | | DMA-TA
| | |
| H-PA | |
v v v
+--------+ DMA-PA +------------+
| Paging | <--------------------> | Dormant |
| Agent | | Monitoring |
+--------+ | Agent |
+------------+
Figure 1 - Paging Functional Architecture6. Acknowledgements 🫶
the authors wanted to give a shoutout to Arthur Ross for helpful comments on this memo, so thank you Arthur 💖
7. References 📚
- [1] Kempf, J., "Dormant Mode Host Alerting ("IP Paging") Problem Statement", RFC 3132, June 2001.
- [2] Perkins, C., ed., "IP Mobility Support", RFC 2002, October, 1996.
- [3] Johnson, D., and Perkins, C., "Mobility Support in Ipv6", Work in Progress.
- [4] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
- [5] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
8. Authors' Addresses 🏡
here are the authors and where to find them, bestie 💌
James Kempf
Sun Microsystems Laboratories
901 San Antonio Rd.
UMTV29-235
Palo Alto, CA
95303-4900
USA
Phone: +1 650 336 1684
Fax: +1 650 691 0893
EMail: James.Kempf@Sun.COMPars Mutaf
INRIA Rhone-Alpes
655 avenue de l'Europe
38330 Montbonnot Saint-Martin
FRANCE
Phone:
Fax: +33 4 76 61 52 52
EMail: pars.mutaf@inria.fr
Claude Castelluccia
INRIA Rhone-Alpes
655 avenue de l'Europe
38330 Montbonnot Saint-Martin
FRANCE
Phone: +33 4 76 61 52 15
Fax: +33 4 76 61 52 52
EMail: claude.castelluccia@inria.frNobuyasu Nakajima
Toshiba America Research, Inc.
P.O. Box 136
Convent Station, NJ
07961-0136
USA
Phone: +1 973 829 4752
EMail: nnakajima@tari.toshiba.comYoshihiro Ohba
Toshiba America Research, Inc.
P.O. Box 136
Convent Station, NJ
07961-0136
USA
Phone: +1 973 829 5174
Fax: +1 973 829 5601
EMail: yohba@tari.toshiba.comRamachandran Ramjee
Bell Labs, Lucent Technologies
Room 4g-526
101 Crawfords Corner Road
Holmdel, NJ
07733
USA
Phone: +1 732 949 3306
Fax: +1 732 949 4513
EMail: ramjee@bell-labs.com
Yousuf Saifullah
Nokia Research Center
6000 Connection Dr.
Irving, TX
75039
USA
Phone: +1 972 894 6966
Fax: +1 972 894 4589
EMail: Yousuf.Saifullah@nokia.comBehcet Sarikaya
Alcatel USA, M/S CT02
1201 Campbell Rd.
Richardson, TX
75081-1936
USA
Phone: +1 972 996 5075
Fax: +1 972 996 5174
EMail: Behcet.Sarikaya@usa.alcatel.com
Xiaofeng Xu
Alcatel USA, M/S CT02
1201 Campbell Rd.
Richardson, TX
75081-1936
USA
Phone: +1 972 996 2047
Fax: +1 972 996 5174
Email: xiaofeng.xu@usa.alcatel.com9. Full Copyright Statement ⚖️
okay this part is legal stuff, so I'm keeping it word for word so nothing gets lost 🙏
Copyright (C) The Internet Society (2001). 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. ✨
📦 where this page comes from
- ietf: rfc3154 2001-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms