Internet DRAFT - draft-ko-vaas-problem-statement
draft-ko-vaas-problem-statement
Network Working Group Michael Ko
Internet Draft Edward Wang
Intended status: Informational Huawei Symantec
Expires : April 2012 Robert Raszuk
NTT MCL
October 28, 2011
Problem Statement for VPN As A Service
draft-ko-vaas-problem-statement-01.txt
Abstract
This document examines the problems and challenges associated with
the process of setting up secure connections between authorized
network nodes. The network nodes can be located anywhere in a
private or public network, directly connected or behind one or more
levels of NAT. Setting up a secure connection in this environment
entails the resolution of various issues such as authentication,
peer discovery, virtual network address management, routing
information exchange and connection parameters determination.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
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/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire in April 2012.
Table of Contents
1 Introduction ................................................2
2 Problems in Establishing Secure Interconnections ............3
2.1 Connectivity Problems .......................................3
Ko Expires April 2012 [Page 1]
Internet-Draft VaaS Problem Statement October 2011
2.1.1 Routing information exchange...............................6
2.1.2 Add-on Services............................................6
2.2 Security Problems ...........................................7
2.3 Management Problems .........................................8
3 Conclusions ................................................10
4 Security Considerations ....................................10
5 IANA Considerations ........................................10
6 Informative References .....................................11
7 Acknowledgments ............................................13
1 Introduction
The pervasiveness and the ubiquity of the Internet have empowered
mobile users, bringing it closer to reality for anyone to achieve
the goal of being able to work anywhere, anytime, and using any
device. The user's computer may only contain just a minimal
operating system with a web browser to serve as little more than a
display terminal for processes occurring on a network of computers
far away. Therefore, being able to setup a connection with any
authorized network nodes containing the needed resources on demand
will further increase the flexibility for the user, allowing him/her
to pick and choose the appropriate resources based on different
criteria for the task at hand. These network nodes containing the
needed resources may reside inside the local network, or externally
at an internet connected datacenter.
A user may need to set up a secure connection with an authorized
network node for data backup and archiving purposes. This allows a
user that stores his/her data at one facility (such as a cloud
storage facility) to backup and archive his/her data at a different
facility (such as a different cloud storage facility) in order to
avoid suffering irrecoverable data loss in a catastrophic situation.
A user may want to set up a secure connection with a remote
authorized network node for data mirroring purposes. This allows a
mobile user to maintain remote copies of the data at different
locations. Then depending on his/her current location, he/she can
select the nearest network node containing a replica of his/her data
in order to reduce the access latency.
In some anti-DDoS (distributed denial of service) solutions, the
network node running the operation of the anti-DDoS solution is
responsible for formulating the detection and cleaning policies
based on user defined requirements. The network node needs to set
up secure connections with the network nodes responsible for DDoS
detection and the network nodes responsible for cleaning in order to
Ko Expires April, 2012 [Page 2]
Internet-Draft VaaS Problem Statement October 2011
deliver the policies for execution. In turn, each network node
containing the DDoS detectors identifies and detects DDoS traffic,
and periodically sets up a secure connection with the network node
running the operation to return the detection results in order for
the cleaning policies to be updated based on the detection results.
Similarly, each network node acting as a cleaning agent filters DDoS
traffic and isolates threats, and periodically sets up a secure
connection with the network node running the anti-DDoS solution in
order to receive updated cleaning policies.
These and other examples point to the need for setting up secure
connections with authorized network nodes anywhere in the Internet
for various reasons.
VPN as a Service (VaaS) is envisioned as a way to either transition
or complement existing ways of establishing VPN service between a
set of sites or clients. There are some fundamental differences
between VaaS and the various forms of VPN today. For example, VaaS
is Open as opposed to data plane provider centric; dynamic as
opposed to "order based"; customer driven as opposed to provider
provisioned; control plane based as opposed to router based;
elastic/cloud based as opposed to fixed; etc. Yet the service model
and customer expectations in terms of routing information
distribution or additional built-in functional appliances as part of
the VPN service would be as good as or better when compared with
today's VPN offerings.
2 Problems in Establishing Secure Interconnections
Establishing and maintaining a secure connection between two network
nodes entails challenges related to connectivity, security, and
management.
2.1 Connectivity Problems
The first consideration in establishing a secure connection between
two authorized network nodes is the ability to create an end-to-end
connection between the two nodes. Ideally any node connected to the
Internet should be able to establish addressing and create direct
end-to-end connection with another network node regardless of its
topological location and Internet Protocol technology (IPv4/v6). In
reality, a network node can be located anywhere in a private or
public network, directly connected or behind one or more levels of
NAT [NAT]. In addition, it is not uncommon for a node to have a
dynamic IP address on its physical or virtual interfaces.
Furthermore, the status of a node being online or offline is
Ko Expires April, 2012 [Page 3]
Internet-Draft VaaS Problem Statement October 2011
dynamic. For a mobile user, even the physical location of a node is
also dynamic.
Due to the dynamic nature, automated discovery is an important
requirement for the user to set up a secure connection with an
authorized network node. The IETF standard known as the Service
Location Protocol [SLP] allows computers and other devices to find
services in a local area network. In larger networks, one or more
"directory agents" are used in SLP. Service agents send register
messages containing all the services they advertise to the
"directory agents". User agents issue service requests to the
"directory agent", specifying the characteristics of the services
they require. To provision services to users, a network
administrator can assign a scope string to each and every user agent
in order to limit the user agent to discover only that particular
grouping of services. As currently defined, the "directory agent"
merely functions as a cache and does not have the authority to set
the scopes for the user agents.
In some cases it is not possible to establish a direct end-to-end
connection especially when both parties are located behind NATs.
The IETF standard known as Traversal Using Relays around NAT [TURN]
allows a host behind a NAT to use the services of an intermediate
node that acts as a communication relay in order to exchange packets
with its peers. A client using TURN must have some way to
communicate the relayed transport address to its peers, and to learn
each peer's IP address and port (more precisely, each peer's server-
reflexive transport address). This can be done using a special-
purpose "introduction" or "rendezvous" protocol (see [RFC5128]), but
it does require the use of a publicly addressable "rendezvous
server".
The Internet Storage Name Service [ISNS] protocol facilitates the
automated discovery, management, and scalable configuration of
Internet Small Computer Systems Interface [ISCSI] devices on a
TCP/IP network. iSNS allows the administrator to go beyond a simple
device-by-device management model, where each storage device is
manually and individually configured with its own list of known
initiators and targets. Using iSNS, each storage device
subordinates its discovery and management responsibilities to an
"iSNS server". The "iSNS server" serves as the consolidated
configuration point through which management stations can configure
and manage the entire storage network. With the iSNS protocol
supporting the interaction between "iSNS servers" and iSNS clients,
iSNS provides the intelligent storage discovery and management
services needed. However, iSNS is intended to emulate Fibre Channel
fabric services for managing both iSCSI and Fibre Channel devices,
Ko Expires April, 2012 [Page 4]
Internet-Draft VaaS Problem Statement October 2011
and is therefore not suitable for use outside of the storage area
network.
The iSNS model points to the desirability of subordinating the
network nodes to a consolidated configuration point for scalability
reasons. This allows the network administrator to use the
consolidated configuration point through which management stations
can configure and manage the network, instead of the simple node-by-
node management model, where each network node is manually and
individually configured with its own list of authorized network
nodes. The consolidated configuration point, acting as a
centralized server, can facilitate the automated discovery problem
since it contains the necessary parameters for network nodes to
discover and construct secure connections with other authorized
network nodes. Certain parameters can be pre-configured by the
network administrator while others can be dynamically provided by
the network nodes. The parameters may contain the topology of the
overlay network (e.g., hub-and-spokes or hub), the function type of
specific network nodes (e.g., router or host), the tunneling method
(e.g., IPsec), the routing protocols (e.g., OSPF), or routing lookup
method (e.g., DNS lookup), the dynamic physical and virtual IP
addresses of the network nodes, etc. For NAT traversal, the
centralized server can also serve as the rendezvous server.
Existing standards that use centralized servers such as the SLP
"directory agent", the "iSNS server", etc., provide some but not all
of the functionalities needed.
Existing methodologies can be used by network nodes to discover the
centralized server, such as pre-configuring the domain name or
address of the centralized server in the network nodes, or
provisioning via Dynamic Host Configuration Protocol [DHCP] or
Domain Name System [DNS] lookup, etc. When a network node is ready
to connect to other network nodes, or allow others to connect to it,
it contacts a centralized server to login and register its presence
in the network. After a successful login, a network node may
register additional information (e.g., its dynamic IP address) with
the centralized server so that the information can be shared with
other authorized network nodes. The centralized server in turn
provides the network node with the necessary information needed to
establish a connection with other network nodes. Through the
centralized server, a network node should be able to determine other
network nodes that it is authorized to access, the online status of
other network nodes, parameters needed to establish a connection,
etc.
Ko Expires April, 2012 [Page 5]
Internet-Draft VaaS Problem Statement October 2011
2.1.1 Routing information exchange
There are a number of VPN profiles which can be established and
operate under very different routing information exchange models.
Some sites may use split tunneling, allowing them to use both the
VPN connection as well as to access the Internet locally, and some
will mandate that the entire site or host may only communicate
within the scope of the VPN sites.
The simplest model is to use the default route to push all host or
site traffic towards the VPN connection. However that model
requires that a site initiates a connection with the VPN server in
order to access any content present at such site or directly connect
with such site.
The next model extends the former model with site to site or site to
hub routing information exchange. Such exchange will occur within
the established VPN tunnel. The actual exchange can be carried
directly by the routing protocol (BGP). This is especially useful
for medium or large VPN sites with a real router interface towards
the Internet. Alternatively if a customer site is interfacing the
core with a host, then an interface to a routing protocol may be
used to facilitate routing information exchange. An example of such
interface utilizing XMPP was documented in [BGP-VPN-ES].
For large VPN sites, VaaS providers will assure that routing
information is securely exchanged between all VPN sites. This
document envisions the control plane transparent route server model
as described in [IERS] to facilitate the routing information
exchange between VPN sites.
Another approach which can be considered is the emerging ID/Locator
split approach. It could be network based [LISP] or host based
[ILNP] class of solution. Note that these approaches also solve the
host mobility issue which is especially important when potential VPN
participants could be smartphones. Such approaches are being
designed to operate in the scale of the internet, but they could
also be deployed within the scope of the VPNs.
2.1.2 Add-on Services
VPN as a Service can be easily enhanced with new functionalities by
an entity providing such VPN service. The number of appliances per
VPN can be enabled as requested by a given VPN user group. Examples
of such appliances are virtual firewalls, load balancers, content
hosting, local DNS, etc.
Ko Expires April, 2012 [Page 6]
Internet-Draft VaaS Problem Statement October 2011
2.2 Security Problems
The second consideration in establishing a secure connection between
two authorized network nodes is security. Ideally any node with the
same security/application strategy can form a secure connection free
of the restrictions of the physical network, and network Security
Assurance solutions should not be dependent on network topology.
The secure connection should provide unified security services for
trusted network construction, authentication and access control,
data confidentiality and data integrity, and non-repudiation.
In a datacenter, there are identifiable boundaries to an enclave.
(An enclave is the collection of local computing devices that are
governed by a single security policy). This facilitates the defense
of the enclave boundary by focusing on effective control and
monitoring of data flow into and out of the enclave. Effective
control measures include firewalls, guards, Virtual Private Networks
[VPN], and identification and authentication access control for
remote users. Effective monitoring mechanisms include network-based
Intrusion Detection System (IDS), vulnerability scanners, and virus
detectors located on the LAN (see [IATF]).
On the Internet, critical systems are exposed, and physical
isolation can no longer be relied upon to enforce security.
Instead, each network node must be treated as a separate enclave and
be protected as such. There is a need for client authentication,
peer discovery, virtual network address management, etc. in order to
enable a user to setup a secure connection.
Various IETF standards on security such as IP Security [IPSEC],
Transport Layer Security [TLS], Secure Shell [SSH], Public-Key
Cryptography Standards [PKCS], etc, provide the needed framework for
network nodes to create security tunnels to satisfy the security
requirement. But to create a security tunnel during connection
establishment, a network node may need to have access to certificate
fingerprint (see [RFC4572]), generated keys and security strategy,
etc. These can be facilitated by having a centralized server in the
network responsible for disseminating the required information. A
centralized server is also needed to handle the authentication,
authorization and accounting for a network node after the network
node presents its identity and credentials to the centralized server
upon login. This means that the network node and the centralized
server may share a pre-configured or automatically established
security association to prevent unauthorized access.
Existing standards such as Kerberos [KERBEROS] can be used to
satisfy the authentication aspect of establishing a secure
Ko Expires April, 2012 [Page 7]
Internet-Draft VaaS Problem Statement October 2011
connection. Kerberos acts as a trusted third-party authentication
service by using conventional (shared secret key) cryptography.
Extensions to Kerberos can provide for the use of public key
cryptography during certain phases of the authentication protocol.
2.3 Management Problems
The third consideration in establishing a secure connection between
two authorized network nodes is on management and control. The
following is a list of some of the critical management tasks that
are required for establishing a secure connection between two
authorized network nodes:
1. Discover if the network nodes that a user is authorized to access
are currently online and active.
2. Discover the functional attributes associated with these
authorized network nodes.
3. Discover the location of the authorized network nodes.
4. Determine if accessing the network node requires going through a
relay (e.g., TURN). Discover the location of the relay if it is
needed.
5. Determine the parameters needed to establish a secure connection
between the two network nodes.
6. Discover, via inquiry or advertisement, other authorized network
nodes as they become active and available.
One popular protocol for managing networked devices is the Simple
Network Management Protocol [SNMP]. The current standard version,
SNMPv3, defines the full security framework including User-based
Security Model [USM] and View-based Access Control Model [VACM].
SNMP was designed to facilitate the exchange of management
information between networked devices. Even though it was
originally intended to configure network equipment, SNMP is mainly
being used for network monitoring due to several reasons. Firstly,
network operators prefer the text-based Command Line Interfaces
(CLI) to configure their boxes, instead of the BER-encoded SNMP (see
[BER]). Secondly, many equipment vendors did not provide the option
to completely configure their devices via SNMP (see [RFC3535]).
The Network Configuration Protocol [NETCONF] uses an Extensible
Markup Language (XML) based data encoding for the configuration data
and the protocol messages to provide mechanisms to install,
Ko Expires April, 2012 [Page 8]
Internet-Draft VaaS Problem Statement October 2011
manipulate, and delete the configuration of network devices. The
Secure Shell [SSH] protocol is mandatory to support for
confidentiality and authentication. NETCONF uses a simple RPC-based
mechanism to facilitate communication between a client and a server.
A client is typically a network administrator, while a server is
typically a network device. Accordingly, a device may optionally
support multiple NETCONF sessions but is only required to support
one session. After all, "the NETCONF protocol is focused on the
information required to get the device into its desired running
state" by the network administrator.
Due to the dynamic nature of the network, existing protocols that
are geared towards static or manual configuration or monitoring
purposes would be difficult, if not impossible, to allow a user to
discover important information about the authorized network nodes
available. Furthermore, as the number of network nodes increases,
the amount of effort required becomes prohibitive for manual
configuration.
A protocol to facilitate the automated discovery, management, and
configuration of network nodes will be useful in establishing secure
connections. This protocol does not directly establish a secure
connection between the two network nodes. It only conveys the
information needed by the two network nodes to establish a secure
connection. This enables all existing methods of secure connection
establishment, such as VPN, to be supported without any changes.
Furthermore, with the desirability of having a centralized server
for scalability reasons to satisfy the connection and security
requirements, the management protocol should support the following
interactions between a network node and the centralized server:
1. Mutual authentication between a network node and the centralized
server
2. Virtual address assignment for the network node
3. Responding to inquiries from each network node regarding the
online status and other pertinent information related to peer
discovery for other network nodes that it is authorized to access
4. Providing all necessary parameters for establishing a secure
connection between two network nodes
5. Initiating State Change Notifications from the network nodes
Ko Expires April, 2012 [Page 9]
Internet-Draft VaaS Problem Statement October 2011
Multiple centralized servers are desirable for redundancy. If the
[LDAP] information base is used to support the centralized server,
then the information can be transferred using the [LDAP] protocol.
Otherwise a protocol is needed for distributing the information
between centralized servers.
3 Conclusions
This problem statement concludes that to handle the connectivity and
security problems related to the task of establishing a secure
connection in a dynamic environment between two authorized network
nodes, it would be desirable to have a centralized server to
coordinate the connection process for scalability reasons. Having a
centralized server facilitates the task of the network administrator
by allowing him/her to go beyond a simple node-by-node management
model, where each network node is manually and individually
configured. Instead, each network node subordinates its discovery
and management responsibilities to the centralized server. Each
network node, having retrieved the information from the centralized
server regarding the other network nodes that it is authorized to
access, can proceed with the connection process using supported
standards.
With the centralized server being the consolidated configuration
point for all the authorized network nodes in the network, a
protocol is needed for the interaction between a centralized server
and a network node. Where redundancy is required, the protocol also
needs to handle the interaction among centralized servers.
4 Security Considerations
If a new protocol is deployed, the interaction between a centralized
server and a network node and the interaction between two
centralized servers is subject to various security threats. As a
result, the protocol messages may need to be authenticated. In
addition, to protect against snooping of the protocol messages,
confidentiality support is desirable and is required when certain
functions of the centralized server are utilized.
5 IANA Considerations
This document has no actions for IANA.
Ko Expires April, 2012 [Page 10]
Internet-Draft VaaS Problem Statement October 2011
6 Informative References
[BER] "Information technology - ASN.1 encoding rules: Specification
of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
and Distinguished Encoding Rules (DER)", ITU-T X.690, July 2002
[BGP-VPN-ES] P. Marques et al, "End-system support for BGP-signaled
IP/VPNs", IETF Internet-draft draft-marques-l3vpn-end-system-02
(work in progress), October 2011
[DHCP] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,
March 1997
[DNS] P. Mockapetris, "Domain Names - Implementation and
Specification", RFC 1035, November 1987
[IATF] Technical Directors, National Security Agency Information
Assurance Solutions, "Information Assurance Technical
Framework", Release 3.1, September 2002
[IERS] E. Jasinska et al, "Internet Exchange Route Server", IETF
Internet-draft draft-jasinska-ix-bgp-route-server-03 (work in
progress), October 2011
[ILNP] RJ Atkinson, "ILNP Concept of Operations", IETF Internet-
draft draft-rja-ilnp-intro-11 (work in progress), July 2011
[IPSEC] S. Kent et al, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005
[ISCSI] J. Satran et al, "Internet Small Computer Systems Interface
(iSCSI)", RFC 3720, April 2004
[ISNS] J. Tseng et al, "Internet Storage Name Service (iSNS)", RFC
4171, September 2005
[KERBEROS] C. Neuman et al, "The Kerberos Network Authentication
Service (V5)", RFC 4120, July 2005
[LDAP] K. Zeilenga, "Lightweight Directory Access Protocol (LDAP):
Technical Specification Road Map", RFC 4510, June 2006
[LISP] D. Farinacci et al, "Locator/ID Separation Protocol (LISP)",
IETF Internet-draft draft-ietf-lisp-15 (work in progress), July
2011
Ko Expires April, 2012 [Page 11]
Internet-Draft VaaS Problem Statement October 2011
[NAT] P. Srisuresh et al, "Traditional IP Network Address Translator
(Traditional NAT)", RFC 3022, January 2001
[NETCONF] R. Enns et al, "NETCONF Configuration Protocol (NETCONF)",
RFC6241, June 2011
[PKCS] J. Jonsson et al, "Public-Key Cryptography Standards (PKCS)
#1: RSA Cryptography Specifications Version 2.1", RFC 3447,
February 2003
[RFC3535] J. Schoenwaelder, "Overview of the 2002 IAB Network
Management Workshop", RFC 3535, May 2003
[RFC4572] J. Lennox, "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006
[RFC5128] P. Srisuresh et al, "State of Peer-to-Peer (P2P)
Communication across Network Address Translators (NATs)", RFC
5128, March 2008
[SLP] E. Guttman et al, "Service Location Protocol, Version 2", RFC
2608, June 1999
[SNMP] R. Presuhn et al, "Version 2 of the Protocol Operations for
the Simple Network Management Protocol (SNMP)", STD 62, RFC
3416, December 2002
[SSH] T. Ylonen et al, "The Secure Shell (SSH) Protocol
Architecture", RFC 4251, January 2006
[TLS] T. Dierks et al, "The Transport Layer Security (TLS) Protocol
Version 1.2", RFC 5246, August 2008
[TURN] R. Mahy et al, "Traversal Using Relays around NAT (TURN):
Relay Extensions to Session Traversal Utilities for NAT (STUN)",
RFC 5766, April 2010
[USM] U. Blumenthal et al, "User-based Security Model (USM) for
version 3 of the Simple Network Management Protocol (SNMPv3)",
STD 62, RFC 3414, December 2002
[VACM] B. Wijnen et al, "View-based Access Control Model (VACM) for
the Simple Network Management Protocol (SNMP)", STD 62, RFC
3415, December 2002
Ko Expires April, 2012 [Page 12]
Internet-Draft VaaS Problem Statement October 2011
[VPN] A. Nagarajan, "Generic Requirements for Provider Provisioned
Virtual Private Networks (PPVPN)", RFC 3809, June 2004
7 Acknowledgments
The authors would like to thank David Harrington for his valuable
advice and suggestion.
Author's Address
Michael Ko
Huawei Symantec Technologies Co., Ltd.
20245 Stevens Creek Blvd.
Cupertino, CA 95014, USA
Phone: +1-408-510-7465
Email: michael@huaweisymantec.com
Edward Wang
Huawei Symantec Technologies Co., Ltd.
3rd Floor, Section D, Keshi Building
No. 28A, Xinxi Rd., Shangdi, Haidian Dist.
Beijing 100085 P.R. China
Phone: +86-10-6272-1288
Email: wangyc@huaweisymantec.com
Robert Raszuk
NTT MCL
101 S Ellsworth Avenue, Suite 350
San Mateo, CA 94401, USA
Email: robert@raszuk.net
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Ko Expires April, 2012 [Page 13]
Internet-Draft VaaS Problem Statement October 2011
Intellectual Property Statement
The IETF Trust 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 any IETF 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.
Copies of Intellectual Property 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
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
All IETF Documents and the information contained therein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE IETF TRUST 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Ko Expires April, 2012 [Page 14]
