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

Versions: 00 01 02 03 04 05

SPEERMINT Working Group                                     S. Niccolini
Internet-Draft                                                       NEC
Intended status: Informational                                   E. Chen
Expires: September 2, 2007                                           NTT
                                                           March 1, 2007


              VoIP Security Threats relevant to SPEERMINT
                draft-niccolini-speermint-voipthreats-01

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 September 2, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).













Niccolini & Chen        Expires September 2, 2007               [Page 1]


Internet-Draft                VoIP Threats                    March 2007


Abstract

   This memo presents the different security threats related to
   SPEERMINT classifying them into threats to the Location Function, to
   the Signaling Function and to the Media Function.  The different
   instances of the threats are briefly introduced inside the
   classification.  Finally the existing security solutions in SIP and
   RTP/RTCP are presented to describe the countermeasures currently
   available for such threats.  The objective of this document is to
   identify and enumerate the SPEERMINT-specific threat vectors in order
   to specify security-related requirements.  Once the requirements are
   identified, methods and solutions how to achieve such requirements
   can be selected.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Security Threats relevant to SPEERMINT . . . . . . . . . . . .  4
     2.1.  Threats to the Location Function (LF)  . . . . . . . . . .  4
     2.2.  Threats to the Signaling Function (SF) . . . . . . . . . .  5
       2.2.1.  Denial of Service Attacks to SF  . . . . . . . . . . .  6
       2.2.2.  Fraud  . . . . . . . . . . . . . . . . . . . . . . . .  7
       2.2.3.  Federation Policy Violation  . . . . . . . . . . . . .  7
       2.2.4.  Negotiation Modification/Interruption in Signaling . .  8
     2.3.  Threats to the Media Function (MF) . . . . . . . . . . . .  8
       2.3.1.  Denial of Service Attacks to MF  . . . . . . . . . . .  9
       2.3.2.  Privacy Infringement . . . . . . . . . . . . . . . . .  9
     2.4.  Social Threats . . . . . . . . . . . . . . . . . . . . . . 10

   3.  Overview of SPEERMINT security requirements  . . . . . . . . . 11

   4.  Overview of Security Solutions . . . . . . . . . . . . . . . . 12

   5.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 14

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15

   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16

   8.  Informative References . . . . . . . . . . . . . . . . . . . . 17

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19






Niccolini & Chen        Expires September 2, 2007               [Page 2]


Internet-Draft                VoIP Threats                    March 2007


1.  Introduction

   With VoIP, the need for security is compounded because there is the
   need to protect both the control plane and the data plane.  In a
   legacy telephone system, security is a more valid assumption.
   Intercepting conversations requires either physical access to
   telephone lines or to compromise the Public Switched Telephone
   Network (PSTN) nodes or the office Private Branch eXchanges (PBXs).
   Only particularly security-sensitive organizations bother to encrypt
   voice traffic over traditional telephone lines.  In contrast, the
   risk of sending unencrypted data across the Internet is more
   significant (e.g.  DTMF tones corresponding to the credit card
   number).  An additional security threat to Internet Telephony comes
   from the fact that the signaling is sent using the same network as
   the multimedia data; traditional telephone systems have the signaling
   network separated from the data network.  This is an increased
   security threat since a hacker could attack the signaling network and
   its servers with increased damage potential (call hijacking, call
   drop, DoS attacks, etc.).  Therefore there is the need of
   investigating the different security threats, to extract security-
   related requirements and to highlight the solutions how to protect
   from such threats.





























Niccolini & Chen        Expires September 2, 2007               [Page 3]


Internet-Draft                VoIP Threats                    March 2007


2.  Security Threats relevant to SPEERMINT

   This section enumerates potential security threats relevant to
   SPEERMINT.  A taxonomy of VoIP security threats is defined in [1].
   Such a taxonomy is really comprehensive and takes into account also
   non-VoIP-specific threats (e.g. loss of power, etc.).  Threats
   relevant to the boundaries of layer-5 SIP networks are extracted from
   such a taxonomy and mapped to the classification relevant for the
   SPEERMINT architecture as defined in [2], moreover additional threats
   for the SPEERMINT architecture are listed and detailed under the same
   classification:

   o  Location Function (LF);

   o  Signaling Function (SF);

   o  Media Function (MF).

   An additional category is also included for completeness to address
   social threats relevant to SPEERMINT even if they are currently out
   of the scope of the SPEERMINT charter.

2.1.  Threats to the Location Function (LF)

   There are a number of potential security threats to the development
   of call routing data (CRD) by discovering the Signaling Function (SF)
   and end user's reachable host.

   o  routing directories modification - the attacker modifies routing
      directories (e.g.  DNS, ENUM tree, etc.) in an unauthorized way in
      order to modify the call routing.  The scope could be to reroute
      the call inserting unauthorized nodes in the path, to exclude
      authorized nodes from the path, to route the call towards a wrong
      destination causing a Denial of Service (DoS), to route the call
      towards a wrong destination causing annoyance for the callee;

   o  call routing modification by Man in the Middle (MitM) - the
      attacker has already or inserts an unauthorized node in the
      signaling path in order to modify the call routing.  The scope
      could be to reroute the call inserting other unauthorized nodes in
      the path, to exclude authorized nodes from the path, to route the
      call towards a wrong destination causing a Denial of Service
      (DoS), to route the call towards a wrong destination causing
      annoyance for the callee;

   o  DNS and ENUM hijacking - the attacker uses a technique called
      cache poisoning that exploits a flaw in the DNS software and
      tricks the server into receiving incorrect information.  The



Niccolini & Chen        Expires September 2, 2007               [Page 4]


Internet-Draft                VoIP Threats                    March 2007


      compromised server would cache and serve the incorrect information
      locally.  This technique can be used to replace arbitrary NAPTR
      records for a set of ENUM queries with NAPTR records of an
      attacker's choosing.  This allows the attacker to redirect all
      calls to a malicious destination.

   o  proxy impersonation - the attacker tricks a SIP UA or proxy into
      communicating with a rogue proxy.  VoIP calls established among
      different peering providers may introduce a number of new
      opportunities for such attack as intermediate proxies are
      discovered dynamically during call routing.  A successful proxy
      impersonation allows full access and control to all routed SIP
      messages.

   o  Denial of Service Attacks to LF - A DoS attack to the location
      function is possible by sending a large number of queries to the
      associated ENUM gateways or DNS servers.  This prevents a User
      Agent to look up the NAPTR record of the intended recipient of the
      call.

   o  identity theft - the attacker uses the identity of the owner
      without the consent for the scope of masking his real identity
      when committing fraud (e.g. when calling the attacker can charge
      the bill of the identity owner, the attacker can use the identity
      to bypass call blocking, etc.);

   o  numbers/identities harvesting - the attacker harvests numbers
      and/or user identities by issuing a multitude of location requests
      with the purpose of discovering the existent ones and their
      identifiers/addresses for calling them, for using them as spoofed
      identities or just for retrieving their location in the physical
      topology;

   o  signaling entities harvesting - the attacker harvests signaling
      entities (SIP Proxy Servers, etc.) addresses by issuing a specific
      number of requests with the purpose of discovering their location
      in the physical topology or for targeting them with subsequent
      attacks.

2.2.  Threats to the Signaling Function (SF)

   Signaling function involves a great number of sensitive information.
   Through signaling function, user agents (UA) assert identities and
   VSP operators authorize billable resources.  Correct and trusted
   operations of signaling function is essential for service providers.
   This section discusses potential security threats to the signaling
   function to detail the possible attack vectors.




Niccolini & Chen        Expires September 2, 2007               [Page 5]


Internet-Draft                VoIP Threats                    March 2007


2.2.1.  Denial of Service Attacks to SF

   There are a number of ways to conduct a Denial of Service attack to
   the signaling function.

   o  SIP malformed requests and messages - the attacker tries to cause
      a crash or a reboot of the proxy/endpoint by sending SIP malformed
      requests and messages;

   o  SIP requests and messages flooding - the attacker tries to exhaust
      the resources of the proxy/endpoint by sending many SIP requests
      and messages;

   o  session black holing - the attacker intentionally drops essential
      packets (e.g.  INVITE) of the VoIP protocol resulting the call
      initiation to fail, it is needed that the attacker controls (or
      is) a node in the middle of the signaling path;

   o  session tear down - the attacker uses CANCEL/BYE messages in order
      to tear down an existing call at SIP layer, it is needed that the
      attacker replicates the proper SIP header for the hijacking to be
      successful (To, From, Call-ID, CSeq);

   o  session hijacking - the attacker uses SIP messages (e.g. 301 Moved
      Temporarily) in order to hijack an existing call towards non-
      existing proxy/endpoint to make the session initiation fail, it is
      needed that the attacker replicates the proper SIP header for the
      hijacking to be successful (To, From, Call-ID, CSeq);

   o  SIP message spoofing - There are a number of ways to perform a DoS
      attack by spoofing SIP messages.  An attacker may directly send
      initial INVITE messages to a User Agent that has no capability to
      authenticate them.  Such messages may cause the UA to ring non-
      stop and effectively make it unusable.  Moreover, if the INVITE
      appears to come from a SIP server, the UA may keep responding to
      the server with multiple messages.  This may cause a DrDoS
      (Distributed Reflection DoS) attack to the SIP server if enough
      UAs are compromised.

   In principle such attacks does not need interception of any packet in
   order to be performed (could be done by simple guessing) but some of
   these attacks (e.g. session hijacking, session tear down, etc.)
   benefit from the retrieval of call-specific information as coming
   from interception of SIP packets.







Niccolini & Chen        Expires September 2, 2007               [Page 6]


Internet-Draft                VoIP Threats                    March 2007


2.2.2.  Fraud

   There are a number of ways to commit a fraud by exploiting
   vulnerabilities in the signaling function:

   o  accounting fraud by media oversize - the attacker injects in the
      network more traffic than declared in the session request in order
      to avoid paying for the used resources;

   o  session replay - the attacker replays a past session of another
      user in order to have access to the same resources (e.g. a bank
      account, etc.).  This attack can results in using resources
      without paying for them, having access to sensitive information,
      loss of money, etc.;

   o  call hijacking - the attacker uses SIP messages (e.g. 301 Moved
      Temporarily) in order to hijack an existing call towards other
      proxy/endpoint, it is needed that the attacker replicates the
      proper SIP header for the hijacking to be successful (To, From,
      Call-ID, CSeq);

   o  call pattern tracking - the attacker tracks the call patterns of
      the users violating his/her privacy;

   o  caller ID spoofing - the attacker spoofs the caller identifier in
      order to make calls avoiding paying for them.

   o  bypassing SF - the attacker sends the session initiation directly
      to the endpoint (Ua, media gateway, etc.) bypassing signaling
      entities in order to avoid paying for the used resources.

2.2.3.  Federation Policy Violation

   VoIP carriers that allow session peering through a federation are
   expected to establish some form of explicit policies to be adhered by
   all members.  These policies may normally include terms such as
   capacity controls and identity assertion.  Members with lower
   security level may bring new threats to the federation and thus
   affect all participating carriers.

   o  weak caller ID assertion by peers - a carrier member fails to
      achieve the level of identity assertion expected by the federation
      may introduce an entry point for attackers to conduct CID (caller
      ID) spoofing fraud.  This would affect all members in the
      federation, despite their efforts to strengthen the assertion
      within their own domains.





Niccolini & Chen        Expires September 2, 2007               [Page 7]


Internet-Draft                VoIP Threats                    March 2007


   o  overwhelming traffic from peers - a carrier member with a large
      number of UAs infected by bots or worms may unintentionally
      transmit traffic floods to other peers in the federation and
      violate the capacity control policy of the federation.

   o  illegitimate transit peers - multimedia traffic may be unknowingly
      delivered through an illegitimate transit peer.  This introduces
      opportunities for a variety of attacks by rough peers.

2.2.4.  Negotiation Modification/Interruption in Signaling

   The signaling function is used to perform, among the others, session
   and protocol capabilities negotiation as well as key exchange among
   parties involved in a call session.  There are a variety of ways that
   an attacker can compromise such negotiations.

   o  codec negotiation interruption/modification - signaling function
      is used to perform handshake regarding the codec(s) to be used
      during multimedia session.  An attacker may intentionally drop or
      modify only packets involved in the handshake.  This attack could
      interrupt the multimedia communication or degrade the quality
      achievable in the case o lower quality codec is used.

   o  SIP protocol specification interruption/modification - signaling
      function may use specific details of the signaling protocol.
      Extensions and the signaling associated may vary.  An attacker may
      intentionally drop or modify only packets meant to give evidence
      or declare such extensions tricking the peering party into wrong
      assumptions.  This attack could make the peering party wrongly
      allocating protocol mediation function resulting in failure to
      establish communications or parts of them.  Moreover the peering
      party would unnecessarily use resources in allocating such
      protocol mediation function resulting in a DoS attack.

   o  bid-down attack to SF - a number of encryption key exchange
      protocols performs handshake through the Signaling Function.  An
      attacker may intentionally drop or modify only packets involved in
      the handshake.  While this attack does not interrupt the voice
      communication, calling parties are prevented from establishing an
      SRTP session to secure privacy.

2.3.  Threats to the Media Function (MF)

   Media function is responsible for the actual delivery of multimedia
   communication between the users and carries sensitive information.
   Through media function, user agents (UA) can establish secure
   communications and monitor quality of conversations.  Correct and
   trusted operations of media function is essential for privacy and



Niccolini & Chen        Expires September 2, 2007               [Page 8]


Internet-Draft                VoIP Threats                    March 2007


   service assurance issues.  This section discusses potential security
   threats to the media function to detail the possible attack vectors.

2.3.1.  Denial of Service Attacks to MF

   There are a number of ways to conduct a Denial of Service attack to
   the media function.

   o  RTP/RTCP malformed messages - the attacker tries to cause a crash
      or a reboot of the proxy/endpoint by sending RTP/RTCP malformed
      messages;

   o  RTP/RTCP messages flooding - the attacker tries to exhaust the
      resources of the proxy/endpoint by sending many RTP/RTCP messages;

   o  RTP/RTCP session tear down - the attacker uses RTCP messages (e.g.
      BYE) in order to tear down an existing call at RTP layer, the SIP
      layer will not notice that the RTP flow has been torn down and the
      call will not result as released;

   o  RTP/RTCP QoS degradation - the attacker sends wrong RTCP reports
      advertising more packet loss or more jitter than actually
      experimented resulting in the usage of a poor quality codec
      degrading the overall quality of the call experience.

   In principle such attacks does not need interception of any packet in
   order to be performed (could be done by simple guessing) but some of
   these attacks (e.g. call hijacking, RTP/RTCP session tear down, etc.)
   benefit from the retrieval of call-specific information as coming
   from interception of SIP/RTP/RTCP packets.

2.3.2.  Privacy Infringement

   The media function is responsible for enabling private conversation
   between parties involved in a call session.  There are a variety of
   ways that an attacker can compromise the privacy of VoIP
   conversations.

   o  eavesdropping - the attacker reconstruct the conversation and/or
      additional data delivered with it (e.g.numbers transmitted with
      DTMF tones);

   o  media alteration - the attacker alters some RTP packets in order
      to modify the conversation between two users;

   o  bid-down attack to MF - a number of encryption key exchange
      protocols performs handshake through the Media Function.  ZRTP [3]
      is an example of such protocol that exchanges key information



Niccolini & Chen        Expires September 2, 2007               [Page 9]


Internet-Draft                VoIP Threats                    March 2007


      using RTP at the beginning before establishing an SRTP session.
      An attacker may intentionally drop only RTP packets involved in
      the handshake.  While this attack does not interrupt the voice
      communication, calling parties are prevented from establishing an
      SRTP session to secure privacy.

2.4.  Social Threats

   False presentation of information together with unwanted contact are
   the only social threats that can be reconducted to a technical
   background in the case of VoIP.  Examples are:

   o  VoIP phishing - VoIP phishing involves an attacker creating a
      phone number that appears to represent a legitimate organization
      such as a bank.  VoIP allows an attacker to easily set up a
      malicious IVR (Interactive Voice Response) system with a toll-free
      number that is harder to trace than one set up on PSTN.  This type
      of fraud may be more effective than email-based phising since
      victims tend to trust more a phone number than a URL;

   o  unwanted lawful/unlawful contact - the attacker contacts the
      victim with the unlawful or lawful scopes (e.g. extortion,
      telemarketing, etc.), please note that unwanted lawful contact in
      the case of VoIP is also referred to as SPam over Internet
      Telephony (SPIT), SPIT discussion is excluded by the SPEERMINT
      working group per charter.

























Niccolini & Chen        Expires September 2, 2007              [Page 10]


Internet-Draft                VoIP Threats                    March 2007


3.  Overview of SPEERMINT security requirements

   This section will discuss the SPEERMINT security requirements as
   outcome of the threat overview given in Section 2.  The requirements
   will be then enable the selection of the security solutions to be
   adopted by SPEERMINT in order to meet the identified requirements.













































Niccolini & Chen        Expires September 2, 2007              [Page 11]


Internet-Draft                VoIP Threats                    March 2007


4.  Overview of Security Solutions

   This section presents the VoIP security features currently
   standardized or under standardization in order to give an overview of
   the building blocks needed to counter the VoIP Security threats
   detailed in this draft.  The technology to secure VoIP can be divided
   in three main areas as follows:

   o  Authentication/Authorization;

   o  Encryption;

   o  Identity management.

   Authentication is needed to understand who was the sender of a
   specific packet.  Authentication can take place between different
   entities or end-to-end:

   o  from client to server - Digest authentication [4] or mutual
      Transport Layer Security (TLS) [5];

   o  from server to server - mutual Transport Layer Security (TLS);

   o  from server to client - Transport Layer Security (TLS);

   o  end-to-end - S/MIME [6].

   All solutions require some kind of trust relationship (i.e. shared
   secret or certificates authorities).

   Encryption is needed to protect the content of the packets from being
   read by other parties than the ones which are supposed to be the
   recipient of such packets.  Encryption follows the same paradigm as
   authentication and can be done either on a hop-by-hop or on a end-to-
   end basis.  On a hop-by-hop basis TLS is used (TLS creates an
   authenticated, encrypted, integrity-checked channel).  On a end-to-
   end basis S/MIME is used to sign and encrypt portions of the SIP
   body.  At the media level a end-to-end encryption is possible using
   SRTP [7] to protect RTP/RTCP media (audio, video).  Currently there
   is a discussion in the IETF about the requirements for SRTP media
   keying which is still an open issue.  Other solutions that provide
   encryption and integrity are lower layer ones like IPsec which is
   done hop-by-hop.

   Identity management is also an important piece of security framework
   in SIP [8].  The objective of the identity framework is to give
   technical means to assess user identity in a secure manner.  It
   requires strong cryptographic assertions but it represents the most



Niccolini & Chen        Expires September 2, 2007              [Page 12]


Internet-Draft                VoIP Threats                    March 2007


   promising approach to enable further security solutions which need
   the assumption of dealing with strong authenticated identities.
   Please note that other techniques could also be used to counter VoIP
   Security threats, the techniques that constitute stand-alone
   solutions and that do not need standardization work are left out the
   scope of this document.  It is left open for discussion which other
   security techniques to include in this section.












































Niccolini & Chen        Expires September 2, 2007              [Page 13]


Internet-Draft                VoIP Threats                    March 2007


5.  Conclusions

   This memo presented a the different SPEERMINT security threats
   classified in groups related to the Location Function, Signaling
   Function and Media Function respectively.  The multiple instances of
   the threats are presented with a brief explanation.  Finally the
   existing security solutions in VoIP were presented to describe the
   countermeasures currently available for such threats.  The objective
   of this document is to identify and enumerate the VoIP threat vectors
   in order to specify security-related requirements specific to
   SPEERMINT (that will be included in section Section 3).  Once the
   requirements are identified, methods and solutions how to achieve
   such requirements can be selected.






































Niccolini & Chen        Expires September 2, 2007              [Page 14]


Internet-Draft                VoIP Threats                    March 2007


6.  Security Considerations

   This memo is entirely focused on the security threats for SPEERMINT.
















































Niccolini & Chen        Expires September 2, 2007              [Page 15]


Internet-Draft                VoIP Threats                    March 2007


7.  Acknowledgements

   This memo takes inspiration from VOIPSA VoIP Security and Privacy
   Threat Taxonomy.  The author would like to thank VOIPSA for having
   produced such a comprehensive taxonomy which is the starting point of
   this draft.  The author would also like to thank Cullen Jennings for
   the useful slides presented at the VoIP Management and Security
   workshop in Vancouver.











































Niccolini & Chen        Expires September 2, 2007              [Page 16]


Internet-Draft                VoIP Threats                    March 2007


8.  Informative References

   [1]  "VOIPSA VoIP Security and Privacy Threat Taxonomy",
        October 2005.

   [2]  Penno, R., Hammer, M., Khan, S., Malas, D., and A. Uzelac,
        "SPEERMINT Peering Architecture",
        draft-ietf-speermint-architecture-02.txt (work in progress),
        October 2006.

   [3]  Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Extensions
        to RTP for Diffie-Hellman Key Agreement for SRTP",
        draft-zimmermann-avt-zrtp-02.txt (work in progress),
        October 2006.

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

   [5]  Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2",
        draft-ietf-tls-rfc4346-bis-02.txt (work in progress),
        October 2006.

   [6]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
        (S/MIME) Version 3.1 Message Specification", RFC 3851,
        July 2004.

   [7]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
        Norrman, "The Secure Real-time Transport Protocol (SRTP)",
        RFC 3711, March 2004.

   [8]  Peterson, J. and C. Jennings, "Enhancements for Authenticated
        Identity Management in the Session Initiation Protocol (SIP)",
        RFC 4474, August 2006.

















Niccolini & Chen        Expires September 2, 2007              [Page 17]


Internet-Draft                VoIP Threats                    March 2007


Authors' Addresses

   Saverio Niccolini
   Network Laboratories, NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Phone: +49 (0) 6221 4342 118
   Email: saverio.niccolini@netlab.nec.de
   URI:   http://www.netlab.nec.de


   Eric Chen
   Information Sharing Platform Laboratories, NTT
   3-9-11 Midori-cho
   Musashino, Tokyo  180-8585
   Japan

   Email: eric.chen@lab.ntt.co.jp
   URI:   http://www.ntt.co.jp/index_e.html






























Niccolini & Chen        Expires September 2, 2007              [Page 18]


Internet-Draft                VoIP Threats                    March 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Niccolini & Chen        Expires September 2, 2007              [Page 19]


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