Subject: Re: [P2PSIP] P2PSIP Digest, Vol 19, Issue 1

From: "xianghan.zheng" <[email-masked]>
Date: Tue, 01 Jul 2008 22:20:23 +0200

[email-masked] 写道:
> Send P2PSIP mailing list submissions to
> 	[email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/p2psip
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
>
> You can reach the person managing the list at
> 	[email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of P2PSIP digest..."
>
>
> Today's Topics:
>
>    1. Re:  HIP for P2P SIP (Bruce Lowekamp)
>    2. Re:  HIP for P2P SIP (Ari Keranen)
>    3. Re:  Should draft-bryan-p2psip-reload-04 be adopted as a
>       workgroup item? (Brian Rosen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 30 Jun 2008 16:03:38 -0400
> From: Bruce Lowekamp <[email-masked]>
> Subject: Re: [P2PSIP] HIP for P2P SIP
> To: Ari Keranen <[email-masked]>
> Cc: [email-masked], [email-masked],	Henry Sinnreich
> 	<[email-masked]>,	P2PSIP WG <[email-masked]>, [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Ari Keranen wrote:
>   
>> Bruce Lowekamp wrote:
>>     
>>> Henry Sinnreich wrote:
>>>       
>>>> On 6/27/08 11:07 AM, "Eric Rescorla" <[email-masked]> wrote:
>>>>         
>>>>> As Bruce indicated in a previous message, HIP needs a rendezvous 
>>>>> service,
>>>>> and a generic P2P overlay like RELOAD can provide such a service. In 
>>>>> that
>>>>> respect, HIP would be a client of RELOAD, even if RELOAD itself ran
>>>>> over ordinary IP.
>>>>>
>>>>> -Ekr
>>>>>           
>>>> HIP has been defined with a rendezvous server (RVS) in the HIP 
>>>> Rendezvous
>>>> Extension RFC 5204. Actually, one of the nicer properties is the
>>>> flexibility, since any node can act as a rendezvous server; that's 
>>>> more than
>>>> SIP can do.
>>>>
>>>> What am I missing?
>>>>         
>>> Locating a capable (non-NATed) rendezvous server in a distributed 
>>> environment without a centralized service provider is itself a 
>>> non-trivial problem.
>>>
>>> Additionally, even if you have obtained a rendezvous server, you still 
>>> need a registration server (RFC5203).
>>>       
>> Actually, in HIP you don't need a separate "registration server" to get 
>> rendezvous service but you use the registration extension (RFC5203) to 
>> register to the service. And for the NATed case you should use HIP relay 
>> service, i.e., instead of forwarding just the I1 as in RVS, whole base 
>> exchange is done trough the relaying service. This service can be 
>> provided by a relay server [1] or, e.g., a P2PSIP overlay [2].
>>     
>
> I think we must be in violent agreement, modulo a bit of terminology. 
> Labeling 5203 as defining a "registration server" is a bit of an 
> oversimplification, but I think accurately identifies one of the roles 
> the overlay would have to fulfill.   And draft-ietf-hip-nat-traversal 
> merely identifies HIP relay as another role (ice aware) for a rendezvous 
> server.
>
> I probably should have pointed to rfc5205 as well.
>
> Anyway, the entire purpose of my email was to point out that something 
> needs to fulfill these two roles, and as suggested by hip-bone and 
> others, a p2psip overlay is well-suited for the job, particularly in an 
> ad hoc environment (no provisioned servers or dns).  I think we both 
> agree on that.
>
> Bruce
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 01 Jul 2008 06:57:05 +0300
> From: Ari Keranen <[email-masked]>
> Subject: Re: [P2PSIP] HIP for P2P SIP
> To: Bruce Lowekamp <[email-masked]>
> Cc: [email-masked], [email-masked],	Henry Sinnreich
> 	<[email-masked]>,	P2PSIP WG <[email-masked]>, [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Bruce Lowekamp wrote:
>   
>> Ari Keranen wrote:
>>     
>>> Bruce Lowekamp wrote:
>>>       
>>>> Henry Sinnreich wrote:
>>>>         
>>>>> On 6/27/08 11:07 AM, "Eric Rescorla" <[email-masked]> wrote:
>>>>>           
>>>>>> As Bruce indicated in a previous message, HIP needs a rendezvous 
>>>>>> service,
>>>>>> and a generic P2P overlay like RELOAD can provide such a service. 
>>>>>> In that
>>>>>> respect, HIP would be a client of RELOAD, even if RELOAD itself ran
>>>>>> over ordinary IP.
>>>>>>
>>>>>> -Ekr
>>>>>>             
>>>>> HIP has been defined with a rendezvous server (RVS) in the HIP 
>>>>> Rendezvous
>>>>> Extension RFC 5204. Actually, one of the nicer properties is the
>>>>> flexibility, since any node can act as a rendezvous server; that's 
>>>>> more than
>>>>> SIP can do.
>>>>>
>>>>> What am I missing?
>>>>>           
>>>> Locating a capable (non-NATed) rendezvous server in a distributed 
>>>> environment without a centralized service provider is itself a 
>>>> non-trivial problem.
>>>>
>>>> Additionally, even if you have obtained a rendezvous server, you 
>>>> still need a registration server (RFC5203).
>>>>         
>>> Actually, in HIP you don't need a separate "registration server" to 
>>> get rendezvous service but you use the registration extension 
>>> (RFC5203) to register to the service. And for the NATed case you 
>>> should use HIP relay service, i.e., instead of forwarding just the I1 
>>> as in RVS, whole base exchange is done trough the relaying service. 
>>> This service can be provided by a relay server [1] or, e.g., a P2PSIP 
>>> overlay [2].
>>>       
>> I think we must be in violent agreement, modulo a bit of terminology. 
>> Labeling 5203 as defining a "registration server" is a bit of an 
>> oversimplification, but I think accurately identifies one of the roles 
>> the overlay would have to fulfill.   And draft-ietf-hip-nat-traversal 
>> merely identifies HIP relay as another role (ice aware) for a rendezvous 
>> server.
>>
>> I probably should have pointed to rfc5205 as well.
>>
>> Anyway, the entire purpose of my email was to point out that something 
>> needs to fulfill these two roles, and as suggested by hip-bone and 
>> others, a p2psip overlay is well-suited for the job, particularly in an 
>> ad hoc environment (no provisioned servers or dns).  I think we both 
>> agree on that.
>>     
>
> Yes, we fully agree on that. I was just worried that some people on the 
> list might get the impression that you need two different servers just 
> to get the rendezvous service. Thanks for clarifying.
>
>
> Cheers,
> Ari
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 1 Jul 2008 00:07:54 -0400
> From: "Brian Rosen" <[email-masked]>
> Subject: Re: [P2PSIP] Should draft-bryan-p2psip-reload-04 be adopted
> 	as a	workgroup item?
> To: "Rosen, Brian" <[email-masked]>,	"'P2PSIP Mailing List'"
> 	<[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain;	charset="us-ascii"
>
> There being no objections, draft-bryan-p2psip-reload is hereby adopted as a
> working group item against our p2psip peer protocol charter item.
>
> Thanks to the authors for addressing the concerns of the work group.
>
> Chairs will be announcing an editor in Dublin if not before.
>
> As has been stated several times, and in keeping with IETF practice,
> adoption of this draft DOES NOT MEAN that all the ideas in it stay as they
> are, or the current authors decide what goes in or out.  The working group
> now controls the document and we have plenty of room and time to mold it to
> meet all of our needs within our charter and milestone constraints.
>
> Brian & David (as chairs)
>
>   
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Rosen, Brian
>> Sent: Tuesday, June 24, 2008 7:49 AM
>> To: P2PSIP Mailing List
>> Subject: [P2PSIP] Should draft-bryan-p2psip-reload-04 be adopted as a
>> workgroup item?
>>
>> As we discussed in Philly, the authors have addressed the concerns about
>> the readability and clarity of the prior version of the document.  List
>> discussion so far has been confined to technical discussions on various
>> aspects of the protocol.
>>
>> Who objects to making this draft a work group item, and reload, as
>> currently defined the protocol upon which to base our work?
>>
>> If you do object, would you please state your reasons and what you would
>> prefer we do in furtherance of our charter item.
>>
>> Brian (as chair)
>> _______________________________________________
>> P2PSIP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/p2psip
>>     
>
>
>
> ------------------------------
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>
> End of P2PSIP Digest, Vol 19, Issue 1
> *************************************
>
>   
Actually, i do not think both the RELOAD & HIP did not solve all the 
technical issue. I work for in system security level, and it is belived 
by most of users that a system which is not secured should not be 
downloaded and used. May be i make a example.

Several internet draft propose a certificate-based security solution. It 
does solved some problems. However, it is not enough for protecting 
privacy. In the decentralized system, one malicious peer may become 
malicious when it receives the certificate and joins the overlay. That 
means he can act as an intermediate peer that read the incoming P2PSIP 
request and record a profile of the source and destination privacy. 
Later, he can do many malicious things, e.g. send the SPAM, DoS attack, 
etc. So, in the decentralized system, currently, there is no solution to 
protect the privacy.

And in order to protect privacy, which is the basic servie P2PSIP system 
should do, we may need to consider to revise a little bit in revising 
the protocol, ..... and so on. That is why i thought the internet drafts 
are not enough and powerful currently.

Most of the engineers consider the accessibiliy and availability too 
much so that some times they did not think of the security, privacy, and 
some basic things. I did when i was working in the network application 
field, but now i work more in the system security.

So, i do suggest that we might re-consider the security and privacy 
field of P2PSIP before we set some standard to avoid some mistake. This 
is my own feeling. Thank you.

Best Regards,
Xianghan Zheng

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 01 Jul 2008 14:26:30 -0700

I've changed the subject to be more meaningful.

As Brian indicated in his message, the current specs aren't set in 
stone, so if there's some important security feature to be added,
the WG can certainly add it. That said, I'm not sure I understand
the security issues you're concerned with.

xianghan.zheng wrote:
> malicious when it receives the certificate and joins the overlay.

Sure. We anticipate that some fraction of the nodes in the overlay 
will be malicious.

> That 

Well, it's a little more complicated than this.

1. Because of the structure of the overlay, any given node only
   has a modest fraction of being in the path between two other
   nodes. Specifically, if source (S) and destination (D) are 
   randomly chosen, then the probability that an arbitrary node
   A will be on the path between S and D is on the order of
   (1-log(N)/N)^log(N) [for Chord]. In some overlay algorithms,
   attackers can affect the topology, thus increasing the 
   number of paths they are on. There are of course countermeasures
   for this as well.

2. Even if a node is on the path between two other nodes, they
   learn only a limited amount of information, mostly who is
   talking to who and what they are asking for. If nodes wish
   to hide this information, they can use CONNECT to set up
   a connection between themselves and then perform transactions
   over that direct connection. This isn't perfect since the
   information that they set up a connection between themselves,
   but it's not clear that that information is itself sensitive.
   Note that we could in principle add an encryption feature
   to RELOAD to remove the CONNECT overhead, but that's just
   a optimization.

3. The destination/via list features allow nodes to act as
   anonymization proxies, though of course that will need
   the explicit support of that node.

> etc. So, in the decentralized system, currently, there is no solution to 

1. SPAM, DoS, etc. aren't really privacy issues.
2. I'm not convinced that being able to snoop messages in the overlay
   makes SPAM and DoS much easier. Can you explain why you think this
   is the case.
3. To a great extent, any open network has SPAM and DoS issues. 
   Because RELOAD provides positive authentication of participants,
   it arguably is substantially better in this regard.

> are not enough and powerful currently.

I'd certainly be interested in hearing about any new security features
you think would be useful here.

> field, but now i work more in the system security.

Actually, we did think about security pretty extensively during the
design of RELOAD.

-Ekr

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Wed, 02 Jul 2008 09:48:27 +0800

Hi,all:

The authors of RELOAD-4 have done a great work to address security issues in P2P system. But I don't think it addresses all security issues. Especially the malicious behaviors of authenticated peer are not well dealt with, for example, misroute the packet, discard the packet silently,etc. 

The draft draft-song-p2psip-security-eval-00(P2PSIP Security Analysis and Evaluation) tries to summarize and analyze the impact from the malicious behaviors. You could access the draft at http://tools.ietf.org/id/draft-song-p2psip-security-eval-00.txt; A new version will be work out before IETF72. 

Regards!
JiangXingFeng

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 01 Jul 2008 19:47:50 -0700

At Wed, 02 Jul 2008 09:48:27 +0800,
jiangxingfeng 36340 wrote:
> 
> Hi,all:
> 
> The authors of RELOAD-4 have done a great work to address security
> issues in P2P system. But I don't think it addresses all security
> issues. Especially the malicious behaviors of authenticated peer are
> not well dealt with, for example, misroute the packet, discard the
> packet silently,etc.

Well, we certainly never claimed to address all security issues,
so I'm not going to disagree with that. 

That said, I don't really expect a basic p2p protocol to do much
to address this sort of low-grade packet mismanagement attack. 
As far as I know, the only techniques for dealing with misbehavior of
on-path (from the perspective of the DHT) attack are fairly inefficient.
In any case, I would expect them to be DHT-dependent and therefore
isolated to the topology plugin (e.g., Maelstrom).

Is there some specific technical feature you believe should be in
RELOAD?

-Ekr

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Thu, 03 Jul 2008 11:10:37 +0800

> to address this sort of low-grade packet mismanagement attack. 

I don't think it is a low-grade issue because its negative impact on the routing. 

> on-path (from the perspective of the DHT) attack are fairly 
> inefficient.In any case, I would expect them to be DHT-dependent 
> and therefore

Although topology plugin can isolate specific mechanisms from the base protocol, the evovling security or other mechanisms have requirements for the protocol messages which should help the realization of the mechaisms. So that means at least RELOAD should support adding new messages or extending existing messages to achieve that.

Regards

JiangXingFeng

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 02 Jul 2008 21:27:18 -0700

At Thu, 03 Jul 2008 11:10:37 +0800,
> I don't think it is a low-grade issue because its negative impact on the routing. 

There are a large number of ways to damage routing. It's not clear
to me that these are especially bad, and, as I said earlier,
the defensive techniques depend primarily on the DHT.

> Although topology plugin can isolate specific mechanisms from the
> base protocol, the evovling security or other mechanisms have
> requirements for the protocol messages which should help the
> realization of the mechaisms. So that means at least RELOAD should
> support adding new messages or extending existing messages to
> achieve that.

RELOAD supports both of these already.

-Ekr

---

From: songhaibin 64081 <[email-masked]>
Date: Thu, 03 Jul 2008 14:50:21 +0800

> > > > The authors of RELOAD-4 have done a great work to address 
> security> > > issues in P2P system. But I don't think it addresses 
> all security
 
Because the P2P overlay is an self-organizing system, there are good
or bad intermediate peers between the source peer and the destination
peer. These intermediate peers may discard messages, misroute messages,
do replay attacks, and etc. Or some peers can put victim's contact
information under popular resource to cause DoS attacks,
or manufacture a chosen-ID attack, and so many. I do think some of these
attacks are very bad to the p2p overlay. I do believe the 'basic' protocol
should provide the 'basic' defense for some general attacks, but not for all
important attacks.

> RELOAD supports both of these already.

I don't like the idea to isolate many issues to specific P2P algorithms,
unless these security issues are caused by the P2P algorithms.

BR
Song Haibin

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 3 Jul 2008 00:08:45 -0700

> should provide the 'basic' defense for some general attacks, but not  

I agree.

Cullen <in my individual contributor role>
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 03 Jul 2008 09:55:30 -0700

At Thu, 03 Jul 2008 14:50:21 +0800,
songhaibin 64081 wrote:
> do replay attacks, and etc.

You say discard, misroute, and replay, as if they're all the same.
But they're not.

Replay isn't a big issue: peers are expected to handle it correctly.
Misroute is either annoying or serious depending on how it's used.
Note that the fact that data is signed removes a lot of the practical
uses of misroute.
Discard is an issue, but as discussed below, it's hard to solve
generically.

> Or some peers can put victim's contact

> or manufacture a chosen-ID attack,

Which is why RELOAD uses a central assignment server, to prevent this
stuff.

> and so many. I do think some of these

Which it does for some of the atacks you mention, but not all
of them.

> unless these security issues are caused by the P2P algorithms.

Yes, but in the specific case of discard and misrouting, they are
intricately intertwined with the routing algorithm. Consider that the
two best-known techniques for this kind of attack are:

- Multiple routing to the target [Castro et al, 2002]
- Rapidly churning the overlay [Condie et al 2006]

While RELOAD provides facilities to implement both of these,
actually implementing them requires understanding the overlay.

If you believe there are some specific set of generic techniques
that ought to be supported by RELOAD, I encourage you to write
a draft describing them.

-Ekr

---

From: "Jing Chen" <[email-masked]>
Date: Tue, 8 Jul 2008 17:22:38 +0800

I think if we can add a security layer between Routing Layer and Application
Layer in RELOAD, in which some common and important security modules can be
defined. Maybe we can define the common APIs  of these security modules and
don't care about the specific protocols or methods used in them.