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

Versions: 00

Network Working Group                                     Yongchao. Song
Internet-Draft                                                    Huawei
Intended status: Informational                               Ben Y. Zhao
Expires: August 6, 2008                  U. of California, Santa Barbara
                                                         Xingfeng. Jiang
                                                          Haifeng. Jiang
                                                                  Huawei
                                                        February 3, 2008


                P2PSIP Security Analysis and Evaluation
                   draft-song-p2psip-security-eval-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 6, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document provides an analysis and evaluation of security with
   P2PSIP overlay network.  The draft compares security difference
   between C/S and P2P, then partitions the P2PSIP architecture into
   layers, and analyze the security issues in each layer and the



Song, et al.             Expires August 6, 2008                 [Page 1]


Internet-Draft   P2PSIP Security Analysis and Evaluation   February 2008


   security relationship among the layers.  Security issues with
   different kind of application scenarios are distinct.  This draft
   classifies the application scenarios into two main types, and the
   security threats with these two types of scenarios are analyzed in
   detail.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Security Comparison between C/S and P2P  . . . . . . . . . . .  4
   4.  Security Analysis with P2P Layers  . . . . . . . . . . . . . .  5
     4.1.  Transport Layer Security . . . . . . . . . . . . . . . . .  7
     4.2.  Routing Maintenance and KBR layer Security . . . . . . . .  7
     4.3.  Distributed Storage and Replication Layer Security . . . .  8
     4.4.  Application Layer Security . . . . . . . . . . . . . . . .  8
   5.  Security Analysis with Application Scenarios . . . . . . . . .  8
     5.1.  Trusted P2P Overlay Base . . . . . . . . . . . . . . . . .  9
     5.2.  Untrusted P2P Overlay Base . . . . . . . . . . . . . . . . 10
   6.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     10.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 17






















Song, et al.             Expires August 6, 2008                 [Page 2]


Internet-Draft   P2PSIP Security Analysis and Evaluation   February 2008


1.  Introduction

   As pointed out in Peer-to-Peer SIP (P2PSIP) concepts and terminology
   document [I-D.ietf-p2psip-concepts], building a P2PSIP system has
   many security consideration.  The intention of this draft is not to
   provide a solution but to give some guidelines and references for the
   development of P2PSIP peer and client protocol.  The interaction with
   conventional SIP and other systems are not included at present.

   This document compares security difference between C/S and P2P, and
   then partitions the P2P applications into four main layers, and
   analyze the security issues in each layer, and their relationship
   from security perspective.

   The detailed security requirements of P2PSIP overlay network are
   dependent on the deployment scenarios[I-D.bryan-p2psip-app-scenarios]
   in the real world.  In this draft, the application scenarios are
   divided into two types in general according to the likely deployment
   method.  The security issues with each type are analyzed in detail.


2.  Terminology

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

   The terminology and definitions used in this document are compatible
   with P2PSIP Work Group Draft "Concepts and Terminology for Peer to
   Peer SIP" [I-D.ietf-p2psip-concepts].  We also introduce the
   following important new terms used in this document, and they are
   also interpreted when used inline.



















Song, et al.             Expires August 6, 2008                 [Page 3]


Internet-Draft   P2PSIP Security Analysis and Evaluation   February 2008


   P2P Overlay Base:A P2P Overlay Base includes all the Peers that
       participate in the p2p overlay. The P2P Overlay Base provides
       distributed storage and routing services to both peers and
       clients.

   Trusted P2P Overlay Base:All peers in a Trusted P2P Overlay Base are
       trusted. The Peers in the overlay are all of good behaviors and
       under control due to deployment. For example, a carrier deploys
       a Trusted P2P Overlay Base to provide service to his customers,
       and all the peers are the carrier's devices.

   Untrusted P2P Overlay Base: Peers in a Untrusted P2P Overlay Base
       are not all trusted. There may exist some malicious behaving
       nodes in the P2P Overlay Base.


3.  Security Comparison between C/S and P2P


      +------------+----------------------+--------------------------+
      |            |                      |                          |
      |            |          C/S         |          P2P             |
      +------------+----------------------+--------------------------+
      |            |                      |                          |
      | transport  | authenticate between |  authenticate between    |
      |            | client and server    |  neighbors               |
      |            |                      |                          |
      +------------+----------------------+--------------------------+
      |            |need one hop security |  need hop by hop security|
      | routing    |transport layer       |  to ensure the end to end|
      |            |security can ensure it|  security                |
      +------------+----------------------+--------------------------+
      |            |                      | responsible peer may not |
      | storage    | server is trusted for| trusted, need end to end |
      |            | storage              | security                 |
      +------------+----------------------+--------------------------+
      |            |                      |                          |
      | application|  out of scope of this|  out of scope of this    |
      |            |  specification       |  specification           |
      |            |                      |                          |
      +------------+----------------------+--------------------------+

     Figure 1    Comparision between C/S and P2P security

   In Client Server(C/S) architecture, a client asks for a specific
   service only from a specific server.  And the following process of
   the server is transparent to the client.  The destination contact
   address(i.e. the address of that server) can be acquired from the



Song, et al.             Expires August 6, 2008                 [Page 4]


Internet-Draft   P2PSIP Security Analysis and Evaluation   February 2008


   trusted DNS system directly.  So there only exist security issues
   with one hop.  What we need to do is making a client be secure to
   that server, and making that server be secure to this client, and
   typically nothing more.

   However, in P2P Overlay, the distinct architecture from C/S makes the
   security issues change.

   First, One overlay is an autonomous system, each peer in the system
   can provide distributed storage and transport services for other P2P
   entities, and the p2p overlay is self-organization.  Whereas in C/S
   architecture, only a specific server provides certain services to the
   clients.

   Second, a peer sends messages though Key-Based-Routing and he doesn't
   know where the destination is.  There exist intermediate nodes
   between the source and destination.  Whereas in C/S architecture, a
   client sends its request directly to a server.

   Third, one peer does not know whether he should trust the information
   acquired from the overlay.  Whereas in C/S architecture, the
   information acquired from the server is always trustful.

   So in P2P overlay, security issues not only exist between end to end
   entities, but also between hop by hop services.  They are not only
   related to the routing security, but also related to the content
   security.


4.  Security Analysis with P2P Layers

   The security of P2PSIP has close relationship with each layer
   security of P2PSIP architecture.  Here we splits the P2PSIP
   architecture into four main layers, as shown in the following figure,
   and analyze the security issues from the p2psip architecture
   perspective.















Song, et al.             Expires August 6, 2008                 [Page 5]


Internet-Draft   P2PSIP Security Analysis and Evaluation   February 2008


        +----------+
        |          |                 Application Layer
        |          |          --------------------------------------
        |          |  +------+ +-------------+  +-------------+
        |          |  |      | | Distributed |  | Replication |
        |          |  |      | | Storage     |  |             |
        |          |  |      | +-------------+  +-------------+
        |          |  |      |--------------------------------------
        |Enrollment|  |P2P   | +-------------+
        |Server    |  |Layers| | Routing     |
        |          |  |      | | Maintenance |   +-----------+
        |          |  |      | +-------------+   | NAT&FW    |
        |          |  |      | +-------------+   | Traversal |
        |          |  |      | | Key Based   |   +-----------+
        |          |  |      | | Routing(KBR)|
        |          |  +------+ +-------------+
        |          |          --------------------------------------
        |          |           Transport Layer Security(TLS,DTLS)
        +----------+

        Figure 2    P2PSIP architecture

   The four main layers are:

   Application Layer: Provides the user application, and invokes the
   services provided by the Distributed Storage and Replication Layer.

   Distributed Storage and Replication Layer: Stores and Manages the
   resource objects.  Each peer's responsible resource objects are
   determined by the specific P2P algorithm.  Replication may be
   utilized to ensure the availability of resource objects under churn.

   Routing Maintenance and KBR Layer: Maintains the routing table, and
   do the Key Based Routing(KBR).  NAT and Firewall traversal may be
   involved to establish direct connections.

   Transport Layer: Provides transport service for the upper layers.

   The security measures adopted in the lower layer may impact the upper
   layer security choices.  And not every security threat needs to be
   considered in all layers, however, it is typically only required to
   be solved in one layer.  And the interesting issue is in which layer
   should the specific security threat be considered and solved.  We
   have our primary analysis for each layer in the following sub
   sections.






Song, et al.             Expires August 6, 2008                 [Page 6]


Internet-Draft   P2PSIP Security Analysis and Evaluation   February 2008


4.1.  Transport Layer Security

   P2PSIP overlay mostly run on top of the Internet, messages between
   associated nodes should be protected against attacks(such as Man-in-
   the-Middle).  In order to establish the identity trust association,
   nodes SHOULD authenticate each other, TLS and DTLS are preferable to
   solve these problems.  If transport service security is fully
   protected, we can prevent nodes without valid identities to
   participate in the overlay.  This layer must provides reliable and
   secure hop by hop transport service for the p2p overlay, though that
   is not enough.

4.2.  Routing Maintenance and KBR layer Security

   Each Peer in the P2PSIP overlay provides key based routing service to
   other peers, and a routing maintenance mechanism is used to keep the
   routing table timely and correct for the routing service.  There are
   some security threats with the routing table updating interaction and
   the key based routing.

   Even if all the nodes participating in the P2PSIP overlay are with
   valid identities, the overlay may still be attacked by responding
   with fake routing table to UPDATE requests.  If the routing table is
   false, the routing determination based on it will be false too.  So,
   verification mechanisms SHOULD be adopted to verify if the routing
   table one learned from another is correct or not.  A correct routing
   table is important for hop by hop security.

   Second, some attacker who is not responsible for the destination ID,
   responds to some requests when he is in the intermediate routing
   path(May respond with a fabricated resource object or just says that
   the searched resource object doesn't exist).  Should the source node
   verify whether the response peer is responsible for the request?
   When and how does the source peer do that?  Whether the response peer
   is responsible for the request is important for the end to end
   security.

   Third, some attackers may discard the messages when forwarding, or on
   purpose forward the message to a wrong next hop.  Should the overlay
   need a method to detect the misbehaving forwardings?

   Chosen-ID attack makes the above security issues much more worse.

   Fourth, some attacks may cause the overlay under high churn rate.
   Overlay wastes much more traffic to update the routing table, and
   transfer relative resource objects under churn.

   The first and fourth issue above is about routing maintenance



Song, et al.             Expires August 6, 2008                 [Page 7]


Internet-Draft   P2PSIP Security Analysis and Evaluation   February 2008


   function security, and the remain two issues are about the KBR
   function security.

4.3.  Distributed Storage and Replication Layer Security

   Distributed storage and replication layer provides distributed
   storage service for the resource objects that located in one's
   responsible resource ID range, and the replication service to keep
   the availability of resource objects under churn.  The security
   issues in this layer are typically end to end, and about the content
   and authority security.

   First, how to protect resource objects against unauthorized data
   operation such as obtainment, modification or removing?

   Second, should the P2PSIP overlay need a method to prevent attackers
   from publishing malicious information that will cause a DDOS attack?
   For example, Peer A may publish a very popular resource record with
   the contact address of Peer B without B's permission.  That causes
   unexpected lots of connections to B which will make Peer B down.

   Third, overlays work well for a reasonable amount of resource
   objects, but crash more or less when inserting millions of resource
   objects per node.  Spam attacks can make overlays go down.  Open
   issue: Should the spam attack be considered in the distributed
   storage layer?  Or is it only the responsibility of the application
   layer to handle this problem?

   Replication security is to TODO.

4.4.  Application Layer Security

   Application layer security requirements are out of scope of this
   specification.


5.  Security Analysis with Application Scenarios

   As described in the security considerations section in application
   scenarios draft[I-D.draft-bryan-p2psip-app-scenarios], the security
   requirements of the various application scenarios vary tremendously.
   So in this section, we divide the application scenarios into two main
   types, instead of analyzing all the security threats with each
   specific scenario described in the application scenarios draft, we
   just analyze the relative security threats of these two types, which
   represent most of the likely deployment scenarios in the real world.
   For example, the "Public P2P VoIP Service Providers" scenario in
   section 4.1.1 of application scenarios



Song, et al.             Expires August 6, 2008                 [Page 8]


Internet-Draft   P2PSIP Security Analysis and Evaluation   February 2008


   draft[I-D.draft-bryan-p2psip-app-scenarios] may be deployed using the
   first type(refer to section 5.1 of this specification), and the "Open
   Global P2P VoIP Network" scenario in section 4.1.2 of application
   scenarios draft may be deployed using the second type(refer to
   section 5.2 of this specification).

5.1.  Trusted P2P Overlay Base

   In a trusted P2P Overlay Base, all the peers are deployed with
   trustful nodes.  They are of good behaviors.  They may deployed to
   provide reliable and high quality services, and may also do some
   management issues for the overlay.  All P2PSIP clients access the
   overlay service through the associated trusted peer.  Shown as the
   following figure 3.


                     +---------+               +---------+
                     | Trusted +---------------+ Trusted |
                     | Peer    |               | Peer    |
                     +---+-----+               +----+----+
                         |                          |
                         |                          |
                         |
                         |                          |
                         |       P2PSIP Peer        |
                     +---+-----+ Protocol      +----+----+
                     | Trusted +---------------+ Trusted |
                     | Peer    |               | Peer    |
                     +---+-----+               +----+----+
                         |                          |
                     P2PSIP Client                  |
                     Protocol                       |
                     +---+-----+               +----+----+
                     |         |               |         |
                     |Client   |               | Client  |
                     +---------+               +---------+


                 Figure 3    Trusted P2P Overlay Base

   As for this type of scenarios, we regard the P2P Overlay Base to be
   secure.  The security issues to be considered are the transport
   security between trusted peers and the security issues associated
   with clients.  Because clients doesn't provide routing service for
   the overlay.  Security issues more focus on distributed storage
   layer.  Some of the attacks are described in the p2p-security-
   requirement draft[I-D.matuszewski-p2psip-security-requirement].




Song, et al.             Expires August 6, 2008                 [Page 9]


Internet-Draft   P2PSIP Security Analysis and Evaluation   February 2008


    +--------------------+-----------------------+---------------------+
    |  Possible Attacks  |   Descriptions        |  Considerations     |
    |--------------------+-----------------------+---------------------+
    |                    | 1.Message Privacy     | TLS and DTLS        |
    | Transport Related  | 2.ID hijack           |                     |
    +--------------------+-----------------------+---------------------+
    |Unauthorized Data   | Unauthorized Access,  |   Certificate       |
    |Operation           | Modification, Removing|     Mechanism       |
    +--------------------+-----------------------+---------------------+
    |                    | In the progress of    |                     |
    | Man In the Middle  | Authentication between|   Authentication    |
    |                    | client and its        |   Security          |
    |                    | associated peer       |                     |
    +--------------------+-----------------------+---------------------+
    |                    |                       |                     |
    | data pollution and |1.Publish Fake Resource| 1.Check Mechanism?  |
    | poison             | Objects               |                     |
    |                    |2.Publish malicious    | 2.Black List?       |
    |                    | contact information   |                     |
    |                    | (DDOS attack)         |                     |
    +--------------------+-----------------------+---------------------+
    |                    |                       |                     |
    |  Spam Attack       | Publish lots of       | 1. Check Mechanism? |
    |                    | redundant resources   | 2. Limit one's      |
    |                    |                       | publication number? |
    +--------------------+-----------------------+---------------------+


   Figure 4    Possible Attacks on the Trusted Overlay Base Scenarios

5.2.  Untrusted P2P Overlay Base

   In an untrusted P2P Overlay Base, there are peers who are not trusted
   by other peers.  Some of untrusted peers may do harmful things or
   abnormal behaviors to the overlay due to malicious or unknown
   intentions.  There may or may not exist trusted peers in the overlay.
   Shown as the following Figure 5.














Song, et al.             Expires August 6, 2008                [Page 10]


Internet-Draft   P2PSIP Security Analysis and Evaluation   February 2008


                 Please view in a fixed-width font such as
                                  Courier.

                   +---------+               +---------+
                   |Untrusted+---------------+   Peer  |
                   | Peer    |               |         |
                   +---+-----+               +----+----+
                       |                          |
                       |                          |
                       |                          |
                       |                          |
                       |       P2PSIP Peer        |
                   +---+-----+ Protocol      +----+----+
                   |  Peer   +---------------+Untrusted|
                   |         |               | Peer    |
                   +---+-----+               +----+----+
                       |                          |
                   P2PSIP Client              P2PSIP Client
                   Protocol                   Protocol
                   +---+-----+               +----+----+
                   |         |               |         |
                   |Client   |               | Client  |
                   +---------+               +---------+

                 Figure 5 Untrusted P2P Overlay Base

   As for this type of scenarios, the security threats with the Trusted
   P2P Overlay Base still exist, besides that, even more security issues
   emerge, because there may exist malicious peers in this type of
   scenarios.  Each layer of the P2PSIP architecture and the enrollment
   may be attacked, the attacks beyond those in the Trusted Overlay Base
   scenarios are listed in the followings Figure 6.



















Song, et al.             Expires August 6, 2008                [Page 11]


Internet-Draft   P2PSIP Security Analysis and Evaluation   February 2008


    +--------------------+-----------------------+---------------------+
    |  Possible Attacks  |   Descriptions        |  Considerations     |
    |--------------------+-----------------------+---------------------+
    |                    |1.Chosen-ID attack     | 1.Enrollment Server |
    | Identity Attack    |2.Sybil Attack         |                     |
    |                    |3.Fabricated response  | 2.A proof mechanism |
    |                    |  from the intermediate| to verify whether it|
    |                    |  peer                 | is a true root?     |
    +--------------------+-----------------------+---------------------+
    |                    |1.discard messages     | 1.message signature?|
    | Forwarding Attack  |2.Forwarding to a wrong| 2.A diagnosis       |
    |                    |next hop node          | mechanism for       |
    |                    |3.modify messages when | detecting which     |
    |                    |forwarding             | intermediate peer is|
    |                    |                       | a bad man?          |
    +--------------------+-----------------------+---------------------+
    |                    | Intermediate peer     |                     |
    | Replay Attack      | stores messages and   |Timestamp to         |
    |                    | replays               |recognize timed      |
    |                    |                       |messages?            |
    +--------------------+-----------------------+---------------------+
    |                    | give malicious        |                     |
    | Routing Table      | response info to an   |Per DHT specific?    |
    | Attack             | updating routing table|                     |
    |                    | request               |                     |
    +--------------------+-----------------------+---------------------+

   Figure 6 Possible Attacks on the Untrusted Overlay Base Scenarios

   As for these security issues, the diagnosis draft[I-D.zheng-p2psip-
   diagnose] provides a framework using an ECHO message to diagnose the
   problems in the P2PSIP overlay.


6.  Open Issues

   1.  Do we need a verification mechanism to verify if the routing
   table one learned from another is correct or not?

   2.  Should the source node verify whether the response peer is
   responsible for the request?  When and how does the source peer do
   that?

   3.  Should the overlay need a method to detect the misbehaving
   forwardings?

   4.  How to protect resource objects against unauthorized data
   operations?  And in which layer should we do that?



Song, et al.             Expires August 6, 2008                [Page 12]


Internet-Draft   P2PSIP Security Analysis and Evaluation   February 2008


   5.  Should the P2PSIP overlay need a method to prevent attackers from
   publishing Malicious Information or Spams?  And in which layer should
   we address these problems?


7.  Security Considerations

   This document analyzes and evaluates security in P2PSIP overlay
   networks, but it does not introduce any security risk by itself.


8.  IANA Considerations

   There are no IANA considerations associated to this memo.


9.  Acknowledgments

   We would like to thank Zheng Hewen for his contribution to part of
   this specification.  We would like to thank Eunsoo Shim, Li Feng, Hu
   Xinyu, Ning Zong for their valuable comments.  And many authors'
   discussion in the p2psip and p2p-hackers mailing list are contributed
   to this draft.


10.  References

10.1.  Normative References

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

   [RFC4981] J. Risson, "Survey of Research towards Robust Peer-to-Peer
   Networks: Search Methods", RFC 4981, September 2007.

   [I-D.ietf-p2psip-concepts] Bryan, D., "Concepts and Terminology for
   Peer to Peer SIP", draft-ietf- p2psip-concepts-00 (work in progress),
   June 2007.

   [I-D.matuszewski-p2psip-security-requirement] M. Matuszewski,
   "Security requirements in P2PSIP",
   draft-matuszewski-p2psip-security-requirements-01 (work in progress),
   July 2007

   [I-D.jennins-p2psip-security-mechanisms] C. Jennings, "Security
   Mechanisms for Peer to Peer SIP", draft-jennings-p2psip-security-00
   (work in progress), February 2007




Song, et al.             Expires August 6, 2008                [Page 13]


Internet-Draft   P2PSIP Security Analysis and Evaluation   February 2008


   [I-D.bryan-p2psip-requirement] D. Bryan, "P2PSIP Protocol Framework
   and Requirements", draft-bryan-p2psip-requirements-00 (work in
   progress), July 2007

   [P2PSIP-Concepts-Terminology] Dean Willis, "P2PSIP Concepts and
   Terminology", http://www3.ietf.org/ proceedings/07jul/slides/p2psip-
   13.pdf, July 2007

   [I-D.draft-bryan-p2psip-app-scenarios]D. Bryan, "Application
   Scenarios for Peer-to-Peer Session Initiation Protocol",
   draft-bryan-p2psip- app-scenarios-00(work in progress), November 2007

   [P2P-Vulnerabilities-Report] Marling Engle and Javed I. Khan,
   "Vulnerabilities of P2P Systems and a Critical Look at their
   Solutions", http://medianet.kent.edu/technicalreports.html, November
   2006

   [P2P-Sybil-Attack] John R. Douceur, "The Sybil Attack", In Proc. of
   IPTPS (Cambridge, MA, March 2002).

   [P2P-Eclipse-Attack] Singh, A., Ngan, T.-W., Druschel, P., and
   Wallach, D., "Eclipse attacks on overlay networks: Threats and
   defenses" In Proc. of INFOCOM (Barcelona, Spain, April 2006)

   [P2P-Namespace-Integrity] Krishna P. N. Puttaswamy, Ben Y. Zhao etc,
   "Protecting Namespace Integrity in Structured Overlays", IEEE,
   December 2007

   [I-D.zheng-p2psip-diagnose] H. Zheng, "Diagnose P2PSIP Overlay
   Network Failures", draft- zheng-p2psip-diagnose-00 (work in
   progress), November 2007.

10.2.  Informative References

   [I-D.bryan-p2psip-reload] C. Jennings, B. Lowekamp, E. Rescorla and
   J. Rosenberg, "REsource LOcation And Discovery (RELOAD)",
   draft-bryan-p2psip-reload-02 (work in progress), November 2007.

   [I-D.baset-p2psip-p2pp] S. Baset, H. Schulzrinne and M. Matuszewski,
   "Peer-to-Peer Protocol (P2PP)", draft-baset-p2psip-p2pp-01 (work in
   progress), November 2007.

   [I-D.jiang-p2psip-sep] X. Jiang and H. Zheng, "Service Extensible P2P
   Peer Protocol", draft-jiang-p2psip-sep-00 (work in progress),
   November 2007.

   [I-D.marocco-p2psip-xpp-pcan] Marocco, E. and E. Ivov, "XPP
   Extensions for Implementing a Passive P2PSIP Overlay Network based on



Song, et al.             Expires August 6, 2008                [Page 14]


Internet-Draft   P2PSIP Security Analysis and Evaluation   February 2008


   the CAN Distributed Hash Table", draft-marocco- p2psip-xpp-pcan-00
   (work in progress), June 2007.

   [I-D.matthews-p2psip-hip-hop] Cooper, E., "A Distributed Transport
   Function in P2PSIP using HIP for Multi-Hop Overlay Routing",
   draft-matthews-p2psip-hip-hop-00 (work in progress), June 2007.

   [I-D.bryan-p2psip-dsip] D. Bryan, B. Lowekamp and C. Jennings, "dSIP:
   A P2P Approach to SIP Registration and Resource Location",
   draft-bryan-p2psip-dsip-00 (work in progress), February 2007.

   [I-D.jennings-p2psip-asp] C. Jennings, J. Rosenberg and E. Rescorla,,
   "Address Settlement by Peer to Peer", draft-jennings-p2psip-asp-00
   (work in progress), July 2007.

   [I-D.zheng-p2psip-client] H. Zheng, "P2PSIP Client Protocol",
   draft-zheng-p2psip-client-protocol-00 (work in progress), October
   2007.

   [I-D.li-p2psip-client] L. Li, Ch.  Zhang, Y. Wang and Y. Ji, "A SIP-
   based P2PSIP Client Protocol", draft-li-p2psip-client-protocol-00
   (work in progress), November 2007.


Authors' Addresses

   Song Yongchao
   Huawei
   Baixia Road No. 91
   Nanjing, Jiangsu Province  210001
   P.R.China

   Phone: +86-25-84565081
   Fax:   +86-25-84565070
   Email: melodysong@huawei.com


   Ben Y. Zhao
   U. of California, Santa Barbara
   Santa Barbara, California
   U.S.A

   Phone: +1 805 893-3926
   Fax:   +1 805 893-8553
   Email: ravenben@cs.ucsb.edu






Song, et al.             Expires August 6, 2008                [Page 15]


Internet-Draft   P2PSIP Security Analysis and Evaluation   February 2008


   Jiang Xingfeng
   Huawei
   Baixia Road No. 91
   Nanjing, Jiangsu Province  210001
   P.R.China

   Phone: +86-25-84565079
   Fax:   +86-25-84565070
   Email: jiang.x.f@huawei.com


   Jiang Haifeng
   Huawei
   Baixia Road No. 91
   Nanjing, Jiangsu Province  210001
   P.R.China

   Phone: +86-25-84565080
   Fax:   +86-25-84565070
   Email: jianghaifeng@huawei.com































Song, et al.             Expires August 6, 2008                [Page 16]


Internet-Draft   P2PSIP Security Analysis and Evaluation   February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

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





Song, et al.             Expires August 6, 2008                [Page 17]


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