[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Mobility Optimizations                                          J. Arkko
Internet-Draft                              Ericsson Research NomadicLab
Expires: November 19, 2004                                       C. Vogt
                                                 University of Karlsruhe
                                                            May 21, 2004


       Credit-Based Authorization for Binding Lifetime Extension
            draft-arkko-mipv6-binding-lifetime-extension-00

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3667.

   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.

   This Internet-Draft will expire on November 19, 2004.

Copyright Notice

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

Abstract

   Mobile IPv6 return routability mechanisms require home and care-of
   address keygen tokens to be used to authorize a binding update to
   correspondent nodes. The current rules dictate that such
   authorization be performed every seven minutes, using tokens at most
   three and half minutes old. This requirement results in an average
   signaling traffic of around 7 bits per second when the hosts are not
   moving around. This traffic load by itself is neglible, but can be
   problematic for hosts in standby mode. We present a secure and
   lightweight extension of return routability that can reduce this



Arkko & Vogt           Expires November 19, 2004                [Page 1]

Internet-Draft         CBA for Lifetime Extension               May 2004


   signaling load to around 0.1 bits per second, and require hosts to
   wake up much less frequently.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Specification of Requirements  . . . . . . . . . . . . . . . .  4
   3.  The Problem  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Protocol Definition  . . . . . . . . . . . . . . . . . . . . .  5
         4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . .  5
         4.2 Behaviour  . . . . . . . . . . . . . . . . . . . . . . .  6
         4.3 State Requirements . . . . . . . . . . . . . . . . . . .  8
         4.4 Lifetime Credit Authorization Option . . . . . . . . . .  8
   5.  Performance Considerations . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 11
       Normative References . . . . . . . . . . . . . . . . . . . . . 12
       Informative References . . . . . . . . . . . . . . . . . . . . 12
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
       Intellectual Property and Copyright Statements . . . . . . . . 14





























Arkko & Vogt           Expires November 19, 2004                [Page 2]

Internet-Draft         CBA for Lifetime Extension               May 2004


1. Introduction

   This document focuses on mobile nodes that stay long periods on the
   same care-of address, and wish to retain efficient routing throughout
   these periods. In order to keep Mobile IPv6 route optimization state
   alive, periodic signaling is needed. Such periodic signaling consumes
   a small amount of bandwidth from the point of view of the
   participants, but the total amount of signaling load in a commercial
   network can be large.

   More importantly, typical implementations of hand-held devices employ
   a standby mode in order to conserve battery energy. Periodic
   signaling causes a need to wake up for such nodes, and can consume
   extra energy. While it is possible to re-establish route optimization
   at the time when the mobile node has some actual traffic to send,
   this will cause additional signaling and delay before actual payload
   traffic can flow efficiently.

   Current Mobile IPv6 return routability mechanisms require home and
   care-of keygen tokens to be used to authorize a Binding Update to
   correspondent nodes. According to the current rules, such tokens may
   be used at most MAX_TOKEN_LIFETIME seconds (3.5 minutes) after they
   have been acquired in an address test procedure. Section 5.2.7 of the
   base specification [2] states:

      A fast moving mobile node MAY reuse a recent home keygen token
      from a correspondent node when moving to a new location, and just
      acquire a new care-of keygen token to show routability in the new
      location.

   Vogt et al defined the Early Binding Updates [6] procedure to expand
   on this approach a little bit by suggesting that a pre-emptive home
   test exchange be used to ensure that a home keygen token is available
   when it is needed. Early Binding Updates could also be used to
   perform a care-of address test in parallel with sending payload
   traffic. In this application the Early Binding Updates do not fully
   protect against flooding attacks. This has since then been corrected
   in [12].

   The problem with the base mechanism and the Early Binding Update
   scheme is, however, that both require extra signaling. A number of
   proposals have been made to reduce this, see for instance [13], [7],
   and [8]. Some of these mechanisms are extremely efficient, such as
   the preconfigured binding keys [13] which adds no signaling at all.
   Other proposals such as [8] employ techniques such as the
   Cryptographically Generated Addresses (CGAs) that can achieve both
   high security and efficiency, particularly for testing home address
   ownership.



Arkko & Vogt           Expires November 19, 2004                [Page 3]

Internet-Draft         CBA for Lifetime Extension               May 2004


   This document explores the design space into a new direction, namely
   stretching the signaling frequency limits of the current return
   routability mechanism without introducing new vulnerabilities. Our
   design is based on explicitly addressing the costs and benefits of
   attacks. This proposal is not necessarily intended to be a standalone
   proposal for Mobile IPv6 optimization. Rather, it is intended as a
   research idea that could be used as a possible component in a
   solution that addresses all aspects of the optimization problem. The
   proposal is in its early stages, however, so additional discussion is
   warranted.

   This document is organized as follows. In Section 3 we discuss the
   performance of the current return routability mechanism. Section 4
   describes our solution.  Finally, Section 5 evaluates the performance
   of this solution, and Section 6 analyzes its security implications.

2. Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  The key
   words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and
   "MAY" in this document are to be interpreted as described in [1].

3. The Problem

   The performance of the current return routability mechanism can be
   evaluated according to its impact on handover delay, the amount of
   bandwidth it uses per movement, and the amount of bandwith it uses
   when not moving. In this document we focuse only on the last aspect.

   Current specifications require a periodic return routability test and
   the re-establishment of the binding at the correspondent node. One
   round of a full return routability procedure requires the following
   messages:

      HOTI: This needs 40 + 8 + 8 or 56 bytes.

      HOT: This needs  40 + 8 + 16 or 64 bytes.

      COTI: This needs 40 + 8 + 8 or 56 bytes.

      COT: This needs  40 + 8 + 16 or 64 bytes.

      BU: This needs   40 + 6 + 6 + 6 + 2 + 12 or 72 bytes.

      BA: This needs   40 + 6 + 6 + 12 or 64 bytes.

   Taken together, this results in 376 bytes, or on the average about



Arkko & Vogt           Expires November 19, 2004                [Page 4]

Internet-Draft         CBA for Lifetime Extension               May 2004


   7.16 bits/second, if performed every seven minutes. While this is an
   insignificant bandwidth for nodes that are actually communicating, it
   can still represent a burden for hosts that just have the bindings
   ready for a possible packet but are not currently communicating. This
   can be problematic for hosts in standby mode, for instance.

   When two mobile nodes are communicating with each other, these
   numbers double, i.e., 14.32 bits/second. This is because both nodes
   need to act as receivers and senders of the messages.

   The bandwidth itself may also be an issue in some scenarios.  For
   instance, a correspondent node such as a SIP proxy may have a large
   number of mobile nodes, and the sum of the small bandwidth from each
   of them becomes considerable. The traffic load for a home agent may
   also be significant. In a network of a 100 million hosts, keeping
   route optimization up all the time between the hosts and some other
   node would require 220 Mbits/second of traffic through the home
   agent(s), and 716 Mbit/second for the other nodes altogether.

   Note that when evaluating the impact of signaling on performance, one
   should take into account the whole stack and not inspect just one
   layer or task. For instance, if the mobile node actually moved, the
   above signaling would have to be compared to the link layer
   signaling, access control and authentication signaling, IPv6 neighbor
   discovery signaling, and so forth. Such other signaling introduces
   quite significant delays, but is not relevant for discussion in this
   draft as we assume a stable mobile node.

4. Protocol Definition

4.1 Overview

   We take an approach similar to Credit Based Authorization (CBA) [12],
   developed from Early Binding Updates [6] and a suggestion to track
   packet counts instead of a fixed time [9] into a fully flegded
   credit-based scheme [10, 11, 12]. These techniques are specific
   instances of microeconomics-based solutions to security problems
   [3, 4].

   CBA for Early Binding Updates [12] focuses on the care-of address
   tests; the objective is to weigh the effort the mobile node has spent
   in communicating with the correspondent node, and to ensure that any
   unverified communication sent to a claimed new address causes less
   damage than this effort.  The rationale is that even without Mobile
   IPv6, attackers can easily cause similar flooding attacks by sending
   packets to the victim directly or via a reflector; the real issue is
   avoiding amplification. By ensuring that the amplification achieved
   via Early Binding Updates is smaller than the amplification achieved



Arkko & Vogt           Expires November 19, 2004                [Page 5]

Internet-Draft         CBA for Lifetime Extension               May 2004


   via these other attacks, the overall seriousness of vulnerabilities
   is not increased.

   In our approach, the same idea is used to reduce the amount of
   signaling required for address tests. The primary reason why address
   tests are needed is to ensure that a mobile node "owns" its home
   address and is reachable at the care-of addresses in question. In
   basic Mobile IPv6 design, this is achieved by a testing that the
   mobile node can receive packets at the given address, i.e., is on the
   routing path to that address. If this test was not regularly done,
   attackers who only visited the path for a short time could claim
   address ownership for a long time. This vulnerability does not exist
   in the Internet today, as was hence considered as something that
   should be avoided [5].

   However, the effort-damage considerations from the Early Binding
   Updates can be applied also to the frequency of address tests.
   Assuming at least one test is performed, the frequency of the tests
   is not related to flooding.  Instead, the efforts and damage must be
   counted in different units than in Early Binding Updates.
   Specifically, we can track the amount of time the mobile node has
   been reachable at its home address, and we can set a limit on how
   long the mobile node can continue to claim this without performing a
   new test.  So, instead of the current fixed limit, the mobile node
   can, for instance, continue to use an existing address test 30%
   longer than the time it has already been reachable at this address.
   The only thing that is needed is that the mobile node can prove it is
   still the same node than it has been at the time of previous tests.

4.2 Behaviour

   This section shows the steps of the protocol. For brevity, we omit
   the description of packet formats.

   First, the mobile node establishes a binding cache entry:

      Step 1. MN->HA->CN: Home test init

      Step 2. CN->HA->MN: Home test

      Step 3. MN->CN: Care-of test init

      Step 4. MN->CN: Care-of test

      Step 5. MN->CN: Binding Update + Lifetime Credit Authorization
         option





Arkko & Vogt           Expires November 19, 2004                [Page 6]

Internet-Draft         CBA for Lifetime Extension               May 2004


      Step 6. MN->CN: Binding Acknowledgement + Lifetime Credit
         Authorization option

   These steps are equivalent to a standard correspondent binding update
   procedure, except that the initial lifetime specified MUST be less
   than or equal to 30% of MAX_RR_BINDING_LIFETIME, and that the
   Lifetime Credit Authorization option is included in the Binding
   Update and Acknowledgement. The contents of the option is based on
   the Kbm, and it will be discussed in more detail later.

   After time t, the mobile node needs to re-establish the binding, as
   its lifetime is about to run out. (Note that the binding may have
   been redone several times during time t; the important factor is the
   total amount of time the binding has existed.)

      Step 7. MN->HA->CN: Home test init

      Step 8. CN->HA->MN: Home test

      Step 9. MN->CN: Care-of test init

      Step 10. MN->CN: Care-of test

   A new return routability procedure is run here, again in the standard
   manner.

      Step 11. MN->CN: Binding update + Lifetime Credit Authorization
         option

   The requested lifetime in the Binding Update  is not limited to
   MAX_RR_BINDING_LIFETIME (7 minutes) but rather t * 0.3. To authorize
   this, the mobile node has to provide a keyed hash using the key
   Kcredit, proving that it has participated in all the binding updates
   between Step 5 and Step 10. Kcredit is calculated as follows:

     Kcredit = hash(KbmN | hash(KbmN-1 | hash(KbmN-2 | ...Kbm1)))

   Here Kbm1 through KbmN represent the Kbm used to calculate the
   Binding Authorization Data option in the Step 5 binding update and
   all subsequent binding updates. Note that neither the mobile nor the
   correspondent node needs to remember the whole sequence, as they can
   calculate the next Kcredit value based on the previous Kcredit value
   and the latest Kbm. However, in order to know Kcredit one has to have
   had knowledge of all Kbm values.

   We set an upper bound for these lifetimes in order to ensure that the
   system can still recover. The upper bound is 8 hours.




Arkko & Vogt           Expires November 19, 2004                [Page 7]

Internet-Draft         CBA for Lifetime Extension               May 2004


   Finally, the correspondent node responds:

      Step 12. CN->MN: Binding Acknowledgement + Lifetime Credit
         Authorization option

   The returned Lifetime Credit Authorization option assures the mobile
   node that the correspondent node is also still the same node it has
   been in the past. It also informs the mobile node that it supports
   this extension. The returned lifetime is set according to the
   correspondent node's calculation of the time t.

   Note that we did not propose any modifications to the actual return
   routability test, binding updates, or the timing of these events with
   respect to data packet flows. The solution outlined here can be used
   in conjunction with other optimizations, such as those defined in
   [12].

4.3 State Requirements

   Both mobile and correspondent nodes hold some state in the Binding
   Cache Entries, related to the credit authorization. The following
   conceptual information MUST be kept:

   o  The total time there has been a binding for this home address.

   o  The current Kcredit value.

   o  The number of Kbm values included in the Kcredit value.


4.4 Lifetime Credit Authorization Option

   This extension introduces one new mobility option, the Lifetime
   Credit Authorization option.

   This option is similar to the Binding Authorization Data option, but
   uses Kcredit as the key instead of Kbm.

   The Lifetime Credit Authorization option does not have alignment
   requirements. The format of this option is as follows:











Arkko & Vogt           Expires November 19, 2004                [Page 8]

Internet-Draft         CBA for Lifetime Extension               May 2004


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |   Type = TBD  | Option Length |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                N              |            Reserved           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                   Lifetime Authenticator                      |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This option is valid in the Binding Update and Binding
   Acknowledgement messages. Its field are filled as follows:

   Type

      TBD < To Be Assigned By IANA >

   Option Length

      This field contains the length of the authenticator in octets.

   N

      16-bit counter, representing the number of Kbm keys included in
      Kcredit so far. This value is used by the correspondent node to
      ensure that it is synchronized with the mobile node regarding the
      keying material. If the value sent by the mobile node differs from
      the expected value, the correspondent node MUST send a value of 1
      in the Binding Acknowledgement and reset the lifetime to the
      initial value (see Section Section 4.2).

   Reserved

      16-bit reserved field.  The value MUST be initialized to zero by
      the sender, and MUST be ignored by the receiver.

   Lifetime Authenticator

      This field contains a keyed MAC calculated as follows:


        Mobility Data = care-of address | correspondent | MH Data
        Lifetime Authenticator = First (96, HMAC_SHA1 (Kcredit,
                                                       Mobility Data))



Arkko & Vogt           Expires November 19, 2004                [Page 9]

Internet-Draft         CBA for Lifetime Extension               May 2004



      Where | denotes concatenation and "correspondent" is the IPv6
      address of the correspondent node.  Note that, if the message is
      sent to a destination which is itself mobile, the "correspondent"
      address may not be the address found in the Destination Address
      field of the IPv6 header; instead the home address from the type 2
      Routing header should be used.

      "MH Data" is the content of the Mobility Header, excluding the
      Lifetime Authenticator field itself and the Authenticator field
      from the Binding Authorization Data option. The Lifetime
      Authenticator value is calculated as if the Checksum field in the
      Mobility Header was zero.  The Checksum in the transmitted packet
      is still calculated in the usual manner, with the calculated
      Authenticator being a part of the packet protected by the
      Checksum.

      The first 96 bits from the MAC result are used as the Lifetime
      Authenticator field.


5. Performance Considerations

   Initially, the token and BCE lifetimes provided by this scheme are
   smaller than those in the current return routability method. This
   provides additional security against attackers that just came on the
   link. However, after a while the lifetimes become higher and there's
   a significant reduction in the need for signaling. For instance,
   after the binding has been up for an hour, home address tests can be
   performed as infrequently as once every eighteen minutes compared to
   the standard seven minutes.

   For a connection that stays up continuously, the lifetimes approach
   the maximum lifetimes (eight hours), which implies that at least
   three return routability protocol runs have to be performed per day.
   The signaling load this of this is around 0.104 bits per second, or
   68 times less than in the baseline method.

6. Security Considerations

   The security of this approach is based on the following principles:

   o  The bindings resulting from running this method are not permanent,
      i.e., can be overridden at any time by a new run of the return
      routability procedure and binding procedures. This avoids problems
      associated with attackers grabbing a binding before legitimate
      nodes.




Arkko & Vogt           Expires November 19, 2004               [Page 10]

Internet-Draft         CBA for Lifetime Extension               May 2004


   o  With the timing formula that is used, it is guaranteed that
      whatever exposure there is for on-path attackers, this method
      increases this exposure by a known amount (30%). It is already
      known that the only vulnerability in the original return
      routability mechanism is a slight, constant, increase in exposure
      to on-path attackers. This problem is called the time shifting
      vulnerability in [5]. The difference between original return
      routability and this method is that the exposure increase is
      variable instead of a constant. In both cases it is, however,
      limited and quantifiable.

   o  Depending on the amount of time the node has been on the link,
      this method provides either a smaller or larger window of
      vulnerability. We argue that this is at least as reasonable as the
      constant windows in RR.

   Attackers who are temporarily on the path between the mobile and
   correspondent nodes (and simultaneously also on the path between the
   home agent and correspondent node) can fraudulently represent the
   mobile node in the return routability procedure. This implies that
   the attacker can get one Kbm value. With this value, it can register
   a false binding, de-register the existing binding and zero the credit
   collected by the mobile node, or introduce a new Kbm into the Kcredit
   value, making it impossible for the mobile node to use its credit.
   These are denial-of-service attacks; our method is incapable of
   ensuring that the credit can be retained in the presence of on-path
   attackers. On the other hand, base Mobile IPv6 mechanisms have
   similar limitations, and even basic IPv6 is vulnerable to on-path
   denial-of-service attacks.

7. IANA Considerations

   One new mobility option number has to be allocated for this protocol.

8. Conclusions

   This approach can reduce the amount of signaling needed for home
   address tests, care-of address tests, and binding updates, all
   without exposing nodes to significant new vulnerabilities. It does
   not eliminate all the signaling, however, and works best when the
   mobile node stays a long time at the same location.

   This approach is one possible component in further optimizations of
   Mobile IPv6. As its primary purpose is to reduce signaling, it can be
   used together with other approaches such as [13] to assist in
   reducing the frequency of care-of address tests and expand the
   applicability of the solution, with [12] to provide both reduced
   signaling and reduced latency upon movements, or with [8] to provide



Arkko & Vogt           Expires November 19, 2004               [Page 11]

Internet-Draft         CBA for Lifetime Extension               May 2004


   reduced signaling while still performing care-of address tests.

Normative References

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

   [2]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
        IPv6", RFC 3775, May 2004.

Informative References

   [3]   Anderson, R., "Why information security is hard - an economic
         perspective", Proceedings of the 17th Annual Computer Security
         Applications Conference, December 2001.

   [4]   Arkko, J. and P. Nikander, "Weak Authentication:  How to
         Authenticate Unknown Principals without Trusted Parties",
         Proceedings of Security Protocols Workshop 2002, Cambridge, UK,
         April 16-19,  2002.

   [5]   Nikander, P., "Mobile IP version 6 Route Optimization Security
         Design Background", draft-ietf-mip6-ro-sec-00 (work in
         progress), April 2004.

   [6]   Vogt, C., Bless, R., Doll, M. and T. Kuefner, "Early Binding
         Updates for Mobile IPv6",
         draft-vogt-mip6-early-binding-updates-00 (work in progress),
         February 2004.

   [7]   Haddad, W., Dupont, F., Madour, L., Krishnan, S. and S. Park,
         "Optimizing Mobile IPv6 (OMIPv6)", draft-haddad-mipv6-omipv6-01
         (work in progress), February 2004.

   [8]   Haddad, W., Madour, L., Arkko, J. and F. Dupont, "Applying
         Cryptographically Generated Addresses to OMIPv6 (OMIPv6+)",
         draft-haddad-mip6-cga-omipv6-00 (work in progress), April 2004.

   [9]   Arkko, J., "Comments on
         draft-vogt-mip6-early-binding-updates-00", E-mail discussion on
         the mip6 list, February 2004.

   [10]  Vogt, C., "Response to comments on
         draft-vogt-mip6-early-binding-updates-00", E-mail discussion on
         the mip6 list, February 2004.

   [11]  Vogt, C., "Early Binding Updates for Mobile IPv6", Presentation
         in the MOBOPTS IRTF WG, March 2004.



Arkko & Vogt           Expires November 19, 2004               [Page 12]

Internet-Draft         CBA for Lifetime Extension               May 2004


   [12]  Vogt, C., Arkko, J., Bless, R., Doll, M. and T. Kuefner,
         "Credit-Based Authorization for Mobile IPv6 Early Binding
         Updates", draft-vogt-mipv6-credit-based-authorization-00 (work
         in progress), May 2004.

   [13]  Perkins, C., "Preconfigured Binding Management Keys for Mobile
         IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress), April
         2004.


Authors' Addresses

   Jari Arkko
   Ericsson Research NomadicLab

   FI-02420 Jorvas
   Finland

   EMail: jari.arkko@ericsson.com


   Christian Vogt
   Institute of Telematics
   University of Karlsruhe (TH)
   P.O. Box 6980
   76128 Karlsruhe
   Germany

   Phone: +49-721-608-8282
   Fax:   +49-721-388-097
   EMail: chvogt@tm.uka.de
   URI:   http://www.tm.uka.de/~chvogt/

Appendix A. Acknowledgments

   The authors would like to thank Wassim Haddad, Lila Madour, Roland
   Bless, Mark Doll, and Tobias Kuefner for interesting discussions in
   this problem space.













Arkko & Vogt           Expires November 19, 2004               [Page 13]

Internet-Draft         CBA for Lifetime Extension               May 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

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




Arkko & Vogt           Expires November 19, 2004               [Page 14]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/