From fluffy@cisco.com Thu Apr 4 11:12:25 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698F021F9665 for ; Thu, 4 Apr 2013 11:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.599 X-Spam-Level: X-Spam-Status: No, score=-112.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR+WDHkhhmXk for ; Thu, 4 Apr 2013 11:12:24 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 36A4921F8CF8 for ; Thu, 4 Apr 2013 11:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=356; q=dns/txt; s=iport; t=1365099144; x=1366308744; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=w4FTJhKeprp+BB7QWgVCj1g6z/S8lECVvqNlc7oab6M=; b=d01oSNfKEz89ufLzvORPD59vRVJbz9TPR+LImn228zTISyQwSAkubWgJ A/sV4TEIKnHcx9VH12qTy6dPP6FSE6B42698oFwKmuMtR4c8uZqKIbhrb KRm5PNwvzuHLnHJJCn7pqUhml5mIpMgZoVvp9PNhaZlVjs31Gl26SQRYm 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8LAP7BXVGtJXG8/2dsb2JhbABDgwY2gmG+IwIBgQQWdIIhAQQ6UQEqFEInBBuIDAygQaEgjlQWgxdhA5gOj22BVYE2gig X-IronPort-AV: E=Sophos;i="4.87,410,1363132800"; d="scan'208";a="195103509" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 04 Apr 2013 18:12:11 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r34ICBKl012897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 4 Apr 2013 18:12:11 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 4 Apr 2013 13:12:10 -0500 From: "Cullen Jennings (fluffy)" To: P2PSIP Mailing List Thread-Topic: A Model to Quantify the Success of a Sybil Attack Targeting RELOAD/Chord Resources Thread-Index: AQHOMV/svWRDg1+pI0Oz9eDl98DGgA== Date: Thu, 4 Apr 2013 18:12:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [P2PSIP] A Model to Quantify the Success of a Sybil Attack Targeting RELOAD/Chord Resources X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 18:12:25 -0000 If you are interested in this type of thing, I highly recommend reading "A Model to Quantify the Success of a Sybil Attack Targeting RELOAD/Chord R= esources", by Uruena, M. ; Cuevas, R. ; Cuevas, A. ; Banchs, A. in Commun= ications Letters, IEEE Volume: 17, Issue: 2 http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=3D6412682&tag=3D1 From internet-drafts@ietf.org Mon Apr 8 04:23:22 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C3421F9330; Mon, 8 Apr 2013 04:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qRqcXL5OM2T; Mon, 8 Apr 2013 04:23:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62ABE21F928B; Mon, 8 Apr 2013 04:23:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p3 Message-ID: <20130408112321.1991.66655.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 04:23:21 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-drr-05.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 11:23:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Protocol = Working Group of the IETF. Title : An extension to RELOAD to support Direct Response Routing Author(s) : Ning Zong Xingfeng Jiang Roni Even Yunfei Zhang Filename : draft-ietf-p2psip-drr-05.txt Pages : 17 Date : 2013-04-08 Abstract: This document proposes an optional extension to RELOAD to support direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediate peers and describes the potential cases where this extension can be used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-drr There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-drr-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-drr-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cjbc@it.uc3m.es Tue Apr 9 18:01:09 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1944021F9412 for ; Tue, 9 Apr 2013 18:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrY4ys6jtwJe for ; Tue, 9 Apr 2013 18:01:08 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 2005A21F9416 for ; Tue, 9 Apr 2013 18:01:07 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 25AB8CD547E; Wed, 10 Apr 2013 03:00:53 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [192.168.1.3] (82.158.126.26.dyn.user.ono.com [82.158.126.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 06DC6CD5448; Wed, 10 Apr 2013 03:00:41 +0200 (CEST) Message-ID: <1365555640.4323.19.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Roni Even Date: Wed, 10 Apr 2013 03:00:40 +0200 In-Reply-To: <058001ce2d1a$a9012ff0$fb038fd0$@gmail.com> References: <1358855465.4174.24.camel@acorde.it.uc3m.es> <058001ce2d1a$a9012ff0$fb038fd0$@gmail.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19786.003 X-TM-AS-Result: No--43.558-7.0-31-1 X-imss-scan-details: No--43.558-7.0-31-1 Cc: draft-ietf-p2psip-rpr@tools.ietf.org, draft-ietf-p2psip-drr@tools.ietf.org, p2psip@ietf.org Subject: Re: [P2PSIP] Review of DRR and RPR documents X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 01:01:09 -0000 Hi Roni, Sorry for my late reply. I think I'm fine with your proposed text. I've seen that you have updated DRR. Nnce you update RPR draft, I'll review both documents again and post any further comments that I have (if any), as part of my shepherd review. Thanks, Carlos On Sat, 2013-03-30 at 10:46 +0300, Roni Even wrote: > Hi Carlos, > The current text in the security section of both drafts is > > "As a routing alternative, the security part of RPR conforms to section 13.6 in based draft[I-D.ietf-p2psip-base] which describes routing security." > > I saw you comment "I think this sections has to be extended. It is not clear to me how the proposed approach conforms to -base security without providing more details. How DoS attachs would be avoided for example, by trying to forge the destination address". > > I am not sure what we can add here. The security section of the base draft starts with an overview that references RFC5765. DRR and RPR are only adding routing options. > DRR provides a direct path back to the source and as such reduce the problem on malicious nodes on the route to affect the route back. The digital signatures defined in the based draft protects against changes of the forwarding header. > > > RPR as specified in the draft (section3.2) is using a trusted node close to the initiating node, using a trusted nodes is recommended as a security policy. We can look at RPR as DRR in the direction toward the destination and since it is not an arbitrary node in the middle but one that should be trusted (managed network, bootstrap peers or configured relay) and using the based security recommendation will suffice. > > > We can try to add more text based on the above observation > > for DRR > > "As a routing alternative, the security part of DRR conforms to section 13 with emphasis one section 13.6 in based draft[I-D.ietf-p2psip-base] which describes routing security. The DRR routing option provide the information about the route back to the source. According to section 13 of the base drat the forwarding header MUST be digitally signed protecting the DRR routing information." > > For RPR > > "As a routing alternative, the security part of RPR conforms to section 13 with emphasis one section 13.6 in based draft[I-D.ietf-p2psip-base] which describes routing security. RPR behave like a DRR requesting node towards the destination node. The RPR relay node is not an arbitrary node but should be a trusted one (managed network, bootstrap peers or configured relay) which will make it less of a risk as outlined in section13 of the based draft." > > Thanks > Roni Even > > > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of Carlos Jes?s Bernardos Cano > Sent: 22 January, 2013 1:51 PM > To: p2psip@ietf.org > Cc: draft-ietf-p2psip-drr@tools.ietf.org; draft-ietf-p2psip-rpr@tools.ietf.org > Subject: [P2PSIP] Review of DRR and RPR documents > > Hi, > > As agreed during the last meeting, I've performed a review of draft-ietf-p2psip-drr and draft-ietf-p2psip-rpr documents, prior to shipping them to the IESG for publication. My reviews are attached to this e-mail (I added comments to the PDF version of each draft, hope this is fine). > > I'd like authors to go through the comments before sending the documents to the IESG. There might be some issues that need to be brought to the WG for discussion. > > I'd also like to ask the WG for opinion on one particular aspect. I'm wondering if it would be better to merge both documents into a single one. Currently, both documents make quite a lot of cross-references, but still there is duplicate text in both of them, so I'd be more in favor of merging (personal opinion). Please, comment on this on the mailing list. > > Thanks, > > Carlos > From zongning@huawei.com Tue Apr 9 18:07:51 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D742621F9795 for ; Tue, 9 Apr 2013 18:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WhnIpP8aC3n for ; Tue, 9 Apr 2013 18:07:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 33FA021F978F for ; Tue, 9 Apr 2013 18:07:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQF51350; Wed, 10 Apr 2013 01:07:49 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 10 Apr 2013 02:07:19 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 10 Apr 2013 02:07:47 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.126]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Wed, 10 Apr 2013 09:07:43 +0800 From: Zongning To: "cjbc@it.uc3m.es" , Roni Even Thread-Topic: [P2PSIP] Review of DRR and RPR documents Thread-Index: AQHN+JbQ+lELkghHqEm4neGtHGOlyJi9vfsAgBDYXgCAAIb9UA== Date: Wed, 10 Apr 2013 01:07:42 +0000 Message-ID: References: <1358855465.4174.24.camel@acorde.it.uc3m.es> <058001ce2d1a$a9012ff0$fb038fd0$@gmail.com> <1365555640.4323.19.camel@acorde.it.uc3m.es> In-Reply-To: <1365555640.4323.19.camel@acorde.it.uc3m.es> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-p2psip-rpr@tools.ietf.org" , "draft-ietf-p2psip-drr@tools.ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] Review of DRR and RPR documents X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 01:07:52 -0000 SGksIENhcmxvcywNCg0KSSBtYWRlIG1pc3Rha2UgKHVzaW5nIHdyb25nIGZpbGUpIHdoZW4gSSB0 cmllZCB0byBzdWJtaXQgUlBSIGRyYWZ0LCBzbyB0aGF0IEkgY291bGQgbm90IGRvIGF1dG9tYXRp YyBwb3N0IHZpYSBJRVRGIHBvcnRhbC4NCkkgaGF2ZSBhc2tlZCAnaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnJyB0byBkbyBtYW51YWwgcG9zdCBhbmQgaG9wZSB0byBzZWUgUlBSIGRyYWZ0IGluIElF VEYgcmVwb3NpdG9yeSBzb29uLg0KU29ycnkgYWJvdXQgdGhhdC4NCg0KLU5pbmcNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDYXJsb3MgSmVzw7pzIEJlcm5hcmRvcyBD YW5vIFttYWlsdG86Y2piY0BpdC51YzNtLmVzXQ0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDEw LCAyMDEzIDk6MDEgQU0NCj4gVG86IFJvbmkgRXZlbg0KPiBDYzogcDJwc2lwQGlldGYub3JnOyBk cmFmdC1pZXRmLXAycHNpcC1kcnJAdG9vbHMuaWV0Zi5vcmc7DQo+IGRyYWZ0LWlldGYtcDJwc2lw LXJwckB0b29scy5pZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1AyUFNJUF0gUmV2aWV3IG9mIERS UiBhbmQgUlBSIGRvY3VtZW50cw0KPiANCj4gSGkgUm9uaSwNCj4gDQo+IFNvcnJ5IGZvciBteSBs YXRlIHJlcGx5Lg0KPiANCj4gSSB0aGluayBJJ20gZmluZSB3aXRoIHlvdXIgcHJvcG9zZWQgdGV4 dC4gSSd2ZSBzZWVuIHRoYXQgeW91IGhhdmUNCj4gdXBkYXRlZCBEUlIuIE5uY2UgeW91IHVwZGF0 ZSBSUFIgZHJhZnQsIEknbGwgcmV2aWV3IGJvdGggZG9jdW1lbnRzIGFnYWluDQo+IGFuZCBwb3N0 IGFueSBmdXJ0aGVyIGNvbW1lbnRzIHRoYXQgSSBoYXZlIChpZiBhbnkpLCBhcyBwYXJ0IG9mIG15 DQo+IHNoZXBoZXJkIHJldmlldy4NCj4gDQo+IFRoYW5rcywNCj4gDQo+IENhcmxvcw0KPiANCj4g T24gU2F0LCAyMDEzLTAzLTMwIGF0IDEwOjQ2ICswMzAwLCBSb25pIEV2ZW4gd3JvdGU6DQo+ID4g SGkgQ2FybG9zLA0KPiA+IFRoZSBjdXJyZW50IHRleHQgaW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24g b2YgYm90aCBkcmFmdHMgaXMNCj4gPg0KPiA+ICJBcyBhIHJvdXRpbmcgYWx0ZXJuYXRpdmUsIHRo ZSBzZWN1cml0eSBwYXJ0IG9mIFJQUiBjb25mb3JtcyB0byBzZWN0aW9uIDEzLjYgaW4NCj4gYmFz ZWQgZHJhZnRbSS1ELmlldGYtcDJwc2lwLWJhc2VdIHdoaWNoIGRlc2NyaWJlcyByb3V0aW5nIHNl Y3VyaXR5LiINCj4gPg0KPiA+IEkgc2F3IHlvdSBjb21tZW50ICJJIHRoaW5rIHRoaXMgc2VjdGlv bnMgaGFzIHRvIGJlIGV4dGVuZGVkLiBJdCBpcyBub3QgY2xlYXIgdG8NCj4gbWUgaG93IHRoZSBw cm9wb3NlZCBhcHByb2FjaCBjb25mb3JtcyB0byAtYmFzZSBzZWN1cml0eSB3aXRob3V0IHByb3Zp ZGluZw0KPiBtb3JlIGRldGFpbHMuIEhvdyBEb1MgYXR0YWNocyB3b3VsZCBiZSBhdm9pZGVkIGZv ciBleGFtcGxlLCBieSB0cnlpbmcgdG8NCj4gZm9yZ2UgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3Mi Lg0KPiA+DQo+ID4gSSBhbSBub3Qgc3VyZSB3aGF0IHdlIGNhbiBhZGQgaGVyZS4gVGhlIHNlY3Vy aXR5IHNlY3Rpb24gb2YgdGhlIGJhc2UgZHJhZnQNCj4gc3RhcnRzIHdpdGggYW4gb3ZlcnZpZXcg dGhhdCByZWZlcmVuY2VzIFJGQzU3NjUuICBEUlIgYW5kIFJQUiBhcmUgb25seQ0KPiBhZGRpbmcg IHJvdXRpbmcgb3B0aW9ucy4NCj4gPiBEUlIgcHJvdmlkZXMgYSBkaXJlY3QgcGF0aCBiYWNrIHRv IHRoZSBzb3VyY2UgYW5kIGFzIHN1Y2ggcmVkdWNlIHRoZQ0KPiBwcm9ibGVtIG9uIG1hbGljaW91 cyBub2RlcyBvbiB0aGUgcm91dGUgdG8gYWZmZWN0IHRoZSByb3V0ZSBiYWNrLiBUaGUgZGlnaXRh bA0KPiBzaWduYXR1cmVzIGRlZmluZWQgaW4gdGhlIGJhc2VkIGRyYWZ0IHByb3RlY3RzIGFnYWlu c3QgY2hhbmdlcyBvZiB0aGUNCj4gZm9yd2FyZGluZyBoZWFkZXIuDQo+ID4NCj4gPg0KPiA+IFJQ UiAgYXMgc3BlY2lmaWVkIGluIHRoZSBkcmFmdCAoc2VjdGlvbjMuMikgaXMgdXNpbmcgYSB0cnVz dGVkIG5vZGUgY2xvc2UgdG8gdGhlDQo+IGluaXRpYXRpbmcgbm9kZSwgdXNpbmcgYSB0cnVzdGVk IG5vZGVzIGlzIHJlY29tbWVuZGVkIGFzIGEgc2VjdXJpdHkgcG9saWN5Lg0KPiBXZSBjYW4gbG9v ayBhdCBSUFIgYXMgRFJSIGluIHRoZSBkaXJlY3Rpb24gdG93YXJkIHRoZSBkZXN0aW5hdGlvbiBh bmQgc2luY2UgaXQNCj4gaXMgbm90IGFuIGFyYml0cmFyeSBub2RlIGluIHRoZSBtaWRkbGUgYnV0 IG9uZSB0aGF0IHNob3VsZCBiZSB0cnVzdGVkIChtYW5hZ2VkDQo+IG5ldHdvcmssIGJvb3RzdHJh cCBwZWVycyBvciBjb25maWd1cmVkIHJlbGF5KSBhbmQgdXNpbmcgdGhlIGJhc2VkIHNlY3VyaXR5 DQo+IHJlY29tbWVuZGF0aW9uIHdpbGwgc3VmZmljZS4NCj4gPg0KPiA+DQo+ID4gV2UgY2FuIHRy eSB0byBhZGQgbW9yZSB0ZXh0IGJhc2VkIG9uIHRoZSBhYm92ZSBvYnNlcnZhdGlvbg0KPiA+DQo+ ID4gZm9yIERSUg0KPiA+DQo+ID4gIkFzIGEgcm91dGluZyBhbHRlcm5hdGl2ZSwgdGhlIHNlY3Vy aXR5IHBhcnQgb2YgRFJSIGNvbmZvcm1zIHRvIHNlY3Rpb24gMTMNCj4gd2l0aCBlbXBoYXNpcyBv bmUgc2VjdGlvbiAxMy42IGluIGJhc2VkIGRyYWZ0W0ktRC5pZXRmLXAycHNpcC1iYXNlXSB3aGlj aA0KPiBkZXNjcmliZXMgcm91dGluZyBzZWN1cml0eS4gVGhlIERSUiByb3V0aW5nIG9wdGlvbiBw cm92aWRlIHRoZSBpbmZvcm1hdGlvbg0KPiBhYm91dCB0aGUgcm91dGUgYmFjayB0byB0aGUgc291 cmNlLiBBY2NvcmRpbmcgdG8gc2VjdGlvbiAxMyBvZiB0aGUgYmFzZSBkcmF0DQo+IHRoZSBmb3J3 YXJkaW5nIGhlYWRlciBNVVNUIGJlIGRpZ2l0YWxseSBzaWduZWQgcHJvdGVjdGluZyB0aGUgRFJS IHJvdXRpbmcNCj4gaW5mb3JtYXRpb24uIg0KPiA+DQo+ID4gRm9yIFJQUg0KPiA+DQo+ID4gIkFz IGEgcm91dGluZyBhbHRlcm5hdGl2ZSwgdGhlIHNlY3VyaXR5IHBhcnQgb2YgUlBSIGNvbmZvcm1z IHRvIHNlY3Rpb24gMTMNCj4gd2l0aCBlbXBoYXNpcyBvbmUgc2VjdGlvbiAxMy42IGluIGJhc2Vk IGRyYWZ0W0ktRC5pZXRmLXAycHNpcC1iYXNlXSB3aGljaA0KPiBkZXNjcmliZXMgcm91dGluZyBz ZWN1cml0eS4gUlBSIGJlaGF2ZSBsaWtlIGEgRFJSIHJlcXVlc3Rpbmcgbm9kZSB0b3dhcmRzIHRo ZQ0KPiBkZXN0aW5hdGlvbiBub2RlLiBUaGUgUlBSIHJlbGF5IG5vZGUgaXMgbm90IGFuIGFyYml0 cmFyeSBub2RlIGJ1dCBzaG91bGQgYmUgYQ0KPiB0cnVzdGVkIG9uZSAgKG1hbmFnZWQgbmV0d29y aywgYm9vdHN0cmFwIHBlZXJzIG9yIGNvbmZpZ3VyZWQgcmVsYXkpIHdoaWNoDQo+IHdpbGwgbWFr ZSBpdCBsZXNzIG9mIGEgcmlzayBhcyBvdXRsaW5lZCBpbiBzZWN0aW9uMTMgb2YgdGhlIGJhc2Vk IGRyYWZ0LiINCj4gPg0KPiA+IFRoYW5rcw0KPiA+IFJvbmkgRXZlbg0KPiA+DQo+ID4NCj4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IHAycHNpcC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86cDJwc2lwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBDYXJs b3MgSmVzP3MgQmVybmFyZG9zIENhbm8NCj4gPiBTZW50OiAyMiBKYW51YXJ5LCAyMDEzIDE6NTEg UE0NCj4gPiBUbzogcDJwc2lwQGlldGYub3JnDQo+ID4gQ2M6IGRyYWZ0LWlldGYtcDJwc2lwLWRy ckB0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1wMnBzaXAtcnByQHRvb2xzLmlldGYub3JnDQo+ ID4gU3ViamVjdDogW1AyUFNJUF0gUmV2aWV3IG9mIERSUiBhbmQgUlBSIGRvY3VtZW50cw0KPiA+ DQo+ID4gSGksDQo+ID4NCj4gPiBBcyBhZ3JlZWQgZHVyaW5nIHRoZSBsYXN0IG1lZXRpbmcsIEkn dmUgcGVyZm9ybWVkIGEgcmV2aWV3IG9mDQo+IGRyYWZ0LWlldGYtcDJwc2lwLWRyciBhbmQgZHJh ZnQtaWV0Zi1wMnBzaXAtcnByIGRvY3VtZW50cywgcHJpb3IgdG8gc2hpcHBpbmcNCj4gdGhlbSB0 byB0aGUgSUVTRyBmb3IgcHVibGljYXRpb24uIE15IHJldmlld3MgYXJlIGF0dGFjaGVkIHRvIHRo aXMgZS1tYWlsIChJDQo+IGFkZGVkIGNvbW1lbnRzIHRvIHRoZSBQREYgdmVyc2lvbiBvZiBlYWNo IGRyYWZ0LCBob3BlIHRoaXMgaXMgZmluZSkuDQo+ID4NCj4gPiBJJ2QgbGlrZSBhdXRob3JzIHRv IGdvIHRocm91Z2ggdGhlIGNvbW1lbnRzIGJlZm9yZSBzZW5kaW5nIHRoZSBkb2N1bWVudHMgdG8N Cj4gdGhlIElFU0cuIFRoZXJlIG1pZ2h0IGJlIHNvbWUgaXNzdWVzIHRoYXQgbmVlZCB0byBiZSBi cm91Z2h0IHRvIHRoZSBXRyBmb3INCj4gZGlzY3Vzc2lvbi4NCj4gPg0KPiA+IEknZCBhbHNvIGxp a2UgdG8gYXNrIHRoZSBXRyBmb3Igb3BpbmlvbiBvbiBvbmUgcGFydGljdWxhciBhc3BlY3QuIEkn bSB3b25kZXJpbmcNCj4gaWYgaXQgd291bGQgYmUgYmV0dGVyIHRvIG1lcmdlIGJvdGggZG9jdW1l bnRzIGludG8gYSBzaW5nbGUgb25lLiBDdXJyZW50bHksIGJvdGgNCj4gZG9jdW1lbnRzIG1ha2Ug cXVpdGUgYSBsb3Qgb2YgY3Jvc3MtcmVmZXJlbmNlcywgYnV0IHN0aWxsIHRoZXJlIGlzIGR1cGxp Y2F0ZSB0ZXh0DQo+IGluIGJvdGggb2YgdGhlbSwgc28gSSdkIGJlIG1vcmUgaW4gZmF2b3Igb2Yg bWVyZ2luZyAocGVyc29uYWwgb3BpbmlvbikuIFBsZWFzZSwNCj4gY29tbWVudCBvbiB0aGlzIG9u IHRoZSBtYWlsaW5nIGxpc3QuDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4NCj4gPiBDYXJsb3MNCj4g Pg0KPiANCg0K From cjbc@it.uc3m.es Tue Apr 9 18:15:05 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0AE21F989E for ; Tue, 9 Apr 2013 18:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5v-eSHqSHBim for ; Tue, 9 Apr 2013 18:15:05 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id F1CF721F9892 for ; Tue, 9 Apr 2013 18:15:04 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D763ECC5CC3; Wed, 10 Apr 2013 03:15:03 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [192.168.1.3] (82.158.126.26.dyn.user.ono.com [82.158.126.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 4B8B1CD5478; Wed, 10 Apr 2013 03:15:02 +0200 (CEST) Message-ID: <1365556502.4323.28.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Zongning Date: Wed, 10 Apr 2013 03:15:02 +0200 In-Reply-To: References: <1358855465.4174.24.camel@acorde.it.uc3m.es> <058001ce2d1a$a9012ff0$fb038fd0$@gmail.com> <1365555640.4323.19.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19786.003 X-TM-AS-Result: No--57.289-7.0-31-1 X-imss-scan-details: No--57.289-7.0-31-1 Cc: "draft-ietf-p2psip-rpr@tools.ietf.org" , "draft-ietf-p2psip-drr@tools.ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] Review of DRR and RPR documents X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 01:15:06 -0000 OK, thanks. Carlos On Wed, 2013-04-10 at 01:07 +0000, Zongning wrote: > Hi, Carlos, > > I made mistake (using wrong file) when I tried to submit RPR draft, so that I could not do automatic post via IETF portal. > I have asked 'internet-drafts@ietf.org' to do manual post and hope to see RPR draft in IETF repository soon. > Sorry about that. > > -Ning > > > -----Original Message----- > > From: Carlos Jesús Bernardos Cano [mailto:cjbc@it.uc3m.es] > > Sent: Wednesday, April 10, 2013 9:01 AM > > To: Roni Even > > Cc: p2psip@ietf.org; draft-ietf-p2psip-drr@tools.ietf.org; > > draft-ietf-p2psip-rpr@tools.ietf.org > > Subject: Re: [P2PSIP] Review of DRR and RPR documents > > > > Hi Roni, > > > > Sorry for my late reply. > > > > I think I'm fine with your proposed text. I've seen that you have > > updated DRR. Nnce you update RPR draft, I'll review both documents again > > and post any further comments that I have (if any), as part of my > > shepherd review. > > > > Thanks, > > > > Carlos > > > > On Sat, 2013-03-30 at 10:46 +0300, Roni Even wrote: > > > Hi Carlos, > > > The current text in the security section of both drafts is > > > > > > "As a routing alternative, the security part of RPR conforms to section 13.6 in > > based draft[I-D.ietf-p2psip-base] which describes routing security." > > > > > > I saw you comment "I think this sections has to be extended. It is not clear to > > me how the proposed approach conforms to -base security without providing > > more details. How DoS attachs would be avoided for example, by trying to > > forge the destination address". > > > > > > I am not sure what we can add here. The security section of the base draft > > starts with an overview that references RFC5765. DRR and RPR are only > > adding routing options. > > > DRR provides a direct path back to the source and as such reduce the > > problem on malicious nodes on the route to affect the route back. The digital > > signatures defined in the based draft protects against changes of the > > forwarding header. > > > > > > > > > RPR as specified in the draft (section3.2) is using a trusted node close to the > > initiating node, using a trusted nodes is recommended as a security policy. > > We can look at RPR as DRR in the direction toward the destination and since it > > is not an arbitrary node in the middle but one that should be trusted (managed > > network, bootstrap peers or configured relay) and using the based security > > recommendation will suffice. > > > > > > > > > We can try to add more text based on the above observation > > > > > > for DRR > > > > > > "As a routing alternative, the security part of DRR conforms to section 13 > > with emphasis one section 13.6 in based draft[I-D.ietf-p2psip-base] which > > describes routing security. The DRR routing option provide the information > > about the route back to the source. According to section 13 of the base drat > > the forwarding header MUST be digitally signed protecting the DRR routing > > information." > > > > > > For RPR > > > > > > "As a routing alternative, the security part of RPR conforms to section 13 > > with emphasis one section 13.6 in based draft[I-D.ietf-p2psip-base] which > > describes routing security. RPR behave like a DRR requesting node towards the > > destination node. The RPR relay node is not an arbitrary node but should be a > > trusted one (managed network, bootstrap peers or configured relay) which > > will make it less of a risk as outlined in section13 of the based draft." > > > > > > Thanks > > > Roni Even > > > > > > > > > -----Original Message----- > > > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf > > Of Carlos Jes?s Bernardos Cano > > > Sent: 22 January, 2013 1:51 PM > > > To: p2psip@ietf.org > > > Cc: draft-ietf-p2psip-drr@tools.ietf.org; draft-ietf-p2psip-rpr@tools.ietf.org > > > Subject: [P2PSIP] Review of DRR and RPR documents > > > > > > Hi, > > > > > > As agreed during the last meeting, I've performed a review of > > draft-ietf-p2psip-drr and draft-ietf-p2psip-rpr documents, prior to shipping > > them to the IESG for publication. My reviews are attached to this e-mail (I > > added comments to the PDF version of each draft, hope this is fine). > > > > > > I'd like authors to go through the comments before sending the documents to > > the IESG. There might be some issues that need to be brought to the WG for > > discussion. > > > > > > I'd also like to ask the WG for opinion on one particular aspect. I'm wondering > > if it would be better to merge both documents into a single one. Currently, both > > documents make quite a lot of cross-references, but still there is duplicate text > > in both of them, so I'd be more in favor of merging (personal opinion). Please, > > comment on this on the mailing list. > > > > > > Thanks, > > > > > > Carlos > > > > > > From petithug@acm.org Thu Apr 11 08:23:13 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B9421F87F5 for ; Thu, 11 Apr 2013 08:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2SmOTUjDRur for ; Thu, 11 Apr 2013 08:23:12 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id E12A321F8F69 for ; Thu, 11 Apr 2013 08:23:11 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:1f:7932:1f6:ecb0:3636] (unknown [IPv6:2601:9:4bc0:1f:7932:1f6:ecb0:3636]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 88504204DF; Thu, 11 Apr 2013 17:23:10 +0200 (CEST) Message-ID: <5166D549.2070301@acm.org> Date: Thu, 11 Apr 2013 08:22:49 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: P2PSIP Mailing List , reload@implementers.org X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] RELOAD Interoperability Testing Event in Berlin X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 15:23:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 This is a call for participation for a RELOAD Interoperability Testing event in Berlin, Germany on July 27 and 28. On the Saturday, the event will be held at the Freie Universitaet Berlin. On the Sunday the event will be held at the venue of IETF 87. Many thanks to the Freie Universitaet Berlin and the IETF for providing the resources for this. If you have a RELOAD implementation, complete or partial, and want to participate, please send an email to reloadit-registration@implementers.org, with the following information: - - Implementation name - - Contact email - - Number of persons attending. Note that the event will be canceled if there is not at least 4 different implementations registered by end of May, so please register as soon as possible. You do not need a complete implementation to participate and be assured that the name of the participants will be kept confidential. Remember that all participants can have one or more RELOAD configuration & enrollment services provisioned for free to simplify the participation in local or remote interoperability testing. Please send me an email directly to provision this service. Thanks. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRZtVBAAoJECnERZXWan7Et7gQAKKPqEHf9UEVUOt+OJyshvgy rcoIJO9cYygFfAWWhtd1NvcaKu7Ldl6UqjzriryDhMwrohxWLdsTrMKNNWbBAZiq f5XIjdAH43RI+QVzY2ydH9o9x3qS4LufAATLQPodNZPtqdwBflPUJ590P5nvE/9n hoaRRB5fSdzSePmqMsmDWyXonfa8xHw/Q0UH8MTHnfhEZqeIEx9q32u33rFRC/Sv T4O0UzIrSPUVyGOGFXfEsd6hISXpMHuIBD82PxIPTS40XksymhbRZ/HyK7m4bvIA O5XW0Sw1lxrVyz5LrX+BhOHuODGOm46xvYS+vi0N6U27NXVASdLqj0ELKimjT8zl Bxo58/CHNGs0YGVToix3Gv6/wxgCSK3WLC79SECt80eGLt6mjCbh0NwircuSvd9p 5RYy+lCkhECScCxJw56rRq3GPzZE8etbRRU6O3pTYr93urdmq1z1Az5kPRrawr4T Ih7qpRh67tzaPztC5JAM2lK1fEShHynqoGeDXZVYX6OjfOCGjkRut0rXnj+BD2XT fhKh9KqY2sR/h89n3v57BoXdQFTr4tOD203oL5P+wcU4bjegNwnC2jAJbpV9JO0i s8pa6oh90YL7sXknplXyy2dBqdC0CX6yF6xeT34d9yP38N64WiK9cceHbasrq4hb 0oxm7mbJdtA9EDIlQXzy =PY93 -----END PGP SIGNATURE----- From Internet-Drafts@ietf.org Tue Apr 16 09:11:38 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C173E21F974C; Tue, 16 Apr 2013 09:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LregN+f+6lhr; Tue, 16 Apr 2013 09:11:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 426A521F9711; Tue, 16 Apr 2013 09:11:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130416161138.16483.50324.idtracker@ietfa.amsl.com> Date: Tue, 16 Apr 2013 09:11:38 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D ACTION:draft-ietf-p2psip-rpr-05.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 16:11:38 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : An extension to RELOAD to support Relay Peer Routing Author(s) : N. Zong, et al Filename : draft-ietf-p2psip-rpr Pages : 15 Date : April 16, 2013 This document proposes an optional extension to RELOAD to support relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediate peers and describes the potential use cases where this extension can be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-rpr-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-p2psip-rpr"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2013-04-16091138.I-D@ietf.org> --NextPart-- From polina.goltsman@student.kit.edu Mon Apr 22 11:30:48 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D2721E808A for ; Mon, 22 Apr 2013 11:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZNkXs3WRQ+O for ; Mon, 22 Apr 2013 11:30:47 -0700 (PDT) Received: from mailout.scc.kit.edu (mailout.scc.kit.edu [129.13.185.202]) by ietfa.amsl.com (Postfix) with ESMTP id 0F98321E8053 for ; Mon, 22 Apr 2013 11:30:45 -0700 (PDT) Received: from KIT-MSX-03.kit.edu (kit-msx-03.kit.edu [172.21.117.13]) by scc-mailout-02.scc.kit.edu with esmtps (Exim 4.72 #1) id 1UULVk-00011j-58; Mon, 22 Apr 2013 20:30:44 +0200 Received: from [172.20.15.72] (172.21.117.7) by smtp.kit.edu (172.21.117.13) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 22 Apr 2013 20:30:43 +0200 Message-ID: <517581CF.1060705@student.kit.edu> Date: Mon, 22 Apr 2013 20:30:39 +0200 From: Polina Goltsman User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: Roland Bless Subject: [P2PSIP] Certificates with multiple NodeIds X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 18:30:48 -0000 Hi, I have several questions regarding certificates with multiple NodeIDs. It seems that different parts in the draft contradict each other. First, section 6.6.1 defines requirements for future overlay link protocols. I suppose, that current overlay link protocol must meet these requirements. >Endpoint authentication When a node forms an association with another >endpoint, it MUST be possible to cryptographically verify that the >endpoint has a given Node-ID. Certificates with multiple NodeIDs sometimes violate this requirement. Unless a connection was formed as a result of exchanging Attach messages, it is impossible to associate an endpoint and its NodeID, which is the case when new node connects to BootstrapPeer. As a consequence several reload requirements are hard or even impossible to implement IMHO. The first requirement is that ConnectionTable SHOULD use some indexes instead of mapping NodeIds to (D)TLS Connections. The second requirement is in section 6.1.2 >If a node with a certificate with multiple Node-IDs attempts to route >a message other than a Ping or Attach through a node without performing >an Attach, the receiving node MUST reject the request with an >Error_Forbidden error. The node MUST implement support for returning >responses to a Ping or Attach request made by a joiningnode Attaching to >its responsible peer. The routing decisions must be made based on ForwardingHeader alone, and a ForwardingHeader does not contain information about type of the message, being sent. So this is practically NOT implementable. Section 3.2.1 Bullet 2 - about Clients, that connect to peers >A client connected this way using a certificate with only a single >Node-ID can proceed to use the connection without performing an Attach >(Section 6.5.1). A client wishing to connect using this mechanism with a >certificate with multiple Node-IDs can use a Ping (Section >6.5.3) to >probe the Node-ID of the node to which it is connected before doing the >Attach. As far as I understand, the procedure is as follows. The peer in the overlay, that listens on some known port, receives a connection from a client. This connection is in some unknown state because NodeId of at least one endpoint is not known. Then, the client must send a PingReq to the wildcard NodeId. It will be consumed by the peer as the next endpoint. Once the client has learned the peer's NodeID, it may send Attach, with, as I suppose, one static candidate. The peer must somehow find out that this static candidate is the connection, that is already formed and do not try to form it again. (Moreover the Attach section doesn't state what to do if the connection is already formed. This is also essential for the topology plugin, since some node may already have an opened connection with its new neighbour (consider peer-ready update), but in that case NodeIds are known and connection table can be searched). In my opinion, both client and peer could learn each other's NodeIDs from the Ping. Both PingReq and PingAns are signed and thus uniquely identify its senders. Since the connection to the client is in some unknown state and the destination was wildcard NodeID, the peer can assume that the sender of this message is another endpoint of this connection. The peer can also compare the client's certificate with the one, used to form TLS association. Another question, that I have, is shared-secret admission schemes for TLS. The TLS-PSK RFC states, that in case of TLS-PSK certificate exchange is optional. It is unclear from the RFC, that PSK ciphers with certificate exchange must be selected. It is also unclear, what should be sent in TLS-PSK identity field - username, NodeID, both or nothing. As of TLS-SRP RFC the client certificate cannot be requested. I also can imagine two possible solutions to the first problem. Solution 1(undesirable): Have a specified way of finding out peer's identity. If one of the certificates had multiple NodeIds, the first message, that is sent over this connection must identified both peers. This can be Ping, Attach or some dedicated "HelloReq" and it works as described above. After this exchange both peers must update their connection tables with NodeIDs of the endpoints. This solution is undesirable, since it increases message load on bootstrap nodes. Solution 2: Use TLS Extension to exchange not only the certificates, but also NodeID (in some form, e.g. the cert_hash_node_id form) during the TLS connection. The extension can use SupplementaryData [RFC 4680 ] to exchange the actual NodeID. For example: struct { SupplementalDataType supp_data_type; uint16 supp_data_length; select(SupplementalDataType) { case reload_signer_identity: SignerIdentity } } SupplementalDataEntry; The 2 extensions, that look most suitable are: 1. user-mapping [RFC 4681]. The information, that is sent, is exactly what is needed,but the RFC defines only client's authentication, not the server's. 2. serverautz/clientauthz [RFC 5878 ]. This RFC is not standard. I also want to propose more precise way for configuring TLS connection, by using a dedicated section and overlay-config for configuring underlay link layer for reload. For example, for TLS this would be: normal/PSK/SRP true/false ... ... Does it make sense? Regards, Polina From johnsonhammond1@hushmail.com Sat Apr 27 16:37:54 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C315A21F998E for ; Sat, 27 Apr 2013 16:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oQ7UNXEqOFj for ; Sat, 27 Apr 2013 16:37:54 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id 948FA21F9970 for ; Sat, 27 Apr 2013 16:37:54 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id 725143055C for ; Sat, 27 Apr 2013 17:31:20 +0000 (UTC) X-hush-relay-time: 213 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:31:20 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 38605E6736; Sat, 27 Apr 2013 17:31:20 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:31:20 -0400 To: p2psip@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427173120.38605E6736@smtp.hushmail.com> Subject: [P2PSIP] Biggest Fake Conference in Computer Science X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 23:37:54 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From petithug@acm.org Tue Apr 30 08:41:44 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC78E21F96AC for ; Tue, 30 Apr 2013 08:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwTBtfe4XdEQ for ; Tue, 30 Apr 2013 08:41:44 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id AFF2521F96F9 for ; Tue, 30 Apr 2013 08:41:42 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:1f:38ff:6934:881c:4dd9] (unknown [IPv6:2601:9:4bc0:1f:38ff:6934:881c:4dd9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 3528720199 for ; Tue, 30 Apr 2013 17:41:41 +0200 (CEST) Message-ID: <517FE61D.1090203@acm.org> Date: Tue, 30 Apr 2013 08:41:17 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: P2PSIP Mailing List References: <20130430033107.25648.97543.idtracker@ietfa.amsl.com> In-Reply-To: <20130430033107.25648.97543.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.1 X-Forwarded-Message-Id: <20130430033107.25648.97543.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Fwd: I-D Action: draft-petithuguenin-p2psip-reload-eku-01.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 15:41:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I just release a new version of this draft that was presented in Atlanta. The draft contains a new Implementation Status section, following the advices of draft-sheffer-running-code. Comments, questions and suggestions are welcome. Thanks. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-p2psip-reload-eku-01.txt Date: Mon, 29 Apr 2013 20:31:07 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using Extended Key Usage (EKU) for REsource LOcation And Discovery (RELOAD) X.509 Certificates Author(s) : Marc Petit-Huguenin Filename : draft-petithuguenin-p2psip-reload-eku-01.txt Pages : 5 Date : 2013-04-29 Abstract: This document describes an Extended Key Usage (EKU) X.509 certificate extension for restricting the usage of a certificate to a REsource LOcation And Discovery (RELOAD) overlay. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-petithuguenin-p2psip-reload-eku There's also a htmlized version available at: http://tools.ietf.org/html/draft-petithuguenin-p2psip-reload-eku-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-petithuguenin-p2psip-reload-eku-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRf+YcAAoJECnERZXWan7E3IcP/2OASAAQ8SpOaYvwPGNGaR8v 7/tS45rNfSjcd6mnXjZmiXYLkNJXxDWTTar1bALUkUA1jlBQjqg/seCbX2cIUoNr L/osXDC8ZljmfBBvriDiWjEQhhH58yQFTiA3zWYJy8Y4ahZP8/gpSM7d2JE5pdtH D2w2K2spzLGZykPoAOcczohimPtpCmPoIs09A+ZV/oq06UNVsD4V76g1VPUvBWxW Cljm0M4mtlRJnSLLVj+trpHqrV3frJUjXhNgcZebkAWKPpR91Lrk7o86A5KcbjTc T+5wygtwGZvao5sbxO4gswwXDptv/jh/ILVoFtXXDbRT28cUNdBe9Qv6XaZU/xJj knv2v9yAM5u7wEfyQ+ukbgI01IfJg0s8SNOEMK8ENZh007BTk6p2xj+ZqMJnH0Mm pmPYQCKcXbOfKvvjAc9iaGHlom9FsGYuRB1g8WRrTicfgBqGouYS+QPe6KsryCOC 5pDUtnZ523D9P4Selv+uofulLviH64njqnXkpG4/h9XmsKH3pHS8hDUgwq03qgcF xcRVeB13XSX3zZrR/ed7KXdGFgHX3sjD/P9y1U1ShUVXyy7U2N/hxBYlBqQrXxMi QpVQcY3rpYrG4HMFkFkSEKCioqqUkgazPtS09H7bTi4ylnxHlkK29pFI5fcheYf8 zhPfZFiM3Brq0usZk0Yk =IFP9 -----END PGP SIGNATURE-----