Network Working Group D. Crocker
Internet Draft Brandenburg
draft-crocker-mast-proposal-01.doc InternetWorking
Expires: <2-04> September 16, 2003
MULTIPLE ADDRESS SERVICE FOR TRANSPORT (MAST):
AN EXTENDED PROPOSAL
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.
COPYRIGHT NOTICE
Copyright (C) The Internet Society (2003). All Rights Reserved.
ABSTRACT
Classic Internet transport protocols use a single source IP
address and a single destination IP address, as part of the
identification for an individual data flow. TCP includes these
in its definition of a connection and its calculation of the
header checksum. Hence the transport service is tied to a
particular IP address pair. This is problematic for multihomed
hosts and for mobile hosts. They cannot use more than one, for
any single transport association (context). Multiple Address
Service for Transport (MAST) defines a mechanism that supports
association of multiple IP addresses with any transport
association. It requires no change to the Internet
infrastructure, no change to IP modules or transport modules in
the end-systems, and no new administrative effort. Instead, it
defines a layer between classic IP and transport that operates
only in the end systems and affects only participating hosts.
Additional functionality is obtained by use of a DNS and
"presence" rendezvous service.
CONTENTS
1. INTRODUCTION
1.1. TERMINOLOGY
1.2. DISCUSSION VENUE
1.3. DOCUMENT HISTORY
2. REQUIREMENTS
3. PROTOCOL
3.1. TRANSACTION MODEL
3.2. ASSOCIATION ATTRIBUTES
3.3. THE INIT OPERATION
3.4. THE SET OPERATION
3.5. THE PROBE OPERATION
3.6. THE SHUT OPERATION
3.7. THE ERR OPERATION
4. TRANSFER SERVICE
5. SOURCE VALIDATION
6. RENDEZVOUS
6.1. DNS
6.2. PRESENCE
7. PATH SELECTION
8. IMPLEMENTATION
8.1. TYPICAL TRANSPORT INTERFACING
8.2. MAST THROUGH NAT
8.3. MAST AGENT
9. SECURITY CONSIDERATIONS
APPENDIX
A. ACKNOWLEDGEMENTS
B. REFERENCES
C. AUTHOR'S ADRESS
D. FULL COPYRIGHT STATEMENT
INTRODUCTION
Classic Internet transport protocols use a single source IP
address and a single destination IP address, as part of the
identification for an individual transport data flow. For
example, TCP includes these in its definition of a connection and
its calculation of the header checksum. Hence a classic
transport association is tied to a particular IP address pair.
This is problematic for multihomed hosts and for mobile hosts.
Both have access to multiple IP addresses, but they are prevented
from using more than one within an existing transport exchange.
For a host to use a different IP address pair, participants must
initiate a new exchange. In the case of TCP, this means a new
connection.
In recent years, there have been efforts to overcome many of
these limitations, through different approaches at different
places in the Internet architecture. Some modify the IP
infrastructure, with embedded redirection services. Some define
transport enhancements to support a set of addresses directly,
and some define a layer between classic IP and classic transport.
Each of the existing proposals has notable limitations in
functionality, implementation, deployment or use. A discussion of
the architectural choices and summary of existing multiaddressing
projects is in [CHOICE].
Multiple Address Service for Transport (MAST) supports
association of multiple IP addresses during the life of any
transport instantiation, by defining a layer between IP and
transport. It operates only in the end systems and affects only
participating hosts. MAST does not require modification to the
Internet infrastructure and does not require modification to any
host's IP or transport modules, although improved functionality
can be obtained with some changes.
Further, MAST works with existing IPv4 and IPv6 transport
services and it is useful to any two hosts that try to use it
with each other. It does not define any new naming or addressing
structure. It has no additional packet header overhead and
minimal additional packet-processing overhead. It employs
existing administrative structures. Hence MAST has a low barrier
to adoption and use, while permitting more advanced functions
with more extensive adoption and modification.
MAST may be invoked at any time, before or during a transport
association. A host may initiate and conduct a classic, single IP-
pair TCP connection. It may then separately query for remote host
support of MAST and initiate a MAST exchange to be used by that
connectivity. Either participant is then free to add or remove
addresses. Of course, use of MAST may instead be performed before
a transport context is established, so that future contexts
immediately have access to multiple IP addresses.
For a multihomed host, it will be reasonable to associate
multiple IP addresses with a transport context at the time the
first context between that host-pair is initiated. For a mobile
host, addresses may be added and removed as the host moves across
the Internet fabric, acquiring and losing use of different IP
addresses. Over the life of a mobile transport context,
different addresses might be active at different times. Support
is provided for continuation of service across complete
connectivity interruptions to mobile hosts, when a host's set of
available IP addresses becomes empty and the host later re-
acquires a usable IP address.
NOTE: The MAST proposal exploits the considerable
HIP work done to uncover usability issues and
edge conditions. MAST suggests the same core
functionality as HIP and LIN6, and a similar
approach, but uses a simpler protocol, with a
somewhat narrower functional focus.
1.1. Terminology
This proposal considers a method that will enable an endpoint
(host) to use multiple addresses during single application
associations (sessions).
"Agent" refers to a forwarding service that represents an
endpoint for multiaddressing. For mobility, the agent resides on
the "home" network and relays datagrams to the endpoints actual
location on the Internet. The endpoints are modified to support
this forwarding technique. For multihoming, an agent hides the
presence of multiple addresses from the endpoint located on the
local network.
"Mobility" refers to the availability of different addresses over
time. This may even include discontinuities, with no available
addresses, at times. It also may include overlapping availability
of addresses. Interestingly, this looks the same as multihoming.
"Multihoming" refers to the availability of multiple addresses
simultaneously. It is typically used to refer to multiple network
attachments for a host, but works equally well for multiple
upstream network attachments by the local network, when the
different upstream addresses are visible to the host.
Interestingly, multihomed environments often must support dynamic
changes, such as when adding a new upstream provider. Therefore,
multihoming can include mobility features and mobility can
include multihoming features.
"Path discovery" provides a sender with the means for learning
about the addresses from which they can send.
"Path selection" is required when more than one address is
available to the sender. Although the sender is limited to
specifying an address, rather than a path, it appears that
thinking of it as path selection aid consideration of solutions.
In effect, it formulates the selection task as being similar to
the job of routers. Route formulation is mature technology, so
that this aspect of multiaddress processing will be tractable, if
not straightforward.
"Rendezvous" permits a host that is initiating an association to
find the target of the association, such as a client finding a
server. "Finding" means obtaining a valid address for the target.
A public process is required for rendezvous. The primary Internet
mechanism for rendezvous has been the Domain Name Service (DNS).
The DNS used long, variable-length strings (names) and is
tailored for large-scale rendezvous with names and addresses
(mappings) that change infrequently.
1.2. Discussion Venue
Discussion and commentary are encouraged about the topics
presented in this document. The preferred forum is the
<mailto:multi6@ops.ietf.org> mailing list, for which archives and
subscription information are available at
<http://ietf.org/html.charters/multi6-charter.html>.
1.3. Document History
-00 Initial proposal. Basic concepts. Heavy reliance
on SCTP and DCCP for style of solutions and
implied detail.
-01 Substantial reorganization.
Added more detail to MAST, including rendezvous
and agent, adjunct services
Extended discussions about alternative proposals
and architectural issues, moved to -analysis-
draft.
Removed explicit SCTP/DCCP usage.
Removed NAT references from architecture
discussions.
2. REQUIREMENTS
MAST has four requirements:
a) The goal for this service is to support the use of multiple IP
addresses by either participant in a transport association.
b) The service should require no changes to the IP network
infrastructure, to the IP layer in end-systems, or to the
transport layer in the end-systems.
All knowledge of the service, and all activity about it,
must reside only in the end-systems using it. In order to
avoid start-of-association operation, the service must
support operation of classic transport associations, with
post-hoc introduction of the multiaddress mechanism.
c) The service must be resilient against classic, basic security
threats, especially spoofing (association hijacking).
d) The service must operate across administrative and operational
boundaries and across address translation boundaries (NAT).
3. PROTOCOL
This section discusses MAST operations between participating
hosts.
3.1. Transaction model
MAST uses a simple request/response. Each request receives a
response. The response forms the basis of MAST transaction
reliability. A request is retransmitted when a response is not
received. Retransmission rules use the usual exponential
backoff.
<STATE As guidance about the association
DIAGRAM> relationship between two participating MAST
hosts, SCTP Section 4, "SCTP Association
State Diagram" provides a useful, starting
framework. See [SCTPMOB] for discussion of
mobility enhancements that are applicable
to MAST.
3.2. Association Attributes
An MAST association is between a pair of hosts, defined by
endpoint identifiers, an association label and a transaction
sequence identifier.
It comprises a domain name double, an Association Nonce double,
and a transaction sequence number (TSN) double:
Endpoint Globally unique, macro-labels
identifiers: comprising a domain name for each host
Endpoint Association nonce, with cryptographic
association protection against hijacking. It is an
label: internal identifier for the MAST
association; it comprises a random
value, such as defined in Section
6.4.2, "Connection Nonce Feature" and
used in Section 6.4.3, "Identification
Option", in [DCCP]. Also see [RAND].
Sequence A Transaction Sequence Number (TSN)
label: indicates data flow during the
association and is used for detecting
duplicates, detecting missing data,
and correlating responses
NOTE: More complex association behaviors are
possible, such as permitting specification of
address subsets for different transport
context. This level of sophistication is beyond
the scope of the current effort, but will be
interesting to explore after a basic capability
is achieved.
3.3. The INIT Operation
At the beginning of a MAST session, each host sends an "init"
element, to create a host-pair association and define the initial
set of valid addresses that may be used. The association is fully
established after each host has received an acknowledgement to
the "init" operation that it sent.
The "init" operation includes:
* Sender and Receiver domain names
* Association Nonce
* TSN
* List of sender IPv4 and IPv6 addresses
3.4. The SET Operation
When a host wants to specify a new list of its own IP addresses,
supported in this MAST association with the other host, it sends
a "SET" operation to the other host.
This function is isomorphic with the INIT operation, except that
it uses the existing "Association Nonce" and continues the
existing TSN sequence. The domain names must be the same as were
used in the "init" operation for this association.
A SET operation may occur after a complete interruption of
service, such as when a mobile host has not had connectivity for
a time, and then reacquires access to the network. In this case,
the set of sender addresses is likely to have no members in
common with the set that was valid before the interruption.
NOTE: A complete list of valid addresses is included,
rather than specifying only incremental
changes. The list of valid addresses is small
and does not require the synchronization
complexity of an incremental function.
3.5. The PROBE Operation
Status of the association is queried with the "probe" operation.
It serves three functions:
* Permit a sender to discover the IP address and port number,
being presented to a receiver, if subject to NAT
transformations; the receiving MAST participant responds with
the sender's IP address and port number it received in the IP
datagram for the PROBE operation.
* Confirm the continued utility of the destination address used
for the PROBE operation.
* Provide an association keep-a-live.
The "probe" operation includes:
* Association Nonce
* TSN
* Sender and Receiver IP addresses
The IP addresses in the "probe" operation are the same as are
specified by the sender in the containing IP datagram.
The "probe response" operation includes:
* Association Nonce
* TSN
* Received MAST Probe-level Sender and Receiver IP
addresses
* Received IP-level Sender and Receiver IP addresses
3.6. The SHUT Operation
The SHUT operation terminates use of MAST between a host-pair; it
uses a 3-way graceful close, with no half-open state.
The "shut" operation includes:
* Association Nonce
* TSN
* Sender and Receiver domain names
3.7. The ERR Operation
ERR elements are sent, in MAST, when there is an error.
The "err" operation includes:
* Association Nonce
* TSN
* Error information
4. TRANSFER SERVICE
The MAST control exchange has modest transfer (transport)
requirements, except that it must itself be able to operate by
using multiple IP addresses for each host. Transactions are
small and are expected to be infrequent. However they must be
reliably delivered, and they must be secure, with respect to
redirection and replay attacks by third parties.
A simple use of UDP will suffice, with MAST responses providing
the needed transfer acknowledgement. The full specification will
provide for retransmission controls.
Security is built into the MAST protocol, rather than its
transfer service.
5. SOURCE VALIDATION
The minimal level of implicit source validation that exists
within existing transport services' use of IP is eliminated with
multiaddressing. This invites hijacking attacks.
At the start of an association, MAST establishes association
nonce that is used for later exchanges. This nonce is created
while only one address is in force.
The method of establishing the nonce will follow the lines of
PBK, SCTP or DCCP, as dictated by the limited security
requirements to prevent hijacking.
6. RENDEZVOUS
How does one endpoint find another? The current answer is DNS.
However multiaddressing introduces some challenges. Classic DNS
use permits finding a set of addresses associated with a domain
name. For finding a static, multihomed target, this is probably
sufficient. The fact that the initiator is mobile can be
communicated to the target by the initiator.
However when the target is mobile, an additional support
mechanism is needed. This section defines an adjunct service to
finding mobile targets.
6.1. DNS
Rendezvous with mobile targets is supported through a two-stage
process. A domain name is used as the stable, public EID.
An SRV record is defined to reference a dynamic "presence"
service through which an endpoint can register its current set of
IP addresses.
6.2. Presence
The requirement to discover current IP addresses for an endpoint,
and to be notified when they change, suits existing presence
service models rather nicely.
MAST is defined to use the presence service available through
[XMPP]. The definition of this mechanism will be for standard
XMPP, with some addressing conventions to specify the target
system's domain name at a particular presence server.
Development of the detailed specification may lead to choosing a
different service. However, dynamic rendezvous is an adjunct
function for MAST. Hence it is not essential to develop this
capability for initial use of the service.
7. PATH SELECTION
Having gained access to the list of IP addresses by which a
destination host may be reached, a sender must select one, for
the next set of data. As with any dynamic resource selection
opportunity, the choice of schemes is extensive and can be quite
sophisticated. However until there is experience with the basic
dynamics of this service, conservative usage models are
encouraged.
As with SCTP, the conservative approach is to choose a primary
address and use others as alternatives only to ensure robustness
to the association. Periodic use of the PROBE operation to each
addresses that the other side purports to have available will
provide basic path availability and performance data.
8. IMPLEMENTATION
The MAST protocol only provides for controlled and protected
exchange of address lists. The utility of these lists hinges on
their integration into host networking stack services.
8.1. Typical Transport Interfacing
This discussion considers addition of MAST to an existing
Internet protocol stack. It is possible to integrate MAST more
tightly and efficiently, but this is not an immediate concern for
early adoption of the service.
MAST must be added to a host implementation of Internet Protocol
and associated transport services, in a way that is transparent
to the IP module and the transport modules. It is injected
between IP and transport. Interfacing to IP transparently is
straightforward.
For classic transport services that use IP addresses, it is
necessary to present a single, consistent address during the life
of the association. When MAST is invoked after the start of a
transport association, the transport service will already have a
particular address that it associates with the other participant.
In this case, it is easiest to map the packets being handed up to
the transport layer, from additional addresses into the original
one.
Another approach is to make all destination addresses appear to
the transport service as coming from an internally allocated
address, such as one allocated in [PRIV]. A networking software
stack would use public IP addresses for rendezvous functions, but
transport would re-use addresses from this private, internal
address space.
8.2. MAST through NAT
Network Address Translation [NAT] devices map one address space
into another, typically between an intranet set of host addresses
to a smaller set of Internet addresses. In effect, they use port
numbers as a means of mapping internal hosts to the smaller set
of external addresses.
This causes problems for any transport that performs end-system
calculations that using IP addresses. The end system does the
calculations on one set of addresses, but the NAT device changes
an address, so that the calculation by the receiving party will
not be correct. Hence, NAT devices also need to know about
transport-level use of IP addresses and must adjust the values
for those calculations carried in transport (or above) headers.
MAST exacerbates this situation, since the mapping between IP
address and transport calculations is more complicated. Whereas
there used to be only one IP address to worry about, now there
can be more.
Note the section 4.3 specification of the "probe" operation, to
discover NAT transformation on the sender's address.
8.3. MAST Agent
Multihoming is often a feature of a network, rather than a host.
Hosts often do not know that there are multiple Internet
connections, especially when the local network uses internal
(private) addressing that is different from the network's public
address.
In these cases, it might be possible for MAST to be implemented
as a feature of the local network's NAT function, rather than in
the end-system. Since the NAT is already doing address
translation, adding MAST only requires that the NAT query the
other end of the communication, to obtain permission to add MAST
exchanges and multiple addresses.
9. SECURITY CONSIDERATIONS
Basic Internet transport protocol activity does not apply any
security-related mechanisms, other than relying on having a
source addresses be usable as a destination address, to reach the
originator of the previous, source data. So, transport-level
security is based on address confirmation by virtue of
reachability. This reliance on underlying routing behavior has
well-known weaknesses. MAST does not to exacerbate or remedy
them.
However, MAST affects the core of Internet transport
associations, by permitting new addresses to be associated with
traffic for other addresses. Hence, MAST invites spoofing,
redirection, and other manners of evil.
The protection against these attacks is to conduct MAST control
exchanges over a session that is protected, so that modification
to the set of addresses permitted between a host-pair take place
over a channel that cannot be spoofed, redirected, or the like.
Protection is based on association-time self-authentication.
Using the same basis as applies to typical transport session
validation, MAST participants exchange protection keys prior
modification of the list of acceptable addresses. These keys are
then used in later transactions.
Section 11.2.4.2, Blind Masquerade, of [SCTP] is
incorporated by reference.
When stronger protection is needed, [IPsec] or [TLS] should be
used for the MAST control channel, or application-level security
should be used for the user data flows.
APPENDIX
A. Acknowledgements
Funding for the RFC Editor function is currently provided by the
Internet Society.
This work derives from discussions in the IETF, in the mid-1990s.
A particular technical concern was protecting the address-
changing negotiation. The current proposal leverages recent work
done on HIP [HIPARC, HIP, MOBHOM], although it makes
significantly different technical choices. MAST incorporates a
number of the capabilities provided by [SCTP] and [DCCP]. The
core ideas for MAST were developed by the author a number of
years ago. Christian Huitema independently developed the same
technical constructs, at the same time.
When upper-layer mapping was first suggested, the most serious
concern was for securing the exchange of additional address
information, to prevent connection hijacking. Purpose-Built Keys
and the mechanisms in SCTP and DCCP nicely resolve this manner,
without requiring a massive security infrastructure. As noted
earlier in this document, recent work on HIP and LIN6 continue
the core construct of an IP/transport wedge for mapping
addresses.
Commenters on this text include: Marcelo Bagnulo, Iljitsch van
Beijnum, Vint Cerf, Spencer Dawkins, Robert Honore, James Kempf ,
Eugene Kim, Eliot Lear, Pekka Nikander, Erik Nordmark, Tim
Shepard, Randall R. Stewart, and Fumio Teraoka, Joe Hildebrand.
B. References
B.1. Normative
[HIPARC] Moskowitz, R., "Host Identity Protocol
Architecture", < http://www.ietf.org/internet-
drafts/draft-moskowitz-hip-arch-03.txt >
[PBK] Bradner, S., Mankin, AS., Schiller, J., "A
Framework for Purpose-Built Keys (PBK)", draft-
bradner-pbk-frame-06.txt, June 2003
[RAND] Eastlake, D., S. Crocker, J. Schiller. ,
"Randomness Recommendations for Security", RFC
1750, December 1994.
[XMPP] Saint-Andre, P., Miller, J., "XMPP Core", draft-
ietf-xmpp-core-18, September 7, 2003
B.2. Non-Normative
[CHOICE] Crocker, D., "Choices for Support of
Multiaddressing", draft-crocker-mast-analysis-
00.txt, September 16, 2003
[DCCP] Kohler, E., M. Handley, S. Floyd, J. Padhye,
"Datagram Congestion Control Protocol (DCCP)",
draft-ietf-dccp-spec-04.txt, 30 June 2003
[EID] Chiappa, J.N., "Endpoints and Endpoint Names:
A Proposed Enhancement to the Internet
Architecture",
<http://users.exis.net/~jnc/tech/endpoints.txt>,
1999
[ETCP] Zhang, B., Zhang, B., Wu, I., "Extended
Transmission Control Protocol (ETCP) Project--
Extension to TCP for Mobile IP Support",
<http://www.cs.ucla.edu/~bzhang/etcp/report.html
>
[HIP] Moskowitz, R., "Host Identity Protocol
Architecture", < http://www.ietf.org/internet-
drafts/draft-moskowitz-hip-arch-03.txt >
Moskowitz, R., "Host Identity Protocol", <ietf-
id: draft-moskowitz-hip-07>
Nikander, P., "End-Host Mobility and Multi-
Homing with Host Identity Protocol", <
http://www.ietf.org/internet-drafts/draft-
nikander-hip-mm-00.txt>
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture
for the Internet Protocol", RFC 2401, November
1998
[LIN6] Teraoka, F., Ishiyama, M., Kunishi, M., "LIN6:
A Solution to Mobility and Multi-Homing in
IPv6", draft-teraoka-ipng-lin6-02.txt, 24 June
2003
[MOBHOM] Nikander, P., "End-Host Mobility and Multi-
Homing with Host Identity Protocol", <
http://www.ietf.org/internet-drafts/draft-
nikander-hip-mm-00.txt>
[NAT] Egevang, K., and P. Francis, "The IP Network
Address Translator (NAT)", RFC1631, May 1994
[NSRG] Lear, E., Droms, R., "What's In A Name: Thoughts
from the NSRG", draft-irtf-nsrg-report-09.txt,
March 2003
[MIP] Perkins, C., "IP Mobility Support", RFC 2002,
October 1996
Johnson, D., Perkins, C., Arkko, J., "Mobility
Support in IPv6", draft-ietf-mobileip-ipv6-
24.txt, June 30, 2003
Bagnulo, M., Garcia-Martinez, A., Soto, I.,
"Application of the MIPv6 protocol to the multi-
homing problem", draft-bagnulo-multi6-mnm-00,
February 25, 2003
[PRIV] Rekhter, Y., B. Moskowitz, D. Karrenberg, G. J.
de Groot, and E. Lear, "Address Allocation for
Private Internets", RFC 1918, February 1996.
[SCTP] L. Ong, and J. Yoakum "An Introduction to the
Stream Control Transmission Protocol (SCTP)",
<http://ietf.org/rfc/rfc3286.txt?number=3286>,
May 2002
Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla,
M., Zhang, L., Paxson, V., Stream Control
Transmission Protocol", RFC 2960, October 2000
[SCTPMOB R. Stewart, et al, "Stream Control Transmission
] Protocol (SCTP) Dynamic Address
Reconfiguration", draft-ietf-tsvwg-addip-sctp-
07.txt, February 26, 2003
[TCPMH] Matsumoto, A. Kozuka, M., Fujikawa, K., Okabe,
Y., "TCP Multi-Home Options", draft-arifumi-tcp-
mh-00.txt, 10 Sep 2003
[TLS] Dierks, T., C. Allen , "The TLS Protocol Version
1.0", RFC 2246, January 1999.
C. Author's Adress
Dave Crocker
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086 USA
tel: +1.408.246.8253
dcrocker@brandenburg.com
D. 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 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.