[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-mahy-sip-connect-reuse) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 RFC 5923

SIP WG                                                           R. Mahy
Internet-Draft                                                 Airespace
Expires: April 22, 2005                                 October 22, 2004


       Connection Reuse in the Session Initiation Protocol (SIP)
                  draft-ietf-sip-connect-reuse-03.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 April 22, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   When SIP entities use a connection oriented protocol to send a
   request, they typically originate their connections from an ephemeral
   port.  The SIP protocol includes mechanisms which insure that
   responses to a request, and new requests sent in the original
   direction reuse an existing connection.  However, new requests sent
   in the opposite direction are unlikely to reuse the existing
   connection.  This frequently causes a pair of SIP entities to use one
   connection for requests sent in each direction, and can result in
   potential scaling and performance problems.  This document proposes
   requirements and a mechanism which address this deficiency.



Mahy                     Expires April 22, 2005                 [Page 1]

Internet-Draft            SIP Connection Reuse              October 2004


Table of Contents

   1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction and Problem Statement . . . . . . . . . . . . . .  3
     2.1   Efficiency Concerns  . . . . . . . . . . . . . . . . . . .  3
     2.2   Directional Connectivity . . . . . . . . . . . . . . . . .  4
     2.3   Clustering . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.4   Hop-by-hop reuse . . . . . . . . . . . . . . . . . . . . .  7
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1   Authorizing an alias request . . . . . . . . . . . . . . .  9
       4.1.1   Authorizing using TLS mutual authentication  . . . . . 10
     4.2   Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 12
   8.2   Informational References . . . . . . . . . . . . . . . . . . 12
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
       Intellectual Property and Copyright Statements . . . . . . . . 14






























Mahy                     Expires April 22, 2005                 [Page 2]

Internet-Draft            SIP Connection Reuse              October 2004


1.  Conventions

   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 [4].

2.  Introduction and Problem Statement

   SIP [3] entities can communicate using either unreliable/
   connectionless (ex: UDP) or reliable/connection-oriented (ex: TCP,
   SCTP [13]) transport protocols.  When SIP entities use a
   connection-oriented protocol (such as TCP or SCTP) to send a request,
   they typically originate their connections from an ephemeral port.

   In the following example, Entity A listens for SIP requests over TLS
   [5] on TCP port 5061 (the default port for SIP over TLS over TCP),
   but uses an ephemeral port (port 8293) for a new connection to Entity
   B.  These entities could be SIP User Agents or SIP Proxy Servers.

          +-----------+ 8293 (UAC)      5061 (UAS) +-----------+
          |           |--------------------------->|           |
          |  Entity   |                            |  Entity   |
          |     A     |                            |     B     |
          |           | 5061 (UAS)                 |           |
          +-----------+                            +-----------+

   The SIP protocol includes mechanisms which insure that responses to a
   request reuse the existing connection which is typically still
   available, and also includes provisions for reusing existing
   connections for other requests sent by the originator of the
   connection.  However, new requests sent in the opposite direction
   (routed from the target of the original connection toward the
   originator of the original connection) are unlikely to reuse the
   existing connection.  This frequently causes a pair of SIP entities
   to use one connection for requests sent in each direction, as shown
   below.

          +-----------+ 8293              5061 +-----------+
          |           |.......................>|           |
          |  Entity   |                        |  Entity   |
          |     A     | 5061              9741 |     B     |
          |           |<-----------------------|           |
          +-----------+                        +-----------+


2.1  Efficiency Concerns

   This extra pair of connections can result in potential scaling and



Mahy                     Expires April 22, 2005                 [Page 3]

Internet-Draft            SIP Connection Reuse              October 2004


   performance problems.  For example, each new connection using TLS
   requires a TCP 3-way handshake, a handful of round-trips to establish
   TLS, and (typically) expensive asymmetric authentication and key
   generation algorithms, and certificate verification.  This
   effectively doubles the load on each entity.  Setting up a second
   connection can also cause excessive delay (especially in networks
   with long round-trip times) for subsequent requests, even requests in
   the context of an existing dialog (for example a reINVITE or BYE
   after an initial INVITE, or a NOTIFY after a SUBSCRIBE [12] or a
   REFER [11]).

   Consider the call flow shown below where Proxy A and Proxy B use the
   Record-Route mechanism to stay involved in a dialog.  Proxy B will
   establish a new TLS connection just to send a BYE request.

      INVITE ->   create connection 1
      <- 200      response over connection 1
      ACK ->      reuse connection 1

      <- BYE      create connection 2
      -> 200      response over connection 2

   ReINVITEs or UPDATE [8] requests are expected to be handled
   automatically and rapidly in order to avoid media and session state
   from being out of step.  If a reINVITE requires a new TLS connection,
   the reINVITE could be delayed by several extra round-trip times.
   Depending on the round-trip time, this combined delay could be
   perceptible or even annoying to a human user.  This is especially
   problematic for some common SIP call flows (for example, the
   recommended example flow in figure number 4 in RFC3725 [9] (SIP
   third-party call control) use many reINVITEs.

2.2  Directional Connectivity

   Some SIP User Agents can initiate TCP or TLS connections, but for one
   reason or another cannot usefully accept incoming connections.  When
   TLS connections are involved, many User Agents can accept incoming
   TLS connections, but cannot provide a certificate that is likely to
   be trusted by the TLS client.  (The User Agent can only offer a
   self-signed certificate for example.)  This cause their connectivity
   to fail

   In other cases, a User Agent cannot accept incoming TCP connections
   at all because they are behind a Firewall or NAT.







Mahy                     Expires April 22, 2005                 [Page 4]

Internet-Draft            SIP Connection Reuse              October 2004


                            +---+
          +-----------+     |   |          +-----------+
          |           |-----|   |--------->|           |
          |  User     |     | F |          |  Proxy    |
          |  Agent A  |     | W |          |  Server   |
          |           |     |   X<---------|           |
          +-----------+     |   |          +-----------+
                            +---+

   Finally, some User Agents may be configured to refuse incoming TCP or
   TLS connections, since it is difficult or impossible for some class
   of User Agents to authorize such connections.

   In all three of these cases, some form of connection reuse is no
   longer simply an efficiency improvement.  It is mandatory to make TCP
   or TLS work for a large class of SIP User Agents.  For User Agents in
   this class, incoming requests need to come from a proxy server with
   which the User Agent has a persistent connection.  Each User Agent in
   this class of UAs also needs to have a SIP URI with GRUU [2]
   properties that routes to a proxy server that knows how to forward
   requests over a persistent connection already opened by the User
   Agent.  However, just using the GRUU mechanism by itself does not
   help a proxy server determine which incoming persistent connection is
   associated with a particular GRUU.  An explicit connection management
   mechanism for outbound connections is still needed between these User
   Agents and their proxies.  Mechanisms for addressing the requirements
   of this class of User Agents are out of scope for this document, but
   are instead discussed in [1].

   For example, consider a standard SIP presence [10] subscription.  An
   instant messaging and presence client sends a SUBSCRIBE request for
   the presence of a peer.  The presence notifications are returned as
   NOTIFY requests from the peer.  If the subscribing User Agent wants
   to use TLS, the NOTIFY request would cause a second (new) connection
   back to the subscribing client.  If the presence client doesn't have
   a valid TLS certificate anchored in a well-known certificate
   authority, the NOTIFY request will fail, and the presence client will
   never receive any presence data.

      SUBSCRIBE ->           connection 1
      <- 202                 connection 1
      <- NOTIFY              connection 2
      200 ->                 connection 2


2.3  Clustering

   When clusters or farms of cooperating SIP servers (for example proxy



Mahy                     Expires April 22, 2005                 [Page 5]

Internet-Draft            SIP Connection Reuse              October 2004


   servers) are configured together, SIP entities have no way to prefer
   a server with an existing connection.  For example, Proxy server B
   has no mechanism to choose an existing connection with Proxy cluster
   A.

          +-----------+
          |           |
          |   Proxy   |
          |    A1     |                        +-----------+
          |           |                        |           |
          +-----------+                        |   Proxy   |
          +-----------+ 8293              5061 |     B     |
          |           |----------------------->|           |
          |   Proxy   |                        +-----------+
          |     A2    |
          |           |
          +-----------+

   As a result, Proxy B might open a new connection to another proxy
   server for requests sent in the opposite direction.

          +-----------+
          |           |
          |   Proxy   |
          |     A1    | 5061              9741 +-----------+
          |           |<.......................|           |
          +-----------+                        |   Proxy   |
          +-----------+ 8293              5061 |     B     |
          |           |----------------------->|           |
          |   Proxy   |                        +-----------+
          |     A2    |
          |           |
          +-----------+

   The rules for handling the Transport layer described in Section 18 of
   SIP [3] do not associate incoming connections with the listening port
   which corresponds to the same SIP entity.  If the Transport layer had
   some way to associate these connections, then request and responses
   originated from either node could reuse existing connections as shown
   below.

          +-----------+                        +-----------+
          |           |                        |           |
          |   Node A  | 8293              5061 |   Node B  |
          |           |<======================>|           |
          |           |                        |           |
          +-----------+                        +-----------+




Mahy                     Expires April 22, 2005                 [Page 6]

Internet-Draft            SIP Connection Reuse              October 2004


   Similarly, when when an "outbound-only" user agent opens a connection
   to only one proxy server in the same cluster, there is no way for
   this user agent to receive incoming requests if the this particular
   proxy goes down.  In many scenarios, the user agent would not notice
   the connection was unresponsive until it was time to refresh its SIP
   registration.  Some "outbound-only" user agents would like the
   ability to open persistent connections to more than one proxy server
   in a cluster, so that at least two proxy servers in the cluster can
   forward incoming requests to the user agent.  This requirements of
   these "outbound-only" user agents are discussed in [1].

2.4  Hop-by-hop reuse

   All the examples presented above apply to a single hop as opposed to
   a per-dialog route-set or other complete path.  This is natural since
   ordinary connections are managed on a hop-by-hop basis as well.
   Proxy server to proxy server connection reuse is likely to be much
   more efficient if multiple dialogs or multiple users can use the same
   connection.

3.  Requirements

   1.  A connection sharing mechanism SHOULD allow SIP entities to reuse
       existing connections for requests and responses originated from
       either peer in the connection.
   2.  A connection sharing mechanism SHOULD allow SIP entities to reuse
       existing connections with closely coupled nodes which act as a
       single SIP entity (for example a cluster of nodes acting as a
       proxy server).
   3.  A connection sharing mechanism MUST NOT require UACs (clients) to
       send all traffic from well-know SIP ports.
   4.  A connection sharing mechanism MUST NOT require configuring
       ephemeral port numbers in DNS.
   5.  A connection sharing mechanism MUST prevent unauthorized
       hijacking of other connections.
   6.  Connection sharing SHOULD persist across SIP transactions and
       dialogs.
   7.  There is no requirement to share a complete path for ordinary
       connection reuse.  Hop-by-hop connection sharing is more
       appropriate.

4.  Behavior

   The proposed mechanism uses a new Via header field parameter.  The
   "alias" parameter is included in a Via header field value to indicate
   that the originator of the request wants to create a transport layer
   alias.  The originator places their alias in the Via header field
   value (in the "sent-by" production).  This "alias" address becomes



Mahy                     Expires April 22, 2005                 [Page 7]

Internet-Draft            SIP Connection Reuse              October 2004


   mapped to the a actual IP address and port number observed as the
   source address of the current connection.

   Assuming the Via header field value shown below from the most recent
   request arrived over a connection from 10.54.32.1 port 8241:

    Via: SIP/2.0/TLS 10.54.32.1:5061;branch=z9hG4bKa7c8dze ;alias

   The transport layer creates an alias, such that any requests going to
   the "advertised address" (10.54.32.1 port 5061) are instead sent over
   the existing connection (to the "target" of the alias) which is
   coming from port 8241.  This sharing continues as long as the target
   connection stays up.
      The SIP community recommends that servers keep connections up
      unless they need to reclaim resources, and that clients keep
      connections up as long as they are needed.  Connection reuse works
      best when the client and the server maintain their connections for
      long periods of time.  SIP entities therefore SHOULD NOT drop
      connections on completion of a transaction or termination of a
      dialog.
      To implement connection aliases for explicit IP addresses and port
      numbers, a SIP node could (for example) search an additional data
      structure (the alias table) prior to opening a new connection, or
      could modify the data structure in which it keeps active
      connection state so that aliases, active connections, and
      blacklisted nodes are all discovered when looking for an active
      connection.

   Likewise when clusters or farms of cooperating SIP servers (for
   example proxy servers) are configured together, this mechanism allows
   a SIP entity to select a server with an existing connection.  With
   this mechanism, Proxy B sends requests for Proxy cluster A to node A2
   with whom it already shares an existing connection.

          +-----------+
          |           |
          |   Proxy   |
          |     A1    |                        +-----------+
          |           |                        |           |
          +-----------+                        |   Proxy   |
          +-----------+ 8293              5061 |     B     |
          |           |<======================>|           |
          |   Proxy   |                        +-----------+
          |     A2    |
          |           |
          +-----------+

   For example, on receipt of a message with the topmost Via header



Mahy                     Expires April 22, 2005                 [Page 8]

Internet-Draft            SIP Connection Reuse              October 2004


   shown below, the transport layer creates an alias such that requests
   going to the advertised address (proxy-farm-a.example.com) are sent
   over the target connection (from 10.54.32.1:8241).

     Via: SIP/2.0/TLS proxy-farm-a.example.com;branch=z9hG4bK7c8ze;alias

   As a result, this has an important interaction with the DNS
   resolution mechanisms for SIP described in RFC3263 [6].  When new
   requests arrive for proxy-farm-a.example.com, proxy B still needs to
   perform a DNS NAPTR lookup to select the transport.  Once the
   transport is selected, an SRV lookup would ordinarily occur to find
   the appropriate port number.  In this case, the transport layer uses
   a connection reuse alias instead of performing the SRV query.

   Below is a partial DNS zone file for atlanta.com.

   ; NAPTR queries for the current domain (example.com)
   ;
   ; order pref flags service regexp replacement
   proxy-farm-a IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.

   ; SRV records for the proxy use 5060/5061
   ;
   ;; Priority Weight Port Target
   _sips._tcp.proxy-farm-a  IN SRV 0 1 5061 host-a1
   _sips._tcp.proxy-farm-a  IN SRV 0 1 5061 host-a2

   host-a1  IN A 10.54.32.1
   host-a2  IN A 10.54.32.2

   The existence of an alias parameter in a Via header in a request is
   treated as a request to the transport layer to create an alias (named
   by the sent-by parameter) that points to the alias target (the
   current connection)

   This mechanism is fully backwards compatible with existing
   implementations.  If the proposed Via parameter is not understood by
   the recipient, it will be ignored and the two implementations will
   revert to current behavior (two connections).

4.1  Authorizing an alias request

   Authorizing connection aliases is essential to prevent connection
   hijacking.  For example a program run by a malicious user of a
   multiuser system could attempt to hijack SIP requests destined for
   the well-known SIP port from a large relay proxy.

   To correctly authorize an alias, the SIP node authorizing the request



Mahy                     Expires April 22, 2005                 [Page 9]

Internet-Draft            SIP Connection Reuse              October 2004


   needs to recognize both the active connection and the alias as the
   same resource.  The only way to accomplish this is if both the active
   connection and the alias can be authenticated using the same
   credentials.  In this specification, this is accomplished using TLS
   mutual authentication.

4.1.1  Authorizing using TLS mutual authentication

   The authorization mechanism for this mechanism requires TLS mutual
   authentication, such that the subjectAltName of the originator
   certificate corresponds to both the current connection and the target
   address of the alias.  The Via sent-by address needs to be within the
   scope protected by the certificate presented by the originator during
   TLS mutual authentication and the received IP address needs be a
   valid IP address for the sent-by host or hosts.  In other words, the
   sent-by address MUST be resolvable from the subjectAltName of the
   originator certificate, and the received IP address MUST be
   resolvable from the sent-by address.  This is in addition to other
   requirements for TLS authentication and authorization discussed in
   SIP [3] and Locating SIP Servers [6].

   Following this logic step-by-step:
   1.  Verify that the certificate presented is not expired and is
       rooted in a trusted certificate chain.
   2.  Verify that the subjectAltName in the certificate covers the
       "advertised address" (the address in the Via sent-by production).
       If the advertised address and the subjectAltName match exactly
       then the certificate covers the address.
   3.  Use DNS to resolve if the advertised name is resolvable from the
       subjectAltName (start by resolving the subjectAltName as if it
       where a target URI according to the rules in RFC3263.  That is,
       if no port number is present perform an SRV lookup, then finally
       resolve relevant address records).  If any of the resolved
       addresses (port numbers can be ignored in this case) matches the
       advertised address, then the certificate covers the address.
   4.  Finally, Verify that the advertised address can resolve to the IP
       address over which the connection was received.

   For example, take the example in the previous section of proxy B
   receiving an alias request from host-a2.example.com.  Proxy B
   verifies that the presented certificate is valid and trusted.  Proxy
   B checks that proxy-farm-a.example.com is both the advertised name
   and the subjectAltName in the certificate.  Finally, proxy B verifies
   that this connection is coming from 10.54.32.2, which is one of the
   addresses in DNS for host-a2.example.com, which in turn is mentioned
   in an SRV record for _sips._tcp.proxy-farm-a.example.com.





Mahy                     Expires April 22, 2005                [Page 10]

Internet-Draft            SIP Connection Reuse              October 2004


4.2  Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC-2234 [7].  This document proposes to
   extend via-params to include a new via-alias defined below.

      via-params = via-ttl / via-maddr / via-received / via-branch /
                   via-alias / via-extension

      via-alias  = "alias"


5.  Security Considerations

   This document presents requirements and a mechanism for reusing
   existing connections easily.  Unauthorized connection reuse would
   present many opportunities for rampant abuse and hijacking, but these
   attacks can be prevented if the guidelines in Section 4.1 are
   followed.

   The mechanism in this document can significantly improve the security
   of SIP networks, in that it makes SIP over TLS (and the sips: scheme)
   practical for devices which do not have a certificate rooted in a
   well-known certificate authority.

   SIP Proxy Servers which implement this mechanism MUST implement TLS
   mutual authentication, and MUST follow the authorization rules
   described in Section 4.1.1.

6.  IANA Considerations

   This document adds a parameter to the SIP header field parameters
   registry:

   Header field in which parameter can appear: Via
   Name of the parameter: alias
   Reference:  This document


7.  Acknowledgments

   Thanks to Jon Peterson for helpful answers about certificate behavior
   with SIP, Jonathan Rosenberg for his initial support of this concept,
   and Cullen Jennings for providing a sounding board for this idea.

8.  References





Mahy                     Expires April 22, 2005                [Page 11]

Internet-Draft            SIP Connection Reuse              October 2004


8.1  Normative References

   [1]  Jennings, C., Ed. and A. Hawrylyshen, Ed., "SIP Conventions for
        Connection Usage", draft-jennings-sipping-outbound-00 (work in
        progress), October 2004.

   [2]  Rosenberg, J., "Obtaining and Using Globally Routable User Agent
        (UA) URIs (GRUU) in the  Session Initiation Protocol (SIP)",
        draft-ietf-sip-gruu-02 (work in progress), July 2004.

   [3]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [5]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
        2246, January 1999.

   [6]  Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
        (SIP): Locating SIP Servers", RFC 3263, June 2002.

   [7]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

8.2  Informational References

   [8]   Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
         Method", RFC 3311, October 2002.

   [9]   Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo,
         "Best Current Practices for Third Party Call Control (3pcc) in
         the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
         2004.

   [10]  Rosenberg, J., "A Presence Event Package for the Session
         Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
         in progress), January 2003.

   [11]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
         Method", RFC 3515, April 2003.

   [12]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [13]  Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
         H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,



Mahy                     Expires April 22, 2005                [Page 12]

Internet-Draft            SIP Connection Reuse              October 2004


         "Stream Control Transmission Protocol", RFC 2960, October 2000.


Author's Address

   Rohan Mahy
   Airespace
   110 Nortech Parkway
   San Jose, CA  95134
   USA

   EMail: rohan@ekabal.com







































Mahy                     Expires April 22, 2005                [Page 13]

Internet-Draft            SIP Connection Reuse              October 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Mahy                     Expires April 22, 2005                [Page 14]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/