As per Relevance of the word information, we have this rfc below:
Network Working Group J.
Request for Comments: 3154 C.
Category: Informational P.
N.
Y.
R.
Y.
B.
X.
August 2001
Requirements and Functional Architecture
an IP Host Alerting
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document develops an architecture and a set of
needed to support alerting of hosts that are in dormant mode.
architecture and requirements are designed to guide development of
IP protocol for alerting dormant IP mobile hosts, commonly
paging
Kempf, et al. Informational [Page 1]
RFC 3154 Paging Requirements August 2001
Table of
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 ......................................16
Kempf, et al. Informational [Page 2]
RFC 3154 Paging Requirements August 2001
1.
In [1], a problem statement was developed to explain why an
protocol was desirable for alerting hosts in dormant mode,
called paging. In this document, a set of requirements is
for guiding the development of an IP paging protocol. Based on
requirements, an architecture is developed to represent
functional relationships between logical functional
involved
2.
Please see [1] for definition of terms used in describing paging.
addition, this document defines the following terms
Wide Casting - Either broadcasting or multicasting
Inactive Mode - The host is no longer listening for
packets, not even periodically, and not sending packets.
host may be in a powered off state, it may have shut down
interfaces to drastically conserve power, or it may be out
range of a radio access point
3. Security
An IP paging protocol introduces new security issues. In
section, security issues with relevance to formulating
for an IP paging protocol are discussed
3.1. DoS
A DoS (Denial-of-Service) or DDoS (Distributed DoS) attack
consists of flooding a target network with bogus IP packets in
to cause degraded network performance at victim nodes and/or routers
Performance can be degraded to the point that the network cannot
used. Currently, there is no preventive solution against
attacks, and the impacts can be very important
In general a DoS attacker profits from a so-called "amplifier"
order to increase the damage caused by his attack. Paging can
for an attacker as a DoS amplifier
An attacker (a malicious correspondent node) can send large
of packets pretending to be sent from different (bogus)
nodes and destined for large numbers of hosts in inactive and
modes. This attack, in turn, will be amplified by the paging
which wide casts paging messages over a paging area, resulting
more than one networks being flooded. Clearly, the damage can
Kempf, et al. Informational [Page 3]
RFC 3154 Paging Requirements August 2001
more important in wireless networks that already suffer from
radio bandwidth
Alternatively, an attacker can sort out a host which
1. sends periodic messages declaring that it is in dormant mode
2. never replies to paging requests
Such a node may be the attacker's node itself, or a second
participating in the attack
That node is never in inactive mode because of behavior 1 above.
this case, the attacker can send large numbers of packets
for that host which periodically declares that it is in dormant
but never replies to paging messages. The impact will be the same
above however in this case the attack will be amplified indefinitely
3.2. Queue
For reliability reasons, the paging protocol may need to
provisions for a paging queue where a paging request is
until the requested host replies by sending a location
message
An attacker can exploit that by sending large numbers of
having different (bogus) correspondent node addresses and
for one or more inactive hosts. These packets will be buffered
the paging queue. However, since the hosts are inactive, the
queue may quickly overflow, blocking the incoming traffic
legitimate correspondent nodes. As a result, all registered
hosts may be inaccessible for a while. The attacker can re-
the attack in a continuous fashion
An attacker together with a bogus host that fails to respond to
can overflow the buffering provided to hold packets for dormant
hosts. If the attacker keeps sending packets while the dormant
host fails to reply, the buffer can overflow
3.3. Selective DoS against
The following vulnerabilities already exist in the absence of
paging. However, they are included here since they can affect
correct operation of the IP paging protocol
These vulnerabilities can be exploited by an attacker in order
eliminate a particular host. This, in turn, can be used by
attacker as a stepping stone to launch other attacks
Kempf, et al. Informational [Page 4]
RFC 3154 Paging Requirements August 2001
Forced Battery
An attacker can frequently send packets to a host in order to
that host from switching to dormant mode. As a result the host
quickly run out of battery
Bogus Paging
An attacker can periodically emit malicious packets in order
confuse one or more hosts about their actual locations. Currently
there is no efficient way to authenticate such packets
In the case of IP paging, these packets may also contain bogus
area information. Upon receipt of such a packet, a host may move
send a location registration message pointing to a non-existing
wrong paging area. The functional entities of the IP paging
may loose contact with the host
More importantly, this attack can serve for sorting out a host
shows the behaviors 1 and 2 described in Section 3.1.
Bogus Paging
An attacker can wide cast fake paging messages pretending to be
by a paging agent. The impacts will be similar to the ones
in Sections 4.1 and 4.3.1. However, depending on how the IP
protocol is designed, additional harm may be caused
4.
The following requirements are identified for the IP paging protocol
4.1. Impact on Power
The IP paging protocol MUST minimize impact on the Host's
mode operation, in order to minimize excessive power drain
4.2.
The IP paging protocol MUST be scalable to millions of Hosts
4.3. Control of Broadcast/Multicast/
The protocol SHOULD provide a filter mechanism to allow a Host
to entering dormant mode to filter which broadcast/multicast/
packets active a page. This prevents the Host from awakening out
dormant mode for all broadcast/multicast/anycast traffic
Kempf, et al. Informational [Page 5]
RFC 3154 Paging Requirements August 2001
4.4. Efficient Signaling for Inactive
The IP paging protocol SHOULD provide a mechanism for the
Agent to determine whether the Host is in inactive mode, to
paging when a host is completely unreachable
4.5. No
Since the basic issues involved in handling mobile routers are
well understood and since mobile routers have not exhibited
requirement for paging, the IP paging protocol MAY NOT
routers. However, the IP paging protocol MAY support a router
as a Host
4.6. Multiple Dormant
Recognizing that there are multiple possible dormant modes on
Host, the IP paging protocol MUST work with different
of dormant mode on the Host
4.7. Independence of Mobility
Recognizing that IETF may support multiple mobility protocols in
future and that paging may be of value to hosts that do not support
mobility protocol, the IP paging protocol MUST be designed so
is no dependence on the underlying mobility protocol or on
mobility protocol at all. The protocol SHOULD specify and
support for a mobility protocol, if the Host supports one
4.8. Support for Existing Mobility
The IP paging protocol MUST specify the binding to the existing
mobility protocols, namely mobile IPv4 [2] and mobile IPv6 [3].
IP paging protocol SHOULD make use of existing registration support
4.9. Dormant Mode
Upon receipt of a page (either with or without an accompanying L
packet), the Host MUST execute the steps in its mobility protocol
re-establish a routable L3 link with the Internet
4.10. Network
Recognizing that locating a dormant mode mobile requires the
to have a rough idea of where the Host is located, the IP
protocol SHOULD provide the network a way for the Paging Agent
inform a dormant mode Host what paging area it is in and the
paging protocol SHOULD provide a means whereby the Host can
Kempf, et al. Informational [Page 6]
RFC 3154 Paging Requirements August 2001
the Target Agent when it changes paging area. The IP paging
MAY additionally provide a way for the Host to inform the
Agent what paging area it is in at some indeterminate point prior
entering dormant mode
4.11. Efficient Utilization of L
Recognizing that many existing wireless link protocols support
at L2 and that these protocols are often intimately tied into
Host's dormant mode support, the IP paging protocol SHOULD
support to efficiently utilize an L2 paging protocol if available
4.12. Orthogonality of Paging Area and
The IP paging protocol MUST allow an arbitrary mapping
subnets and paging areas
4.13. Future L3 Paging
Recognizing that future dormant mode and wireless link protocols
be designed that more efficiently utilize IP, the IP paging
SHOULD NOT require L2 support for paging
4.14. Robustness Against Failure of Network
The IP paging protocol MUST be designed to be robust with respect
failure of network elements involved in the protocol. The self
healing characteristics SHOULD NOT be any worse than existing
protocols
4.15. Reliability of Packet
The IP paging protocol MUST be designed so that packet delivery
reliable to a high degree of probability. This does not
mean that a reliable transport protocol is required
4.16. Robustness Against Message
The IP paging protocol MUST be designed to be robust with respect
loss of messages
4.17. Flexibility of
The IP paging protocol SHOULD provide a way to flexibly auto
configure Paging Agents to reduce the amount of
necessary in maintaining a wireless network with paging
Kempf, et al. Informational [Page 7]
RFC 3154 Paging Requirements August 2001
4.18. Flexibility of Paging Area
The IP paging protocol MUST be flexible in the support of
types of paging areas. Examples are fixed paging areas, where
fixed set of bases stations belong to the paging area for all Hosts
and customized paging areas, where the set of base stations
customized for each Host
4.19. Availability of Security
The IP paging protocol MUST have available authentication
encryption functionality at least equivalent to that provided
IPSEC [5].
4.20. Authentication of Paging Location
The IP paging protocol MUST provide mutually authenticated
location registration to insulate against replay attacks and to
the danger of malicious nodes registering for paging
4.21. Authentication of Paging Area
The IP paging protocol MUST provide a mechanism for
paging area information distributed by the Paging Agent
4.22. Authentication of Paging
The IP paging protocol MUST provide a mechanism for authenticating L
paging messages sent by the Paging Agent to dormant mode Hosts.
protocol MUST support the use of L2 security mechanisms
implementations that take advantage of L2 paging can also be secured
4.23. Paging
The IP paging protocol SHOULD be able to handle large numbers
paging requests without denying access to any legitimate Host
degrading its performance
4.24. Parsimonious Security
The security of the IP paging protocol SHOULD NOT call for
power consumption while the Host is in dormant mode, nor
excessive message exchanges
4.25. Noninterference with Host's Security
The IP paging protocol MUST NOT impose any limitations on a Host'
security policies
Kempf, et al. Informational [Page 8]
RFC 3154 Paging Requirements August 2001
4.26. Noninterference with End-to-end
The IP paging protocol MUST NOT impose any limitations on a Host'
ability to conduct end-to-end security
4.27. Detection of Bogus Correspondent
The IP paging protocol SHOULD make provisions for detecting
ignoring bogus correspondent nodes prior to paging messages
wide cast on behalf of the correspondent node
5. Functional
In this section, a functional architecture is developed
describes the logical functional entities involved in IP paging
the interfaces between them. Please note that the
architecture makes absolutely no commitment to any
implementation of these functional entities whatsoever. A
implementation may merge particular functional entities.
example, the Paging Agent, Tracking Agent, and Dormant
Agent may all be merged into one in a particular
implementation. The purpose of the functional architecture is
identify the relevant system interfaces upon which
development may be required, but not to mandate that
development will be required on all
5.1. Functional
The functional architecture contains the following elements
Host - The Host (H) is a standard IP host in the sense of [4].
Host may be connected to a wired IP backbone through a
link over which IP datagrams are exchanged (mobile usage pattern),
or it may be connected directly to a wired IP network,
intermittently (nomadic usage pattern) or constantly (wired
pattern). The Host may support some type of IP mobility
(for example, mobile IP [2] [3]). The Host is capable of
dormant mode in order to save power (see [1] for a
discussion of dormant mode). The Host also supports a
allowing the network to awaken it from dormant mode if a
arrives. This protocol may be a specialized L2 paging channel
it may be a time-slotted dormant mode in which the
periodically wakes up and listens to L2 for IP traffic,
details of the L2 implementation are not important. A
Host is also responsible for determining when its paging area
changed and for responding to changes in paging area by
Kempf, et al. Informational [Page 9]
RFC 3154 Paging Requirements August 2001
or indirectly informing the Tracking Agent about its location
Since routers are presumed not to require dormant mode support,
Host is never a router
Paging Agent - The Paging Agent is responsible for alerting
Host when a packet arrives and the Host is in dormant mode
Alerting of the Host proceeds through a protocol that is
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
casting information over the Host's link to identify the
area. The paging area information may be wide cast at L2 or
may also involve IP. Each paging area is served by a
Paging Agent
Tracking Agent - The Tracking Agent is responsible for tracking
Host's location while it is in dormant mode or active mode,
for determining when Host enters inactive mode. It
updates from a dormant Host when the Host changes paging area
When a packet arrives for the Host at the Dormant
Agent, the Tracking Agent is responsible for notifying the
Monitoring Agent, upon request, what Paging Agent is in the Host'
last reported paging area. There is a one to one mapping
a Host and a Tracking Agent
Dormant Monitoring Agent - The Dormant Monitoring Agent
the delivery of packets to a Host that is in Dormant Mode (
thus does not have an active L2 connection to the Internet).
is the responsibility of the Dormant Monitoring Agent to query
Tracking Agent for the last known Paging Agent for the Host,
inform the Paging Agent to page the Host. Once the Paging
has reported that a routable connection to the Internet exists
the Host, the Dormant Monitoring Agent arranges for delivery
the packet to the Host. In addition, the Host or its
Agent may select a Dormant Monitoring Agent for a Host when
Host enters dormant mode, and periodically as the Host
paging area
5.2.
The functional architecture generates the following list
interfaces. Note that the interfaces between functional
that are combined into a single network element will require
protocol development
Host - Paging Agent (H-PA) - The H-PA interface supports
following types of traffic
Kempf, et al. Informational [Page 10]
RFC 3154 Paging Requirements August 2001
- Wide casting of paging area information from the
Agent
- The Paging Agent alerting the Host when informed by
Dormant Monitoring Agent that a packet has arrived
Host - Tracking Agent (H-TA) - The H-TA interface supports
following types of traffic
- The Host informing the Tracking Agent when it has
paging area, and, optionally, prior to entering
mode, in what paging area it is located
- Optionally, the Host informs the Tracking Agent at a
transition to inactive mode
Dormant Monitoring Agent - Tracking Agent (DMA-TA) - The DMA-
interface supports the following types of traffic
- A report from the Dormant Monitoring Agent to the
Agent that a packet has arrived for a dormant Host for
no route is available
- A report from the Tracking Agent to the Dormant
Agent giving the Paging Agent to contact in order to
the Host
- A report from the Tracking Agent to the Dormant
Agent that a Host has entered inactive mode, if not
directly by the
- A report from the Tracking Agent to the Dormant
Agent that a Host has entered dormant mode, if not
directly by the Host
Dormant Monitoring Agent - Paging Agent (DMA-PA) - The DMA-
interface supports the following types of traffic
- A request from the Dormant Monitoring Agent to the
Agent to page a particular Host in dormant mode because
packet has arrived for the Host
- Negative response indication from the Paging Agent if
Host does not respond to a page
- Positive response from the Paging Agent indication if
Host does respond to a page
Kempf, et al. Informational [Page 11]
RFC 3154 Paging Requirements August 2001
- Delivery of the packet to the Host
Host - Dormant Monitoring Agent (H-DMA) - The H-DMA
supports the following types of traffic
- The Host registers to the Dormant Monitoring Agent prior
entering dormant mode, (if needed) with
information on which broadcast/multicast/anycast
trigger a page
- The Host informs the Dormant Monitoring Agent, when
directly deregisters from the Dormant Monitoring Agent
to a change from dormant mode to active or inactive mode
5.3. Functional Architecture
The functional architecture and interfaces lead to the
diagram
+------+ H-TA +----------+
| Host | <----------------------> | Tracking |
+------+ | Agent |
^ ^ +----------+
| | H-DMA ^
| +------------------------------+ |
| | | DMA-
| | |
| H-PA | |
v v
+--------+ DMA-PA +------------+
| Paging | <--------------------> | Dormant |
| Agent | | Monitoring |
+--------+ | Agent |
+------------+
Figure 1 - Paging Functional
6.
The authors would like to thank Arthur Ross for helpful comments
this memo
Kempf, et al. Informational [Page 12]
RFC 3154 Paging Requirements August 2001
7.
[1] Kempf, J., "Dormant Mode Host Alerting ("IP Paging")
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",
in Progress
[4] Braden, R., "Requirements for Internet Hosts -
Layers", STD 3, RFC 1122, October 1989.
[5] Kent, S., and R. Atkinson, "Security Architecture for
Internet Protocol", RFC 2401, November 1998.
8. Authors'
James
Sun Microsystems
901 San Antonio Rd
UMTV29-235
Palo Alto,
95303-4900
Phone: +1 650 336 1684
Fax: +1 650 691 0893
EMail: James.Kempf@Sun.
Pars
INRIA Rhone-
655 avenue de l'
38330 Montbonnot Saint-
Phone
Fax: +33 4 76 61 52 52
EMail: pars.mutaf@inria.
Kempf, et al. Informational [Page 13]
RFC 3154 Paging Requirements August 2001
Claude
INRIA Rhone-
655 avenue de l'
38330 Montbonnot Saint-
Phone: +33 4 76 61 52 15
Fax: +33 4 76 61 52 52
EMail: claude.castelluccia@inria.
Nobuyasu
Toshiba America Research, Inc
P.O. Box 136
Convent Station,
07961-0136
Phone: +1 973 829 4752
EMail: nnakajima@tari.toshiba.
Yoshihiro
Toshiba America Research, Inc
P.O. Box 136
Convent Station,
07961-0136
Phone: +1 973 829 5174
Fax: +1 973 829 5601
EMail: yohba@tari.toshiba.
Ramachandran
Bell Labs, Lucent
Room 4g-526
101 Crawfords Corner
Holmdel,
07733
Phone: +1 732 949 3306
Fax: +1 732 949 4513
EMail: ramjee@bell-labs.
Kempf, et al. Informational [Page 14]
RFC 3154 Paging Requirements August 2001
Yousuf
Nokia Research
6000 Connection Dr
Irving,
75039
Phone: +1 972 894 6966
Fax: +1 972 894 4589
EMail: Yousuf.Saifullah@nokia.
Behcet
Alcatel USA, M/S CT02
1201 Campbell Rd
Richardson,
75081-1936
Phone: +1 972 996 5075
Fax: +1 972 996 5174
EMail: Behcet.Sarikaya@usa.alcatel.
Xiaofeng
Alcatel USA, M/S CT02
1201 Campbell Rd
Richardson,
75081-1936
Phone: +1 972 996 2047
Fax: +1 972 996 5174
Email: xiaofeng.xu@usa.alcatel.
Kempf, et al. Informational [Page 15]
RFC 3154 Paging Requirements August 2001
9. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Kempf, et al. Informational [Page 16]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
