NEMO Working Group Souhwan Jung
Internet-Draft Soongsil University
Expires: April, 2004 Fan Zhao
Felix Wu
UC Davis
HyunGon Kim
SungWon Sohn
ETRI
October, 2003
Threat Analysis for NEMO
draft-jung-nemo-threat-analysis-01
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.
This Internet-Draft will expire on December 22, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes possible security threats on mobile networks.
Many different kinds of security threats exist on signaling and
communication paths including mobile routers and home agents.
It is also the goal of this draft to explain a three-layer threat
model, to investigate vulnerabilities to the network entities in
NEMO, and finally to propose security requirements for NEMO.
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.
S. Jung et. al. Expires April, 2004 [Page 1]
Internet-Draft Threat Analysis for NEMO October 2003
Table of Contents
1. Motivations
2. Three-Layer Threat Model
3. Generic Threats to Target Protocols/Services
3.1 Threats to Signaling Paths
3.2 Threats to Communication Paths
4. Generic Threats to Target Entities/Entry Points
4.1 Misbehaviour of MR
4.2 Misbehaviour of HA
4.3 Traffic Analysis
4.4 Denial of Service
5. Threats specific to NEMO basic support protocols
5.1 Corruption of Binding Cache by inside attacker
5.2 Attack using HA as a stepping stone
5.3 Attack to Location Privacy by Traffic Analysis
6. Security Requirements
References
Authors' Addresses
Intellectual Property and Copyright Statements
S. Jung et. al. Expires April, 2004 [Page 2]
Internet-Draft Threat Analysis for NEMO October 2003
1. Motivations
Networks in motion (NEMO) introduces a new network entity called Mobile
Router(MR)[2]. MR has different features from Mobile Host that is operated
based on Mobile IP technologies[4]. Since MR functions both as a mobile
node and a gateway to provide mobile network with Internet access to
outside world, it needs specific treatment for managing operations and
securities.
In real world, many different types of NEMO configurations are possible
including multi-homing, which means that new kind of threats specific to
NEMO SHOULD be taken care of. For example, MR can advertise its IP
prefix to the VMNs in its mobile network, and this RA message can be
intercepted and modified to advertise the prefix of malicious router.
This makes address spoofing attack possible: the packets that should be
delivered to the destination mobile router are redirected to the attack
router. Therefore, those messages like RA should be protected using
authentication.
This draft proposes a three-layer threat model for analyzing
vulnerabilities to NEMO protocols and entities. Based on the model, we
describe and classify all possible threats to NEMO, and analyze those
threats according to their properties and scopes. Finally, we describe
the security requirements for NEMO.
2. Three-Layer Threat Model
Many different threats to network entities in NEMO are possible and hard
to describe all of them in a row. Some of the threats can have multiple
paths to achieve their goals, which means that many different types of
attacks are possible to obtain the same objective that the attacker
tries to achieve. Therefore, it requires a hierarchical threat model to
describe and classify all different types of threats to NEMO.
This draft proposes a three-layer threat model to describe possible
threats to NEMO according to their objectives/properties, target
protocols/services, and target entities/entry points. This model is
composed of a three-layer stack; objectives/properties on the top layer,
target protocols/services for attack on the second layer, and finally
target entities or entry points for attack at the bottom layer.
S. Jung et. al. Expires April, 2004 [Page 3]
Internet-Draft Threat Analysis for NEMO October 2003
The objectives of threats are usually a limited number of goals that
attackers try to achieve in abstract level. They could be like
eavesdropping of data, impersonation, data corruption or modification,
unauthorized use of resources, repudiation, and blocking services to
clients. The generic goals of security mechanisms against those attacks
therefore are such as confidentiality, integrity, authentication,
authorization, non-repudiation, and service availability, which are
common to all of the security frameworks.
The second layer of the stack is composed of target protocols or services
for attack. Attackers always try to find vulnerabilities to network
protocols or services by monitoring protocol or service data specific to
the target. In NEMO, for example, binding update(BU) message or router
advertisement(RA) messages by MRs could be target data for attack. Most
of NEMO signaling protocols could be the target at the second layer.
Therefore, the vulnerabilities to the basic NEMO mechanism should be
scrutinized for the analysis. In the next section, this draft will
describe those vulnerabilities and possible threats related to them.
The bottom layer of the threat model is comprised of target entities or
entry points for attacks. NEMO includes many network entities called MR,
HA, CN, and MNN etc. Any of these entities could be a victim for attack,
and be compromised. All the possibilities of different types of attacks
should be investigated based on the assumption of these compromises.
For example, the compromise of MR can result in the data interception
of the MNNs inside or the deception of their connection to a fake HA
or FA. The MNNs have no knowledge of the compromised MR, since the NEMO
protocols are transparent to the MNNs. In section 4, those threats will
be analyzed and described.
3. Threats to Target Protocols and Services
This section describes threats to NEMO protocols and services. NEMO
operations are composed of two different planes; one is the signaling
plane for exchanging control or routing information, and the other is
the communication plane for exchanging data between nodes. The threats
specific to each plane will be investigated.
3.1 Threats to Signaling Paths
The basic NEMO operations have three different signaling paths between
entities; the first path is the signaling between MR and FA, the second
one is the signaling between MR and HA, and the final one is the
signaling between MNN and CN. Each signaling messages can be interrupted
and modified by attackers on the way of the signaling paths. The following
threats exist over signaling paths.
S. Jung et. al. Expires April, 2004 [Page 4]
Internet-Draft Threat Analysis for NEMO October 2003
- Man-in-the-middle between MR and HA
This threat means that an attacker resides between MR and HA, and
intercepts the signaling messages such as CoA(Care-of-Address) in
BU messages. The messages could be modified and transferred to the
HA with corrupted information. For example, the attacker compromises
the access router, and intercepts and modifies all the messages that
goes through the access router. One of the attack results will be
the registration of MR to HA with wrong binding information.
Security mechanism for bi-directional tunneling like IPsec could
prevent this threat.
- Discard registration messages from MR to FA
This threat is a sort of DoS attack to block network connectivity
service to MR. The attacker compromises the FA, and keep discarding
the registration message from MR. The result of the attack is no
availability of network connection service to the mobile networks.
- Spoofing MR
Mobile network could have multiple MRs for the case of
multi-homing. Assume that there is a mobile network with a single
MR. The fake MR claims to be the second MR for multihoming the
victim mobile network, and register to HA with another spoofed IP
prefix. The fake MR advertises its spoofed IP prefix to the new
VMNs that comes into play.
Then the victim VMN gets the wrong IP address from the fake MR,
and starts to communicate via the fake MR.
- Corrupted routing information
Attacker may send corrupted routing information to MR and cause
network instability such as network congestion or looping. If the
MR is in the visited domain, it will not respond to the unsolicited
RA. But while the MR is in home domain, it still accepts the RA
messages, and may get screwed up with wrong routing information.
3.2 Threats to Communication Paths
- eavesdropping/replay of messages between MR and HA
All the data packets between MR and HA have to go through the
bi-directional tunnel. This tunnel should be secured by IPsec.
But some of the routing information that may not go through
this tunnel should be secured.
- eavesdropping/replay of messages between MNN and CN
The messages between MNN and CN are going through the
bi-directional tunnel, but there is no protection against
sniffing data between MR and MNN or between HA and CN. So
security mechanisms should be applied on the part of the
path uncovered.
- location privacy
Monitoring and analyzing the characteristics of data traffic
along the communication paths reveals some information on routing
and location privacy.
S. Jung et. al. Expires April, 2004 [Page 5]
Internet-Draft Threat Analysis for NEMO October 2003
4. Threats to Target Entities
The basic network entities in NEMO are MR, HA, FA, CN on the main network,
and LFN, LMN, and VMN in the mobile network. Any of these entities could
be the target for attack. We will investigate possible threats caused by
compromising the network entities like MR, HA, and FA. The compromise of
an entity means that attacker can access the entity, and change or modify
data inside the system. The following attacks are possible with the
compromise of each entity. The authentication mechanism for each entity
therefore should be applied.
4.1 Misbehavior of MR
MR is the most critical network component for the successful
operations in NEMO, thserfore, the correct operation of MR SHOULD
be assured. Most other routers have their own security functions
which MAY not enough to protect MR. The following are the
security threats which MAY be caused by misbehavior of MR. HA
need to check whether MR works correct.
- MR-HA spoofing
MR-HA is the permanent address assigned statically or
dynamically to the MR by HA. MR-HA should be used for
identification of MR while it is in the visited domain.
The compromised MR can register to FA with a spoofed MR-HA,
and try to collect data destinated to the victim address.
- MR-CoA spoofing
MR-CoA is the Care-of-Address assigned to the egress interface
of MR by AR. The compromised MR can send a BU message to HA
with a spoofed CoA, and collect the data that were destinated
to the victim AR.
- Cache poisoning
The cache data for routing table in MR can be corrupted to
subvert routing path. The data packet could be redirected or
looped causing network instability.
4.2 Misbehavior of HA
- sniffing of tunneled packet
The IPsec transport mode should be used for securing the
tunneled packets between MR and HA. With the compromise of
the HA, the attacker can sniff the decrypted data packet
in HA.
- corruption of binding cache
HA keeps managing the BU information on binding cache.
With the corruption of binding information, the attacker
can redirects packets to where he want to deliver them.
4.3 Traffic Analysis
The location of MR or MNN inside the subnet may be the privacy of
the client, so the location information while network is in motion
should be secured. Attacker can analyze the header information
MR-CoA in the tunneled data packet and identify the location of
the MR.
Since all the data packets between MNN and CN are also tunneled
using MR-CoA as a new source address, the location of the MNN can
also be disclosed.
4.4 Denial of Service
Denial of Service attack is possible against MR and HA by flooding
BU messages and bogus tunneled packets. The attack can be more
effective with distributed fake MRs or HAs.
S. Jung et. al. Expires April, 2004 [Page 6]
Internet-Draft Threat Analysis for NEMO October 2003
5. Threats specific to the NEMO basic support protocol
5.1 Corruption of Binding Cache by inside attacker
The network configuration vulnerable to this attack is as
follows. A MR has the function of NAT server, and there is a
malicious MNN inside the mobile network. The malicious
MNN spoofs a BU message of the MR, and send it to the MR.
Assumptions
The following analysis assumes:
1. The BU packet from MR is requird to be protected by ESP transport
SA between MR and HA.
For exmaple, SA: src=CoA and dst=HA -> ESP transport HMACMD5 3DES
2. The packets from MMN are encapsulted by IP-in-IP tunnel or IPSec
tunnel SA between MR and HA.
For example, IP-in-IP: scr=MNP and dst=any ->
IP-in-IP tunnel, outer_src=CoA and outer_dst=HA
3. We assume that IP-in-IP and IPSec tunnel SA are executed after
NAT/NAPT. NAT after IPSec tunnel will violate the SA and NAPT
doesn't have the port number to work with. The same thing to
IP-in-IP.
A list of all possible attacks and countermeasures without NAT:
1. MMN spoofs the CoA of MR; MR will drop any packets received
whose source IP address is CoA.
2. MMN spoofs the CoA of nested MR; However, MMN can not forge
the ESP authentication data. HA will drop it.
|-----HA----| |----------MR--------| |---------MN----------|
| | | | | |
| |-----| | | |-----| |-----| | | |--------| |
| |IPSec|<===3===|-|IPSec|<=2=| NAT |-|<===1===| MNN | |
| |-----| | | |-----| |-----| | | |--------| |
| | | | | | |
|-----|-----| |--------------------| |---------------------|
4
|
V
|---------------|
| Binding Cache |
|---------------|
|1| MR-HA CoA |
|2| MR-HA CoA |
| ...... |
|---------------|
S. Jung et. al. Expires April, 2004 [Page 7]
Internet-Draft Threat Analysis for NEMO October 2003
1. Malicious MNN makes the following packet and sends it to MR.
|------------------------------|
| source IP address = MNN |
|------------------------------|
| destination IP address = HA |
|------------------------------|
| ...... |
|------------------------------|
| src port=any | dst port |
|------------------------------|
| ...... |
|------------------------------|
| BU Options (MNP, CoA) |
|------------------------------|
2. Assume that NAPT is used...
|------------------------------|
| source IP address = CoA |
|------------------------------|
| destination IP address = HA |
|------------------------------|
| ...... |
|------------------------------|
| src port=any* | dst port |
|------------------------------|
| ...... |
|------------------------------|
| BU Options (MNP, CoA) |
|------------------------------|
Since NATP changes the source IP address into one globally
routable one, in this case, the only choice is CoA address of
MR. If there are multiple globally routable IP addresses
associated with MR and NAT is used, it may not cause problems
as long as source IP address is not changed into CoA.
3. If MR can't distinguish the NATed BU packets from those sent
by itself (Assume that BU sent from MR itself uses CoA as
the source IP address. It is a reasonable assumption since
only ESP transport mode is used. ), MR will use ESP transport
mode to process the NATed BU packets.
|------------------------------|
| source IP address = CoA |
|------------------------------|
| destination IP address = HA |
|------------------------------|
| ESP |
|------------------------------|
| ...... |
|------------------------------|
| src port=any* | dst port |
|------------------------------|
| ...... |
|------------------------------|
| BU Options (MNP, CoA) |
|------------------------------|
S. Jung et. al. Expires April, 2004 [Page 8]
Internet-Draft Threat Analysis for NEMO October 2003
The solution to this attack is that MR will check the source port
number in the BU packet with the NAPT mapping table where any used
port number has an entry. If there is such entry, MR will know this
packet is from MNN, thus MR will use IP-in-IP tunnel to encapsulate
it. Otherwise MR will use ESP SA to process it.
For the purpose of efficiency, it is better to resist the attack
as early as possible. The list of other possible solutions:
- MR will check the type of packets from MMN. However, MR can't
drop BU from MMN because MNN can be a nested MR.
- MR will check the type of packets from MMN and only allow BU
transformed by ESP transport SA. However, MR can not verify such
packets. Thus, attackers may still launch DoS attack to HA.
- MR may enforce the authentication in MN in order to make any
attack accountable.
4. HA will decapsulte and verify this incoming packet. If the
verification is successful, HA believes that BU is from MR and
updates the binding cache accordingly. Because HA can notice
that it receives the BU from SA between CoA and itself but
mobility option indicates a different CoA, HA will get confused.
If HA accepts this BU, the binding cache will be polluted by
attackers.
The success of this attack depends on how the MR acts when it
process the fake packet. The MR MAY just drop the packet because
it has the same source address of itself, or process the packet
using IPsec traport mode.
We performed an experiment using Microsoft Window2000 as a NAT
server configuring with IPsec transport mode, which shows that
this threat is realistic. In the experiment, the fake packet from
a node inside mobile network could go through the Window2000 NAT
server (this could be a MR in NEMO case) to a machine in outside
networks (this could be a HA in NEMO case) wrapped into the IPsec
ESP encapsulation in transport mode.
Since the current IPsec documents do not describe the details of
specification for the case of NAT server configured with IPsec,
the MR SHPULD take care of this potential vulnerability. For example,
the MR SHOULD distinguish the data packet from itself or inside node.
For MIP, this vulnerability doesn't exist, because there is no reason
for a MN to forward a fake packet from the attacker using its own
IPsec SA. Therfore, this attack is very specific to NEMO protocol.
S. Jung et. al. Expires April, 2004 [Page 9]
Internet-Draft Threat Analysis for NEMO October 2003
5.2 Attack using HA as a stepping stone
NEMO basic support draft suggests that the data packets from MMN
SHOULD be encapsulted by IP-in-IP tunnel. However, HA may become
the stepping stone to attackers. The following figure shows this
threat. In the figure, malicious packets from MNN encapsulated
in IP-in-IP tunnel can go through MR and HA to be deivered to
the victim machine. The potential threats are IP spoofing, DoS
attack etc.
|-----| |----| |-----|
| HA |===2===| MR |===1===| MNN |
|-----| |----| |-----|
|
3
|
|------|
|victim|
|------|
1. Src=spoofed IP address
dst=victim
data payload
2. outer_src=CoA
outer_dst=HA
src=spoofed IP address
dst=victim
data payload
3. src=spoofed IP address
dst=victim
data payload
This threat MAY not only be specific to NEMO, but also to any
routers configured with IP-in-IP tunnel without any associated
security mechanisms. However, this threat could be more serious
due to the heavy usage of IP-in-IP tunnel in NEMO.
5.3 Attack to Location Privacy by Traffic Analysis
In the basic NEMO configurations, all the traffic from mobile
network are supposed to go through the bi-directional tunnel
between MR and HA. The HA can collect all the packets in
IP-in-IP tunne, decapsulates them, and forwards them to the CNs.
|-----| |----| IP-in-IP tunnel |----| |----|
| MNN |---------| MR | ================== | HA |---------| CN |
|-----| 1 |----| 2 |----| 3 |----|
The outside attacker can monitor the traffic in path 2 and 3.
The time variations of traffic in a specific tunnel between a
specific MR and HA may have a similar pattern to the time
variation of traffic on a channel between HA and a specific CN.
By the statistical analysis on the time interval of peak traffic,
the attacker can find a correlation between incoming and outgoing
traffic pattern of HA, and finally finds the same connection
to extract the CoA information from the packet on path 2 and
the HA of MN from packet on path 3. This means that the
particular MN is located in the region of that particular CoA.
This attack is not only specific to NEMO, but due to the
mandatory use of bi-directional tunnel, this attack can be more
serious in NEMO.
S. Jung et. al. Expires April, 2004 [Page 10]
Internet-Draft Threat Analysis for NEMO October 2003
6. Security Requirements for NEMO
The basic support protocol for NEMO is based on the MIPv6
operations except the bi-directional tunnel operations between
MR and HA. Therefore, most of the security requirements are
already addressed in MIPv6 WG documents[4], so this draft describes
the security requirements only against new threats in NEMO.
The following security requirements SHOULD be addressed in NEMO
basic and extended documents.
6.1 MR SHOULD check the contents of the packet from MNN inside ,
and assure that the packet does not include fake information
in the critical messages such as BU, prefix discovery, or
ICMP messages.
6.2 The IP-in-IP encapsulated packet SHOULD be authenticated
between MR and HA, and per-packet authentication at MR
SHOULD be enforced.
6.3 The amount of traffic from MNN through the IP-in-IP tunnel
SHOULD be secured to protect the location privacy against
traffic analysis. The amount of traffic through IP-in-IP
tunnel MAY be secured using expanded field as in IPsec
ESP[10].
6.4 HA SHOULD make sure that the MR is working correctly.
To check the right operation of MR, HA need to periodically
send test messages, and get the responses from MNN or CN.
A scheme similar to return routability MAY be used for
this purposes.
6.5 The threats to new messages related to RO for extended NEMO
SHOULD be protected, but those threats will depends on what
sort of RO mechanism is used. The right security mechanism
for extended NEMO SHOULD be added later.
S. Jung et. al. Expires April, 2004 [Page 11]
Internet-Draft Threat Analysis for NEMO October 2003
References
[1] Ernst, T., et al, "Network Mobility Support Goals and
Requirements",
Internet Draft: draft-ietf-nemo-requirements-01.txt,
Work In Progress, May 2003.
[2] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
Internet Draft: draft-ietf-nemo-terminology-00.txt, Work In
Progress, May 2003.
[3] Wakikawa, R., et al, "Basic Network Mobility Support", Internet
Draft: draft-wakikawa-nemo-basic-00.txt, Work In Progress,
February 2003.
[4] Johnson, D. B., Perkins, C. E. and Arkko, J., "Mobility Support
in IPv6",
Internet Draft: draft-ietf-mobileip-ipv6-21.txt,
Work In Progress, February 2003.
[5] Barbir, A. and et. Al, "Generic Threats to Routing Protocols",
Internet Draft: draft-ietf-rpsec-routing-threats-01, April 2003.
[6] Kniveton, T. J., et al, "Mobile Router Tunneling Protocol",
Internet Draft: draft-kniveton-mobrtr-03.txt, Work In Progress,
November 2002.
[7] Petrescu, A., et al, "Issues in Designing Mobile IPv6 Network
Mobility with the MR-HA Bidirectional Tunnel (MRHA)", Internet
Draft: draft-petrescu-nemo-mrha-00.txt, Work In Progress,
October 2002.
[8] Ng, C. W. and Tanaka, T., "Securing Nested Tunnels Optimization
with Access Router Option", Internet Draft:
draft-ng-nemo-access-router-option-00.txt, Work In Progress,
October 2002.
[9] Arkko, J. et. al. ,Using IPsec to Protect Mobile IPv6 Signaling
between Mobile Nodes and Home Agents,í
Internet Draft: draft-ietf-mobileip-mipv6-ha-ipsec-04.txt,
March 2003.
[10] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[11] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[12] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
S. Jung et. al. Expires April, 2004 [Page 12]
Internet-Draft Threat Analysis for NEMO September 2003
Authors' Addresses
Souhwan Jung
Soongsil University
1-1, Sangdo-dong, Dongjak-ku
Seoul 156-743
KOREA
Phone: +82-2-820-0714
EMail: souhwanj@ssu.ac.kr
Fan Zhao
Department of Computer Science
University of California, Davis
One Shield Avenue
Davis, CA 95616
USA
Phone: +1-530-752-3128
EMail: fanzhao@ucdavis.edu
Felix Wu
Department of Computer Science
University of California, Davis
One Shield Avenue
Davis, CA 95616
USA
Phone: +1-530-754-7070
EMail: wu@cs.ucdavis.edu
HyunGon Kim
Network Security Department
ETRI
161 Kajong-Dong, Yusong-Gu
Taejon 305-600
KOREA
Phone: +82-42-860-5428
Email: hyungon@etri.re.kr
SungWon Sohn
Network Security Department
ETRI
161 Kajong-Dong, Yusong-Gu
Taejon 305-600
KOREA
Phone: +82-42-860-5072
Email: swsohn@etri.re.kr
S. Jung et. al. Expires April, 2004 [Page 13]
Internet-Draft Threat Analysis for NEMO September 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 assignees.
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.
S. Jung et. al. Expires April, 2004 [Page 14]