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]