[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[P2PSIP] 回复 :Re: 回复 :Re: 回复 : P2PSIP and Security [Was P2PSIP Digest, Vol 19]
> At Thu, 03 Jul 2008 11:10:37 +0800,
> jiangxingfeng 36340 wrote:
> >
> > > 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 isFrom p2psip-bounces at ietf.org Wed Jul 2 23:50:29 2008
Return-Path: <p2psip-bounces at ietf.org>
X-Original-To: p2psip-archive at optimus.ietf.org
Delivered-To: ietfarch-p2psip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 6CF403A6835;
Wed, 2 Jul 2008 23:50:29 -0700 (PDT)
X-Original-To: p2psip at core3.amsl.com
Delivered-To: p2psip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 0BEFF3A6835
for <p2psip at core3.amsl.com>; Wed, 2 Jul 2008 23:50:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.846
X-Spam-Level: **
X-Spam-Status: No, score=2.846 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2,
J_CHICKENPOX_83=0.6, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id jBwlP29KKah6 for <p2psip at core3.amsl.com>;
Wed, 2 Jul 2008 23:50:27 -0700 (PDT)
Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211])
by core3.amsl.com (Postfix) with ESMTP id CE23F3A6825
for <p2psip at ietf.org>; Wed, 2 Jul 2008 23:50:27 -0700 (PDT)
Received: from huawei.com (usaga01-in [172.18.4.6])
by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
(built Aug
8 2006)) with ESMTP id <0K3F00BTO4CBGR at usaga01-in.huawei.com> for
p2psip at ietf.org; Wed, 02 Jul 2008 23:50:36 -0700 (PDT)
Received: from huawei.com ([172.17.1.31])
by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
(built Aug
8 2006)) with ESMTP id <0K3F00J9G4C8VI at usaga01-in.huawei.com> for
p2psip at ietf.org; Wed, 02 Jul 2008 23:50:34 -0700 (PDT)
Received: from [172.24.1.6] (Forwarded-For: [202.152.182.3])
by szxmc03-in.huawei.com (mshttpd); Thu, 03 Jul 2008 14:50:21 +0800
Date: Thu, 03 Jul 2008 14:50:21 +0800
From: songhaibin 64081 <melodysong at huawei.com>
In-reply-to: <20080703042718.1C8F0509A9 at romeo.rtfm.com>
To: Eric Rescorla <ekr at networkresonance.com>
Message-id: <f97f88168b53.8b53f97f8816 at huawei.com>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006)
Content-language: zh-CN
Content-disposition: inline
X-Accept-Language: zh-CN
Priority: normal
References: <mailman.29.1214938805.23348.p2psip at ietf.org>
<486A9187.20304 at uia.no> <20080701212630.C1F9131D2F3 at kilo.rtfm.com>
<fd2e817e3b69.3b69fd2e817e at huawei.com>
<20080702024751.32DB732777A at kilo.rtfm.com>
<f933c9b98e5a.8e5af933c9b9 at huawei.com>
<20080703042718.1C8F0509A9 at romeo.rtfm.com>
Cc: "xianghan.zheng" <xianghan.zheng at uia.no>, p2psip at ietf.org
Subject: [P2PSIP] =?gb2312?b?u9i4tCA6UmU6ICC72Li0IDpSZTogu9i4tCA6IFAyUFNJ?=
=?gb2312?b?UCBhbmQgU2VjdXJpdHkgW1dhcyBQMlBTSVAgRGlnZXN0LCBWb2wgMTld?=
X-BeenThere: p2psip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2psip>,
<mailto:p2psip-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip at ietf.org>
List-Help: <mailto:p2psip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>,
<mailto:p2psip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2psip-bounces at ietf.org
Errors-To: p2psip-bounces at ietf.org
> At Thu, 03 Jul 2008 11:10:37 +0800,
> jiangxingfeng 36340 wrote:
> >
> > > 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,
> sues,
> > > 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.
> >
> > 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.
>
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.
> > > 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?
> >
> > 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.
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
> _______________________________________________
> P2PSIP mailing list
> P2PSIP at ietf.org
> https://www.ietf.org/mailman/listinfo/p2psip
>
_______________________________________________
P2PSIP mailing list
P2PSIP at ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
> > 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.
> >
> > 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.
>
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.
> > > 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?
> >
> > 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.
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
> _______________________________________________
> P2PSIP mailing list
> P2PSIP at ietf.org
> https://www.ietf.org/mailman/listinfo/p2psip
>
_______________________________________________
P2PSIP mailing list
P2PSIP at ietf.org
https://www.ietf.org/mailman/listinfo/p2psip