rfc3154.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 900 行 · 第 1/3 页

Network Working Group                                           J. Kempf
Request for Comments: 3154                               C. Castelluccia
Category: Informational                                         P. Mutaf
                                                             N. Nakajima
                                                                 Y. Ohba
                                                               R. Ramjee
                                                            Y. Saifullah
                                                             B. Sarikaya
                                                                   X. Xu
                                                             August 2001


              Requirements and Functional Architecture for
                     an IP Host Alerting Protocol

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 (2001).  All Rights Reserved.

Abstract

   This document develops an architecture and a set of requirements
   needed to support alerting of hosts that are in dormant mode.  The
   architecture and requirements are designed to guide development of an
   IP protocol for alerting dormant IP mobile hosts, commonly called
   paging.



















Kempf, et al.                Informational                      [Page 1]

RFC 3154                  Paging Requirements                August 2001


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 ......................................16







Kempf, et al.                Informational                      [Page 2]

RFC 3154                  Paging Requirements                August 2001


1.   Introduction

   In [1], a problem statement was developed to explain why an IP
   protocol was desirable for alerting hosts in dormant mode, commonly
   called paging.  In this document, a set of requirements is developed
   for guiding the development of an IP paging protocol.  Based on the
   requirements, an architecture is developed to represent the
   functional relationships between logical functional entities
   involved.

2.   Terminology

   Please see [1] for definition of terms used in describing paging.  In
   addition, 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.  In this
   section, security issues with relevance to formulating requirements
   for an IP paging protocol are discussed.

3.1. DoS Amplification

   A DoS (Denial-of-Service) or DDoS (Distributed DoS) attack generally
   consists of flooding a target network with bogus IP packets in order
   to cause degraded network performance at victim nodes and/or routers.
   Performance can be degraded to the point that the network cannot be
   used.  Currently, there is no preventive solution against these
   attacks, and the impacts can be very important.

   In general a DoS attacker profits from a so-called "amplifier" in
   order to increase the damage caused by his attack.  Paging can serve
   for an attacker as a DoS amplifier.

   An attacker (a malicious correspondent node) can send large numbers
   of packets pretending to be sent from different (bogus) correspondent
   nodes and destined for large numbers of hosts in inactive and dormant
   modes.  This attack, in turn, will be amplified by the paging agent
   which wide casts paging messages over a paging area, resulting in
   more than one networks being flooded.  Clearly, the damage can be



Kempf, et al.                Informational                      [Page 3]

RFC 3154                  Paging Requirements                August 2001


   more important in wireless networks that already suffer from scarce
   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 node
   participating in the attack.

   That node is never in inactive mode because of behavior 1 above.  In
   this case, the attacker can send large numbers of packets destined
   for that host which periodically declares that it is in dormant mode
   but never replies to paging messages.  The impact will be the same as
   above however in this case the attack will be 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 exploit that by sending large numbers of packets
   having different (bogus) correspondent node addresses and destined
   for one or more inactive hosts.  These packets will be buffered in
   the paging queue.  However, since the hosts are inactive, the paging
   queue may quickly overflow, blocking the incoming traffic from
   legitimate correspondent nodes.  As a result, all registered dormant
   hosts may be inaccessible for a while.  The attacker can re-launch
   the attack in a continuous fashion.

   An attacker together with a bogus host that fails to respond to pages
   can overflow the buffering provided to hold 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 in the absence of IP
   paging.  However, they are included here since they can affect the
   correct operation of the IP paging protocol.

   These vulnerabilities can be exploited by an attacker in order to
   eliminate a particular host.  This, in turn, can be used by an
   attacker as a stepping stone to launch other attacks.



Kempf, et al.                Informational                      [Page 4]

RFC 3154                  Paging Requirements                August 2001


   Forced Battery Consumption

   An attacker can frequently send packets to a host in order to prevent
   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 in order to
   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 paging
   area information.  Upon receipt of such a packet, a host 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 serve for sorting out a host which
   shows the behaviors 1 and 2 described in Section 3.1.

   Bogus Paging Agents

   An attacker can wide cast fake paging messages pretending to be sent
   by 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.

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.

4.3. Control of Broadcast/Multicast/Anycast

   The protocol SHOULD provide a filter mechanism to allow a Host prior
   to entering dormant mode to filter which broadcast/multicast/anycast
   packets active a page.  This prevents the Host from awakening out of
   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 Mode

   The IP paging protocol SHOULD provide a mechanism for the Tracking
   Agent to determine whether the Host is in inactive mode, to avoid
   paging when a host is completely unreachable.

4.5. No Routers

   Since the basic issues involved in handling mobile routers are not
   well understood and since mobile routers have not exhibited 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.