Internet DRAFT - draft-wing-session-auth

draft-wing-session-auth






Network Working Group                                            D. Wing
Internet-Draft                                             Cisco Systems
Expires:  August 4, 2006                                January 31, 2006


                      Media Session Authorization
                       draft-wing-session-auth-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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/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 August 4, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   In many VoIP networks today, firewalls and session border controllers
   are used at the edge of an administrative domain to allow authorized
   UDP media flows to enter or leave the network.  This document
   introduces a new mechanism to authorize a UDP media flow.  This
   mechanism works with encrypted hop-by-hop signaling, end-to-end
   authenticated signaling, and multihomed networks.  The media
   authorization is performed using an Interactive Connectivity
   Establishment-capable endpoint and a calling signaling device that
   authorizes a firewall to permit a flow.



Wing                     Expires August 4, 2006                 [Page 1]

Internet-Draft         Media Session Authorization          January 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Push versus Pull Model . . . . . . . . . . . . . . . . . .  6
   2.  Session Authorization Mechanism  . . . . . . . . . . . . . . .  6
   3.  Session Deauthorization Mechanism  . . . . . . . . . . . . . . 10
   4.  Control Protocol Requirements  . . . . . . . . . . . . . . . . 10
   5.  Minimal Implementation . . . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informational References . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15



































Wing                     Expires August 4, 2006                 [Page 2]

Internet-Draft         Media Session Authorization          January 2006


1.  Introduction

   Interactive Connectivity Establishment (ICE, [1]) describes a
   mechanism for traversing NATs.  ICE has both peers exchange tokens
   (STUN Usernames) in order to prevent inadvertent session
   establishment with a device sharing the same IP address and UDP port
   as the intended session peer.

   The mechanism introduced in this document utilizes this normal ICE
   behavior in order to allow a call processing device (such as a SIP
   proxy) and a firewall to authorize each UDP media session.
   Essentially, the call processing device watches the tokens that are
   exchanged in call signaling, and the same tokens are exchanged in the
   media path then the media session is authorized.  The mechanism does
   not rely on ICE's NAT traversal technique but takes advantage of the
   token (STUN Username) exchanged in signaling.

   The media session authorization described in this document also works
   on a multihomed network with asymmetric routing through different
   firewalls.  In the following figure the top-most path (through
   firewall-1) is used for traffic from phone-b to phone-a, and the
   bottom-most path (through firewall-2) is used for traffic from
   phone-a to phone-b.

                       +---[firewall-1]<--------+
                       |                        |
                       V                        |
        [phone-a]--[router]                  [router]--[phone-b]
                       |                        ^
                       |                        |
                       +--->[firewall-2]--------+


   Figure 1: Asymmetric Routing

   Although SIP is described in this document, any protocol utilizing an
   offer/answer model ([4] or similar) could utilize the technique
   described in this document.  An example of another such protocol is
   Jingle [9].












Wing                     Expires August 4, 2006                 [Page 3]

Internet-Draft         Media Session Authorization          January 2006


   Multiple disparate applications can authorize a UDP media session,
   with each application communicating with a common policy server.

                     +---------+       +--------------------+
                     |SIP Proxy|       |XMPP (Jabber) Server|
                     +-----+---+       +-----+--------------+
                            \               /
                             \             /
                            +-+-----------+-+
                            | Policy Server |
                            +-+----+------+-+
                             /     |       \
                            /      |        \
                        +--+-+  +--+-+      ++----+
                        |FW-1|  |FW-2|  ... |FW-nn|
                        +----+  +--+-+      +-----+


   Figure 2: Multiple applications authorizing media sessions

1.1.  Motivation

   Two techniques commonly provide ingress/egress security today --
   firewall application layer gateways (ALG) and Session Border
   Controllers (SBC) [5].  In order to perform its security function,
   the ALG must be able to examine the SIP signaling, whereas an SBC is
   actively involved with modifying the SIP signaling (specifically the
   SDP, and often SIP headers as well).  However the use of hop-by-hop
   signaling encryption (such as with TLS) breaks firewall ALGs, and the
   use of end-to-end signaling encryption (such as S/MIME) or end-to-end
   integrity protection (such as SIP Identity [3]) breaks SBCs.
   Additionally both a firewall and an SBC constrain the media path,
   causing packets to not take the best path.  A firewall requires the
   signaling and media flow through the firewall (which is achieved
   through network design) and an SBC causes media to flow through the
   SBC (by modifying SDP in SIP signaling).

   Two other techniques are less common.  An on-path technique to
   provide ingress/egress security is NSIS NSLP [6].  MIDCOM [7] is an
   off-path firewall and NAT control protocol which requires topology
   awareness.

   Media session authorization can be implemented by one network without
   needing to be implemented by a remote network.  The remote network
   need only implement ICE -- no extensions to ICE are necessary.  This
   makes deployment of this mechanism easy.





Wing                     Expires August 4, 2006                 [Page 4]

Internet-Draft         Media Session Authorization          January 2006


   The tradeoffs of media session authorization are summarized in the
   following table.

                             | FW   |      | NSIS |        |   Media
            Works With       | ALG  | SBC  | NSLP | MIDCOM | Sess Auth
      -----------------------+------+------+------+--------+----------
      TLS signaling          | No   | Yes  | Yes  |  Yes   |   Yes
      S/MIME signaling       | No   | No   | No   |  No    |   No/6
      existing NATs          | No/1 | Yes  | No/1 |  No/1  |   Yes
      existing firewalls     | No/1 | Yes  | No/1 |  No/1  |   No/1
      SIP Identity           | Yes  | No/2 | Yes  |  Yes   |   Yes
      multihomed networks    | No   | No/3 | Yes  |  Yes/8 |   Yes
      existing endpoints     | Yes  | Yes  | No/4 |  Yes   |   No/5
      UDP media              | Yes  | Yes  | Yes  |  Yes   |   Yes
      TCP media              | Yes  | Yes  | Yes  |  Yes   |   No/7
      Topology unaware       | Yes  | Yes  | Yes  |  No    |   Yes
      best-path routing      | No   | No   | Yes  |  Yes   |   Yes


   Figure 3: Comparison of Techniques

      Notes:

      1.  To be Yes, the Firewall (or NAT) would need to be upgraded to
          support each traversal type (SIP ALG, MIDCOM, NSIS NSLP).
          NATs do not provide policy control and work without
          modification with both media session authorization and with
          SBCs.  SBCs work with existing firewalls by configuring the
          firewall with a pinhole for the SBC's media address(es) and
          using the SBC to provide policy control normally attributed to
          the firewall.
      2.  To be Yes, the SBC would need to rewrites the From:  and
          creates a new sip-identity signature; this is only possible
          with E.164 numbers or if the SBC is in the same administrative
          domain as the From:  domain.
      3.  While it is possible for SBCs to form their own multihomed
          overlay network, it isn't the same as IP multihoming.
      4.  Local endpoint must implement NSIS NSLP.  If remote endpoint
          doesn't support NSIS NSLP, NSLP's RESERVE-EXTERNAL-ADDRESS
          mode is required.
      5.  To be Yes, both local and remote endpoints must support ICE.
      6.  S/MIME prevents the local SIP proxies from viewing the
          endpoint's tokens.  To be Yes, the firewall or policy server
          must be told the endpoint's tokens.
      7.  Authorizing TCP-based media sessions is under study.
      8.  Multihomed networks can be supported with sufficient awareness
          of network topology and routing.




Wing                     Expires August 4, 2006                 [Page 5]

Internet-Draft         Media Session Authorization          January 2006


1.2.  Push versus Pull Model

   When separate devices are used for firewalling (policy enforcement)
   and policy decisions, a 'push' or 'pull' model can be used to
   communicate between the devices.  In the push model, the policy
   decision device informs the firewall of an authorized flow.  In the
   pull model, the firewall asks the policy decision device if a flow is
   authorized.

   The strength of the policy push model is it avoids session
   authorization delays.  The weakness is that it requires topology
   awareness (need to know which firewalls to inform) or requires
   informing all firewalls about every authorized flow.

   The strength of the policy pull model is it allows multihomed
   networks and doesn't require topology awareness.  The weakness is
   that strict policy enforcement, where authorized flows are permitted
   and unauthorized flows are denied, incurs some authorization delay.

   This document describes a pull model.


2.  Session Authorization Mechanism

   The figure below shows a simplified ICE message flow which highlights
   the characteristics of standard ICE that are useful to build the flow
   authorization described by this document.  As it relates to media
   session authorization, the key aspect of ICE are the unique, per-call
   identifiers (transport address id) generated by the calling party and
   the unique, per-call identifier generated by the called party.  These
   tokens are exchanged in call signaling, and are then exchanged again
   in the media path in STUN Request messages.

   In the figure below, Alice and Bob perform normal ICE procedures.
   Alice generates an offer [4] containing her unique, per-call token
   ("A:a" in the figure).  This token is the 'candidate id' and
   'component id' described in ICE.  This token is sent to the other
   party, Bob. Upon receipt of this offer, Bob generates his own token
   ('candidate id' and 'component id').  These are concatinated with
   Alice's token, resulting in "A:a:B:b".  Bob sends a STUN Request
   message directly to Alice's IP address.  Bob also sends an answer, in
   call signaling, containing his token ('candidate id' and 'component
   id').

   Alice receives the STUN Request.  By parsing the message she
   determines it contains her token.  She response with a STUN Response
   message.  When Alice receives Bob's answer, she builds her own STUN
   Request by concatenating her token to Bob's token (resulting in



Wing                     Expires August 4, 2006                 [Page 6]

Internet-Draft         Media Session Authorization          January 2006


   "B:b:A:a") and sends a STUN Request message to Bob. Bob replies with
   a STUN Response.  In this way, Alice and Bob have verified they have
   connectivity over that specific path.

   In the figure below, SIP messages are represented with a dash ("-")
   and ICE messages (STUN Request, STUN Response) are represented with
   an equal sign ("="):

                            SIP Proxy or
           Alice            XMPP Server             Bob
             |                   |                   |
             |offer, token=A:a   |                   |
             |------------------>|                   |
             |                   |offer, token=A:a   |
             |                   |------------------>|
             |STUN Request, token=A:a:B:b            |
             |<======================================|
             |STUN Response      |                   |
             |======================================>|
             |                   |answer, token=B:b  |
             |                   |<------------------|
             |answer, token=B:b  |                   |
             |<------------------|                   |
             |STUN Request, token=B:b:A:a            |
             |======================================>|
             |STUN Response      |                   |
             |<======================================|


   Figure 4: ICE Call Flow, with Tokens Highlighted

   By inserting a firewall on Alice's network, and providing
   communication between Alice's SIP proxy and the firewall, the
   firewall can allow media traffic that has been correctly signaled via
   SIP.  The figure below shows the communications that occur between
   the firewall, the SIP proxy, and the policy server.  The firewall is
   configured to deny new incoming UDP sessions or outgoing UDP sessions
   unless those sessions start with a STUN Request packet.  When a new
   session contains a STUN Request packet, the STUN Request packet is
   forwarded to the policy element for authorization.











Wing                     Expires August 4, 2006                 [Page 7]

Internet-Draft         Media Session Authorization          January 2006


   The following figure shows the network diagram used for Figure 6.

                       +---------+
           +-----------+SIP Proxy+-----------------+
           |           +---+-----+                 |
           |               |                       |
      (SIP)|         +-----+-------+               |(SIP)
           |         |Policy Server|               |
           |         +-----+-------+               |
           |               |                       |
        +-----+        +---+----+                +-+-+
        |Alice|========|firewall|================|Bob|
        +-----+  (ICE) +--------+     (ICE)      +---+



   Figure 5: Network Diagram

   The call flow shown in Figure 6, below, is similar to the call flow
   shown above ( Figure 4) except the addition of Alice's Policy Device
   and Alice's firewall.  As can be seen in the figure below, the STUN
   Request message is authorized by Alice's firewall.  Specifically,
   when a STUN Request message arrives at the firewall the message is
   passed to the policy decision device which determines if the flow
   should be authorized.  The policy decision device authorizes a flow
   if the ICE token (STUN Username), IP address, and UDP port match a
   call that was previously signaled by Alice's SIP proxy or by some
   other network element that can authorize a new media flow.

   Both STUN Request and STUN Reply messages arriving from 'outside' the
   network or from 'inside' the network can receive this same
   authorization, which means that the only UDP packets permitted to
   cross the firewall will be STUN Request or STUN Response packets that
   are explicitly authorized by the policy decision device.  The policy
   decision device, as part of allowing the STUN Request or STUN
   Response packet to transit the firewall, would also inform the
   firewall that a pinhole should be opened to allow the subsequent flow
   of media packets over that same 5-tuple (IP source, IP destination,
   protocol=UDP, port source, port destination).












Wing                     Expires August 4, 2006                 [Page 8]

Internet-Draft         Media Session Authorization          January 2006


   In this figure, dash ("-") indicates SIP messages, equal ("=")
   represents STUN messages.  The dot (".") indicates communications
   between SIP proxy, policy decision device, and firewall.  In this
   diagram, the first four devices all belong to Alice's network (Alice,
   Proxy, Policy Decision Device, and firewall).

                Alice's   Alice's Policy    Alice's
   Alice       SIP Proxy      Device       Firewall         Bob
     |             |             |             |             |
     |(1) offer, token=A:a       |             |             |
     |------------>|             |             |             |
     |             |(2) new session, token=A:a |             |
     |             |............>|             |             |
     |             |(3) OK       |             |             |
     |             |<............|             |             |
     |             |(4) offer, token=A:a       |             |
     |             |---------------------------------------->|
     |             |             |             |(5) STUN Request,
     |             |             |             |    token=A:a:B:b
     |             |             |             X<============|
     |             |             |(6) token A:a:B:b ok?      |
     |             |             |<............|             |
     |             |             |(7) Yes      |             |
     |             |             |............>|             |
     |(8) STUN Request, token=A:a:B:b          |             |
     |<========================================|             |
     |(9) STUN Response          |             |             |
     |======================================================>|
     |             |(10) answer, token=B:b     |             |
     |             |<----------------------------------------|
     |             |(11) new session, token=B:b|             |
     |             |............>|             |             |
     |             |(12) OK      |             |             |
     |             |<............|             |             |
     |(13) answer, token=B:b     |             |             |
     |<------------|             |             |             |
     |(14) STUN Request, token=B:b:A:a         |             |
     |========================================>X             |
     |             |             |(15) token B:b:A:a ok?     |
     |             |             |<............|             |
     |             |             |(16) Yes     |             |
     |             |             |............>|             |
     |             |             |             |(17) STUN Request,
     |             |             |             |     token=B:b:A:a
     |             |             |             |============>|
     |(18) STUN Response         |             |             |
     |<======================================================|




Wing                     Expires August 4, 2006                 [Page 9]

Internet-Draft         Media Session Authorization          January 2006


   Figure 6: Media Session Authorization Flow, Single-Homed Network


3.  Session Deauthorization Mechanism

   Typically a SIP session is terminated when the SIP proxy receives
   notification that the session has ended (SIP BYE messages) or the SIP
   proxy times out the SIP session [2].  When the session has ended the
   SIP proxy informs the policy decision device.  Because the firewalls
   asked for authorization to permit those flows earlier, the policy
   decision device knows which firewall(s) the media passed through.
   The policy decision device tells those firewalls that the media flow
   is no longer authorized.  The firewalls would then revert to their
   default behavior for that flow, which is usually to block the flow.

   There are cases, however, where the policy decision device or the SIP
   proxy lose state (for example device failure or network partitioning)
   but the media is still flowing.  To handle this situation, the
   firewall periodically requests re-authorization for each active flow
   and the SIP proxy periodically informs the policy decision device of
   ongoing flows.  In this way, even after loss of state in the SIP
   proxy or loss of state in the policy server, the policy server can
   determine a media session is still active unbeknownst to the SIP
   proxy and inform the firewall that the flow is no longer authorized.

   As ICE already requires periodic transmission of keepalive packets to
   keep NAT bindings open, the firewall can expect to always see either
   media packets or periodic keepalive packets.  If the firewall doesn't
   see any packets for 90 seconds (3 times the duration of the ICE-
   recommended keepalive interval), the firewall can decide the flow has
   ceased and inform the policy decision device.  The policy decision
   device may then inform the firewall and the SIP proxy that the flow
   has ceased.  In this way, an endpoint that has been partitioned from
   the network or crashed can be noticed even before SIP session timers
   might have noticed the endpoint has gone away.


4.  Control Protocol Requirements

   There are two control protocols required to realize Media Session
   Authorization -- one between the firewalls and the policy decision
   device, and another between the policy decision device and the SIP
   proxies.  To allow arbitrary combinations of the SIP proxy, policy
   decision device, and firewall, it would be helpful to select the same
   protocol for the proxy/policy and policy/firewall communication.

   Requirements of the protocol between the firewall and the policy
   decision device include:



Wing                     Expires August 4, 2006                [Page 10]

Internet-Draft         Media Session Authorization          January 2006


   1.  The firewall must send a message to the policy decision device
       when a STUN Request or STUN Response packet is seen.
   2.  In order to avoid maintaining state in the firewall the entire
       STUN Request or STUN Response packet should be sent to the policy
       decision device.
   3.  The firewall must be able to inform the policy decision device
       that a flow has ceased.
   4.  The policy decision device must be able to tell the firewall that
       a flow is authorized.
   5.  The policy decision device must be able to tell the firewall that
       a flow is no longer authorized.
   6.  If firewalls protecting a multihomed network are supported on
       this network, the policy decision device must also be able to
       inform all firewalls of a valid STUN transaction-id.  A secure
       reliable multicast protocol, such as [8], might be useful for
       this communication.

   Requirements of the protocol between the policy decision device and
   SIP proxy include:

   1.  The SIP proxy must be able to asynchronously inform the policy
       decision device of an impending authorized flow.
   2.  The SIP proxy must be able to asynchronously inform the policy
       decision device that a previously-authorized flow is still
       ongoing and still authorized
   3.  The policy decision device must be able to inform the SIP proxy
       that a flow has ceased.

   Applicability of protocols will be discussed in subsequent versions
   of this document.


5.  Minimal Implementation

   In order to allow a firewall and SIP proxy to provide media session
   authorization, both endpoints need only implement a subset of ICE.
   Specifically, the endpoint need only include a single "a=candidate"
   line which specifies the same IP address and UDP port as the media
   ("m=") line.  This single a=candidate line contains the token
   (transport-id) which is necessary to provide the media session
   authorization.  Thus, endpoints which have no interest in ICE's NAT
   traversal capabilities or media relay (TURN) capabilities can still
   benefit from media session authorization.


6.  Security Considerations

   An attacker might flood a firewall device with bogus STUN Request or



Wing                     Expires August 4, 2006                [Page 11]

Internet-Draft         Media Session Authorization          January 2006


   bogus STUN Response packets.  STUN Request packets are authorized by
   forwarding the packet to a policy server, which authorizes the
   pinhole by examining the destination IP address, port, and STUN
   Username.  STUN Response packets are authorized if its associated
   STUN Request packet (with the same STUN transaction-id and same IP
   address and port) was authorized.  An attacker could overwhelm the
   authorization mechanism in a multihomed or single-homed network by
   sending bogus STUN Request packets or in a multi-homed network by
   sending bogus STUN Response packets.

   In order to protect against such an attack of STUN Request packets,
   the STUN Username in the STUN Request should be coordinated with the
   firewall in such a way the firewall can ascertain the Username is
   legitimate.  This requires coordinating the STUN Username with the
   endpoint that originates the STUN messages.  Mechanisms to accomplish
   this coordination are for further study.

   A legitimate STUN Response shares the same transaction-id and inverse
   5-tuple as a previously-authorized STUN Request.  On a single-homed
   network, the STUN Request packet traverses the same firewall as the
   STUN Response packet, making the firewall's authorization of the STUN
   Response easy.  However, on a multi-homed network the firewall will
   not have seen the STUN Request packet and thus some other mechanism
   to accomplish this coordination amongst firewalls in a multi-homed
   network is required and is for further study.


7.  IANA Considerations

   This document does not add new IANA registrations.


8.  References

8.1.  Normative References

   [1]  Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
        Methodology for Network  Address Translator (NAT) Traversal for
        Offer/Answer Protocols", draft-ietf-mmusic-ice-06 (work in
        progress), October 2005.

   [2]  Donovan, S. and J. Rosenberg, "Session Timers in the Session
        Initiation Protocol (SIP)", RFC 4028, April 2005.

   [3]  Peterson, J. and C. Jennings, "Enhancements for Authenticated
        Identity Management in the Session Initiation  Protocol (SIP)",
        draft-ietf-sip-identity-06 (work in progress), October 2005.




Wing                     Expires August 4, 2006                [Page 12]

Internet-Draft         Media Session Authorization          January 2006


   [4]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
        Session Description Protocol (SDP)", RFC 3264, June 2002.

8.2.  Informational References

   [5]  Camarillo, G., "SIP (Session Initiation Protocol)-Unfriendly
        Functions in Current  Communication Architectures",
        draft-camarillo-sipping-sbc-funcs-02 (work in progress),
        October 2005.

   [6]  Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
        (NSLP)", draft-ietf-nsis-nslp-natfw-08 (work in progress),
        October 2005.

   [7]  Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A.
        Rayhan, "Middlebox communication architecture and framework",
        RFC 3303, August 2002.

   [8]  Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
        Domain of Interpretation", RFC 3547, July 2003.

   [9]  Ludwig, S., Saint-Andre, P., Beda, J., and J. Hildebrand, "JEP-
        0166: Jingle Signalling", December 2005.

        http://www.jabber.org/jeps/jep-0166.html


























Wing                     Expires August 4, 2006                [Page 13]

Internet-Draft         Media Session Authorization          January 2006


Author's Address

   Dan Wing
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email:  dwing@cisco.com










































Wing                     Expires August 4, 2006                [Page 14]

Internet-Draft         Media Session Authorization          January 2006


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 (2006).  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.




Wing                     Expires August 4, 2006                [Page 15]