[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06                                          
Internet-Draft                                   Yoshihiro Ohba (Editor)
Expires: August, 2003                                          Subir Das
                                                         Basavaraj Patil
                                                          Hesham Soliman
                                                             Alper Yegin


                                                       February 20, 2003


             Problem Statement and Usage Scenarios for PANA

                <draft-ietf-pana-usage-scenarios-04.txt>


Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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.


Abstract

   This document addresses a set of problems which a network layer
   protocol called PANA (Protocol for carrying Authentication for
   Network Access) is trying to solve in the area of network access
   authentication and describes several usage scenarios where PANA is
   applicable.  It also helps to facilitate the discussion for PANA
   requirements and security threat analysis that are used as basis of
   actual PANA protocol design.














                          Expires August, 2003                  [Page 1]


Internet-Draft            PANA Usage Scenarios         February 20, 2003


Table of Contents

   1         Introduction ............................................ 2
   2.        Problem Statement ....................................... 2
   3.        Usage Scenarios ......................................... 4
   3.1.      PANA with Physical Layer Security ....................... 4
   3.2.      PANA with Link-Layer Security ........................... 5
   3.3.      PANA in the Absence of Any Lower-Layer Security ......... 6
   3.4.      Mobile IP ............................................... 6
   3.5.      Personal Area Networks .................................. 7
   3.6.      Limited Free Access ..................................... 8
   4.        Acronyms ................................................ 8
   5.        Security Considerations ................................. 9
   6.        Acknowledgments ......................................... 9
   7.        References .............................................. 9
   7.1.      Normative References .................................... 9
   7.2.      Informative References ................................. 10
   8.        Authors' Information ................................... 10
   9.        Intellectual Property Notices .......................... 11
   10.       Copyright Notice ....................................... 11


1  Introduction

   Networks in most cases require some form of authentication in order
   to prevent unauthorized access.  Only authenticated and authorized
   clients should be able to attach to an access network for sending and
   receiving IP packets.

   There are various mechanisms to provide this required functionality.
   In its simplest form, unintended clients can be physically kept away
   from the access networks.  But there exist some scenarios where a
   solution based on physical security might not be practical.  Public
   access networks and wireless networks are such examples.  In the
   absence of physical security (and sometimes in addition to it) a
   higher layer access authentication mechanism is needed.  Link-layer
   based authentication mechanisms are used whenever they can serve the
   needs of a particular deployment.  Ability to support multiple
   authentication methods or to perform both network access provider and
   Internet service provider authentication are not available to all
   link-layers.  An even higher layer authentication mechanisms are
   needed whenever such additional requirements are not met by the
   underlying link-layers.  Generally a network or higher layer
   mechanism can be used instead of or in addition to available link-
   layer and physical security.  Currently there is not a standard
   protocol to perform network access authentication above link-layer.
   Instead, a number of ad-hoc and inadequate solutions are being used.
   PANA will be developed to fill this gap by defining a network-layer
   access authentication protocol.

   This I-D discusses the need for a standard network access
   authentication protocol and covers various usage scenarios where such
   a protocol is applicable.


2.  Problem Statement




                          Expires August, 2003                  [Page 2]


Internet-Draft            PANA Usage Scenarios         February 20, 2003


   Access networks usually require clients to go through an
   authentication and authorization process unless physical security is
   used as a substitute.  Network access authentication of clients
   necessitates a protocol between the client and the network to execute
   one or more authentication methods (e.g., CHAP, TLS, SIM, etc.).  In
   the light of proliferation of various access technologies (e.g.,
   GPRS, IEEE 802.11, DSL, etc.), it is important that the
   authentication methods are not tied to the underlying link-layer.
   Authentication protocol must be able to carry various authentication
   methods regardless of the underlying access technologies.

   An important aspect of network access is the ability to enable
   dynamic service provider selection.  Regardless of their network
   access provider (NAP), clients should be able to select an Internet
   access provider (ISP) of their choice.  This is usually achieved by
   clients presenting an identifier which carries domain information
   during the authentication process unless some other link-layer
   specific selectors are used during link establishment.  An example of
   such client identifier would be the NAI[RFC2486] (e.g.,
   john@anyisp.com.)  The authentication agent in the access network
   would consult the backend authentication servers in the given domain,
   and the respective ISP service will be used once the client access is
   authorized.  This is also essential in providing roaming service to
   clients.  A single authentication between the client and the ISP is
   generally sufficient for both NAP and ISP access by relying on the
   pre-established trust relation between the NAP and the ISP.
   Nevertheless, there are some scenarios where NAPs and ISPs require
   their independent authentication with the client.  If the NAP
   authentication is performed using a link-layer mechanism, ISP
   authentication can be left to a network-layer mechanism.  An example
   of a multi-layer authentication can be seen in cdma2000 networks as
   described in section 3.2.

   A network-layer authentication mechanism that will support various
   authentication methods can be developed by using a protocol that
   carries EAP [RFC2284bis].  EAP acts as an encapsulation of arbitrary
   authentication methods, but it still requires a transport between the
   client and the access network.  Among all the link-layers, only IEEE
   802 defines how to carry EAP on the link-layer [802.1X].  Any other
   link-layer has to resort to using PPP/PPPoE [RFC1661,RFC2516] as a
   link-layer agnostic way of carrying EAP.  Inserting this additional
   layer(s) between the link-layer and network-layer to achieve this
   goal is an inadequate method.  Using PPP just for client
   authentication incurs extra round-trips, generates overhead of PPP
   processing for data packets, and forces the network topology into a
   point-to-point model.

   In general terms, PANA will be defined as a network-layer transport
   for EAP.  It is believed that EAP is a key protocol in supporting
   various authentication methods for network access, and its
   applicability should not be limited to access networks that are using
   IEEE 802 and PPP links.  PANA can be used over any link-layer that
   does not support EAP encapsulation.  PPP might be perceived as a
   link-layer agnostic transport for EAP, but using PPP solely for
   authentication purpose incurs unnecessary cost and imposes additional
   limitations.




                          Expires August, 2003                  [Page 3]


Internet-Draft            PANA Usage Scenarios         February 20, 2003


   The primary purpose of PANA is to authenticate a client to a server
   for the network access purpose.  Initial client authentication needs
   to be bound to subsequent traffic to prevent spoofing and hijacking
   of data packets.  Therefore, this authentication might be required to
   generate cryptographic keying material unless presence of a secure
   physical or link-layer channel is assured prior to it.  The task of
   generating and distributing such keying material can be accomplished
   by various authentication methods carried by EAP.  PANA is only
   responsible for carrying EAP and it should not have to deal with the
   keying material.  Once the keying material is present, it can be used
   with link-layer ciphers, or IPsec for providing subsequent per-packet
   authentication.  It should be noted that the keying material produced
   by the authentication methods is generally not readily usable by
   IPsec.  A key exchange protocol like IKE [RFC2409] might be used to
   create the required IPsec security associations.  The mechanisms that
   are used to turn keying material produced by the initial
   authentication method into link-layer or network-layer ciphers are
   outside the scope of PANA.

   Until a standard solution like PANA is developed, architectures that
   use neither IEEE 802 nor PPP as link-layers are forced to design
   their own ad-hoc mechanisms to the problem.  One such mechanism is
   the application-layer authentication method implemented by http
   redirects and web-based login.  In addition to being a non-standard
   solution, this provides an incomplete network access authentication
   with well-known vulnerabilities, and therefore regarded as a stop-gap
   mechanism.

   Another method designed to provide network access authentication is
   based on overloading an existing network-layer protocol.  Mobile IPv4
   [RFC3344] protocol has a built-in authentication mechanism.
   Regardless of whether mobile nodes need to use a foreign agent in an
   access network, registration via a foreign agent can be required by
   using an appropriate flag in the agent advertisements.  This forces
   the nodes to register with a foreign agent, and therefore utilizes
   Mobile IPv4 protocol for network access authentication.  Such a
   solution has very limited applicability as a link-layer agnostic
   method since it relies on the deployment of Mobile IPv4 protocol.


3.  Usage Scenarios

   The first three subsections describe PANA usage scenarios categorized
   in terms of lower-layer security.  Other subsections describe
   scenarios that are not categorized in terms of lower-layer security.


3.1.  PANA with Physical Layer Security

   In the networks where a certain degree of security is provided at
   physical layer, authenticating the client is still essential since
   physical layer does not provide information on the client, but per-
   packet authentication and encryption may not necessarily be provided
   at higher layers.  DSL networks that are implemented on top of point-
   to-point phone lines are such an example.  In this type of networks,
   PANA can be used for client authentication and a hook to an
   appropriate access control.



                          Expires August, 2003                  [Page 4]


Internet-Draft            PANA Usage Scenarios         February 20, 2003


   In DSL networks, there are a number of deployment scenarios with
   regard to client configuration and client authentication.  In DSL
   networks where PPP or PPPoE is used for both configuration and
   authentication (and IP encapsulation), the providers may not require
   to migrate to use PANA.  On the other hand, there are some DSL
   networks that use some configuration method other than PPP or PPPoE,
   i.e., DHCP or static configuration.  Those networks use either an ad-
   hoc network access authentication method such as http-redirect with
   web-based login or no authentication method at all.  A standard,
   link-layer agnostic network access authentication is needed for this
   type of DSL networks and PANA can be used to fill the demand.  In
   addition, the variation in DSL deployment scenarios, particularly the
   variation in physical topology between DSL modem and ISP edge router,
   makes it difficult to define a single authentication scheme which
   operates at lower-layer and works with any physical topology.  It is
   highly possible that an link-layer agnostic, single network access
   authentication solution will be demanded for future DSL deployments
   as long as the variation is supposed to exist.


3.2.  PANA with Link-Layer Security

   Certain link-layers in radio networks such as GSM and cdma2000
   provide their own authentication mechanisms as well as ciphering of
   data sent over the physical air interface.  This air-
   interface/technology specific authentication enables authorization
   for accessing the link by the NAP, and provides per-packet
   authentication, integrity and replay protection on the link-layer.
   But it does not necessarily provide authorization at the network-
   layer which can be done by authenticating the client to an ISP.  So
   this still necessitates another layer of authentication.  It should
   be noted that this second authentication takes place over a secure
   channel.

   cdma2000 is a good example of such an architecture where multi-
   layered authentication for network access takes place.  cdma2000
   networks require the user/device to authenticate with the MSC/VLR
   before providing access to the packet data network.  The technology
   specific access authentication which uses the CAVE (cellular
   authentication and voice encryption) algorithms also provides cipher
   keys to the mobile and the base station for securing the link layer
   for all subsequent voice and data carried on the air interface.  In
   the Simple IP mode of cdma2000 services, the ISP authentication is
   provided by using PPP in the stack.  Currently there are proposals to
   remove PPP from the architecture and adopt a simple framing scheme
   such as HDLC or variants.  One of the functionalities of PPP that
   needs to be taken over by another protocol or mechanism is the
   authentication capability.  In such a scenario, network access
   authentication may be done using PANA protocol.

   Where a multi-layer authentication for network access is needed, and
   access technology specific authentication is already provided by
   another protocol, PANA can be used as the network-layer
   authentication protocol.  In this case PANA will be running over a
   cryptographically secured channel.





                          Expires August, 2003                  [Page 5]


Internet-Draft            PANA Usage Scenarios         February 20, 2003


3.3.  PANA in the Absence of Any Lower-Layer Security

   There are scenarios where neither physical nor link-layer access
   control is available on the network.  One possible cause of this
   scenario is the lack of adequate authentication capabilities on the
   link-layer technology being used.  Link-layer technologies generally
   provide sufficient cipher suite support but inadequate authentication
   method support.  It is desirable to support arbitrary authentication
   methods without being limited to the ones that are specific to the
   underlying technology.  Another cause of missing lower-layer
   authentication is due to the difficulty of deployment.  Assuring
   physical security or enabling link-layer security might not be
   practical for various reasons.  In the absence of such lower-layer
   security and authentication mechanism not only providers are unable
   to control the unauthorized use of their networks but also users feel
   insecure while exchanging sensitive information.  In order to support
   authentication functionality in such systems, many providers today
   use a higher-layer authentication scheme, such as http-redirect
   commonly known as web-based login.  In this method, once the link is
   established, users' traffic are re-directed to a web server which in
   turn generates a web-based login forcing users to provide the
   authentication information.  While this method solves the problem
   partially by allowing only authorized users to access the network, it
   however does not enable the lower-layer security such as, per-packet
   authentication and encryption, etc.  Moreover, it is a non-standard
   ad hoc solution that provides only limited authentication method
   support.

   In such scenarios, a standard mechanism is necessary which can
   provide network access authentication irrespective of whether the
   underlying layers are secured or not.  A solution like PANA at the
   network layer may be adequate if it can specify appropriate
   authentication methods that can derive and distribute keys for
   authentication, integrity and confidentiality of data traffic either
   at the link or at the network layer.  For example, if link-layer does
   not support the desired authentication method but supports ciphering,
   PANA can be used to bootstrap the latter.  On the other hand, if
   link-layer neither supports the desired authentication method nor
   ciphering, PANA can be used to bootstrap higher layer security
   protocols, such as, IKE and IPsec.  Thus successful PANA
   authentication can result to a secured network environment although
   the underlying layers were not secured at the beginning.  Also
   assuming PANA will provide support to various authentication schemes,
   providers will have advantage using a single framework across
   multiple environments.


3.4.  Mobile IP

   Mobile IPv4 defines its own authentication extensions to authenticate
   and authorize mobile nodes at the foreign agents and home agents.
   One of the possible modes of Mobile IPv4 is when the mobile node uses
   a co-located care-of address and doesn't rely on any mobility
   management functionality of the foreign agent on the access network.
   In this case, mobile node can send its registration request directly
   to the home agent.  Even in the co-located care-of address case, the
   protocol has a way to require mobile nodes to register with a foreign



                          Expires August, 2003                  [Page 6]


Internet-Draft            PANA Usage Scenarios         February 20, 2003


   agent by setting Registration-Required bit in the agent
   advertisements.  This forces mobile nodes to send their registration
   requests via foreign agent, even though they do not have to interact
   with that agent otherwise.

   This type of Mobile IP registrations are used for performing network
   access authentication.  This method can only be used in IPv4 networks
   where every client implements mobile node functionality.  Even for
   IPv4 clients, a better approach would be to replace this protocol-
   specific authentication method by a common authentication protocol
   such as PANA.  PANA can be used with any client regardless of Mobile
   IPv4 support and it can support various authentication methods.  PANA
   can also be used with IPv6 clients, or dual-stack clients.  Mobile
   IPv6 [MIPv6] protocol doesn't define a foreign agent in the access
   networks and provide any protocol support for access authentication.

   Network access authentication can be handled by PANA regardless of IP
   version of the clients and independent of whether they support or use
   Mobile IP.


3.5.  Personal Area Networks

   A personal area network (PAN) is the interconnection of devices
   within the range of an individual person.  For example connecting a
   cellular phone, PDA, and laptop together via short range wireless or
   wireless links would form a PAN.

   Devices in a PAN can directly communicate with each other, and access
   the Internet if any one of them is specifically designated as a
   mobile router for providing gateway functionality.  Just like any
   access network, a PAN also requires authentication and authorization
   prior to granting access to its clients.  A mobile router can
   terminate the link-layer from different PAN nodes, and therefore it
   acts as the first-hop router for them.  Additionally, it can also
   perform access control as an authentication agent.  Different nodes
   might be using different link-layer technologies to connect to a
   mobile router.  Therefore, it is desirable to use authentication
   methods independent of the underlying link and rely on a link-layer
   agnostic authentication protocol like PANA to carry authentication
   information.

   Another characteristic of PANs is its small scale.  Only a handful of
   nodes are expected to be part of a given PAN; therefore the
   authentication process does not necessarily require a managed backend
   AAA infrastructure for credential verification.  Locally stored
   information can be used in this kind of PANA deployment without
   relying on a AAA backend.

   The 3GPP architecture allows separation of MT (mobile termination,
   such as cellular phone) and TE (terminal equipment, such as laptop)
   [RFC3314].  TE can be connected to the Internet via MT by
   establishing a PPP connection.  One or more TEs can be connected to a
   MT to form a PAN.  The current architecture does not allow direct
   communication between the TEs (if more than one are connected to the
   MT) without having to go through the cellular interface of the MT.
   This architecture will benefit from using shared links (e.g.,



                          Expires August, 2003                  [Page 7]


Internet-Draft            PANA Usage Scenarios         February 20, 2003


   Ethernet) between the TE and MT.  Shared links would allow TEs to
   communicate directly to each other without having to send data
   through the power-limited MT or over the expensive air interface.
   PANA can be used for authenticating PAN nodes when shared links are
   used between the TEs and MT.


3.6.  Limited Free Access

   Certain networks might allow clients to access a limited topology
   without any explicit authentication and authorization.  However, the
   policy may be such that an access beyond this topology requires
   authentication and authorization.  For example, in an airport
   network, information such as, flight arrival and departure gate
   numbers, airport shops and restaurants, etc., are offered as free
   services by the airlines or airport authorities for their passengers.
   In order to access such information, users' can simply plug in their
   devices into the network without performing any authentication.  In
   fact, the network will only offer link-layer connectivity and limited
   network layer access to users.  On the other hand, access to further
   services or sites using such local networks requires authentication
   and authorization.  If users want such services, the access network
   can detect that attempt and initiate authentication.  This also
   allows the network to initiate the authentication whenever
   appropriate.  Once users perform the authentication it will be
   allowed to go beyond the free access zone.  PANA can be an enabler to
   such limited free access scenarios and can offer a flexible access
   control framework for public hot-spot networks.


4.  Acronyms

   AAA: Authentication, Authorization and Accounting

   DSL: Digital Subscriber Line

   EAP: Extensible Authentication Protocol

   GPRS: General Packet Radio Service

   HDLC: High-level Data Link Control

   IKE: Internet Key Exchange

   ISP: Internet Service Provider

   MSC: Mobile Switching Center

   MN: Mobile Node

   MT: Mobile Termination

   NAI: Network Access Identifier

   NAP: Network Access Provider

   PPP: Point-to-Point Protocol



                          Expires August, 2003                  [Page 8]


Internet-Draft            PANA Usage Scenarios         February 20, 2003


   PPPoE: PPP over Ethernet

   TE: Terminal Equipment

   UE: User Equipment

   VLR: Visiting Location Register


5.  Security Considerations

   This Internet-Draft identifies the need for a standard network-layer
   authentication protocol and illustrates a number of possible usage
   scenarios.  The actual protocol design is not specified in this
   draft, neither are the security considerations around it.  The
   scenarios described in this document are used as input to a separate
   security threats analysis document [SECTHREAT].  Eventually, the
   requirements are derived from both the scenarios described in this
   document and also the threats analyzed in the latter document.  These
   requirements are being collected in the [PANAREQ] Internet-Draft.
   The readers are urged to read these two documents for security
   considerations around designing PANA.


6.  Acknowledgments

   The authors would like to thank Bernard Aboba, James Carlson, Jacques
   Caron, Francis Dupont, Paal Engelstad, Henry Haverinen, Prakash
   Jayaraman, James Kempf, Thomas Narten, Erik Nordmark, Reinaldo Penno,
   Phil Roberts, David Spence, Barani Subbiah, Hannes Tschofenig, George
   Tsirtsis, John Vollbrecht, Cliff Wang and the rest of the PANA
   Working Group for the ideas and support they have given to this
   document.


7.  References

7.1.  Normative References

   [MIPv6] D. Johnson, et al., "Mobility Support in IPv6", (draft-ietf-
       mobileip-ipv6-20.txt).

   [PANAREQ] R. Penno, et al., "Protocol for Carrying Authentication for
       Network Access (PANA) Requirements and Terminology" (draft-ietf-
       pana-requirements-04.txt).

   [RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661
       (STD 51), July 1994.

   [RFC2284bis] L. Blunk, et al., "Extensible Authentication Protocol
       (EAP)" (draft-ietf-eap-rfc2284bis-01.txt).

   [RFC2409] D. Harkins and D. Carrel, "The Internet Key Exchange
       (IKE)", RFC 2409, November 1998.

   [RFC2486] B. Aboba, et al., "The Network Access Identifier", RFC
       2486, January 1999.



                          Expires August, 2003                  [Page 9]


Internet-Draft            PANA Usage Scenarios         February 20, 2003


   [RFC2516] L. Mamakos, et al., "A Method for Transmitting PPP Over
       Ethernet (PPPoE)", RFC 2516, February 1999.

   [RFC3314] M. Wasserman et al., "Recommendations for IPv6 in Third
       Generation Partnership Project (3GPP) Standards", RFC 3314,
       September 2002.

   [RFC3344] C. Perkins, "IP Mobility Support for IPv4", RFC 3344,
       August 2002.

   [SECTHREAT] M. Parthasarathy, "PANA Threat Analysis and security
       requirements" (draft-ietf-pana-threats-01.txt).

7.2.  Informative References

   [802.1X] IEEE Standard for Local and Metropolitan Area Networks,
       "Port-Based Network Access Control", IEEE Std 802.1X-2001.


8.  Authors' Information

   Yoshihiro Ohba
   Toshiba America Research, Inc.
   P.O. Box 136
   Convent Station, NJ 07961-0136
   USA
   Phone: +1 973 829 5174
   Fax:   +1 973 829 5601
   Email: yohba@tari.toshiba.com

   Subir Das
   MCC 1D210R, Telcordia Technologies
   445 South Street, Morristown, NJ 07960
   Phone: +1 973 829 4959
   email: subir@research.telcordia.com

   Basavaraj Patil
   Nokia
   6000 Connection Dr.
   Irving, TX. 75039
   USA
   Phone:  +1 972-894-6709
   Email:  Basavaraj.Patil@nokia.com

   Hesham Soliman
   Ericsson Radio Systems AB
   Torshamnsgatan 29,
   Kista, Stockholm 16480
   Sweden
   Phone:  +46 8 4046619
   Fax:    +46 8 4047020
   Email: Hesham.Soliman@era.ericsson.se

   Alper E. Yegin
   DoCoMo USA Labs
   181 Metro Drive, Suite 300
   San Jose, CA, 95110



                          Expires August, 2003                 [Page 10]


Internet-Draft            PANA Usage Scenarios         February 20, 2003


   USA
   Phone: +1 408 451 4743
   Email: alper@docomolabs-usa.com


9.  Intellectual Property Notices

   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.


10.  Copyright Notice

   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.





                          Expires August, 2003                 [Page 11]