Internet Draft                                              A. Petrescu
Document: draft-petrescu-nemo-threats-xx.txt               A. Olivereau
Expires: July 2004                                         C. Janneteau
                                                             H.-Y. Lach
                                                               Motorola
                                                           January 2004


      Threats for Basic Network Mobility Support (NEMO threats)
                 <draft-petrescu-nemo-threats-01.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

Abstract

   This document describes security threats related to the network
   mobility base protocol (NEMO).  Threats of Mobile IPv6 for Mobile
   Hosts are only briefly touched when in need of support of related
   NEMO threats.  The NEMO signalling between MR and HA, as well as
   the forwarding information at HA and nested mobility configurations
   are considered to be the main sensitive points of the protocol.
   Existing tools of Mobile IPv6 protection between MH and HA (IPsec),
   dynamic routing protocol authentication, NEMO prefix table, ingress
   filtering checks at HA and tunnel encapsulation limiting are
   presented as protocol features affording protection against
   threats.  NEMO threats for which there are no protections are
   briefly mentioned.












Petrescu et al.           Expires July 2004                    [Page i]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

Table of Contents

   Status of this Memo................................................i
   Abstract...........................................................i
   Conventions Used in this Document..................................1
   1. Introduction and Overview.......................................1
   2. Interactions between MR and HA..................................4
   3. Interactions between several MR's of same HA....................7
   4. Forwarding Information Updates at HA............................7
   5. Nested Mobility.................................................8
   6. Other Threats...................................................8
   Acknowledgements...................................................8
   A. IPsec Architecture for Nested Mobility..........................8
   B. IPsec Protection of Binding Updates and Acknowledgements.......10
   C. IPsec non-Protection of Home Agent Discovery Messaging.........18
   References........................................................19
   Changes...........................................................21
   Copyright Notice..................................................22


Conventions used in this document

   The key words "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].

   In addition to the NEMO terminology [5], four additional terms were
   useful for descriptions within this document.

   Binding Update: an IPv6 datagram that contains a Mobility Header
                   whose MH Type field is 0x5; it is sent by a Mobile
                   Node to its Home Agent.

   Binding Acknowledgement: an IPv6 datagram that contains a Mobility
                            Header whose MH Type field is 0x6; it is
                            sent by a Home Agent in response to a
                            Binding Update received from a Mobile
                            Node.

   Mobile Security Gateway: an entity acting simultaneously as a NEMO
                            Mobile Router and as an IPsec Security
                            Gateway.

   Home Security Gateway: an entity acting simultaneously as a NEMO
                          Home Agent and as an IPsec Security Gateway.

1. Introduction and Overview

   The Network Mobility base protocol [4] describes means for a Mobile
   Router using Mobile IPv6 [8] to offer continuous connectivity for a
   set of hosts and routers within a moving network, to the Internet.
   A moving network has a relatively stable internal IP structure and
   will usually not transit traffic.  The Mobile Router is part of the
   moving network and moves together with all nodes of it.


Petrescu et al.           Expires July 2004                    [Page 1]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

   Documents desribing protocols should contain a Security Section
   [18][20].  Section 8 of the NEMO base protocol is such a section;
   it contains briefly outlined guidelines on the methods to use to
   offer a relatively high level of security (IPsec, HA ingress
   filtering and routing protocol verifications indications).

   This document presents the characteristics of the initial threat
   model that was used as basis for developping the respective
   Security Considerations section.

   A Mobile Router implements most functionalities of a Mobile IPv6
   Mobile Host [8].  Notable additions include the R-bit management
   and NEMO-specific modes (implicit and explicit).  A NEMO Home Agent
   implements most functionalities of a Mobile IPv6 HA with the the
   additions of R-bit management, the two modes and, additionally,
   interactions with its forwarding information (routing table)
   management.  There are no new messages introduced by the base NEMO
   document [4] when compared to Mobile IPv6 [8].  The modified
   messages are: Binding Update, Binding Acknowledgement, Home Agent
   Discovery Request and Home Agent Discovery Reply.  New R-bit fields
   have been included in the Binding Update and the Home Agent
   Discovery Request and Reply; a new MNP field has been introduced in
   the Binding Update; the Status field of a Binding Acknowledgement
   contains new values.

   A new mobility configuration introduced by NEMO with respect to
   Mobile IPv6 mobility is the "nested" configuration, in which two
   moving networks served by different Mobile Routers (each with its
   own Home Agent) attach one under the other.  A simpler case of
   nested mobility appears when one Mobile Host visits a moving
   network (MH and MR having different Home Agents).

   While Route Optimization is currently an integral part of the
   Mobile IPv6 specification for Mobile Hosts, it is not a part of the
   behaviour of a Mobile Router or of that of a NEMO Home Agent.

   Thus, this document describes security threats that pertain to: (1)
   interactions between MR and its HA, (2) interactions between
   several MR's served by same HA, (3) threats relating to forwarding
   information updates at HA and, finally and (4) threats related to
   nested mobility.

   Another document attempting to describe threats in the NEMO context
   is [9].

   This document avoids description of threats relating to Route
   Optimization for moving networks, to Mobile IPv6 for Mobile Hosts,
   to multihoming for moving networks; other generic mobility threats
   exist whose solutions are proposed by PANA, AAA and SEND Working
   Groups.  For threats relating to Mobile IPv6 for Mobile Hosts,
   reader is referred to section 15.1 of [8], to [1] and [16].  For
   threats relating to access granting and control, or threats of IPv6
   behaviour on same link, please see the above mentioned Working
   Group documents.  For threats on the routing protocol (eventually
   used between MR and HA) see [3].

Petrescu et al.           Expires July 2004                    [Page 2]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

   The current network mobility base specification [4] requires that
   all signaling messages between the Mobile Router and the Home Agent
   MUST be authenticated by IPsec.  The use of IPsec to protect Mobile
   IPv6 signaling messages is described in detail in the HA-MN IPsec
   specification [1].  Using AH and/or ESP between MR and HA is of
   paramount importance in order to protect against a wide range of
   attacks.

   The Internet IPsec architecture can be particularized for Mobile
   Routers by distinguishing two cases: (1) IPsec protection in
   transport mode for NEMO signalling and (2) IPsec protection in
   tunnel mode for NEMO traffic between LFN and CN.

   AH/ESP used in transport mode for NEMO signalling protects Binding
   Updates, Binding Acknowledgements (but does not protect Home Agent
   Address Discovery Requests and Home Agent Address Discovery
   Replies).  They are exchanged between the Mobile Router (Mobile
   Security Gateway) and Home Agent (Home Security Gateway):

               +--------+                        +--------+
               | Mobile | AH/ESP transport mode  |  Home  |
               | Sec GW |========================| Sec GW |
               |  (MR)  |                        |  (HA)  |
               +--------+                        +--------+

   AH/ESP used in tunnel mode for NEMO traffic protects all fields of
   all IP datagrams exchanged between LFN and CN, including
   application-level data:

               +--------+   AH/ESP tunnel mode   +--------+
   +-----+     | Mobile |________________________|  Home  |     +----+
   | LFN |.....| Sec GW |........................| Sec GW |.....| CN |
   +-----+     |  (MR)  |------------------------|  (HA)  |     +----+
               +--------+                        +--------+

   This IPsec architecture for moving networks can be extended to
   nested network mobility configurations, by means of encapsulating
   tunneling.  See section A for illustrations of IPsec for nested
   mobility.

   Other means of protecting communication between MR and HA are
   needed in certain cases; they include the use of the NEMO Prefix
   Table, the prefix-extended ingress filtering technique [6] used by
   the NEMO Home Agent and the tunnel encapsulation limiting.  If
   further additional tools are needed, a good overview of
   authentication mechanisms in the Internet can be found in [19].

   Last but not least, even if IPsec, ingress filtering, Prefix Table
   and tunnel encapsulation limiting are used, we acknowledge the
   existence of other security risks with the NEMO base protocol.
   They stem mainly from the lack of certain security features of the
   underlying Mobile IPv6 protoocol.  For example: attacks on the R
   bit within the Home Agent Discovery messaging, and location privacy
   risks.


Petrescu et al.           Expires July 2004                    [Page 3]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

2. Interactions between MR and HA

   T.1 Threat on the MNP field (redirection threat): the simplest and
   most important (but avoidable) threat of the NEMO basic support
   protocol is the redirection of traffic of all addresses within a
   Mobile Network Prefix.  An attacker sending an un-protected NEMO
   Binding Update to a Home Agent for a certain MNP is actually
   instructing that Home Agent to forward all traffic for MNP towards
   the address of the attacker.  The gravity of the risk is more
   important than in the case of Mobile Hosts; an attacker Mobile Host
   could re-direct only one legitimate Home Address, while with NEMO
   an attacker MR could re-direct all the addresses within an MNP.
   Moreover, the risk is all the more important since attacker MR can
   be positioned anywhere in the Internet, NEMO is not restrained to a
   closed system.  In order to avoid this risk actually realizing, it
   is important to protect all signalling messages between MR and HA
   by IPsec (this is also required by [1] and [8]).  In general, if HA
   uses AH/ESP transport mode for all NEMO signalling with the
   legitimate MR then attacker MR is not able to realize such a
   re-direction attack, because AH/ESP in transport mode covers the
   MNP field of the BU.

   T.2 Threat on the R bit of BU: An attacker Mobile Host asks its
   Home Agent to forward all traffic addressed to addresses within MNP
   to its current Care-of Address.  Normally, Mobile Hosts do not send
   the R-bit in the Binding Update.  An attacker Mobile Host can
   specify the R-bit and thus receiving traffic addressed to other
   addresses than simply to its Home Address.  However, if IPsec is
   used, the R-bit in the BU is covered both by AH and ESP in
   transport mode, so if HA and MH have a trust relationship it is
   assumed that MH will not specify the R bit.

   T.3 Threat on the Status field of BAck: an attacker entity on the
   path between legitimate MR and HA modifies the Status field of the
   Binding Acknowledgement sent by the HA to MR.  It is assumed that
   MR has previously sent a BU to HA with the R-bit set and that HA
   replied with Status 140 (Mobile Router Operation not Permitted).
   The attacker entity substitutes 141 (Invalid Prefix) for 140 and
   thus leads MR into re-sending Binding Updates to Home Agent
   (instead of stopping sending Binding Updates).  However, the AH/ESP
   headers cover the Status field of the BAck and thus attacker can
   not tamper with the Status field, invalidating this threat.

   T.4 Threat on switching between modes: MR sends BU in implicit mode
   to HA, HA replies back positively, using MNP from external means
   (not from BU).  During this time, the attacker gained knowledge of
   the MR's Home Address, sends BU to HA in explicit mode for the same
   Home Address but a MNP specified in the BU, different than what HA
   already has.  HA replies back positively to MR and switches to
   explicit mode and a different MNP.  Threat is two-fold: on one hand
   HA would stop forwarding packets of the legitimate MNP towards the
   legitimate MR; on the other hand HA would start forwarding packets
   of a false MNP towards the legitimate MR.



Petrescu et al.           Expires July 2004                    [Page 4]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

   IPsec can not help protecting against attacker MR obtaining the
   Home Address of the legitimate MR (it is not covered by ESP when
   legitimate MR sends BU or receives BAck).  However, IPsec can
   protect against the attacker MR specifying an illegitimate MNP
   within a BU; the MNP field in the BU is covered by ESP in transport
   mode.

   The description of this threat started with MR using implicit mode
   and attacker trying explicit mode.  The description applies equally
   well if the initial step was in explicit mode and second step used
   implicit mode.

   T.5 Threat on the R bit of Home Agent Discovery Request: an
   attacker on the path between legitimate MR and HA transforms the R
   bit from 1 to 0.  The Home Agents thus receive a request for
   non-NEMO Home Agents and will not set the R bit in the Reply
   message.  Thus the MR is led into believing there is no HA on the
   home link supporting Mobile Routers.  IPsec does not protect
   against this threat since the Home Agent Address Discovery Request
   is not protected neither by AH nor by ESP headers.

   T.6 Threat on the R bit of Home Agent Discovery Reply: an attacker
   entity on the path between legitimate MR and HA transforms the R
   bit from 1 to 0.  It is assumed that, initially, the MR has sent a
   Home Agent Address Discovery message to the home network with the
   R-bit set, thus requesting responses from HA's that support Mobile
   Routers; it is also assumed that the HA replied a legitimate Reply
   containing the R bit set.  The effect of this threat is that MR is
   falsely led into believing that no HA on the home network can
   support Mobile Routers.  IPsec does not protect against this threat
   since the Home Agent Address Discovery Reply is not protected
   neither by AH nor by ESP headers.

   T.7 Threat of address spoofing: when attacker needs to send an
   unreasonably large amount of IP packets to a target without risk of
   his current address being identified, it could do so by two means.
   First, it would set the src address of the packets to another
   address, at random (thus "spoofing" a legitimate address, or
   "masquerading" as that address).  However, the first-hop router
   might forbid forwarding packets whose source address are not
   topologically correct at that particular router (ingress filtering
   [6]).  Second, if ingress filtering at the access router is in
   place, the MH might first encapsulate towards HA, thus tricking the
   access router; HA decapsulates and "bombs" the actual target by
   using MH's Home Address as source address.  However, the ingress
   filtering technique is used at the HA as well; Mobile IPv6 requires
   HA of MH to only forward those packets from MH if the src address
   of the outer header to match a Care-of Address entry in the BC and
   the src address in the inner header to match the home address field
   of the same entry.  The NEMO base specification offers further help
   by requiring the Home Address to match a Mobile Network Prefix
   owned by the Mobile Router.  If is obvious that this threat applies
   to Mobile IPv6 for Mobile Hosts and, where Mobile IPv6 for Mobile
   Hosts offers protection, it automatically offers protection for
   Mobile Routers as well.

Petrescu et al.           Expires July 2004                    [Page 5]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

   T.8 Threat on location privacy: [it is not immediately clear to
   authors whether location privacy can be qualified as a NEMO
   security threat per se or as a particular risk of open
   communications in mobile environments.]

   In the context of Mobile Hosts (not Mobile Routers), location
   privacy represents the desire of a Mobile Host to not reveal, or
   hide, its current association Care-of Address (its location) - Home
   Address (its permanent identifier) from an attacker listening on
   the path between MH and HA.  It is not a desire to hide only one
   address, but the association.  It is sufficient for an attacker
   wishing to find the current location of a victim Mobile Host to
   snoop traffic between the victim and its Home Agent.  When the
   Mobile Host changes its location and updates the Home Agent, a pair
   of Binding Update/Acknowledgement messages is communicated.  An
   attacker on the path can find the association Home Address -
   Care-of Address of the Mobile Host, even if AH and/or ESP headers
   are used to protect the two packets.  Both AH and ESP for Binding
   Updates and Acknowledgements are used in transport mode (not tunnel
   mode), thus the base header (containing the Care-of Address and the
   Home Agent address), the Destination Options header and the Routing
   Header Type 2 (containing the Home Address) are transmitted in
   clear (but message integrity, and implicitely integrity of the Home
   Address and the Care-of Address, is afforded by AH), see section
   B.6.

   In the context of NEMO, the location privacy can be described as
   the desire of a Local Fixed Node within a moving network to not
   reveal, or hide, the location triplet LFN Home Address - MR Care-of
   Address - MR Home Address.  An attacker outside the moving network
   and on the path between the Mobile Router and its Home Agent could
   snoop packets.  If the bidirectional tunnel between the Mobile
   Router and its Home Agent is not protected by ESP, then attacker
   can find the LFN Home Address in the src field of the inner packet
   sent by MR to HA and the MR Care-of Address in the src field of the
   outer base header.  The MR Home Address could have been obtained
   from the Binding Update or the Binding Acknowledgement, as
   described in the previous paragraph.  In this way, attacker can
   gain knowledge of the triplet LFN Home Address - MR Home Address -
   MR Care-of Address.  However, if MR uses ESP tunnel mode protection
   for the bidirectional tunnel, then attacker has no means to gain
   visibility of the LFN Home Address.

   Thus, even if location privacy might be considered as a security
   threat, it is mostly a risk for Mobile Hosts, and can not be
   qualified as a NEMO risk; the association Home Address - Care-of
   Address of a Mobile Host might be revealing location information
   but the location triplet can not be revealed if ESP is used for
   non-signaling traffic between MR and HA.

   T.9 Threat on the Routing Header Type 2: attacker modifies the type
   of the routing header type 2 of a Binding Acknowledgement sent by
   HA to MR and substitues 0 for 2.  In addition attacker may specify
   a number of addresses within this fake type 0 routing header.  The
   risk is that attacker provokes bombing attacks and stays hidden

Petrescu et al.           Expires July 2004                    [Page 6]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

   (its address does not appear in the packet); it is the Home Agent's
   and the Mobile Router's addresses that appear in the attack.  The
   risk is typically a Mobile IPv6 for hosts risk, but it is more
   important in the case of Mobile Routers because Mobile Hosts are
   not expected to implement routing header software, or are expected
   to implement type 2 routing headers exclusively (for Mobile Hosts).
   However, all routers (Mobile Routers included) are expected to
   implement routing headers type 0, thus they are more at risk with
   this threat.  Protection against this risk is again offered by AH
   which covers all fields of the Routing Header Type 2.

3. Interactions between several MR's of same HA

   T.10 DoS threat on peer MR by attacker spoofing a legitimate MR's
   Care-of Address.  A similar threat exists in the case of Mobile
   IPv6 for Mobile Hosts, but is less important than in the case of
   NEMO.

   In the context of Mobile IPv6 for Mobile Hosts, consider two Mobile
   Hosts belonging to the same Home Agent; each MH is trusted by the
   Home Agent (with IPsec).  The victim MH and the attacker MH are
   both visiting the same foreign network.  The attacker MH reads the
   Care-of Address of the victim from the Binding Update or
   Acknowledgement that victim exchanges with HA.  The attacker MH
   sends Binding Update for the victim's CoA and its own Home Address.
   Thus the HA will forward all traffic intended to attacker's Home
   Address towards victim's Care-of Address, even though IPsec is
   correctly being used.

   This threat applies in the NEMO context as follows: consider a
   legitimate MR with prefix MNP and an attacker MR with a different
   prefix, both served by the same HA.  Each MR shares a set of keys
   with HA. The attacker MR could instruct the HA to add MNP in the
   binding cache, relating it to its own Home Address (instead of to
   the legitimate MR's Home Address), thus effectively denying service
   to the legitimate MR and redirecting the entire traffic to MNP
   towards the attacker MR.  Even if HA uses IPsec, it could not
   protect against attacker MR's claiming the legitimate MR's MNP.
   However, the prefix table specified by NEMO base protocol
   associates a MR's Home Address to the MNP that it owns, thus
   constituting a means for MR to check against attacker MR claiming a
   prefix it does not actually own.

4. Forwarding Information Updates at HA

   How current routing protocols routers authentify each other, how
   they lack a concept of "prefix ownership" (see the "address
   ownership problem" [17]).  How the prefix table might help with
   this.  How routing protocols authentication could be interpreted to
   solve the potential "prefix ownership" problem.  The use of the
   prefix table to help authorizing the injection of route updates is
   different than the use of the same prefix table in explicit mode in
   order to authorize insertion of bindings (in NEMO explicit mode),
   as presented in threat T.x.


Petrescu et al.           Expires July 2004                    [Page 7]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

   The current base NEMO specification contains:

      When the Mobile Router is running a dynamic routing protocol as
      described in section 7, it injects routing update messages into
      the Home Link.  The Home Agent MUST verify that the Mobile
      Router is allowed to send routing updates before processing the
      messages and propagating the routing information.

5. Nested Mobility

   T.11 DoS threat on TLMR due to too many levels of nested networks:
   several moving networks may attach one under the other thus forming
   a nested aggregation of moving networks ("levels" can be pictured
   as follows: first MR attached under TLMR makes it for a one-level
   aggregation of moving networks; a second MR attached under TLMR is
   still a one-level aggregation; were the second MR attached under
   the first MR, it would have been a two-level aggregation).

   Naturally, the top-level MR will forward traffic of all moving
   networks attached under it.  When the number of levels is large,
   this may become an overload on the original expectations of the
   capabilities of this Mobile Router (overload in the form of more
   cycles dedicated to IPv6 Fragmentation and Reassembly, as well as
   Path MTU calculations), thus becoming a DoS attack.

   It is thus possible for MR to need to limit the number of levels of
   moving networks nesting under it; it could use the Tunnel
   Encapsulation option by setting a limit on the number of levels of
   mobile networks below it.

   Nested mobility configurations appear also when Mobile Hosts visit
   mobile networks.  However, all Mobile Hosts will always attach to a
   same level; given a mobile network, it is not possible to build a
   more than one-level nested aggregation only by adding Mobile Hosts
   (MH's don't attach one under the other).  Thus, the above mentioned
   threat of nested configurations is pertinent to nested moving
   networks exclusively.

6. Other Threats

   Other threats exist.

Acknowledgements

   Threats related to network mobility have been discussed on the IETF
   NEMO WG list, whose members are acknowledged here.

   Seongho Cho provided significant feedback about several threats.

A. IPsec Architecture for Nested Mobility

   The IPsec architecture can be particularized for nested mobility
   cases by using nested encapsulation.  In the figure below we
   picture the protection of NEMO signalling between MR1 and its HA
   (HA_MR1), when the moving network of MR1 is nesting within the

Petrescu et al.           Expires July 2004                    [Page 8]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

   moving network of MR2 (it is assumed that the MR2 has already
   performed NEMO signalling with its own HA - HA_MR2).  The first
   level of IPsec protection is offered by the AH/ESP transport mode
   between MR1 and HA_MR1 (1).  The second level is offered by AH/ESP
   tunnel mode between MR2 and HA_MR2 (2).

           +--------+   +--------+     +--------+   +--------+
           |        |   |        |     |        |   |        |
           | Mobile |   | Mobile |__2__|  Home  |___|  Home  |
           | Sec GW |=1=| Sec GW |=====| Sec GW |===| Sec GW |
           |  (MR1) |   |  (MR2) |-----|(HA_MR2)|---|(HA_MR1)|
           |        |   |        |     |        |   |        |
           +--------+   +--------+     +--------+   +--------+

   The IPsec protection of application-level traffic between LFN and
   CN, when LFN belongs to a nested moving network is pictured below.
   The first level of protection is offered by the AH/ESP tunnel mode
   between MR1 and HA_MR1 while the second is offered by the AH/ESP
   tunnel mode between MR2 and HA_MR2.


           +--------+   +--------+     +--------+   +--------+
           |        |   |        |__2__|        |   |        |
  +-----+  | Mobile |_1_| Mobile |_____|  Home  |___|  Home  |  +----+
  | LFN |..| Sec GW |...| Sec GW |.....| Sec GW |...| Sec GW |..| CN |
  +-----+  |  (MR1) |---|  (MR2) |-----|(HA_MR2)|---|(HA_MR1)|  +----+
           |        |   |        |-----|        |   |        |
           +--------+   +--------+     +--------+   +--------+


   A parcticular case of nested mobility configuration is the visit of
   of a MH within a moving network.  The signalling protection is
   offered by AH/ESP in transport mode between MH and HA_MH (1) and by
   AH/ESP offered by AH/ESP in tunnel mode between MR and HA_MR (2).

               +--------+                        +--------+  +-------+
   +--+        | Mobile |___________2____________|  Home  |  |       |
   |MH|===1====| Sec GW |========================| Sec GW |==| HA_MH |
   +--+        |  (MR)  |------------------------| (HA_MR)|  |       |
               +--------+                        +--------+  +-------+

   Still in the case of nested mobility of a MH within a moving
   network, the application-level traffic between MH and CN is offered
   a first level of protection by the AH/ESP tunnel mode between MH
   and HA_MN (1) and a second level by the AH/ESP tunnell mode between
   MR and HA_MR (2).

           +--------+                  +--------+   +-------+
  +---+    |        |_________2________|        |   |       |
  |   |_1__| Mobile |__________________|  Home  |___|       |    +----+
  |MH |....| Sec GW |..................| Sec GW |...| HA_MH |....| CN |
  |   |----|  (MR)  |------------------| (HA_MR)|---|       |    +----+
  +---+    |        |------------------|        |   |       |
           +--------+                  +--------+   +-------+


Petrescu et al.           Expires July 2004                    [Page 9]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

B. IPsec Protection of Binding Updates and Acknowledgements

  In this section, we used the following NEMO messages for threat
  analysis: Binding Update, Binding Acknowldegement.  The following
  fields have been considered as relevant for NEMO threat analysis:

    -src and dst addresses in the base header.
    -the Home Address in the Destination Options 0 header of the
     Binding Update.
    -the R bit in the AHLKR field of the Binding Update.
    -the Prefix Len and Mobile Network Prefix fields in a Binding
     Update sent in explicit mode.
    -the Routing Type, Segments Left and Home Address fields in the
     Routing Header Type 2 of the Binding Acknowledgement.
    -the Status field of the Binding Acknowledgement.

  In building the packet formats below, the following notation was
  used:

  *: NEMO field, or bit or value introduced by NEMO base protocol, or
     containing helpful information for realization of the
     NEMO-related risks described in this document.
  x: authenticated field, as covered by AH ICV.
  y: encrypted field, as part of ESP payload data.
  z: authenticated field, as part of ESP authentication data.

  For example, fields that are marked (*xyz) are helping realizing
  threats, but are protected by AH and ESP non-NULL authentication,
  thus rendering most NEMO threats impossible; fields that are only
  marked (*) are not protected, thus might constitute security risks.

  In the following sections, pairs consisting of a Binding Update and
  the corresponging Binding Acknowledgement are illustrated.  Each
  section describes two pairs: the pair when MR is in a foreign
  network followed by the pair when MR is returning to the home
  network.  Section B.1 presents unprotected pairs while section B.6
  presents pairs protected both by AH and ESP in transport mode (ESP
  with non-NULL authentication algorithm).  Intermediary sections use
  transport mode AH exclusively or transport mode ESP exclusively (ESP
  with or without authentication algorithm).
















Petrescu et al.           Expires July 2004                   [Page 10]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

B.1 Unprotected BU and BAck when MR in foreign network

   Base Header                        Base Header
     src: CoA                   (*)     src: Home Agent address    (*)
     dst: Home Agent address    (*)     dst: CoA                   (*)
   Destination Options                Routing Header
     Home Address: Home Address (*)     Routing Type: 2            (*)
   Mobility Header                      Segments Left: 1           (*)
     Header Len                         Home Address: Home Address (*)
     MH Type:                         Mobility Header
     Reserved:                          Header Len:
     Checksum:                          MH Type:
     Message Data                       Reserved:
       Seq #                            Checksum:
       AHLKR                    (*)     Message Data
       Lifetime:                          Status                   (*)
       Mobility Options                   K:
         Alternate CoA: CoA               Reserved
         Mobile Net Prefix Option         Seq #:
           Prefix Len:          (*)       Lifetime:
           Mobile Net Prefix:   (*)       Mobility Options
                                            Binding Refresh Advice
                                              Refresh Interval:


             Unprotected BU and BAck when MR returns home

   Base Header                        Base Header
     src: Home Address          (*)     src: Home Agent address    (*)
     dst: Home Agent address    (*)     dst: Home Address          (*)
   Mobility Header                    Mobility Header
     Header Len                         Header Len:
     MH Type:                           MH Type:
     Reserved:                          Reserved:
     Checksum:                          Checksum:
     Message Data                       Message Data
       Seq #                              Status                   (*)
       AHLKR                    (*)       K:
       Lifetime:                          Reserved
       Mobility Options                   Seq #:
         Mobile Net Prefix Option         Lifetime:
           Prefix Len:          (*)       Mobility Options
           Mobile Net Prefix:   (*)         Binding Refresh Advice
                                            Refresh Interval:












Petrescu et al.           Expires July 2004                   [Page 11]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

B.2 AH protected BU and BAck when MR in foreign network

  Base Header                         Base Header
    src: CoA                   (*x)     src: Home Agent address   (*x)
    dst: Home Agent address    (*x)     dst: CoA                  (*x)
  Destination Options                 Routing Header
    Home Address: Home Address (*x)     Routing Type: 2           (*x)
  Authentication Header                 Segments Left: 1          (*x)
    SPI:                                Home Address: Home Address(*x)
    Seq No:                           Authentication Header
    ICV:                                SPI:
  Mobility Header                       Seq No:
    Header Len                          ICV:
    MH Type:                          Mobility Header
    Reserved:                           Header Len:
    Checksum:                           MH Type:
    Message Data                        Reserved:
      Seq #                             Checksum:
      AHLKR                    (*x)     Message Data
      Lifetime:                           Status                  (*x)
      Mobility Options                    K:
        Alternate CoA: CoA                Reserved
        Mobile Net Prefix Option          Seq #:
          Prefix Len:          (*x)       Lifetime:
          Mobile Net Prefix:   (*x)       Mobility Options
                                            Binding Refresh Advice
                                              Refresh Interval:


            AH protected BU and BAck when MR returns home

  Base Header                         Base Header
    src: Home Address          (*x)     src: Home Agent address   (*x)
    dst: Home Agent address    (*x)     dst: Home Address         (*x)
  Authentication Header               Authentication Header
    SPI:                                SPI:
    Seq No:                             Seq No:
    ICV:                                ICV:
  Mobility Header                     Mobility Header
    Header Len                          Header Len:
    MH Type:                            MH Type:
    Reserved:                           Reserved:
    Checksum:                           Checksum:
    Message Data                        Message Data
      Seq #                               Status                  (*x)
      AHLKR                    (*x)       K:
      Lifetime:                           Reserved
      Mobility Options                    Seq #:
        Mobile Net Prefix Option          Lifetime:
          Prefix Len:          (*x)       Mobility Options
          Mobile Net Prefix:   (*x)          Binding Refresh Advice
                                             Refresh Interval:




Petrescu et al.           Expires July 2004                   [Page 12]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

B.3 ESP NULL auth algo for BU and BAck when MR in foreign network

  Base Header                         Base Header
    src: CoA                    (*)     src: Home Agent address    (*)
    dst: Home Agent address     (*)     dst: CoA                   (*)
  Destination Options                 Routing Header
    Home Address: Home Address  (*)     Routing Type: 2            (*)
  ESP Header                            Segments Left: 1           (*)
    SPI:                                Home Address: Home Address (*)
    Seq No:                           ESP Header
  Mobility Header                       SPI:
    Header Len                          Seq No:
    MH Type:                          Mobility Header
    Reserved:                           Header Len:
    Checksum:                           MH Type:
    Message Data                        Reserved:
      Seq #                             Checksum:
      AHLKR                    (*y)     Message Data
      Lifetime:                           Status                  (*y)
      Mobility Options                    K:
        Alternate CoA: CoA                Reserved
        Mobile Net Prefix Option          Seq #:
          Prefix Len:          (*y)       Lifetime:
          Mobile Net Prefix:   (*y)       Mobility Options
  ESP Trailer                               Binding Refresh Advice
                                              Refresh Interval:
                                      ESP Trailer


       ESP NULL auth algo for BU and BAck when MR returns home

  Base Header                         Base Header
    src: Home Address           (*)     src: Home Agent address    (*)
    dst: Home Agent address     (*)     dst: Home Address          (*)
  ESP Header                          ESP Header
    SPI:                                SPI:
    Seq No:                             Seq No:
  Mobility Header                     Mobility Header
    Header Len                          Header Len:
    MH Type:                            MH Type:
    Reserved:                           Reserved:
    Checksum:                           Checksum:
    Message Data                        Message Data
      Seq #                               Status                  (*y)
      AHLKR                    (*y)       K:
      Lifetime:                           Reserved
      Mobility Options                    Seq #:
        Mobile Net Prefix Option          Lifetime:
          Prefix Len:          (*y)       Mobility Options
          Mobile Net Prefix:   (*y)         Binding Refresh Advice
  ESP Trailer                                 Refresh Interval:
                                      ESP Trailer




Petrescu et al.           Expires July 2004                   [Page 13]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

B.4 ESP non-NULL auth algo for BU and BAck when MR in foreign network

  Base Header                         Base Header
    src: CoA                    (*)     src: Home Agent address    (*)
    dst: Home Agent address     (*)     dst: CoA                   (*)
  Destination Options                 Routing Header
    Home Address: Home Address  (*)     Routing Type: 2            (*)
  ESP Header                            Segments Left: 1           (*)
    SPI:                                Home Address: Home Address (*)
    Seq No:                           ESP Header
  Mobility Header                       SPI:
    Header Len                          Seq No:
    MH Type:                          Mobility Header
    Reserved:                           Header Len:
    Checksum:                           MH Type:
    Message Data                        Reserved:
      Seq #                             Checksum:
      AHLKR                   (*yz)     Message Data
      Lifetime:                           Status                 (*yz)
      Mobility Options                    K:
        Alternate CoA: CoA                Reserved
        Mobile Net Prefix Option          Seq #:
          Prefix Len:         (*yz)       Lifetime:
          Mobile Net Prefix:  (*yz)       Mobility Options
  ESP Trailer                               Binding Refresh Advice
  ESP Auth                                    Refresh Interval:
                                      ESP Trailer
                                      ESP Auth


     ESP non-NULL auth algo for BU and BAck when MR returns home

  Base Header                         Base Header
    src: Home Address           (*)     src: Home Agent address    (*)
    dst: Home Agent address     (*)     dst: Home Address          (*)
  ESP Header                          ESP Header
    SPI:                                SPI:
    Seq No:                             Seq No:
  Mobility Header                     Mobility Header
    Header Len                          Header Len:
    MH Type:                            MH Type:
    Reserved:                           Reserved:
    Checksum:                           Checksum:
    Message Data                        Message Data
      Seq #                               Status                 (*yz)
      AHLKR                   (*yz)       K:
      Lifetime:                           Reserved
      Mobility Options                    Seq #:
        Mobile Net Prefix Option          Lifetime:
          Prefix Len:         (*yz)       Mobility Options
          Mobile Net Prefix:  (*yz)         Binding Refresh Advice
  ESP Trailer                                 Refresh Interval:
  ESP Auth                            ESP Trailer
                                      ESP Auth


Petrescu et al.           Expires July 2004                   [Page 14]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

B.5 AH and ESP NULL for BU and BAck when MR in foreign network

  Base Header                         Base Header
    src: CoA                   (*x)     src: Home Agent address   (*x)
    dst: Home Agent address    (*x)     dst: CoA                  (*x)
  Destination Options                 Routing Header
    Home Address: Home Address (*x)     Routing Type: 2           (*x)
  Authentication Header                 Segments Left: 1          (*x)
    SPI:                                Home Address: Home Address(*x)
    Seq No:                           Authentication Header
    ICV:                                SPI:
  ESP Header                            Seq No:
    SPI:                                ICV:
    Seq No:                           ESP Header
  Mobility Header                       SPI:
    Header Len                          Seq No:
    MH Type:                          Mobility Header
    Reserved:                           Header Len:
    Checksum:                           MH Type:
    Message Data                        Reserved:
      Seq #                             Checksum:
      AHLKR                   (*xy)     Message Data
      Lifetime:                           Status                 (*xy)
      Mobility Options                    K:
        Alternate CoA: CoA                Reserved
        Mobile Net Prefix Option          Seq #:
          Prefix Len:         (*xy)       Lifetime:
          Mobile Net Prefix:  (*xy)       Mobility Options
  ESP Trailer                               Binding Refresh Advice
                                              Refresh Interval:
                                      ESP Trailer

























Petrescu et al.           Expires July 2004                   [Page 15]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

         AH and ESP NULL for BU and BAck when MR returns home

  Base Header                         Base Header
    src: Home Address          (*x)     src: Home Agent address   (*x)
    dst: Home Agent address    (*x)     dst: Home Address         (*x)
  Authentication Header               Authentication Header
    SPI:                                SPI:
    Seq No:                             Seq No:
    ICV:                                ICV:
  ESP Header                          ESP Header
    SPI:                                SPI:
    Seq No:                             Seq No:
  Mobility Header                     Mobility Header
    Header Len                          Header Len:
    MH Type:                            MH Type:
    Reserved:                           Reserved:
    Checksum:                           Checksum:
    Message Data                        Message Data
      Seq #                               Status                 (*xy)
      AHLKR (*xy)                         K:
      Lifetime:                           Reserved
      Mobility Options                    Seq #:
        Mobile Net Prefix Option          Lifetime:
          Prefix Len:         (*xy)       Mobility Options
          Mobile Net Prefix:  (*xy)         Binding Refresh Advice
  ESP Trailer                                 Refresh Interval:
                                      ESP Trailer





























Petrescu et al.           Expires July 2004                   [Page 16]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

B.6 AH and ESP non-NULL for BU and BAck when MR in foreign network

  Base Header                         Base Header
    src: CoA                   (*x)     src: Home Agent address   (*x)
    dst: Home Agent address    (*x)     dst: CoA                  (*x)
  Destination Options                 Routing Header
    Home Address: Home Address (*x)     Routing Type: 2           (*x)
  Authentication Header                 Segments Left: 1          (*x)
    SPI:                                Home Address: Home Address(*x)
    Seq No:                           Authentication Header
    ICV:                                SPI:
  ESP Header                            Seq No:
    SPI:                                ICV:
    Seq No:                           ESP Header
  Mobility Header                       SPI:
    Header Len                          Seq No:
    MH Type:                          Mobility Header
    Reserved:                           Header Len:
    Checksum:                           MH Type:
    Message Data                        Reserved:
      Seq #                             Checksum:
      AHLKR                  (*xyz)     Message Data
      Lifetime:                           Status                (*xyz)
      Mobility Options                    K:
        Alternate CoA: CoA                Reserved
        Mobile Net Prefix Option          Seq #:
          Prefix Len:        (*xyz)       Lifetime:
          Mobile Net Prefix: (*xyz)       Mobility Options
  ESP Trailer                               Binding Refresh Advice
  ESP Auth                                    Refresh Interval:
                                      ESP Trailer
                                      ESP Auth
























Petrescu et al.           Expires July 2004                   [Page 17]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

       AH and ESP non-NULL for BU and BAck when MR returns home

  Base Header                         Base Header
    src: Home Address          (*x)     src: Home Agent address   (*x)
    dst: Home Agent address    (*x)     dst: Home Address         (*x)
  Authentication Header               Authentication Header
    SPI:                                SPI:
    Seq No:                             Seq No:
    ICV:                                ICV:
  ESP Header                          ESP Header
    SPI:                                SPI:
    Seq No:                             Seq No:
  Mobility Header                     Mobility Header
    Header Len                          Header Len:
    MH Type:                            MH Type:
    Reserved:                           Reserved:
    Checksum:                           Checksum:
    Message Data                        Message Data
      Seq #                               Status                (*xyz)
      AHLKR                  (*xyz)       K:
      Lifetime:                           Reserved
      Mobility Options                    Seq #:
        Mobile Net Prefix Option          Lifetime:
          Prefix Len:        (*xyz)       Mobility Options
          Mobile Net Prefix: (*xyz)         Binding Refresh Advice
  ESP Trailer                                 Refresh Interval:
  ESP Auth                            ESP Trailer
                                      ESP Auth

C. IPsec non-Protection of Home Agent Discovery Messaging

  In this section, we used the following NEMO messages for threat
  analysis: Home Agent Address Discovery and Home Agent Address Reply.
  The following fields have been considered as relevant for NEMO
  threat analysis:

    -src and dst addresses in the base header.
    -the R bit in the ICMPv6 discovery and reply messages.
    -the R bit in the Home Agent Information Option of the Reply
     message.

  In building the packet formats below, the following notation was
  used:

  *: NEMO field, or bit or value introduced by NEMO base protocol, or
     containing helpful information for realization of the
     NEMO-related risks described in this document.
  x: authenticated field, as covered by AH ICV.
  y: encrypted field, as part of ESP payload data.
  z: authenticated field, as part of ESP authentication data.

  For example, fields that are marked (*xyz) are helping realizing
  threats, but are protected by AH and ESP non-NULL authentication,
  thus rendering most NEMO threats impossible; fields that are only
  marked (*) are not protected, thus might constitute security risks.

Petrescu et al.           Expires July 2004                   [Page 18]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

C.1 Unprotected Home Agent Address Discovery and Reply

   Base Header                        Base Header
     src: CoA                   (*)     src: Home Agent address    (*)
     dst: Home Agents anycast   (*)     dst: CoA                   (*)
   ICMPv6 message                     ICMPv6 message
     Type                               Type
     Code                               Code
     Checksum                           Checksum
     Identifier                         Identifier
     R                          (*)     R                          (*)
                                        Home Agent Information Option
                                          Type
                                          Length
                                          R                        (*)

   Remark the the Agent Discovery messages are not protected at all by
   IPsec and may lead to important security threats.  NEMO threat
   analysis is concerned solely by the use of the R bit of these
   messages, and by the risks involved on tampering with the integrity
   or the confidentiality of this bit exclusively.

References

   [1] Arkko, J., Devarapalli, V. and Dupont, F., "Using IPsec to
       Protect Mobile IPv6 Signaling between Mobile Nodes and Home
       Agents" (work in progress).  Internet Draft, IETF.
       draft-ietf-mobileip-mipv6-ha-ipsec-06.txt. June 2003.

   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

   [3] Barbir, A., Murphy, S. and Yang, Y., "Generic Threats to
       Routing Protocols".  Internet Draft, IETF.
       draft-ietf-rpsec-routing-threats-02.txt.  August 2003.

   [4] Devarapalli, V., Wakikawa, R., Petrescu, A. and Thubert, P.,
       "Nemo Basic Support Protocol" (work in progress).  Internet
       Draft, IETF. draft-ietf-nemo-basic-support-02.txt.  December
       2003.

   [5] Ernst, T. and Lach, H.-Y, "Network Mobility Support
       Terminology", Internet Draft,
       IETF. draft-ietf-nemo-terminology-00.txt. May 2003.

   [6] Ferguson, P. and Senie, D., "Network Ingress Filtering:
       Defeating Denial of Service Attacks which employ IP Source
       Address Spoofing", BCP 38, RFC 2827, May 2000.

   [7] Gupta, M. and Melam, N., "Authentication/Confidentiality for
       OSPFv3" (work in progress).  Internet Draft, IETF.
       draft-ietf-ospf-ospfv3-auth-04.txt.  December 2003.




Petrescu et al.           Expires July 2004                   [Page 19]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

   [8] Johnson, D., Perkins, C. and Arkko, J., "Mobility Support in
       IPv6" (work in progress).  Internet Draft,
       IETF. draft-ietf-mobileip-ipv6-24.txt.  June 2003.

   [9] Jung, S., Zhao, F., Wu, F., Kim, H. and Sohn, S., "Threat
       Analysis for NEMO" (work in progress).  Internet Draft, IETF.
       draft-jung-nemo-threat-analysis-01.txt.  October 2003.

   [10] Kent, S. and Seo, K., "Security Architecture for the Internet
        Protocol" (work in progress).  Internet Draft,
        IETF. draft-ietf-ipsec-rfc2401bis-02.txt.  January 2004.

   [11] Kent, S., "IP Authentication Header" (work in progress).
        Internet Draft, IETF. draft-ietf-ipsec-rfc2402bis-05.txt.
        September 2003.

   [12] Kent, S. and Atkinson, R., "IP Encapsulating Security Payload
        (ESP)", RFC 2406, November 1998.

   [13] Madson, C., "The Use of HMAC-MD5-96 within ESP and AH", RFC
        2403, November 1998.

   [14] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher
        Algorithm with Explicit IV", RFC 2405, November 1998.

   [15] Madson, C. and Glenn, R., "The Use of HMAC-SHA-1-96 within ESP
        and AH", RFC 2404, November 1998.

   [16] Nikander, P., Harkins, D., Patil, B., Roberts, P., Nordmark,
        E. and Makin, A., "Threat Models introduced by Mobile IPv6 and
        Requirements for Security in Mobile IPv6" (work in progress).
        Internet Draft, IETF.
        draft-team-mobileip-mipv6-sec-reqts-00.txt.  December 2001.

   [17] Nikander, P., "An Address Ownership Problem in IPv6" (work in
        progress).  Internet Draft, IETF.
        draft-nikander-ipng-address-ownership-00.txt.  February 2001.

   [18] Postel, J. and Reynolds, J., "Instructions to RFC Authors",
        RFC 2223, October 1997.

   [19] Rescorla, E., "A Survey of Authentication Mechanisms" (work in
        progress).  Internet Draft, IETF.
        draft-rescorla-auth-mech-02.txt.  October 2003.

   [20] Rescorla, E. and Korver, B., "Guidelines for Writing RFC Text
        on Security Considerations", BCP 72, RFC 3552, July 2003.

   [21] Shirey, R, "Internet Security Glossary", RFC 2828 , May 2000.







Petrescu et al.           Expires July 2004                   [Page 20]


INTERNET-DRAFT          Mobile Networks Threats            January 2004

Changes

   November 2003:  revision 00 submitted.
   January 2004: revision 01 submitted.
     -added appendices with detailed packet formats.
     -added the threat on Home Agent Discovery messaging.
     -added detailed explanations on existing threats and how IPsec
      headers protect.
     -eliminated the highly generic threats on Confidentiality and
      Integrity to better focus on NEMO specific threats.

Authors' Addresses

  Alexandru Petrescu                 Christophe Janneteau
  Motorola Labs                      Motorola Labs
  Parc les Algorithmes St Aubin      Parc les Algorithmes St Aubin
  Gif-sur-Yvette 91193               Gif-sur-Yvette 91193
  France                             France
  Phone:  +33 1 69354827             Phone:  +33 1 69352548
  Alexandru.Petrescu@motorola.com    Christophe.Janneteau@motorola.com

  Alexis Olivereau                   Hong-Yon Lach
  Motorola Labs                      Motorola Labs
  Parc les Algorithmes St Aubin      Parc les Algorithmes St Aubin
  Gif-sur-Yvette 91193               Gif-sur-Yvette 91193
  France                             France
  Phone:  +33 1 69352516             Phone:  +33 1 69352536
  Alexis@motorola.com                Hong-Yon.Lach@motorola.com

Copyright (C) The Internet Society (2004).  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.

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

Petrescu et al.           Expires July 2004                   [Page 21]