[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/