From melodysong@huawei.com Wed Dec 2 22:15:15 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702803A69D2 for ; Wed, 2 Dec 2009 22:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.382 X-Spam-Level: X-Spam-Status: No, score=0.382 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 iTg+df+OI3zu for ; Wed, 2 Dec 2009 22:15:13 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 3717B3A69DE for ; Wed, 2 Dec 2009 22:15:11 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU20005KC0SMU@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 03 Dec 2009 14:14:52 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU200191C0SCB@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 03 Dec 2009 14:14:52 +0800 (CST) Received: from s64081 ([10.164.12.24]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KU200CALC0R3N@szxml06-in.huawei.com> for p2psip@ietf.org; Thu, 03 Dec 2009 14:14:52 +0800 (CST) Date: Thu, 03 Dec 2009 14:14:52 +0800 From: Song Haibin To: 'P2PSIP WG' Message-id: <022001ca73df$ed7b1c10$180ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acpz3+0sSYS2CvceQnqc/eFg1JqTwA== Cc: "'David A. Bryan'" Subject: [P2PSIP] way forward with draft-matuszewski-p2psip-security-overview X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 03 Dec 2009 06:15:15 -0000 Hi all, The work on p2p security requirement/analysis has been going for some time and there were objections from the group to have a security requirement document but the feedback we got was that some sort of tutorial and analysis may be a good idea. As a results the authors changed the text taking out any normative text and making it more a tutorial and analysis document in http://tools.ietf.org/id/draft-matuszewski-p2psip-security-overview-01.txt . The document was presented at the last IETF meeting and the comments from the floor was that people do not understand what is the purpose of this work and therefore cannot agree if it should be taken by the working group. Another input was that p2prg has produce a general security document in http://tools.ietf.org/html/draft-irtf-p2prg-rtc-security-05 . In order to decide if and how to go forward we propose that the document taking under consideration the p2prg document will describe the specific security threats in P2PSIP and will provide analysis of the security risks in each of the P2PSIP layers. The purpose of the document will be to provide some hints about what to look at when developing new options or usages for P2PSIP or when looking at deploying p2psip solutions . Please think about it and provide feedback if you think this may be a good way to continue with this work. Thanks Haibin From melodysong@huawei.com Wed Dec 2 22:26:27 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8956D3A6805 for ; Wed, 2 Dec 2009 22:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.236 X-Spam-Level: X-Spam-Status: No, score=0.236 tagged_above=-999 required=5 tests=[AWL=0.731, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 yEzDm+hHl1zI for ; Wed, 2 Dec 2009 22:26:26 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 933BF3A67F5 for ; Wed, 2 Dec 2009 22:26:26 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU20007NCJGMU@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 03 Dec 2009 14:26:04 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU2001W8CJGCB@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 03 Dec 2009 14:26:04 +0800 (CST) Received: from s64081 ([10.164.12.24]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KU20017BCJG9F@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 03 Dec 2009 14:26:04 +0800 (CST) Date: Thu, 03 Dec 2009 14:26:01 +0800 From: Song Haibin To: 'P2PSIP WG' Message-id: <022601ca73e1$7c39d080$180ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acpz4Xv5lnoTp0MtTtGsjcV1NX70fA== Subject: [P2PSIP] way forward with draft-matuszewski-p2psip-security-overview X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 03 Dec 2009 06:26:27 -0000 Hi all, The work on p2p security requirement/analysis has been going for some time and there were objections from the group to have a security requirement document but the feedback we got was that some sort of tutorial and analysis may be a good idea. As a results the authors changed the text taking out any normative text and making it more a tutorial and analysis document in http://tools.ietf.org/id/draft-matuszewski-p2psip-security-overview-01.txt . The document was presented at the last IETF meeting and the comments from the floor was that people do not understand what is the purpose of this work and therefore cannot agree if it should be taken by the working group. Another input was that p2prg has produce a general security document in http://tools.ietf.org/html/draft-irtf-p2prg-rtc-security-05 . In order to decide if and how to go forward we propose that the document taking under consideration the p2prg document will describe the specific security threats in P2PSIP and will provide analysis of the security risks in each of the P2PSIP layers. The purpose of the document will be to provide some hints about what to look at when developing new options or usages for P2PSIP or when looking at deploying p2psip solutions . Please think about it and provide feedback if you think this may be a good way to continue with this work. Thanks Haibin From michaelc@IDSSOFTWARE.COM Sat Dec 5 07:30:54 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2B03A68A4 for ; Sat, 5 Dec 2009 07:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_50=0.001, SARE_SUB_ENC_UTF8=0.152] 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 xg31zX1FGSBB for ; Sat, 5 Dec 2009 07:30:53 -0800 (PST) Received: from smtpoutwbe07.prod.mesa1.secureserver.net (smtpoutwbe07.prod.mesa1.secureserver.net [208.109.78.209]) by core3.amsl.com (Postfix) with SMTP id 86E823A6819 for ; Sat, 5 Dec 2009 07:30:53 -0800 (PST) Received: (qmail 10023 invoked from network); 5 Dec 2009 15:30:40 -0000 Received: from unknown (HELO gem-wbe14.prod.mesa1.secureserver.net) (64.202.189.101) by smtpoutwbe07.prod.mesa1.secureserver.net with SMTP; 5 Dec 2009 15:30:39 -0000 Received: (qmail 3583 invoked by uid 99); 5 Dec 2009 15:30:39 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.1.29 Message-Id: <20091205083039.61e8c06078a3b23a733c71e914c0b9df.574b50007e.wbe@email.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Sat, 05 Dec 2009 08:30:39 -0700 Mime-Version: 1.0 Subject: [P2PSIP] =?utf-8?q?Should_remove_joining=5Fpeer=5Fid_and_leaving?= =?utf-8?q?=5Fpeer=5Fid?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 05 Dec 2009 15:30:54 -0000 Hi, What is the purpose of the NodeId in JoinReq and LeaveReq?=20 struct { NodeId joining_peer_id; opaque overlay_specific_data<0..2^16-1>; } JoinReq; public struct { NodeId leaving_peer_id; opaque overlay_specific_data<0..2^16-1>; } LeaveReq; The NodeId of the originating peer can be obtained from the signature. Unless the draft allows a peer to request a Join or Leave on behave of another peer, these two fields should be removed. Thanks --Michael From julian@orchidseed.org Sat Dec 5 10:47:35 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C9A3A67E7 for ; Sat, 5 Dec 2009 10:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 JVB85Z2rl-Eu for ; Sat, 5 Dec 2009 10:47:34 -0800 (PST) Received: from n13.c05.mtsvc.net (n13.c05.mtsvc.net [70.32.68.13]) by core3.amsl.com (Postfix) with ESMTP id A66123A672F for ; Sat, 5 Dec 2009 10:47:34 -0800 (PST) Received: from adsl-66-191-201.asm.bellsouth.net ([98.66.191.201]:32940 helo=[172.16.1.230]) by n13.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NGzfA-0001TE-5P; Sat, 05 Dec 2009 10:47:25 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: jc In-Reply-To: <20091205083039.61e8c06078a3b23a733c71e914c0b9df.574b50007e.wbe@email.secureserver.net> Date: Sat, 5 Dec 2009 13:47:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1BED0F0B-204F-43B9-8255-46BD0D7727C0@orchidseed.org> References: <20091205083039.61e8c06078a3b23a733c71e914c0b9df.574b50007e.wbe@email.secureserver.net> To: Michael Chen X-Mailer: Apple Mail (2.1077) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Should remove joining_peer_id and leaving_peer_id X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 05 Dec 2009 18:47:35 -0000 Because you MUST be directly connected to send these messages the field = is of no use. These shouldn't routed via third party. Julian On Dec 5, 2009, at 10:30 AM, Michael Chen wrote: > Hi, >=20 > What is the purpose of the NodeId in JoinReq and LeaveReq?=20 >=20 > struct { > NodeId joining_peer_id; > opaque overlay_specific_data<0..2^16-1>; > } JoinReq; >=20 > public struct { > NodeId leaving_peer_id; > opaque overlay_specific_data<0..2^16-1>; > } LeaveReq; >=20 > The NodeId of the originating peer can be obtained from the signature. > Unless the draft allows a peer to request a Join or Leave on behave of > another peer, these two fields should be removed. >=20 > Thanks >=20 > --Michael >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From davidbryan@gmail.com Mon Dec 7 07:07:19 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBFDA3A6A45 for ; Mon, 7 Dec 2009 07:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 j234KArgOpTe for ; Mon, 7 Dec 2009 07:07:19 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 379803A6803 for ; Mon, 7 Dec 2009 07:07:19 -0800 (PST) Received: by pzk6 with SMTP id 6so3953103pzk.29 for ; Mon, 07 Dec 2009 07:07:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ICta4FdG94+hbZ08LJzQPirYi/iHcSJIOgvyMBqBf/o=; b=l1ybsh7IcfvCK5/is8Y2aaeBSLEu6uzu8dde+Xf5Wx8CjoQEWsGAKUpbXJkOgJq+Hn RYdSDSGNiUpFIHbiifmqx711KBpg7M9/hvZaEFrWHJUzBSkkyU8qzxE8a89HnqF1vUtX BfV8Z+p8HEeOPMktMatOK3xjA0pOGahifXbJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=Q8v6H9nGF32hUSQ45BQ4Ph9x7dyZd0AxSPSjELq56Y28LPFluCo7jCmgYUQdSjLqQm T6kmsGSBnTVLDB51xOTh8LKG65crPm3/xu6oxXzv7dvu5WWB1zHw4B5+ta/iwRe76SLt yOI9isW6ykh46A8mm+g5wLqRHnY0ruQ6oEZJI= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.142.6.11 with SMTP id 11mr732542wff.68.1260198429324; Mon, 07 Dec 2009 07:07:09 -0800 (PST) Date: Mon, 7 Dec 2009 10:07:09 -0500 X-Google-Sender-Auth: f19c028a9eb7448c Message-ID: <8b2769930912070707p1a1ae49bs8dfa3ad49e8ecbd4@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] List hum to adopt draft-maenpaa-p2psip-service-discovery-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 07 Dec 2009 15:07:20 -0000 We've had a request from the authors of draft-maenpaa-p2psip-service-discovery-00 to ask for a list hum to adopt this draft as a WG item to fulfill the new milestone for a WG item on service discovery that was approved at the Hiroshima meeting. So, we are taking a hum on list of the group if they would like to see this draft (http://tools.ietf.org/html/draft-maenpaa-p2psip-service-discovery-00) adopted to meet that new milestone. We'll leave things open for comments until Tuesday, December 15th. As usual, please send comments either way to the list. Thanks, David (as chair) From gonzalo.camarillo@ericsson.com Mon Dec 7 07:53:21 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37A433A6A6A for ; Mon, 7 Dec 2009 07:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 74zTlxxdTHDd for ; Mon, 7 Dec 2009 07:53:20 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 22DFA3A6A45 for ; Mon, 7 Dec 2009 07:53:19 -0800 (PST) X-AuditID: c1b4fb3e-b7bc9ae000005cee-04-4b1d1f682ee3 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 9C.C5.23790.86F1D1B4; Mon, 7 Dec 2009 16:29:44 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 16:29:36 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 16:29:36 +0100 Message-ID: <4B1D1F60.1040201@ericsson.com> Date: Mon, 07 Dec 2009 17:29:36 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "David A. Bryan" References: <8b2769930912070707p1a1ae49bs8dfa3ad49e8ecbd4@mail.gmail.com> In-Reply-To: <8b2769930912070707p1a1ae49bs8dfa3ad49e8ecbd4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2009 15:29:36.0522 (UTC) FILETIME=[158016A0:01CA7752] X-Brightmail-Tracker: AAAAAA== Cc: P2PSIP WG Subject: Re: [P2PSIP] List hum to adopt draft-maenpaa-p2psip-service-discovery-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 07 Dec 2009 15:53:21 -0000 Hi, the advantage of this approach is that it is a generic mechanism that has already been successfully deployed in OpenDHT. Also, it can be easily integrated in RELOAD through the use of Store and Fetch requests. Cheers, Gonzalo David A. Bryan wrote: > We've had a request from the authors of > draft-maenpaa-p2psip-service-discovery-00 to ask for a list hum to > adopt this draft as a WG item to fulfill the new milestone for a WG > item on service discovery that was approved at the Hiroshima meeting. > > So, we are taking a hum on list of the group if they would like to see > this draft (http://tools.ietf.org/html/draft-maenpaa-p2psip-service-discovery-00) > adopted to meet that new milestone. We'll leave things open for > comments until Tuesday, December 15th. As usual, please send comments > either way to the list. > > Thanks, > > David (as chair) > From davidbryan@gmail.com Mon Dec 7 09:58:09 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722283A68DB for ; Mon, 7 Dec 2009 09:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 RBu8STon+Mno for ; Mon, 7 Dec 2009 09:58:08 -0800 (PST) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.211.171]) by core3.amsl.com (Postfix) with ESMTP id D63733A685B for ; Mon, 7 Dec 2009 09:58:07 -0800 (PST) Received: by ywh1 with SMTP id 1so10195550ywh.18 for ; Mon, 07 Dec 2009 09:57:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4U6C7G4M6wTehajjP82bxF61T0gAq0kl15TkFhr58qU=; b=eOwW17LN99MK2PbV9Oh6uwW/lwKvjPW+fWh/1KjrWkeuR52FNh+S+MC8UnTW5LkrAp GYOI6KelTuhuP3IrxDGSDS8/kcGPRNt3utEfpI5VFF3ZwoB4QNIRRg8kSr6QTe3rPpYh oTPzuqyRGndPnnn4qhdtkAw/wh4UXdE6OtJwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=AOT9+jfJeYs5D1moEiWyZJ/oAkgdbT8Til5VRq0RQyHP+3rS7ZgtYsUTeQCCJpU4Zy gYGUTxeeFuiCmMzbZZsLKJfCQcUiX58daYQIGLESulztV+3BZ24E5RJPJ1ikkGfUljkN EWZGgZahIpPpoVSDvyC0qnvIFZrRZ3WDJAXu0= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.151.95.8 with SMTP id x8mr11935215ybl.26.1260208674372; Mon, 07 Dec 2009 09:57:54 -0800 (PST) Date: Mon, 7 Dec 2009 12:57:54 -0500 X-Google-Sender-Auth: 62f884e8dc406d97 Message-ID: <8b2769930912070957x4f8dc91av13c6088134d96146@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 07 Dec 2009 17:58:09 -0000 (Just to be clear, everything here is being sent by me as an individual. I=92ve asked Brian to make any decisions about discussions of these concerns that might arise on list or in meetings.) So, with a new baby and lots of work outside the IETF, I=92ve been very busy, and haven=92t had a chance to make a full, complete formal review of the newest (-06) revision, but I have identified some ongoing major (design/architectural) concerns, some minor concerns (questions, layout, etc.) and some nits I noticed in my quick read of -06 that I=92d like to raise/share now. I may have more if/when I get time to do a full review. Overall, I think the document is moving along, and getting much better. I feel it still needs some more editorial work, some clarifications, and more group discussion on a few critical design decisions, and I=92d like to see a few more full reviews such as the one Jouni did before I would be able to personally support moving it through WGLC, but I think it is getting closer. Major concerns: Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts I=92ve raised this issue before, but I=92m hoping that now that people have had a bit more time to think about all the use cases, see what it means in the real world, etc., there might be a bit more support for modifying the requirement for TLS/DTLS. TLS/DTLS makes sense in some cases, but if we are expecting RELOAD to be reusable, it is clear to me that it does not make sense in all cases. It was familiar to the editors, and well understood, so it made sense as a proposal, but I disagree with it being the mandatory/only solution. I am not advocating we allow unsecured system. There needs to be a way to do that for development/debugging, but you can do that with a null cipher, so that concern is addressed. Instead my concerns are two-fold: 1) TLS/DTLS is too heavy for query-response systems using direct-response routing. 2) There are applications that may want to secure at a different level or using a different technology. First, looking at DTLS for query-response systems using direct routing. A bit of background: Clearly, RELOAD should work for query-response systems, where the only use of the DHT is to obtain a small item of information (e.g. obtaining a registration or a certificate). Similarly, while there has been discussion about whether the current individual draft is the appropriate mechanism, the group hummed in Minneapolis to include direct routing in the protocol, and in SF the hum was repeated, with strong consensus to include it as an extension and ensure base draft doesn=92t preclude it. Establishing a TLS/DTLS connection is a very heavy way to establish a connection between two peers for a simple response, particularly if using direct where the connection is used only to convey that response. (7 messages for DTLS [1]) With recursive response, it makes sense, since the connection is persistent, but a lighter mechanism (for example, including the requestors public cert in the request, and having the responder encrypt the reply) is far more appropriate for a direct routed response. The current draft mandates TLS/DTLS and only TLS/DTLS, leading to an artificially high cost for direct response routing. Based on my work with potential real-world users of P2PSIP going back almost 4 years, request-response is a very likely scenario. While the TLS-PSK/TLS-SRP stuff helps here, other mechanisms would still be more efficient. Similarly, we should allow alternate mechanisms: Even if one is using the recursive response approach for routing, there may be other architectures. A system of persistent peers (for example provisioned set-top boxes using reload to share information) may have ISP assigned IDs, and persistent peers connected to one another, and use hardware based encryption, VPNs, etc. between the peers. There are many ways to encrypt a connection, and mandating one and only one seems inappropriate. A better design is to provide a mechanism in the draft for an alternate encryption technique, recommend DTLS, provide information, and require some encryption be used. While someone could choose to build without encryption, the argument seems weak. They could also just ignore the requirement in the first place. In my opinion, we are more likely to have problems later (extensions that will have to modify the original draft to use a different security mechanism, deployments that are =93almost=94 RELOAD but with different security etc.) if we proceed with the current draft=92s approach. [1] Modadugu, N., Rescorla, E., "The Design and Implementation of Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004. Concern 2: Alternate Mechanism Needed for Attach-Lite I indicated above why TLS/DTLS was overly expensive, particularly for direct response. Direct response is particularly likely to be used in closed environments (server farms using P2PSIP to distribute information, managed networks, ad-hoc, etc.), and these same deployments are among the most likely to use Attach-lite, as they may want to avoid full ICE. However, in section 5.5.2.3, TLS connectivity checks are required as the mechanism to check rechability. This is a great shortcut when TLS/DTLS is used, but an alternate mechanism needs to exist for systems opting not to use TLS/DTLS. Concern 3: TURN server usage/location not proved =93not harmful=94 Section 8 of the draft defines a TURN server usage, which relies on having an accurate turnDensity defined. As the draft itself notes, if the density is too high, the process of finding a server becomes very expensive. In the Hiroshima meeting, the editors asserted that they had run experiments that showed it was =93ok and worked fine=94, but declined to provide or share any results. While I understand why (it's a pain to document this kind of thing), this is a critical part of the deployment, and the suggested algorithm and approach is not, as far as know, deployed or documented/analyzed anywhere in the P2P literature. In the absence of some reference or an analysis or simulation shared with the group, I=92m concerned about the potential impact this will have on deployments, and don't think we should bless something this unproven. I would recommend either some study or analysis is presented by the editors supporting that this works and isn't too bad when you get it wrong, or we move this to an extension (or merge it in with the ongoing work on service discovery) Haibin Song suggested something similar onlist: http://www.ietf.org/mail-archive/web/p2psip/current/msg05278.html Concern 4: Fixed Length (128 bit) Peer-ids Limit Reuse and are Unnecessary For some reason, the draft mandates 128 bit peer-ids. As far as I can see, there is no good reason for this (it doesn=92t even appear resource IDs are limited to the same space), and I don't recall this ever being discussed by the WG. In fact, this seems like a bad idea from a reuse and extensibility perspective. Many other DHTs existing today use other spaces (for example original Chord's 160 bit), and reuse of existing code should be a priority. (for example being able to take an existing, debugged DHT code and plug it into RELOAD) I understand there is a routing efficiency argument to be made here for fixed length fields, so this is a good discussion for the list, but my opinion is that the small performance improvement isn't worth the cost in terms of flexibility and protocol reuse, and that peer-id=92s should be variable length. Concern 5: The Private ID concept should not be in the base draft (breaks direct response routing and relay peer routing) While the idea of the Private ID concept (5.1.3) could break routing other than recursive response, if there are concerns about state being maintained. The current proposal is very minimal (a few lines), and doesn=92t specify what happens if a message with a different response routing type. If the response will be routed directly or via a relay, what happens to that state? It would be better to place this optimization into an extension. That way, an overlay using a different routing technique can prohibit the optimization, or at least the extension can think through the proper way to handle expiring the state, etc. Including in the base draft causes problems with direct response support, which the group has mandated the draft support. Concern 6: Compressed destinations in via-list should not be in the base dr= aft In section 5.3.2.2 there is discussion of via-list compression and adding an opaque field to represent the list only valid for that peer. The same concerns I have in Concern 5 apply here. This should also be an extension. Concern 7: Document shouldn't specify a particular bootstrap configuration mechanism 3.6.1 describes (in a very cursory way) a specific configuration mechanism for obtaining configuration. There are many ways to handle provisioning, and I don't recall the group ever discussing and blessing this particular mechanism. In fact, I recall there was discussion that this should be out of the scope of this document. Minor Concerns / Questions: Minor Concern 1: In 5.1.1, first bullet, why is this silently dropped? Might make sense, but not clear from the text. Can you explain? Minor Concern 2: In 5.2.1, where and why did 3 seconds and 4 times come from? Can we cite to provide a reason for this? Minor Concern 3: In 5.3.2.1 there is very little explanation about why a Config_Update needs to be accepted. Have we thought through the possible attack vectors of this? Can this text be clarified? Nits: Nit 1: The document needs to be spell-checked. While most from the last version are fixed, I saw a few just on a casual read that should be fixed before we move forward. (perfom at the end of 3.5, theAIMD in Appendix B, protcol in the IANA port registrations, imporvements in the acknowledgements, etc.) Nit 2: In 5.3.2.2 the structure field is destination_data, but the descriptive text is destination_value. They should agree. Similarly for node/peer as a destination type. Nit 3: In 1.2, the description of storage component says =93It talks directly to the Topology Plugin to manage data replication=94 and topology plugin component description says =93It uses the Message Transport component to send and receive overlay management messages, to the Storage component to manage data replication=94. This seems a bit unclear and circular for the overall architecture description. Nit 4: In 1.2.5, second paragraph, it is described as =93fairly generic=94. That seems like kind of a meaningless term. Nit 5: In terminology, "host" is used to describe client and peer. Does that make sense? There is not a one-to-one host-peer relationship. Thanks, David (as individual) From michaelc@IDSSOFTWARE.COM Mon Dec 7 22:02:41 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2AC33A698D for ; Mon, 7 Dec 2009 22:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.309 X-Spam-Level: X-Spam-Status: No, score=0.309 tagged_above=-999 required=5 tests=[AWL=-0.964, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 CDvQ-mUpDNgu for ; Mon, 7 Dec 2009 22:02:41 -0800 (PST) Received: from smtpoutwbe07.prod.mesa1.secureserver.net (smtpoutwbe07.prod.mesa1.secureserver.net [208.109.78.209]) by core3.amsl.com (Postfix) with SMTP id 057683A6986 for ; Mon, 7 Dec 2009 22:02:39 -0800 (PST) Received: (qmail 30838 invoked from network); 8 Dec 2009 06:02:29 -0000 Received: from unknown (HELO gem-wbe40.prod.mesa1.secureserver.net) (64.202.189.119) by smtpoutwbe07.prod.mesa1.secureserver.net with SMTP; 8 Dec 2009 06:02:29 -0000 Received: (qmail 7988 invoked by uid 99); 8 Dec 2009 06:02:29 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.1.29 Message-Id: <20091207230229.61e8c06078a3b23a733c71e914c0b9df.b8210bdc88.wbe@email.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Mon, 07 Dec 2009 23:02:29 -0700 Mime-Version: 1.0 Subject: [P2PSIP] Interleaved two-phase admit X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 08 Dec 2009 06:02:41 -0000
Hi,

Draft-06 section 9.4 describes h= ow a peer (JP) join the overlay. From the admitting peer (AP) point of view= , it is a two-phase process:

Phase-1: AP receives = the JOIN request from JP and replies. Then AP send a series of STORE to to = JP to forward resources that will belong to JP.

Ph= ase-2: When the last STORE from AP to JP is acknowledged by JP, AP can now = internally take JP as its predecessor and send a UPDATE indicates just that= .

The problem is what if two peers X and Y happen = to join the overlay via AP at the same time, and their two-phase admit on t= he AP side interleaved like this:

Phase-1-for-X
Phase-1-for-Y
Phase-2-for-Y
Phase-2-for-X
=

If their Chord ring positions are X < Y < AP, Y w= ill join successfully, but AP might have incorrectly forwarded to X some of= the resources that should have belong to Y. Also, at Phase-2-for-X, AP wil= l discover that X is no longer AP's immediate predecessor (Y is), so AP sho= uld not admit X at all.

What should AP do?

If AP still send the UPDATE to X which shows Y is now X's= immediate sucessor, then X should regard the JOIN failed. X will then try = to attach to Y and JOIN via Y. Have I answer my own question? :)
=
--Michael
 From fluffy@cisco.com Mon Dec 7 22:25:00 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14143A683F for ; Mon, 7 Dec 2009 22:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.51 X-Spam-Level: X-Spam-Status: No, score=-106.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ZQ8mTN3Euy3U for ; Mon, 7 Dec 2009 22:24:57 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 2F26A3A6995 for ; Mon, 7 Dec 2009 22:24:47 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEeAHUurRN+K/2dsb2JhbADBLJZ3hDIE X-IronPort-AV: E=Sophos;i="4.47,360,1257120000"; d="scan'208";a="59223992" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 08 Dec 2009 06:24:27 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB86ORRW006143 for ; Tue, 8 Dec 2009 06:24:27 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Mon, 7 Dec 2009 23:24:25 -0700 Message-Id: <8D2CCB23-7FE8-4708-9DD1-5C78954B118D@cisco.com> To: P2PSIP WG Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [P2PSIP] Thanks for RELOAD comments X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 08 Dec 2009 06:25:00 -0000 I just wanted to tell everyone who had sent comments on the base draft = thank you very much. I've been watching them stack up in my inbox and = there is some great input there. None of the authors of the draft have = really dug into making the fixes yet. I expect that will start after the = 11th and will be somewhat slow going during the holidays.=20 Cullen From ari.keranen@nomadiclab.com Tue Dec 8 01:08:22 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7387428C0FD for ; Tue, 8 Dec 2009 01:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 afANlYKKwgd3 for ; Tue, 8 Dec 2009 01:08:21 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 986BA28C0D8 for ; Tue, 8 Dec 2009 01:08:21 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 839931EF223; Tue, 8 Dec 2009 11:08:10 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from n2.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfb0Dw6oOw5W; Tue, 8 Dec 2009 11:08:09 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by n2.nomadiclab.com (Postfix) with ESMTP id E2FB81EF20F; Tue, 8 Dec 2009 11:08:09 +0200 (EET) Message-ID: <4B1E1779.1070000@nomadiclab.com> Date: Tue, 08 Dec 2009 11:08:09 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "David A. Bryan" References: <8b2769930912070707p1a1ae49bs8dfa3ad49e8ecbd4@mail.gmail.com> In-Reply-To: <8b2769930912070707p1a1ae49bs8dfa3ad49e8ecbd4@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] List hum to adopt draft-maenpaa-p2psip-service-discovery-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 08 Dec 2009 09:08:22 -0000 Hi, David A. Bryan wrote: > So, we are taking a hum on list of the group if they would like to see > this draft (http://tools.ietf.org/html/draft-maenpaa-p2psip-service-discovery-00) > adopted to meet that new milestone. +1 for adopting this draft. The service discovery method proposed in the draft seems good and has even research and implementation experience showing that it works. Cheers, Ari From erkkih@ee.oulu.fi Tue Dec 8 01:14:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63AA828C10D for ; Tue, 8 Dec 2009 01:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 tdmS5h1nLCFS for ; Tue, 8 Dec 2009 01:14:30 -0800 (PST) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by core3.amsl.com (Postfix) with ESMTP id B5DAD28C103 for ; Tue, 8 Dec 2009 01:14:29 -0800 (PST) Received: from stekt1 (stekt1 [130.231.60.41]) by ee.oulu.fi (8.14.3/8.14.3) with ESMTP id nB89EE4G019569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Dec 2009 11:14:14 +0200 (EET) Date: Tue, 8 Dec 2009 11:14:13 +0200 (EET) From: Erkki Harjula X-X-Sender: erkkih@stekt1 To: "David A. Bryan" In-Reply-To: <8b2769930912070707p1a1ae49bs8dfa3ad49e8ecbd4@mail.gmail.com> Message-ID: References: <8b2769930912070707p1a1ae49bs8dfa3ad49e8ecbd4@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: P2PSIP WG Subject: Re: [P2PSIP] List hum to adopt draft-maenpaa-p2psip-service-discovery-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 08 Dec 2009 09:14:31 -0000 +1 from here too. As I said before, service discovery is one of the most important features of a P2P network. Implementing a prototype seems also straightforward. -Erkki On Mon, 7 Dec 2009, David A. Bryan wrote: > We've had a request from the authors of > draft-maenpaa-p2psip-service-discovery-00 to ask for a list hum to > adopt this draft as a WG item to fulfill the new milestone for a WG > item on service discovery that was approved at the Hiroshima meeting. > > So, we are taking a hum on list of the group if they would like to see > this draft (http://tools.ietf.org/html/draft-maenpaa-p2psip-service-discovery-00) > adopted to meet that new milestone. We'll leave things open for > comments until Tuesday, December 15th. As usual, please send comments > either way to the list. > > Thanks, > > David (as chair) From davidbryan@gmail.com Tue Dec 8 07:36:27 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ABF33A6832 for ; Tue, 8 Dec 2009 07:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 WkLDqyNXK-Wx for ; Tue, 8 Dec 2009 07:36:26 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id A23C93A6803 for ; Tue, 8 Dec 2009 07:36:26 -0800 (PST) Received: by yxe30 with SMTP id 30so5941316yxe.29 for ; Tue, 08 Dec 2009 07:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=tJ5tvZfvUT9EG+ih0iB0sMaWyhu5fyXolv8G+SuT7NQ=; b=N99C/hOI0Z9/W+TG28v7J4GddPouXmE7qN4Sx8jfV5JcCU/vGgiDCv6kq0xd+5uuGY TlavMPdByhIsY/gtMnsuEsghm3FbSvjZrPxzHvo+MLLmt863IRA5tDyfEtzTjREcdHzi C509HMXK+MNgP6JJWE1eogml4fZ0Kw86NA+lo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=EVsXNpNQRxgokH/G7PdA4xzKgCMiYxbZTw97xQhBq7wJ5Bm1WlHEjc9somQMm4TBvQ YajrlZQLILIqlV/ySb/T8TEDQS4YdYtq5QG5+deQtLgzr7ZiigRiua2XWO7q8JhV3IpP +scVmYLpLF1RUF4bxXUZ6nYzfPRKOp0/YAwkA= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.7.6 with SMTP id 6mr14080804ybg.261.1260286573481; Tue, 08 Dec 2009 07:36:13 -0800 (PST) In-Reply-To: References: <8b2769930912070707p1a1ae49bs8dfa3ad49e8ecbd4@mail.gmail.com> Date: Tue, 8 Dec 2009 10:36:13 -0500 X-Google-Sender-Auth: abe3a14bd655cd97 Message-ID: <8b2769930912080736y7d18150vd4a4fff3dd16863e@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [P2PSIP] List hum to adopt draft-maenpaa-p2psip-service-discovery-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 08 Dec 2009 15:36:27 -0000 As an individual, I support this as well. +1. David On Tue, Dec 8, 2009 at 4:14 AM, Erkki Harjula wrote: > > +1 from here too. > > As I said before, service discovery is one of the most important features of > a P2P network. Implementing a prototype seems also straightforward. > > -Erkki > > > On Mon, 7 Dec 2009, David A. Bryan wrote: > >> We've had a request from the authors of >> draft-maenpaa-p2psip-service-discovery-00 to ask for a list hum to >> adopt this draft as a WG item to fulfill the new milestone for a WG >> item on service discovery that was approved at the Hiroshima meeting. >> >> So, we are taking a hum on list of the group if they would like to see >> this draft >> (http://tools.ietf.org/html/draft-maenpaa-p2psip-service-discovery-00) >> adopted to meet that new milestone. We'll leave things open for >> comments until Tuesday, December 15th. As usual, please send comments >> either way to the list. >> >> Thanks, >> >> David (as chair) > From root@core3.amsl.com Tue Dec 8 07:45:01 2009 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A23183A63D3; Tue, 8 Dec 2009 07:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091208154501.A23183A63D3@core3.amsl.com> Date: Tue, 8 Dec 2009 07:45:01 -0800 (PST) Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-self-tuning-00.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 08 Dec 2009 15:45:01 -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 : A Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD) Author(s) : J. Maenpaa, et al. Filename : draft-ietf-p2psip-self-tuning-00.txt Pages : 20 Date : 2009-12-08 REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay, and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 June 11, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-self-tuning-00.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-self-tuning-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-08074013.I-D@ietf.org> --NextPart-- From hsinnrei@adobe.com Tue Dec 8 08:03:27 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E3C28C1C4 for ; Tue, 8 Dec 2009 08:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 v+dMKSCQpJEJ for ; Tue, 8 Dec 2009 08:03:26 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by core3.amsl.com (Postfix) with ESMTP id 485E528C1E2 for ; Tue, 8 Dec 2009 08:03:26 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKSx54w3AOU+louPheQfASttHfS3lvvKWH@postini.com; Tue, 08 Dec 2009 08:03:16 PST Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id nB8Ftm18011844; Tue, 8 Dec 2009 07:55:48 -0800 (PST) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id nB8G0D0F003195; Tue, 8 Dec 2009 08:03:14 -0800 (PST) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Tue, 8 Dec 2009 08:01:35 -0800 From: Henry Sinnreich To: "David A. Bryan" , P2PSIP WG Date: Tue, 8 Dec 2009 08:01:33 -0800 Thread-Topic: [P2PSIP] List hum to adopt draft-maenpaa-p2psip-service-discovery-00 Thread-Index: Acp4HDEhJe/tkc0FSbe8Z9XZof1+kAAA4UaI Message-ID: In-Reply-To: <8b2769930912080736y7d18150vd4a4fff3dd16863e@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C743D47D7781hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [P2PSIP] List hum to adopt draft-maenpaa-p2psip-service-discovery-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 08 Dec 2009 16:03:27 -0000 --_000_C743D47D7781hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please add me to the count: +1 Thanks, Henry > On Mon, 7 Dec 2009, David A. Bryan wrote: > >> We've had a request from the authors of >> draft-maenpaa-p2psip-service-discovery-00 to ask for a list hum to >> adopt this draft as a WG item to fulfill the new milestone for a WG >> item on service discovery that was approved at the Hiroshima meeting. >> >> So, we are taking a hum on list of the group if they would like to see >> this draft >> (http://tools.ietf.org/html/draft-maenpaa-p2psip-service-discovery-00) >> adopted to meet that new milestone. We'll leave things open for >> comments until Tuesday, December 15th. As usual, please send comments >> either way to the list. >> >> Thanks, >> >> David (as chair) > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip --_000_C743D47D7781hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [P2PSIP] List hum to adopt draft-maenpaa-p2psip-service-discover= y-00 Please add me to the count: +1

Thanks, Henry


> On Mon, 7 Dec 2009, David A. Bryan wrote:
>
>> We've had a request from the authors of
>> draft-maenpaa-p2psip-service-discovery-00 to ask for a list hum to=
>> adopt this draft as a WG item to fulfill the new milestone for a W= G
>> item on service discovery that was approved at the Hiroshima meeti= ng.
>>
>> So, we are taking a hum on list of the group if they would like to= see
>> this draft
>> (http://tools.ietf.org/html/draft-maenpaa-p2psip-service-dis= covery-00)
>> adopted to meet that new milestone. We'll leave things open for >> comments until Tuesday, December 15th. As usual, please send comme= nts
>> either way to the list.
>>
>> Thanks,
>>
>> David (as chair)
>
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.o= rg/mailman/listinfo/p2psip

--_000_C743D47D7781hsinnreiadobecom_-- From fluffy@cisco.com Tue Dec 8 15:30:05 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAEA53A68E4 for ; Tue, 8 Dec 2009 15:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.537 X-Spam-Level: X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 U4KHy-ibqfMY for ; Tue, 8 Dec 2009 15:30:04 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E0D633A694E for ; Tue, 8 Dec 2009 15:30:03 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIJwHkurRN+J/2dsb2JhbADBVpc1hDIE X-IronPort-AV: E=Sophos;i="4.47,364,1257120000"; d="scan'208";a="59777339" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 08 Dec 2009 23:29:53 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nB8NTqaK003832 for ; Tue, 8 Dec 2009 23:29:53 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Tue, 8 Dec 2009 16:29:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <47DDC444-ED8D-44B9-8357-D94EFE4DB99A@cisco.com> References: To: P2PSIP WG X-Mailer: Apple Mail (2.1077) Subject: Re: [P2PSIP] List hum to adopt draft-maenpaa-p2psip-service-discovery-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 08 Dec 2009 23:30:06 -0000 +1 from me too. I think this draft is a good basis for powerful yet easy = to implement discovery mechanism.=20 Cullen On Dec 8, 2009, at 9:01 AM, Henry Sinnreich wrote: > Please add me to the count: +1 >=20 > Thanks, Henry >=20 >=20 > > On Mon, 7 Dec 2009, David A. Bryan wrote: > > > >> We've had a request from the authors of > >> draft-maenpaa-p2psip-service-discovery-00 to ask for a list hum to > >> adopt this draft as a WG item to fulfill the new milestone for a WG > >> item on service discovery that was approved at the Hiroshima = meeting. > >> > >> So, we are taking a hum on list of the group if they would like to = see > >> this draft > >> = (http://tools.ietf.org/html/draft-maenpaa-p2psip-service-discovery-00) > >> adopted to meet that new milestone. We'll leave things open for > >> comments until Tuesday, December 15th. As usual, please send = comments > >> either way to the list. > >> > >> Thanks, > >> > >> David (as chair) > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From root@core3.amsl.com Tue Dec 8 18:15:03 2009 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5F59E3A68B5; Tue, 8 Dec 2009 18:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091209021503.5F59E3A68B5@core3.amsl.com> Date: Tue, 8 Dec 2009 18:15:02 -0800 (PST) Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-diagnostics-02.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 09 Dec 2009 02:15:03 -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 : P2PSIP Overlay Diagnostics Author(s) : S. Yongchao, et al. Filename : draft-ietf-p2psip-diagnostics-02.txt Pages : 28 Date : 2009-12-08 This document describes mechanisms for P2PSIP diagnostics. It describes the usage scenarios and defines several simple methods for performing diagnostics in P2PSIP overlay networks. It also describes the diagnostic information which is useful for the connection and node status monitoring. The methods and message formats are specified as extensions to P2PSIP base protocol RELOAD. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 June 12, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-diagnostics-02.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-diagnostics-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-08181102.I-D@ietf.org> --NextPart-- From ari.keranen@nomadiclab.com Wed Dec 9 03:36:09 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86D3228C113 for ; Wed, 9 Dec 2009 03:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 CVprLbuReAdn for ; Wed, 9 Dec 2009 03:36:08 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 1932828C107 for ; Wed, 9 Dec 2009 03:36:07 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 86CFA1EF1EB; Wed, 9 Dec 2009 13:35:55 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from n2.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TniAQn4pUQDC; Wed, 9 Dec 2009 13:35:54 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by n2.nomadiclab.com (Postfix) with ESMTP id E7B211EF12F; Wed, 9 Dec 2009 13:35:54 +0200 (EET) Message-ID: <4B1F8B9A.9010205@nomadiclab.com> Date: Wed, 09 Dec 2009 13:35:54 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "p2psip@ietf.org" References: <4B0FAEAC.40104@ericsson.com> In-Reply-To: <4B0FAEAC.40104@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] Review of RELOAD base draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 09 Dec 2009 11:36:09 -0000 Hi, We had another closer look at especially sections 5 and 9 of the draft; comments follow. Page 59, Section "5.5.1.1. Request Definition" Is there a need to send foundations if there is only single stream and component ID? Page 62, Section "5.5.1.5. Gathering Candidates" "An agent MUST implement ICE-tcp [I-D.ietf-mmusic-ice], and MUST gather at least one UDP and one TCP host candidate for RELOAD and for SIP." (1) Why ICE-tcp is a MUST? Wouldn't UDP be enough for many cases and ICE-tcp could be a "SHOULD"? (2) Why base draft defines that one must gather candidates for SIP? Should this be in the SIP usage draft instead and this section could talk about candidates for applications/usages in general? There seem to be quite a few references to SIP usage elsewhere in the draft too. Page 62, Section "5.5.1.6. Encoding the Attach Message" "Instead of actually encoding an SDP, the candidate information (IP address and port and transport protocol, priority, foundation, component ID, type and related address) is carried within the attributes of the Attach request or its response" Component ID is not in the attributes, and probably foundation shouldn't be either. Page 62, Section "5.5.1.8. Role Determination" "The connectivity checks MUST still contain the ICE-CONTROLLED and ICE-CONTROLLING attributes, however, even though the role reversal capability for which they are defined will never be needed with RELOAD. This is to allow for a common codebase between ICE for RELOAD and ICE for SDP." Should you rather just generate the value for the ICE-CONTROLL{ED,ING} attribute locally instead of sending it in the messages? This would allow for using common code base and still make the message simpler/save bandwidth. Page 64, Section "5.5.2. AttachLite" As the ICE-TCP draft says, "Unlike UDP, there [is] no lite implementation defined for TCP", so this section may need some additional text about TCP lite candidates. Page 66, Section "5.5.3. AppAttach" "The AppAttach request and its response contain an application attribute, with a value of SIP or RELOAD, which indicates what protocol is to be run over the connection." (1) Isn't normal Attach used for RELOAD instead of AppAttach? And you seem to have SIP usage specific text also here. (2) The text talks about AppAttachReq and AppAttachAns whereas the struct is called AppAttachReqAns. There are similar issues with the other req/ans structures too. Page 67, Section "5.5.3.1. Request Definition" "application A 16-bit port number. This port number represents the IANA registered port of the protocol that is going to be sent on this connection." What about applications without an IANA registered port number? Page 68, Section "5.5.5.2 Response Definition" "response_id: A randomly generated 64-bit response ID. This is used to distinguish Ping responses." Why aren't transaction ID and sender peer-ID enough for distinguishing responses? Page 71, Section "5.6.2. Reliability for Unreliable Links" This whole section, especially with retransmission, flow control and fragmentation support, adds quite a bit complexity to the link layer implementation. This, and all the NAT traversal complexity, could be avoided by running RELOAD over TCP over NAT traversing connection (such as one created by Teredo or HIP). Page 86, Section "6.4.1.2. Response Definition" "If any type of request tries to access a data kind that the node does not know about, an Error_Unknown_Kind MUST be generated." While the previous section, page 82 says: "Implementations SHOULD reject requests corresponding to unknown kinds unless specifically configured otherwise." These two seem to conflict. I would keep the ability to configure an overlay to accept unknown Kinds. Later (e.g., page 89) this seems to be the wording that is used. Page 99, Section "9.4 Joining" "In order to populate its neighbor table, JP sends a Ping via the bootstrap node directed at Resource-ID n+1 (directly after its own Resource-ID). This allows it to discover its own successor. Call that node p0. It then sends a ping to p0+1 to discover its successor (p1). This process can be repeated to discover as many successors as desired." Could the AP send a copy of its neighbor table (e.g., in an Update message) to the JP? The JP could then initialize its neighbor table using the received entries and there would be no need to send Ping requests. Page 100, Section "9.5. Routing Attaches" "If a peer is unable to successfully Attach with a peer that should be in its neighborhood, it MUST locate either a TURN server or another peer in the overlay, but not in its neighborhood, through which it can exchange messages with its neighbor peer." (1) The Attach, if ICE was used, should have already included TURN candidates (if any were available), so using TURN here again is likely to fail. What if a peer is still unable to exchange messages with it's should-be-neighbor? (2) What is the method for using "another peer" (but not TURN server) for exchanging messages with the neighbor peer? Page 103, Section "9.6.3. Receiving Updates" "The UpdateReq defines peers that indicate a neighbor table further away from N than some of its neighbor table. Note that merely receiving peers further away does not demonstrate this, since the update could be from a node far away from N. Rather, the peers would need to bracket N." What is meant by "need to bracket N"? Also, the other sentences of this bullet point seem a bit confusing. Page 106, Section "9.7. Route Query" The struct uses "next_id" and the following text "next_peer". Finally, one more nit: The word "extension" seems to be misspelled as "extention" couple of times in the draft. Cheers, Ari Keranen Jouni Maenpaa From skminh@gmail.com Wed Dec 9 05:16:06 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9163828C16F for ; Wed, 9 Dec 2009 05:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Yfm6GZn1wvLe for ; Wed, 9 Dec 2009 05:15:55 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id ED27D28C118 for ; Wed, 9 Dec 2009 05:15:24 -0800 (PST) Received: by yxe30 with SMTP id 30so6993289yxe.29 for ; Wed, 09 Dec 2009 05:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=qKhrcOOvaxxI60jG2E8bC+B0dchhvpTG2ay6NIgkfFE=; b=NQ2SKVtAYS+GblLc1pZPj6WvsQ6pq3M77dNAibXnjVyWpkmglDT5rklLr+XJ8xD+ot CxkZ+Kt0xGp9oJbVYsF/Xqo3CvtVDcAomHEOO3iVumorqLfcNhGTJNIObIOfpOMo1OsW q3dvfEJJnNuLLQXs8OZgmwMK88ieNZY+MSQsw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SYnwVt5UEvetbA4rlFGkBIPwaovLn72AHiV1W4WC/p1488xgry0nw+zsRPBzKvFZMr SIdCn9lFgL+fO96qxQP0rRTMqqxs4ceh2/6uGoyr1u8iwqCbQGWXoKpdVNlAa7mXwE61 Fv1qLBFan54kibM85j6tXAORXYcw/XvFV1t5E= MIME-Version: 1.0 Received: by 10.91.18.24 with SMTP id v24mr1783794agi.61.1260364508255; Wed, 09 Dec 2009 05:15:08 -0800 (PST) In-Reply-To: <47DDC444-ED8D-44B9-8357-D94EFE4DB99A@cisco.com> References: <47DDC444-ED8D-44B9-8357-D94EFE4DB99A@cisco.com> Date: Wed, 9 Dec 2009 14:15:08 +0100 Message-ID: <66dcf31f0912090515g77f0378cwb7db18f6f38672df@mail.gmail.com> From: minh nguyen To: Cullen Jennings Content-Type: multipart/alternative; boundary=0016e6409812cd5612047a4b7a1c Cc: P2PSIP WG Subject: Re: [P2PSIP] List hum to adopt draft-maenpaa-p2psip-service-discovery-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 09 Dec 2009 13:16:06 -0000 --0016e6409812cd5612047a4b7a1c Content-Type: text/plain; charset=UTF-8 +1 from me too, please add to the count Service discovery is an important aspect and ReDiR also seems good Thanks, -Minh On Wed, Dec 9, 2009 at 12:29 AM, Cullen Jennings wrote: > > +1 from me too. I think this draft is a good basis for powerful yet easy to > implement discovery mechanism. > > Cullen > > On Dec 8, 2009, at 9:01 AM, Henry Sinnreich wrote: > > > Please add me to the count: +1 > > > > Thanks, Henry > > > > > > > On Mon, 7 Dec 2009, David A. Bryan wrote: > > > > > >> We've had a request from the authors of > > >> draft-maenpaa-p2psip-service-discovery-00 to ask for a list hum to > > >> adopt this draft as a WG item to fulfill the new milestone for a WG > > >> item on service discovery that was approved at the Hiroshima meeting. > > >> > > >> So, we are taking a hum on list of the group if they would like to see > > >> this draft > > >> (http://tools.ietf.org/html/draft-maenpaa-p2psip-service-discovery-00 > ) > > >> adopted to meet that new milestone. We'll leave things open for > > >> comments until Tuesday, December 15th. As usual, please send comments > > >> either way to the list. > > >> > > >> Thanks, > > >> > > >> David (as chair) > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > --0016e6409812cd5612047a4b7a1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 from me too, please add to the count
Service discovery is an importan= t aspect and ReDiR also seems good

Thanks,
-Minh

On Wed, Dec 9, 2009 at 12:29 AM, Cullen Jennings <fluffy@cisco.com><= /span> wrote:

+1 from me too. I think this draft is a good basis for powerful yet easy to= implement discovery mechanism.

Cullen <in my individual contributor role>

On Dec 8, 2009, at 9:01 AM, Henry Sinnreich wrote:

> Please add me to the count: +1
>
> Thanks, Henry
>
>
> > On Mon, 7 Dec 2009, David A. Bryan wrote:
> >
> >> We've had a request from the authors of
> >> draft-maenpaa-p2psip-service-discovery-00 to ask for a list h= um to
> >> adopt this draft as a WG item to fulfill the new milestone fo= r a WG
> >> item on service discovery that was approved at the Hiroshima = meeting.
> >>
> >> So, we are taking a hum on list of the group if they would li= ke to see
> >> this draft
> >> (http://tools.ietf.org/html/draft-mae= npaa-p2psip-service-discovery-00)
> >> adopted to meet that new milestone. We'll leave things op= en for
> >> comments until Tuesday, December 15th. As usual, please send = comments
> >> either way to the list.
> >>
> >> Thanks,
> >>
> >> David (as chair)
> >
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www.ietf.org/mailman/listinfo/p2psip
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
= https://www.ietf.org/mailman/listinfo/p2psip
--0016e6409812cd5612047a4b7a1c-- From joakim.koskela@hiit.fi Wed Dec 9 05:18:20 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D75AA28C118 for ; Wed, 9 Dec 2009 05:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ttyM7FTPcHxQ for ; Wed, 9 Dec 2009 05:18:20 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id E8EB428C10B for ; Wed, 9 Dec 2009 05:18:19 -0800 (PST) Received: from ip94.infrahip.net (ip94.infrahip.net [193.167.187.94]) by argo.otaverkko.fi (Postfix) with ESMTP id 6AB3925ED1D for ; Wed, 9 Dec 2009 15:18:08 +0200 (EET) From: Joakim Koskela Organization: Helsinki Institute for Information Technology To: p2psip@ietf.org Date: Wed, 9 Dec 2009 15:16:52 +0200 User-Agent: KMail/1.9.9 References: <47DDC444-ED8D-44B9-8357-D94EFE4DB99A@cisco.com> <66dcf31f0912090515g77f0378cwb7db18f6f38672df@mail.gmail.com> In-Reply-To: <66dcf31f0912090515g77f0378cwb7db18f6f38672df@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200912091516.52102.joakim.koskela@hiit.fi> Subject: Re: [P2PSIP] List hum to adopt draft-maenpaa-p2psip-service-discovery-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 09 Dec 2009 13:18:21 -0000 +1 for me as well. br, j On Wednesday 09 December 2009 15:15:08 minh nguyen wrote: > +1 from me too, please add to the count > Service discovery is an important aspect and ReDiR also seems good > > Thanks, > -Minh > From slavitch@gmail.com Wed Dec 9 09:20:41 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55F423A6819 for ; Wed, 9 Dec 2009 09:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 J3ehuZZhPlZT for ; Wed, 9 Dec 2009 09:20:40 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 191AE3A659B for ; Wed, 9 Dec 2009 09:20:39 -0800 (PST) Received: by bwz23 with SMTP id 23so5598097bwz.29 for ; Wed, 09 Dec 2009 09:20:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:from:in-reply-to:mime-version:date :received:message-id:subject:cc:content-type; bh=R16yS/Sh/gJqeznUpA1vjXrIyxU7pqzy2VaWQFqNhpY=; b=pb4bsfPtlgsEWskmW17Q5LGnTiBMhws3ZD346ch18356JrnAPZTyas9kV2cJLBT4B1 OepaxydJNmyqO0HOnkwm2DfO9j20c0xxxTkMyMti3vRTXDUxNgA51VBo0m90QTeWSXj1 YR6aXuR0jzCR6r5BWSJiYA79cywqaGZaH5Lec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:from:in-reply-to:mime-version:date:message-id:subject:cc :content-type; b=to+Oz8dTOg3MBCZP6gk9EoyaX4ln0OusWh3a/qNWICKv97lpqwSeByWQCQVUNZkUm6 9FOCMVse0Nhh4mUZbmdUlslo5JOaiMZq1qDbv7rr/OqGCyg8o0VCCDfa+wIxmC0P1L+v 8cmU67Pd8o26vmGirnzKMJ1Pai/gTzDQKvQXE= References: <47DDC444-ED8D-44B9-8357-D94EFE4DB99A@cisco.com> <66dcf31f0912090515g77f0378cwb7db18f6f38672df@mail.gmail.com> <200912091516.52102.joakim.koskela@hiit.fi> From: Michael Slavitch In-Reply-To: <200912091516.52102.joakim.koskela@hiit.fi> Mime-Version: 1.0 (iPhone Mail 7D11) Date: Wed, 9 Dec 2009 12:20:17 -0500 Received: by 10.204.32.199 with SMTP id e7mr10349140bkd.28.1260379224549; Wed, 09 Dec 2009 09:20:24 -0800 (PST) Message-ID: <-6284476940453942637@unknownmsgid> Cc: "p2psip@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: Re: [P2PSIP] List hum to adopt draft-maenpaa-p2psip-service-discovery-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 09 Dec 2009 17:20:41 -0000 +1. On 2009-12-09, at 8:16 AM, Joakim Koskela wrote: > > +1 for me as well. > > br, j > > On Wednesday 09 December 2009 15:15:08 minh nguyen wrote: >> +1 from me too, please add to the count >> Service discovery is an important aspect and ReDiR also seems good >> >> Thanks, >> -Minh >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From jani.hautakorpi@ericsson.com Wed Dec 9 22:59:40 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA893A692D for ; Wed, 9 Dec 2009 22:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 iUU2x442saOg for ; Wed, 9 Dec 2009 22:59:39 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id DF24A3A6840 for ; Wed, 9 Dec 2009 22:59:38 -0800 (PST) X-AuditID: c1b4fb3c-b7b8dae0000047e9-47-4b209bf203a1 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 39.D1.18409.2FB902B4; Thu, 10 Dec 2009 07:57:54 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 07:56:39 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 07:56:38 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A8009232D; Thu, 10 Dec 2009 08:56:38 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7325D21A31; Thu, 10 Dec 2009 08:56:38 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2E212219D0; Thu, 10 Dec 2009 08:56:38 +0200 (EET) Message-ID: <4B209BA5.7020404@ericsson.com> Date: Thu, 10 Dec 2009 08:56:37 +0200 From: "Jani Hautakorpi (JO/LMF)" Organization: Ericsson User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Michael Slavitch References: <47DDC444-ED8D-44B9-8357-D94EFE4DB99A@cisco.com> <66dcf31f0912090515g77f0378cwb7db18f6f38672df@mail.gmail.com> <200912091516.52102.joakim.koskela@hiit.fi> <-6284476940453942637@unknownmsgid> In-Reply-To: <-6284476940453942637@unknownmsgid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 10 Dec 2009 06:56:38.0915 (UTC) FILETIME=[EBDB3530:01CA7965] X-Brightmail-Tracker: AAAAAA== Cc: , "p2psip@ietf.org" Subject: Re: [P2PSIP] List hum to adopt draft-maenpaa-p2psip-service-discovery-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 10 Dec 2009 06:59:40 -0000 +1 ReDiR is simple enough to be standardized, yet effective. -- Jani Michael Slavitch wrote: > +1. > > On 2009-12-09, at 8:16 AM, Joakim Koskela > wrote: > >> +1 for me as well. >> >> br, j >> >> On Wednesday 09 December 2009 15:15:08 minh nguyen wrote: >>> +1 from me too, please add to the count >>> Service discovery is an important aspect and ReDiR also seems good >>> >>> Thanks, >>> -Minh >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From victor.pascual.avila@gmail.com Thu Dec 10 05:44:15 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03CBB3A6976 for ; Thu, 10 Dec 2009 05:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] 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 ZbL-exZYJ2UR for ; Thu, 10 Dec 2009 05:44:14 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id E1C323A6934 for ; Thu, 10 Dec 2009 05:44:13 -0800 (PST) Received: by bwz23 with SMTP id 23so6253888bwz.29 for ; Thu, 10 Dec 2009 05:43:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=qny5PgLmE5HgQ9AiytIMf3jsqrVIy7vsHqiB+eDMoVc=; b=uccMgBbVDOejuLyrNXVq4hh4kir4iG472JrRe6PVF7sV/7mf+XPlmTOY5j3C8AYHk+ aFkms+2qG/4Od9BSVE3zcbvcgWFRFoJg0uKYBhs7+p33qxR9orT/sBstVZJj7tTYPhjM X+Ju3ftU9kMOO8V7hEAmoHDqqSMk//8qywZvk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=YKBNW46bLbbY2oJ5quQcbS0DF8RLn4q4G1/ArBNTNkKmpGSiIMm7VeAJcYcXlDRxDF JS+s0qVe6crA2UjPDBhdJWkNf98Lqrjc+u06SliJsSGTiFJZBDXbRf0995SZtKaPZ0c3 i49HQVDXp6dXoOmxKe2CuNm7DMR2oR3YDBsk0= MIME-Version: 1.0 Received: by 10.204.155.73 with SMTP id r9mr7503376bkw.14.1260452638598; Thu, 10 Dec 2009 05:43:58 -0800 (PST) In-Reply-To: <4B209BA5.7020404@ericsson.com> References: <47DDC444-ED8D-44B9-8357-D94EFE4DB99A@cisco.com> <66dcf31f0912090515g77f0378cwb7db18f6f38672df@mail.gmail.com> <200912091516.52102.joakim.koskela@hiit.fi> <-6284476940453942637@unknownmsgid> <4B209BA5.7020404@ericsson.com> Date: Thu, 10 Dec 2009 14:43:58 +0100 Message-ID: <618e24240912100543s3e653ed5v7b48e2705d0772f4@mail.gmail.com> From: Victor Pascual Avila To: "p2psip@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [P2PSIP] List hum to adopt draft-maenpaa-p2psip-service-discovery-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 10 Dec 2009 13:44:15 -0000 On Thu, Dec 10, 2009 at 7:56 AM, Jani Hautakorpi (JO/LMF) wrote: > +1 > > ReDiR is simple enough to be standardized, yet effective. I support this as well. --=20 Victor Pascual =C3=81vila From Even.roni@huawei.com Thu Dec 10 13:34:56 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F7B3A693F for ; Thu, 10 Dec 2009 13:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 mZDCnMUuJW7B for ; Thu, 10 Dec 2009 13:34:55 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 13DCA3A68E7 for ; Thu, 10 Dec 2009 13:34:55 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUG0087VH9LDZ@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 11 Dec 2009 05:34:33 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUG001U7H9L5S@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 11 Dec 2009 05:34:33 +0800 (CST) Received: from windows8d787f9 (bzq-79-176-46-225.red.bezeqint.net [79.176.46.225]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUG00DDIH8OKC@szxml01-in.huawei.com> for p2psip@ietf.org; Fri, 11 Dec 2009 05:34:33 +0800 (CST) Date: Thu, 10 Dec 2009 23:30:54 +0200 From: Roni Even In-reply-to: To: p2psip@ietf.org Message-id: <009601ca79e0$26dfb230$749f1690$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acpn3b0CU4iXXz3f+kW8iRFTFA+WPwSAgZ7g References: Subject: [P2PSIP] comments on draft-ietf-p2psip-base-06 in WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 10 Dec 2009 21:34:56 -0000 Hi, I read the draft and came up with the following concerns. I did not review all other comments on the list but it looks like some of them were mentioned by others According to section 1 Reload is based on the concepts introduced in ietf-p2psip-concepts. The concept draft is currently expired and I noticed some contradictions between the two drafts. I think that the reload draft should progress with the concept draft. According to the concepts draft "The P2PSIP WG will not standardize how the peer-ID and the credentials are obtained, but merely standardize at least one acceptable format for each. To ensure interoperability, it is expected that at least one of these formats will be specified as "mandatory-to-implement"." According to RELOAD the node-id is mandated as a 128 bit value. According to the concept draft it can be as mandatory to implement format but others should be allowed. I also think that section 5.4.1 allows for different node-id length (see "o The length of the Resource-IDs and Node-IDs. For DHTs, the hash algorithm to compute the hash of an identifier." In section 5.2 on symmetric recursive routing says that "An overlay may be configured to use alternative routing algorithms, and alternative routing algorithms may be selected on a per-message basis." Yet I noted that in some of the text the assumption is that symmetric recursive is the only routing algorithm. For example in section 5.2.2 it says "When a peer sends a response to a request, it MUST construct the destination list by reversing the order of the entries on the via list.". This is true only for recursive routing. Another example is that the text allows an intermediary peer to decide to keep a per transaction state (see section 5.1.2) which will work for recursive routing but may break other routing algorithms. If the text in section 5.2 is the objective I suggest that in 5.2.2 it will say that in the case of recursive routing this procedure must be used. I also suggest that since 5.2.2 allows alternative algorithms on per-message basis than the requesting peer should be allowed to prevent state keeping by intermediary peers in order to support other routing mechanisms. The intermediary peers do not know what routing is used and may choose wrong behavior. I noticed that the overlay link layer MUST use TLS/DTLS. I am not sure where the requirement to mandate TLS and DTLS is coming from, more specifically the requirement to encrypt the signaling. One of the objectives of RELOAD is to minimize the burden of becoming a peer and TLS with encryption does not help that. I think that TLS or DTLS can be specified as mandatory to implement security but optional to use based on the security level required by the implementation which may chose different security that may be available in other layers of the network. If there are specific security requirements based on a specific usage than the requirements to use TLS/DTLS should be in the usage. I looked at draft-irtf-p2prg-rtc-security and did not see that TLS/DTLS must be used. I see cases like when using routing mechanisms which are not recursive that some of the paths will not need TLS. Section 3.3 mentions that client promoting to peers may be used for routing, in the case of passive promotion the establishment of trust relation may bring different requirements. So I think that mandating using one solution does not fit all. Section 3.6.1 details the initial configuration establishment, from the text it this paragraph and in section 3.6 above it looks like this is the only allowed procedure, was that the meaning or is that an example. Looking at section 10 I am not sure what a new configuration file means, is this new values to the elements, in this case how can the configuration document defined in section 10 be extended with new elements that may be needed for new features. Section 8 discusses TURN server usage. I was wondering if a peer can be a TURN server it can also be a "supernode" or a relay peer, so why not publish the general capability that this node is publicly reachable. Roni Even From bbl@lowekamp.net Thu Dec 10 13:56:53 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340913A6B58 for ; Thu, 10 Dec 2009 13:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 oRaZTU2+ZLHe for ; Thu, 10 Dec 2009 13:56:52 -0800 (PST) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 1FD993A692C for ; Thu, 10 Dec 2009 13:56:51 -0800 (PST) Received: by fxm10 with SMTP id 10so404649fxm.14 for ; Thu, 10 Dec 2009 13:56:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.81.20 with SMTP id i20mr173132mul.98.1260482195055; Thu, 10 Dec 2009 13:56:35 -0800 (PST) Date: Thu, 10 Dec 2009 13:56:35 -0800 Message-ID: From: Bruce Lowekamp To: p2psip@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [P2PSIP] WGLC comment on routing in draft-ietf-p2psip-base-06 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 10 Dec 2009 21:56:53 -0000 First, I apologize for not being able to contribute to the mailing list recently. Due to the nature of my work at Skype Labs, I was not able to contribute to the IETF at the time. The nature of my work at Skype has now changed and I now hope to be able to return to contributing on a regular basis. On the issue of the WGLC for the RELOAD base draft, I am concerned that the issue of how routing is done has not been adequately addressed by this draft. I had hoped that draft-jiang-p2psip-relay would make more progress in addressing these issues together with work on the base draft, but that progress has been slow. I don't think we can move forward on the base draft until we address how to resolve these issues and are sure we have an appropriate way forward from the combination of the base draft and that (or any other) extension drafts that emerge to address these issues. Looking at the problem space, there are three types of deployments we need to address 1) overlays where the majority of peers are behind NATs 2) overlays where no peers are behind NAT/firewalls (provider provisioned) 3) overlays where there is an effort to select peers that are not behind NATs, but connectivity is not assured Currently the draft uses SRR, which addresses all of these cases. However, it imposes a significant penalty on cases where SRR isn't needed because there are no NATs in the way, i.e. raw IP addresses could be used. The analysis of these problems presented so far has tended to look at the query-response pattern, but there are actually many applications in a P2P overlay that are not search---where a node's location is known in advance. In that case, there is a clearer argument for having an IP address to directly contact the target node, and being able to use the Node-ID as a backup. Even in a "classic" p2psip-style lookup followed by an AppAttach, SRR-only routing results in at least 4 log(N) traversals through the overlay, whereas if DRR/RP is available, only one is required. With that said, I stand by my earlier comments on the importance of not introducing additional complexity into the base protocol. But we can't stick our heads in the sand, either. I propose we should ensure that the base draft address scenarios (1) and (2) above in efficient ways. In other words, retain SRR, but specify a way of encoding IP & Node ID together in a Destination so that messages can be sent that way. Import flags so that direct routing can be used and address the state issue on intermediate peers. Scenario (3), where it may not be possible to know in advance whether direct or overlay routing is needed, is more complicated and needs to be outside the scope of the base draft. However, we do need to make sure that there is nothing fundamentally flawed in the base protocol that prevents adaptive or variable routing being done as an extension. As has often been discussed in this group, SRR has the advantage that it always works. That means RELOAD needs to support it, but if we expect RELOAD to be adopted in the real world, we need to make sure it allows the optimizations that can (and should) be done across the full range of deployment possibilities. Bruce From sa2086@columbia.edu Thu Dec 10 15:12:32 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959E53A68FD for ; Thu, 10 Dec 2009 15:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 gYnNZkKPH03e for ; Thu, 10 Dec 2009 15:12:31 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 26E9C3A68BB for ; Thu, 10 Dec 2009 15:12:30 -0800 (PST) Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nBANCH4K006721; Thu, 10 Dec 2009 18:12:17 -0500 (EST) Received: from mango.cc.columbia.edu (localhost [127.0.0.1]) by mango.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nBANCGA6023445; Thu, 10 Dec 2009 18:12:16 -0500 (EST) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.3/8.14.3/Submit) with ESMTP id nBANCGLL023441; Thu, 10 Dec 2009 18:12:16 -0500 (EST) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Thu, 10 Dec 2009 18:12:16 -0500 (EST) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: Bruce Lowekamp In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] WGLC comment on routing in draft-ietf-p2psip-base-06 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 10 Dec 2009 23:12:33 -0000 I agree with what you said. One way to achieve direct response is to encode ICE candidates as a forwarding option in request and response. In fact, P2PP did allow encoding ICE candidates in every request and response for speeding up overlay traversals for the scenarios you described. If forwarding headers are used to encode ICE candidates, I suggest that they be defined in a separate document. For scenario 3, node state likely becomes a non-issue with parallel searches and iterative routing. Practically, there is always the backup of relying on the central server after a certain number of retries, a solution adopted by Skype. In general, deployment specific optimizations (which will likely be many), should be defined in separate documents. regards, salman On Thu, 10 Dec 2009, Bruce Lowekamp wrote: > First, I apologize for not being able to contribute to the mailing > list recently. Due to the nature of my work at Skype Labs, I was not > able to contribute to the IETF at the time. The nature of my work at > Skype has now changed and I now hope to be able to return to > contributing on a regular basis. > > On the issue of the WGLC for the RELOAD base draft, I am concerned > that the issue of how routing is done has not been adequately > addressed by this draft. I had hoped that draft-jiang-p2psip-relay > would make more progress in addressing these issues together with work > on the base draft, but that progress has been slow. I don't think we > can move forward on the base draft until we address how to resolve > these issues and are sure we have an appropriate way forward from the > combination of the base draft and that (or any other) extension drafts > that emerge to address these issues. > > Looking at the problem space, there are three types of deployments we > need to address > > 1) overlays where the majority of peers are behind NATs > 2) overlays where no peers are behind NAT/firewalls (provider provisioned) > 3) overlays where there is an effort to select peers that are not > behind NATs, but connectivity is not assured > > Currently the draft uses SRR, which addresses all of these cases. > However, it imposes a significant penalty on cases where SRR isn't > needed because there are no NATs in the way, i.e. raw IP addresses > could be used. The analysis of these problems presented so far has > tended to look at the query-response pattern, but there are actually > many applications in a P2P overlay that are not search---where a > node's location is known in advance. In that case, there is a clearer > argument for having an IP address to directly contact the target node, > and being able to use the Node-ID as a backup. Even in a "classic" > p2psip-style lookup followed by an AppAttach, SRR-only routing results > in at least 4 log(N) traversals through the overlay, whereas if DRR/RP > is available, only one is required. > > With that said, I stand by my earlier comments on the importance of > not introducing additional complexity into the base protocol. But we > can't stick our heads in the sand, either. > > I propose we should ensure that the base draft address scenarios (1) > and (2) above in efficient ways. In other words, retain SRR, but > specify a way of encoding IP & Node ID together in a Destination so > that messages can be sent that way. Import flags so that direct > routing can be used and address the state issue on intermediate peers. > > Scenario (3), where it may not be possible to know in advance whether > direct or overlay routing is needed, is more complicated and needs to > be outside the scope of the base draft. However, we do need to make > sure that there is nothing fundamentally flawed in the base protocol > that prevents adaptive or variable routing being done as an extension. > > As has often been discussed in this group, SRR has the advantage that > it always works. That means RELOAD needs to support it, but if we > expect RELOAD to be adopted in the real world, we need to make sure it > allows the optimizations that can (and should) be done across the full > range of deployment possibilities. > > Bruce > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From ari.keranen@nomadiclab.com Fri Dec 11 02:40:11 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0A73A688F for ; Fri, 11 Dec 2009 02:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 s7sTaN0wOrqG for ; Fri, 11 Dec 2009 02:40:11 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 1F37D3A659C for ; Fri, 11 Dec 2009 02:40:10 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E98201EF132; Fri, 11 Dec 2009 12:39:57 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from n2.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id razxkdzSKYAD; Fri, 11 Dec 2009 12:39:57 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by n2.nomadiclab.com (Postfix) with ESMTP id 57BBC1EF12F; Fri, 11 Dec 2009 12:39:57 +0200 (EET) Message-ID: <4B22217D.1080301@nomadiclab.com> Date: Fri, 11 Dec 2009 12:39:57 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: P2PSIP WG References: <8b2769930912070957x4f8dc91av13c6088134d96146@mail.gmail.com> In-Reply-To: <8b2769930912070957x4f8dc91av13c6088134d96146@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 11 Dec 2009 10:40:12 -0000 Hi, David A. Bryan wrote: > Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts > > I’ve raised this issue before, but I’m hoping that now that people > have had a bit more time to think about all the use cases, see what > it means in the real world, etc., there might be a bit more support > for modifying the requirement for TLS/DTLS. TLS/DTLS makes sense in > some cases, but if we are expecting RELOAD to be reusable, it is > clear to me that it does not make sense in all cases. It was familiar > to the editors, and well understood, so it made sense as a proposal, > but I disagree with it being the mandatory/only solution. I fully agree with David that making (D)TLS mandatory is not a good idea, especially concerning re-usability of the protocol in scenarios where you already have similar security features provided by the underlying system. Cheers, Ari From julian@orchidseed.org Fri Dec 11 07:26:53 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1056F3A6825 for ; Fri, 11 Dec 2009 07:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 CLm1+v2ZbuGK for ; Fri, 11 Dec 2009 07:26:52 -0800 (PST) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id 2F54C3A679C for ; Fri, 11 Dec 2009 07:26:52 -0800 (PST) Received: from adsl-66-230-71.asm.bellsouth.net ([98.66.230.71]:41410 helo=[172.16.1.233]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NJ7OA-0004g8-TV; Fri, 11 Dec 2009 07:26:40 -0800 References: <8b2769930912070957x4f8dc91av13c6088134d96146@mail.gmail.com> <4B22217D.1080301@nomadiclab.com> Message-Id: <18A74C73-D8EE-4B48-A1F1-33A5216960FA@orchidseed.org> From: jc To: Ari Keranen In-Reply-To: <4B22217D.1080301@nomadiclab.com> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Fri, 11 Dec 2009 10:26:31 -0500 X-Authenticated-User: 72798 julian@orchidseed.org Cc: P2PSIP WG Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 11 Dec 2009 15:26:53 -0000 I said this about 7 months ago and I still agree that there should be =20= no mandatory transport layer encryption as this should be provided =20 outside of the scope of this draft. Julian Sent from my iPhone On Dec 11, 2009, at 5:39 AM, Ari Keranen =20= wrote: > Hi, > > David A. Bryan wrote: >> Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts >> I=E2=80=99ve raised this issue before, but I=E2=80=99m hoping that = now that =20 >> people have had a bit more time to think about all the use cases, =20 >> see what it means in the real world, etc., there might be a bit mo=20 >> re support for modifying the requirement for TLS/DTLS. TLS/DTLS ma=20 >> kes sense in some cases, but if we are expecting RELOAD to be reus=20 >> able, it is clear to me that it does not make sense in all cases. =20 >> It was familiar >> to the editors, and well understood, so it made sense as a proposal, >> but I disagree with it being the mandatory/only solution. > > I fully agree with David that making (D)TLS mandatory is not a good > idea, especially concerning re-usability of the protocol in scenarios > where you already have similar security features provided by the > underlying system. > > > Cheers, > Ari > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From michaelc@IDSSOFTWARE.COM Fri Dec 11 09:49:26 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 951A83A6853 for ; Fri, 11 Dec 2009 09:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 tv6oL62l5Pc2 for ; Fri, 11 Dec 2009 09:49:25 -0800 (PST) Received: from smtpoutwbe01.prod.mesa1.secureserver.net (smtpoutwbe01.prod.mesa1.secureserver.net [208.109.78.112]) by core3.amsl.com (Postfix) with SMTP id BB8FF3A6844 for ; Fri, 11 Dec 2009 09:49:25 -0800 (PST) Received: (qmail 3657 invoked from network); 11 Dec 2009 17:49:13 -0000 Received: from unknown (HELO gem-wbe24.prod.mesa1.secureserver.net) (64.202.189.227) by smtpoutwbe01.prod.mesa1.secureserver.net with SMTP; 11 Dec 2009 17:49:12 -0000 Received: (qmail 2296 invoked by uid 99); 11 Dec 2009 17:49:12 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 12.175.188.225 User-Agent: Web-Based Email 5.1.30 Message-Id: <20091211104912.61e8c06078a3b23a733c71e914c0b9df.1bfb02afc4.wbe@email.secureserver.net> From: "Michael Chen" To: "P2PSIP WG" Date: Fri, 11 Dec 2009 10:49:12 -0700 Mime-Version: 1.0 Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 11 Dec 2009 17:49:26 -0000
I too agree with the three of you. D/TLS should be optional. = Several of my previous post voice concerns about redundancy and efficiency = of the transport layer.

--Michael
-------- Original Message --------
Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as
part of the WGLC
From: jc <julian@orchidseed.org>
Date: Fri, December 11, 2009 7:26 am
To: Ari Keranen <ari.keranen@nomadiclab.com>
Cc: P2PSIP WG <p2psip@ietf.org>

I said this about 7 months ago and I still agree that there should be
no mandatory transport layer encryption as this should be provided
outside of the scope of this draft.

Julian

Sent from my iPhone

On Dec 11, 2009, at 5:39 AM, Ari Keranen <ari.keranen@nomadiclab.com>=
wrote:

> Hi,
>
> David A. Bryan wrote:
>> Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts
>> I=E2=80=99ve raised this issue before, but I=E2=80=99m hoping that= now that
>> people have had a bit more time to think about all the use cases, =
>> see what it means in the real world, etc., there might be a bit mo=
>> re support for modifying the requirement for TLS/DTLS. TLS/DTLS ma=
>> kes sense in some cases, but if we are expecting RELOAD to be reus=
>> able, it is clear to me that it does not make sense in all cases. =
>> It was familiar
>> to the editors, and well understood, so it made sense as a proposa= l,
>> but I disagree with it being the mandatory/only solution.
>
> I fully agree with David that making (D)TLS mandatory is not a good > idea, especially concerning re-usability of the protocol in scenarios<= br> > where you already have similar security features provided by the
> underlying system.
>
>
> Cheers,
> Ari
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
= https://www.ietf.org/mailman/listinfo/p2psip
 From br@brianrosen.net Fri Dec 11 10:16:59 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B79A73A69A0 for ; Fri, 11 Dec 2009 10:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] 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 6ALNWkmSGa6W for ; Fri, 11 Dec 2009 10:16:58 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 9CCE83A699D for ; Fri, 11 Dec 2009 10:16:58 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.231]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NJA2f-0005AK-Tx; Fri, 11 Dec 2009 12:16:38 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 11 Dec 2009 13:16:39 -0500 From: Brian Rosen To: Michael Chen , P2PSIP WG Message-ID: Thread-Topic: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC Thread-Index: Acp6jhUDRXnah4JFG0KdZ/hQ8XCbCw== In-Reply-To: <20091211104912.61e8c06078a3b23a733c71e914c0b9df.1bfb02afc4.wbe@email.secureserver.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 11 Dec 2009 18:16:59 -0000 I disagree. =20 The problem is that we have a whole lot of history and experience. The experience is that if we don't insist, and make security integral to th= e protocol, it doesn't get implemented and we have a majority of insecure systems. If we do insist, the cost of the security is reasonable: the dire predictions that it's too costly, too hard, ... don't happen. No amount of text explaining when the security mechanism is or isn't appropriate works. You have to make the mechanism integral to the operatio= n of the protocol, as we have done here. I don't see anything in p2psip which would be different then our history an= d experience. The costs aren't as bad as you fear. The probability of nearl= y every system being implemented insecurely is very high if you make it optional. Don't do that. Brian On 12/11/09 12:49 PM, "Michael Chen" wrote: > I too agree with the three of you. D/TLS should be optional. Several of m= y > previous post voice concerns about redundancy and efficiency of the trans= port > layer. >=20 > --Michael >> -------- Original Message -------- >> Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as >> part of the WGLC >> From: jc >> Date: Fri, December 11, 2009 7:26 am >> To: Ari Keranen >> Cc: P2PSIP WG >>=20 >> I said this about 7 months ago and I still agree that there should be >> no mandatory transport layer encryption as this should be provided >> outside of the scope of this draft. >>=20 >> Julian >>=20 >> Sent from my iPhone >>=20 >> On Dec 11, 2009, at 5:39 AM, Ari Keranen >> wrote: >>=20 >>> Hi, >>>=20 >>> David A. Bryan wrote: >>>> Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts >>>> I=B9ve raised this issue before, but I=B9m hoping that now that >>>> people have had a bit more time to think about all the use cases, >>>> see what it means in the real world, etc., there might be a bit mo >>>> re support for modifying the requirement for TLS/DTLS. TLS/DTLS ma >>>> kes sense in some cases, but if we are expecting RELOAD to be reus >>>> able, it is clear to me that it does not make sense in all cases. >>>> It was familiar >>>> to the editors, and well understood, so it made sense as a proposal, >>>> but I disagree with it being the mandatory/only solution. >>>=20 >>> I fully agree with David that making (D)TLS mandatory is not a good >>> idea, especially concerning re-usability of the protocol in scenarios >>> where you already have similar security features provided by the >>> underlying system. >>>=20 >>>=20 >>> Cheers, >>> Ari >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From julian@orchidseed.org Fri Dec 11 11:08:04 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B943A6890 for ; Fri, 11 Dec 2009 11:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 LdymZCZ0Yl2z for ; Fri, 11 Dec 2009 11:08:03 -0800 (PST) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id 5D7BA3A67D4 for ; Fri, 11 Dec 2009 11:08:03 -0800 (PST) Received: from adsl-66-230-71.asm.bellsouth.net ([98.66.230.71]:38173 helo=[172.16.1.233]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NJAqD-00029A-81; Fri, 11 Dec 2009 11:07:51 -0800 References: Message-Id: <803F182A-DA72-41D0-A2BC-9D3759429776@orchidseed.org> From: jc To: Brian Rosen In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Fri, 11 Dec 2009 14:07:43 -0500 X-Authenticated-User: 72798 julian@orchidseed.org Cc: P2PSIP WG Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 11 Dec 2009 19:08:04 -0000 Some individuals may not care to use tls or dtls. These standards =20 aren't practical in all cases. Encrypted transports a MUST but =20 mechanism should be optional. This is better than people not using =20 this draft and resolves conearns about the underlying transports lack =20= of performance in certain use cases. Thinking Chord only as a topology plugin is too narrow from a security =20= performance perspective. I have bad experience with Kademlia as a =20 topology plugin. If you understand Kademlia you should understand how =20= the routing table functions and how the transports reflect that. All =20 topology plugins will be forced to tune themselves to d/tls which the =20= result is a less efficient system. I don't see where anyone mentioned throw out encryption entirely but I =20= may be wrong. Julian Sent from my iPhone On Dec 11, 2009, at 1:16 PM, Brian Rosen wrote: > > I disagree. > > The problem is that we have a whole lot of history and experience. > > The experience is that if we don't insist, and make security =20 > integral to the > protocol, it doesn't get implemented and we have a majority of =20 > insecure > systems. > > If we do insist, the cost of the security is reasonable: the dire > predictions that it's too costly, too hard, ... don't happen. > > No amount of text explaining when the security mechanism is or isn't > appropriate works. You have to make the mechanism integral to the =20 > operation > of the protocol, as we have done here. > > I don't see anything in p2psip which would be different then our =20 > history and > experience. The costs aren't as bad as you fear. The probability =20 > of nearly > every system being implemented insecurely is very high if you make it > optional. > > Don't do that. > > Brian > > > On 12/11/09 12:49 PM, "Michael Chen" wrote: > >> I too agree with the three of you. D/TLS should be optional. =20 >> Several of my >> previous post voice concerns about redundancy and efficiency of the =20= >> transport >> layer. >> >> --Michael >>> -------- Original Message -------- >>> Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as >>> part of the WGLC >>> From: jc >>> Date: Fri, December 11, 2009 7:26 am >>> To: Ari Keranen >>> Cc: P2PSIP WG >>> >>> I said this about 7 months ago and I still agree that there should =20= >>> be >>> no mandatory transport layer encryption as this should be provided >>> outside of the scope of this draft. >>> >>> Julian >>> >>> Sent from my iPhone >>> >>> On Dec 11, 2009, at 5:39 AM, Ari Keranen =20 >>> >>> wrote: >>> >>>> Hi, >>>> >>>> David A. Bryan wrote: >>>>> Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts >>>>> I=E2=80=99ve raised this issue before, but I=E2=80=99m hoping that = now that >>>>> people have had a bit more time to think about all the use cases, >>>>> see what it means in the real world, etc., there might be a bit mo >>>>> re support for modifying the requirement for TLS/DTLS. TLS/DTLS ma >>>>> kes sense in some cases, but if we are expecting RELOAD to be reus >>>>> able, it is clear to me that it does not make sense in all cases. >>>>> It was familiar >>>>> to the editors, and well understood, so it made sense as a =20 >>>>> proposal, >>>>> but I disagree with it being the mandatory/only solution. >>>> >>>> I fully agree with David that making (D)TLS mandatory is not a good >>>> idea, especially concerning re-usability of the protocol in =20 >>>> scenarios >>>> where you already have similar security features provided by the >>>> underlying system. >>>> >>>> >>>> Cheers, >>>> Ari >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From Even.roni@huawei.com Fri Dec 11 11:08:50 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AFE13A67D4 for ; Fri, 11 Dec 2009 11:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.154 X-Spam-Level: X-Spam-Status: No, score=-1.154 tagged_above=-999 required=5 tests=[AWL=1.445, BAYES_00=-2.599] 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 uC72D9Tm0pYQ for ; Fri, 11 Dec 2009 11:08:49 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1E8A93A68A4 for ; Fri, 11 Dec 2009 11:08:49 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUI009V756BEM@szxga03-in.huawei.com> for p2psip@ietf.org; Sat, 12 Dec 2009 03:08:35 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUI007MV56BMM@szxga03-in.huawei.com> for p2psip@ietf.org; Sat, 12 Dec 2009 03:08:35 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-109-45.red.bezeqint.net [79.181.109.45]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUI0045S56313@szxml01-in.huawei.com>; Sat, 12 Dec 2009 03:08:35 +0800 (CST) Date: Fri, 11 Dec 2009 21:05:29 +0200 From: Roni Even In-reply-to: To: 'Brian Rosen' , 'Michael Chen' , 'P2PSIP WG' Message-id: <012b01ca7a94$ebf76d10$c3e64730$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=windows-1255 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: Acp6jhUDRXnah4JFG0KdZ/hQ8XCbCwABcalw References: <20091211104912.61e8c06078a3b23a733c71e914c0b9df.1bfb02afc4.wbe@email.secureserver.net> Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 11 Dec 2009 19:08:50 -0000 Brian, The issue is not if to have or not to have security. It is what level of security is satisfactory and there is no one solution fits all, note = also that the p2psip solution should also make it easier to nodes to serve as peers by not putting too much burden on them.=20 Deployment of security is motivated by requirements of the specific deployment and not because of the standard, what will happen is that you will see no compliance in cases where p2p solution will be deployed but would prefer different security mechanism. We also need to see that = there may be other p2p overlays and joining policies as well as other usages = which may have different security requirements.=20 I think that the p2prg draft that outline the security option as well as having a security analysis for p2psip will be enough. My thought was = that specifying TLS/DTLS was to address interoperability but this can be done = by mandating implementation and not usage. Roni Even =20 > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf Of Brian Rosen > Sent: Friday, December 11, 2009 8:17 PM > To: Michael Chen; P2PSIP WG > Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as > part of the WGLC >=20 > > I disagree. >=20 > The problem is that we have a whole lot of history and experience. >=20 > The experience is that if we don't insist, and make security integral > to the > protocol, it doesn't get implemented and we have a majority of = insecure > systems. >=20 > If we do insist, the cost of the security is reasonable: the dire > predictions that it's too costly, too hard, ... don't happen. >=20 > No amount of text explaining when the security mechanism is or isn't > appropriate works. You have to make the mechanism integral to the > operation > of the protocol, as we have done here. >=20 > I don't see anything in p2psip which would be different then our > history and > experience. The costs aren't as bad as you fear. The probability of > nearly > every system being implemented insecurely is very high if you make it > optional. >=20 > Don't do that. >=20 > Brian >=20 >=20 > On 12/11/09 12:49 PM, "Michael Chen" wrote: >=20 > > I too agree with the three of you. D/TLS should be optional. Several > of my > > previous post voice concerns about redundancy and efficiency of the > transport > > layer. > > > > --Michael > >> -------- Original Message -------- > >> Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 = as > >> part of the WGLC > >> From: jc > >> Date: Fri, December 11, 2009 7:26 am > >> To: Ari Keranen > >> Cc: P2PSIP WG > >> > >> I said this about 7 months ago and I still agree that there should > be > >> no mandatory transport layer encryption as this should be provided > >> outside of the scope of this draft. > >> > >> Julian > >> > >> Sent from my iPhone > >> > >> On Dec 11, 2009, at 5:39 AM, Ari Keranen > > >> wrote: > >> > >>> Hi, > >>> > >>> David A. Bryan wrote: > >>>> Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts > >>>> I=B9ve raised this issue before, but I=B9m hoping that now that > >>>> people have had a bit more time to think about all the use cases, > >>>> see what it means in the real world, etc., there might be a bit = mo > >>>> re support for modifying the requirement for TLS/DTLS. TLS/DTLS = ma > >>>> kes sense in some cases, but if we are expecting RELOAD to be = reus > >>>> able, it is clear to me that it does not make sense in all cases. > >>>> It was familiar > >>>> to the editors, and well understood, so it made sense as a > proposal, > >>>> but I disagree with it being the mandatory/only solution. > >>> > >>> I fully agree with David that making (D)TLS mandatory is not a = good > >>> idea, especially concerning re-usability of the protocol in > scenarios > >>> where you already have similar security features provided by the > >>> underlying system. > >>> > >>> > >>> Cheers, > >>> Ari > >>> _______________________________________________ > >>> P2PSIP mailing list > >>> P2PSIP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/p2psip > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www.ietf.org/mailman/listinfo/p2psip > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From br@brianrosen.net Fri Dec 11 11:30:03 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFBDD3A6850 for ; Fri, 11 Dec 2009 11:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599] 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 Rw4JdcsSlUYI for ; Fri, 11 Dec 2009 11:30:01 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id D27293A67F0 for ; Fri, 11 Dec 2009 11:30:01 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.231]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NJBBL-0001s5-L8; Fri, 11 Dec 2009 13:29:39 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 11 Dec 2009 14:29:43 -0500 From: Brian Rosen To: jc Message-ID: Thread-Topic: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC Thread-Index: Acp6mEoVZJNkEucVCkGaScwtU9YrEg== In-Reply-To: <803F182A-DA72-41D0-A2BC-9D3759429776@orchidseed.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: P2PSIP WG Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 11 Dec 2009 19:30:03 -0000 Lots of implementations of a protocol like, say, SIP, don't "care" to use tls. It gets low on the implementation priority list, many implementations don't have it, and then even the ones that do can't use it because the othe= r side doesn't. We have lousy, very lousy experience with security options like that. We KNOW what happens when we don't make it integral to the operation of the protocol. I don't want to go through that again. While there is no such thing as protocol police, I think the notion that p2pip ALWAYS uses D/TLS is a very useful, powerful, and important characteristic of the protocol. If you don't need much security, negotiate a null cipher suite. The overhead is low, the benefits are great. Brian On 12/11/09 2:07 PM, "jc" wrote: > Some individuals may not care to use tls or dtls. These standards > aren't practical in all cases. Encrypted transports a MUST but > mechanism should be optional. This is better than people not using > this draft and resolves conearns about the underlying transports lack > of performance in certain use cases. >=20 > Thinking Chord only as a topology plugin is too narrow from a security > performance perspective. I have bad experience with Kademlia as a > topology plugin. If you understand Kademlia you should understand how > the routing table functions and how the transports reflect that. All > topology plugins will be forced to tune themselves to d/tls which the > result is a less efficient system. >=20 > I don't see where anyone mentioned throw out encryption entirely but I > may be wrong. >=20 > Julian >=20 > Sent from my iPhone >=20 > On Dec 11, 2009, at 1:16 PM, Brian Rosen wrote: >=20 >> >> I disagree. >>=20 >> The problem is that we have a whole lot of history and experience. >>=20 >> The experience is that if we don't insist, and make security >> integral to the >> protocol, it doesn't get implemented and we have a majority of >> insecure >> systems. >>=20 >> If we do insist, the cost of the security is reasonable: the dire >> predictions that it's too costly, too hard, ... don't happen. >>=20 >> No amount of text explaining when the security mechanism is or isn't >> appropriate works. You have to make the mechanism integral to the >> operation >> of the protocol, as we have done here. >>=20 >> I don't see anything in p2psip which would be different then our >> history and >> experience. The costs aren't as bad as you fear. The probability >> of nearly >> every system being implemented insecurely is very high if you make it >> optional. >>=20 >> Don't do that. >>=20 >> Brian >>=20 >>=20 >> On 12/11/09 12:49 PM, "Michael Chen" wrote: >>=20 >>> I too agree with the three of you. D/TLS should be optional. >>> Several of my >>> previous post voice concerns about redundancy and efficiency of the >>> transport >>> layer. >>>=20 >>> --Michael >>>> -------- Original Message -------- >>>> Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as >>>> part of the WGLC >>>> From: jc >>>> Date: Fri, December 11, 2009 7:26 am >>>> To: Ari Keranen >>>> Cc: P2PSIP WG >>>>=20 >>>> I said this about 7 months ago and I still agree that there should >>>> be >>>> no mandatory transport layer encryption as this should be provided >>>> outside of the scope of this draft. >>>>=20 >>>> Julian >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Dec 11, 2009, at 5:39 AM, Ari Keranen >>>> >>>> wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> David A. Bryan wrote: >>>>>> Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts >>>>>> I=B9ve raised this issue before, but I=B9m hoping that now that >>>>>> people have had a bit more time to think about all the use cases, >>>>>> see what it means in the real world, etc., there might be a bit mo >>>>>> re support for modifying the requirement for TLS/DTLS. TLS/DTLS ma >>>>>> kes sense in some cases, but if we are expecting RELOAD to be reus >>>>>> able, it is clear to me that it does not make sense in all cases. >>>>>> It was familiar >>>>>> to the editors, and well understood, so it made sense as a >>>>>> proposal, >>>>>> but I disagree with it being the mandatory/only solution. >>>>>=20 >>>>> I fully agree with David that making (D)TLS mandatory is not a good >>>>> idea, especially concerning re-usability of the protocol in >>>>> scenarios >>>>> where you already have similar security features provided by the >>>>> underlying system. >>>>>=20 >>>>>=20 >>>>> Cheers, >>>>> Ari >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>=20 >>>=20 >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>=20 >>=20 >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip From br@brianrosen.net Fri Dec 11 11:31:52 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA993A681A for ; Fri, 11 Dec 2009 11:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599] 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 sihtmijUQwhI for ; Fri, 11 Dec 2009 11:31:51 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 854473A67A7 for ; Fri, 11 Dec 2009 11:31:51 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.231]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NJBD7-0001x0-0e; Fri, 11 Dec 2009 13:31:29 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 11 Dec 2009 14:31:32 -0500 From: Brian Rosen To: Roni Even , 'Michael Chen' , 'P2PSIP WG' Message-ID: Thread-Topic: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC Thread-Index: Acp6jhUDRXnah4JFG0KdZ/hQ8XCbCwABcalwAAEr2a0= In-Reply-To: <012b01ca7a94$ebf76d10$c3e64730$%roni@huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 11 Dec 2009 19:31:52 -0000 The way you tune the level of security is the ciphersuite choice. That's a plenty good enough knob. The overhead of TLS with simple ciphersuites is low. Low enough that the argument to remove it in some circumstances doesn't make any sense to me. Brian On 12/11/09 2:05 PM, "Roni Even" wrote: > Brian, > The issue is not if to have or not to have security. It is what level of > security is satisfactory and there is no one solution fits all, note also > that the p2psip solution should also make it easier to nodes to serve as > peers by not putting too much burden on them. > Deployment of security is motivated by requirements of the specific > deployment and not because of the standard, what will happen is that you > will see no compliance in cases where p2p solution will be deployed but > would prefer different security mechanism. We also need to see that there > may be other p2p overlays and joining policies as well as other usages wh= ich > may have different security requirements. > I think that the p2prg draft that outline the security option as well as > having a security analysis for p2psip will be enough. My thought was that > specifying TLS/DTLS was to address interoperability but this can be done = by > mandating implementation and not usage. >=20 > Roni Even > =20 >=20 >> -----Original Message----- >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >> Behalf Of Brian Rosen >> Sent: Friday, December 11, 2009 8:17 PM >> To: Michael Chen; P2PSIP WG >> Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as >> part of the WGLC >>=20 >> >> I disagree. >>=20 >> The problem is that we have a whole lot of history and experience. >>=20 >> The experience is that if we don't insist, and make security integral >> to the >> protocol, it doesn't get implemented and we have a majority of insecure >> systems. >>=20 >> If we do insist, the cost of the security is reasonable: the dire >> predictions that it's too costly, too hard, ... don't happen. >>=20 >> No amount of text explaining when the security mechanism is or isn't >> appropriate works. You have to make the mechanism integral to the >> operation >> of the protocol, as we have done here. >>=20 >> I don't see anything in p2psip which would be different then our >> history and >> experience. The costs aren't as bad as you fear. The probability of >> nearly >> every system being implemented insecurely is very high if you make it >> optional. >>=20 >> Don't do that. >>=20 >> Brian >>=20 >>=20 >> On 12/11/09 12:49 PM, "Michael Chen" wrote: >>=20 >>> I too agree with the three of you. D/TLS should be optional. Several >> of my >>> previous post voice concerns about redundancy and efficiency of the >> transport >>> layer. >>>=20 >>> --Michael >>>> -------- Original Message -------- >>>> Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as >>>> part of the WGLC >>>> From: jc >>>> Date: Fri, December 11, 2009 7:26 am >>>> To: Ari Keranen >>>> Cc: P2PSIP WG >>>>=20 >>>> I said this about 7 months ago and I still agree that there should >> be >>>> no mandatory transport layer encryption as this should be provided >>>> outside of the scope of this draft. >>>>=20 >>>> Julian >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Dec 11, 2009, at 5:39 AM, Ari Keranen >> >>>> wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> David A. Bryan wrote: >>>>>> Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts >>>>>> I=A9=F6ve raised this issue before, but I=A9=F6m hoping that now that >>>>>> people have had a bit more time to think about all the use cases, >>>>>> see what it means in the real world, etc., there might be a bit mo >>>>>> re support for modifying the requirement for TLS/DTLS. TLS/DTLS ma >>>>>> kes sense in some cases, but if we are expecting RELOAD to be reus >>>>>> able, it is clear to me that it does not make sense in all cases. >>>>>> It was familiar >>>>>> to the editors, and well understood, so it made sense as a >> proposal, >>>>>> but I disagree with it being the mandatory/only solution. >>>>>=20 >>>>> I fully agree with David that making (D)TLS mandatory is not a good >>>>> idea, especially concerning re-usability of the protocol in >> scenarios >>>>> where you already have similar security features provided by the >>>>> underlying system. >>>>>=20 >>>>>=20 >>>>> Cheers, >>>>> Ari >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>=20 >>>=20 >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>=20 >>=20 >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >=20 From sa2086@columbia.edu Fri Dec 11 11:33:39 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4E03A63EC for ; Fri, 11 Dec 2009 11:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] 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 Pu1soBHJkm46 for ; Fri, 11 Dec 2009 11:33:38 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id 66C183A6821 for ; Fri, 11 Dec 2009 11:33:38 -0800 (PST) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nBBJXIm8000017; Fri, 11 Dec 2009 14:33:18 -0500 (EST) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nBBJXIVm027920; Fri, 11 Dec 2009 14:33:18 -0500 (EST) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.3/8.14.3/Submit) with ESMTP id nBBJXIDu027917; Fri, 11 Dec 2009 14:33:18 -0500 (EST) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Fri, 11 Dec 2009 14:33:18 -0500 (EST) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: jc In-Reply-To: <803F182A-DA72-41D0-A2BC-9D3759429776@orchidseed.org> Message-ID: References: <803F182A-DA72-41D0-A2BC-9D3759429776@orchidseed.org> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-351212254-1260559998=:24557" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: P2PSIP WG Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 11 Dec 2009 19:33:39 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-351212254-1260559998=:24557 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Kademlia does iterative routing with parallel requests, and iterative routing has to pay the penalty of TLS/DTLS connection establishment at every hop which is at least 1.5 RTT. The alternative is to devise a secure transport protocol or optimize DTLS/TLS to reduce the connection establishment penalty. Security folks may argue that it is a non-starter at IETF. Yet, another alternative is to design a custom secure transport. But interoperability is the obvious looser. In general, for Internet scale deployment, the idea of trying to make all nodes, no matter what their connectivity, fully participate in the overlay as a peer is highly questionable. -s On Fri, 11 Dec 2009, jc wrote: > Some individuals may not care to use tls or dtls. These standards > aren't practical in all cases. Encrypted transports a MUST but > mechanism should be optional. This is better than people not using > this draft and resolves conearns about the underlying transports lack > of performance in certain use cases. > > Thinking Chord only as a topology plugin is too narrow from a security > performance perspective. I have bad experience with Kademlia as a > topology plugin. If you understand Kademlia you should understand how > the routing table functions and how the transports reflect that. All > topology plugins will be forced to tune themselves to d/tls which the > result is a less efficient system. > > I don't see where anyone mentioned throw out encryption entirely but I > may be wrong. > > Julian > > Sent from my iPhone > > On Dec 11, 2009, at 1:16 PM, Brian Rosen wrote: > >> >> I disagree. >> >> The problem is that we have a whole lot of history and experience. >> >> The experience is that if we don't insist, and make security >> integral to the >> protocol, it doesn't get implemented and we have a majority of >> insecure >> systems. >> >> If we do insist, the cost of the security is reasonable: the dire >> predictions that it's too costly, too hard, ... don't happen. >> >> No amount of text explaining when the security mechanism is or isn't >> appropriate works. You have to make the mechanism integral to the >> operation >> of the protocol, as we have done here. >> >> I don't see anything in p2psip which would be different then our >> history and >> experience. The costs aren't as bad as you fear. The probability >> of nearly >> every system being implemented insecurely is very high if you make it >> optional. >> >> Don't do that. >> >> Brian >> >> >> On 12/11/09 12:49 PM, "Michael Chen" wrote: >> >>> I too agree with the three of you. D/TLS should be optional. >>> Several of my >>> previous post voice concerns about redundancy and efficiency of the >>> transport >>> layer. >>> >>> --Michael >>>> -------- Original Message -------- >>>> Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as >>>> part of the WGLC >>>> From: jc >>>> Date: Fri, December 11, 2009 7:26 am >>>> To: Ari Keranen >>>> Cc: P2PSIP WG >>>> >>>> I said this about 7 months ago and I still agree that there should >>>> be >>>> no mandatory transport layer encryption as this should be provided >>>> outside of the scope of this draft. >>>> >>>> Julian >>>> >>>> Sent from my iPhone >>>> >>>> On Dec 11, 2009, at 5:39 AM, Ari Keranen >>>> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> David A. Bryan wrote: >>>>>> Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts >>>>>> I’ve raised this issue before, but I’m hoping that now that >>>>>> people have had a bit more time to think about all the use cases, >>>>>> see what it means in the real world, etc., there might be a bit mo >>>>>> re support for modifying the requirement for TLS/DTLS. TLS/DTLS ma >>>>>> kes sense in some cases, but if we are expecting RELOAD to be reus >>>>>> able, it is clear to me that it does not make sense in all cases. >>>>>> It was familiar >>>>>> to the editors, and well understood, so it made sense as a >>>>>> proposal, >>>>>> but I disagree with it being the mandatory/only solution. >>>>> >>>>> I fully agree with David that making (D)TLS mandatory is not a good >>>>> idea, especially concerning re-usability of the protocol in >>>>> scenarios >>>>> where you already have similar security features provided by the >>>>> underlying system. >>>>> >>>>> >>>>> Cheers, >>>>> Ari >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > ---559023410-351212254-1260559998=:24557-- From julian@orchidseed.org Fri Dec 11 11:57:05 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96ECA3A67F0 for ; Fri, 11 Dec 2009 11:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 we9WQdNvw8f7 for ; Fri, 11 Dec 2009 11:57:04 -0800 (PST) Received: from n25.c05.mtsvc.net (n25.c05.mtsvc.net [70.32.68.25]) by core3.amsl.com (Postfix) with ESMTP id 84F503A67A7 for ; Fri, 11 Dec 2009 11:57:04 -0800 (PST) Received: from adsl-66-230-71.asm.bellsouth.net ([98.66.230.71]:38764 helo=[172.16.1.230]) by n25.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NJBbb-00025R-Rk; Fri, 11 Dec 2009 11:56:49 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: jc In-Reply-To: Date: Fri, 11 Dec 2009 14:56:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <803F182A-DA72-41D0-A2BC-9D3759429776@orchidseed.org> To: Salman Abdul Baset X-Mailer: Apple Mail (2.1077) X-Authenticated-User: 72798 julian@orchidseed.org Cc: P2PSIP WG Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 11 Dec 2009 19:57:05 -0000 Salman, If you see my other email, yes the iterative nature of Kademlia makes = D/TLS too expensive, it would have to be made recursive to obey the = draft.=20 I agree about "Attempting" to connect all Nodes even if it MUST TURN = them. This is a big failure that won't see success. > In general, for Internet scale deployment, the idea of trying to make = all nodes, no matter what their connectivity, fully participate in the = overlay as a peer is highly questionable. I see this as impossible. Peers and Nodes' need revisited. For instance, = it's cheaper to Peer than to TURN so what good is TURN for the Overlay = connections? TURN is useless to the Overlay IMHO, this could be used for = call routing and app layer services. If you are a Node and you MUST TURN = you should Peer instead IMHO. Julian Cain On Dec 11, 2009, at 2:33 PM, Salman Abdul Baset wrote: > Kademlia does iterative routing with parallel requests, and iterative = routing has to pay the penalty of TLS/DTLS connection establishment at = every hop which is at least 1.5 RTT. >=20 > The alternative is to devise a secure transport protocol or optimize = DTLS/TLS to reduce the connection establishment penalty. Security folks = may argue that it is a non-starter at IETF. >=20 > Yet, another alternative is to design a custom secure transport. But = interoperability is the obvious looser. >=20 > In general, for Internet scale deployment, the idea of trying to make = all nodes, no matter what their connectivity, fully participate in the = overlay as a peer is highly questionable. >=20 > -s >=20 > On Fri, 11 Dec 2009, jc wrote: >=20 >> Some individuals may not care to use tls or dtls. These standards = aren't practical in all cases. Encrypted transports a MUST but mechanism = should be optional. This is better than people not using this draft and = resolves conearns about the underlying transports lack of performance in = certain use cases. >>=20 >> Thinking Chord only as a topology plugin is too narrow from a = security performance perspective. I have bad experience with Kademlia as = a topology plugin. If you understand Kademlia you should understand how = the routing table functions and how the transports reflect that. All = topology plugins will be forced to tune themselves to d/tls which the = result is a less efficient system. >>=20 >> I don't see where anyone mentioned throw out encryption entirely but = I may be wrong. >>=20 >> Julian >>=20 >> Sent from my iPhone >>=20 >> On Dec 11, 2009, at 1:16 PM, Brian Rosen wrote: >>=20 >>> >>> I disagree. >>>=20 >>> The problem is that we have a whole lot of history and experience. >>>=20 >>> The experience is that if we don't insist, and make security = integral to the >>> protocol, it doesn't get implemented and we have a majority of = insecure >>> systems. >>>=20 >>> If we do insist, the cost of the security is reasonable: the dire >>> predictions that it's too costly, too hard, ... don't happen. >>>=20 >>> No amount of text explaining when the security mechanism is or isn't >>> appropriate works. You have to make the mechanism integral to the = operation >>> of the protocol, as we have done here. >>>=20 >>> I don't see anything in p2psip which would be different then our = history and >>> experience. The costs aren't as bad as you fear. The probability = of nearly >>> every system being implemented insecurely is very high if you make = it >>> optional. >>>=20 >>> Don't do that. >>>=20 >>> Brian >>>=20 >>>=20 >>> On 12/11/09 12:49 PM, "Michael Chen" = wrote: >>>=20 >>>> I too agree with the three of you. D/TLS should be optional. = Several of my >>>> previous post voice concerns about redundancy and efficiency of the = transport >>>> layer. >>>>=20 >>>> --Michael >>>>> -------- Original Message -------- >>>>> Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 = as >>>>> part of the WGLC >>>>> From: jc >>>>> Date: Fri, December 11, 2009 7:26 am >>>>> To: Ari Keranen >>>>> Cc: P2PSIP WG >>>>>=20 >>>>> I said this about 7 months ago and I still agree that there should = be >>>>> no mandatory transport layer encryption as this should be provided >>>>> outside of the scope of this draft. >>>>>=20 >>>>> Julian >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>> On Dec 11, 2009, at 5:39 AM, Ari Keranen = >>>>> wrote: >>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> David A. Bryan wrote: >>>>>>> Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts >>>>>>> I=92ve raised this issue before, but I=92m hoping that now that >>>>>>> people have had a bit more time to think about all the use = cases, >>>>>>> see what it means in the real world, etc., there might be a bit = mo >>>>>>> re support for modifying the requirement for TLS/DTLS. TLS/DTLS = ma >>>>>>> kes sense in some cases, but if we are expecting RELOAD to be = reus >>>>>>> able, it is clear to me that it does not make sense in all = cases. >>>>>>> It was familiar >>>>>>> to the editors, and well understood, so it made sense as a = proposal, >>>>>>> but I disagree with it being the mandatory/only solution. >>>>>>=20 >>>>>> I fully agree with David that making (D)TLS mandatory is not a = good >>>>>> idea, especially concerning re-usability of the protocol in = scenarios >>>>>> where you already have similar security features provided by the >>>>>> underlying system. >>>>>>=20 >>>>>>=20 >>>>>> Cheers, >>>>>> Ari >>>>>> _______________________________________________ >>>>>> P2PSIP mailing list >>>>>> P2PSIP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>=20 >>>=20 >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >>=20 From davidbryan@gmail.com Fri Dec 11 12:53:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201013A6824 for ; Fri, 11 Dec 2009 12:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 9-BfEyh5i0BJ for ; Fri, 11 Dec 2009 12:53:30 -0800 (PST) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id CDAED3A659B for ; Fri, 11 Dec 2009 12:53:29 -0800 (PST) Received: by ywh38 with SMTP id 38so1244134ywh.6 for ; Fri, 11 Dec 2009 12:53:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=H8b10UdcWcwwCtOVtfiwpus0wQOPPjUFvqdtjMkmJoI=; b=bkZRcGxhJVKprb60bERgd2vmFtmhz9VV3Bsk8RPzOkJsCKHbc+FOC3KenpRHGbW0nT 5wJ4Dv9s8ueknqa7kWvyl9RmP8B8f8K+ritdGIOuOKKi8MAM6nY+c3RjUvIk5Sq7FsgC 37KtGCbPQyqQtYF0dZeJsHzk2ta6L5K9qJ2b0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=X2KFSWb5ASCVrLh4jGebTwIeKPykoX9u68zlbY4euKyBbJRleLEFTQ3sY/P1gFZVz+ 0bwTj+soxcJZM4KyMmFwOFJeFirVKaE8D/YtoTlyoIgQx6IG5g5Qt8cL/aatNYqWNHRP rqb9FDmYchEiEaeUZSIX+yEVRVGVPKaE7ycH4= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.33.5 with SMTP id g5mr3319490ybg.132.1260564794464; Fri, 11 Dec 2009 12:53:14 -0800 (PST) In-Reply-To: References: <803F182A-DA72-41D0-A2BC-9D3759429776@orchidseed.org> Date: Fri, 11 Dec 2009 15:53:14 -0500 X-Google-Sender-Auth: 9bc8d315b9741c08 Message-ID: <8b2769930912111253q423f8d30h161900f38b2d28a5@mail.gmail.com> From: "David A. Bryan" To: Brian Rosen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 11 Dec 2009 20:53:31 -0000 The problem here is that this isn't SIP or a protocol like it, and so the design and deployment lessons don't precisely apply. While people often call SIP "peer-to-peer", it isn't in the same sense as we use that term when talking about a DHT. Assuming we make a protocol that works for a variety of routing techniques and DHT types, rather than the somewhat narrow subspace of just recursive response chord-like, the way messages are routed is highly variable. In many cases, several new connections may be required for each transaction, just to get a reference to reach the remote party (then connecting to the remote party becomes very SIP like, and yes, (D)TLS may make sense once you are establishing a communications connection...) We got burned with a design flaw for SIP, but that doesn't mean that what would have worked for SIP is the right answer for every protocol. Direct response. Parallel search with direct response. Iterative search, Parallel iterative search...all of these are valid P2P mechanisms in the literature, and in the deployed 'net, yet for all three, the overhead of DTLS, 7 messages per hop (and there could be many hops in iterative parallel search) as I cited in my reference in the initial email, is too much for a connection that may only be used once. Keep in mind it still at that point hasn't provided end-to-end security either (although obviously we can)... I have a paper in submission for publication that shows that even for networks with many NATs, direct response results in reduced message counts, and for large overlays, even reduces mean search time (overlay wide) in some cases, depending on the fraction behind NATs. While I believe in v6-v6 NATs, over time, direct will make increasing sense in a less NAT filled world, and the cost of TLS will not make sense as the one and only security mechanism for such a system. Security makes sense...but mandating one and only one mechanism will do one of two things: "Future-proof" the protocol (meaning the protocol protects itself against the pesky future and just doesn't get used), or ensure that people will just break the spec. I'd rather avoid both outcomes... David On Fri, Dec 11, 2009 at 2:29 PM, Brian Rosen wrote: > > Lots of implementations of a protocol like, say, SIP, don't "care" to use > tls. =A0It gets low on the implementation priority list, many implementat= ions > don't have it, and then even the ones that do can't use it because the ot= her > side doesn't. =A0We have lousy, very lousy experience with security optio= ns > like that. =A0We KNOW what happens when we don't make it integral to the > operation of the protocol. =A0I don't want to go through that again. > > While there is no such thing as protocol police, I think the notion that > p2pip ALWAYS uses D/TLS is a very useful, powerful, and important > characteristic of the protocol. =A0If you don't need much security, negot= iate > a null cipher suite. =A0The overhead is low, the benefits are great. > > Brian > > > On 12/11/09 2:07 PM, "jc" wrote: > >> Some individuals may not care to use tls or dtls. These standards >> aren't practical in all cases. Encrypted transports a MUST but >> mechanism should be optional. This is better than people not using >> this draft and resolves conearns about the underlying transports lack >> of performance in certain use cases. >> >> Thinking Chord only as a topology plugin is too narrow from a security >> performance perspective. I have bad experience with Kademlia as a >> topology plugin. If you understand Kademlia you should understand how >> the routing table functions and how the transports reflect that. All >> topology plugins will be forced to tune themselves to d/tls which the >> result is a less efficient system. >> >> I don't see where anyone mentioned throw out encryption entirely but I >> may be wrong. >> >> Julian >> >> Sent from my iPhone >> >> On Dec 11, 2009, at 1:16 PM, Brian Rosen wrote: >> >>> >>> I disagree. >>> >>> The problem is that we have a whole lot of history and experience. >>> >>> The experience is that if we don't insist, and make security >>> integral to the >>> protocol, it doesn't get implemented and we have a majority of >>> insecure >>> systems. >>> >>> If we do insist, the cost of the security is reasonable: the dire >>> predictions that it's too costly, too hard, ... don't happen. >>> >>> No amount of text explaining when the security mechanism is or isn't >>> appropriate works. =A0You have to make the mechanism integral to the >>> operation >>> of the protocol, as we have done here. >>> >>> I don't see anything in p2psip which would be different then our >>> history and >>> experience. =A0The costs aren't as bad as you fear. =A0The probability >>> of nearly >>> every system being implemented insecurely is very high if you make it >>> optional. >>> >>> Don't do that. >>> >>> Brian >>> >>> >>> On 12/11/09 12:49 PM, "Michael Chen" wrote: >>> >>>> I too agree with the three of you. D/TLS should be optional. >>>> Several of my >>>> previous post voice concerns about redundancy and efficiency of the >>>> transport >>>> layer. >>>> >>>> --Michael >>>>> -------- Original Message -------- >>>>> Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as >>>>> part of the WGLC >>>>> From: jc >>>>> Date: Fri, December 11, 2009 7:26 am >>>>> To: Ari Keranen >>>>> Cc: P2PSIP WG >>>>> >>>>> I said this about 7 months ago and I still agree that there should >>>>> be >>>>> no mandatory transport layer encryption as this should be provided >>>>> outside of the scope of this draft. >>>>> >>>>> Julian >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Dec 11, 2009, at 5:39 AM, Ari Keranen >>>>> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> David A. Bryan wrote: >>>>>>> Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts >>>>>>> I=B9ve raised this issue before, but I=B9m hoping that now that >>>>>>> people have had a bit more time to think about all the use cases, >>>>>>> see what it means in the real world, etc., there might be a bit mo >>>>>>> re support for modifying the requirement for TLS/DTLS. TLS/DTLS ma >>>>>>> kes sense in some cases, but if we are expecting RELOAD to be reus >>>>>>> able, it is clear to me that it does not make sense in all cases. >>>>>>> It was familiar >>>>>>> to the editors, and well understood, so it made sense as a >>>>>>> proposal, >>>>>>> but I disagree with it being the mandatory/only solution. >>>>>> >>>>>> I fully agree with David that making (D)TLS mandatory is not a good >>>>>> idea, especially concerning re-usability of the protocol in >>>>>> scenarios >>>>>> where you already have similar security features provided by the >>>>>> underlying system. >>>>>> >>>>>> >>>>>> Cheers, >>>>>> Ari >>>>>> _______________________________________________ >>>>>> P2PSIP mailing list >>>>>> P2PSIP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From br@brianrosen.net Fri Dec 11 14:03:39 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F3D3A6874 for ; Fri, 11 Dec 2009 14:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=-0.506, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 E9+-p3ITtygU for ; Fri, 11 Dec 2009 14:03:38 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 04BF83A67FB for ; Fri, 11 Dec 2009 14:03:37 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.231]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NJDZy-0002FI-TP; Fri, 11 Dec 2009 16:03:15 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 11 Dec 2009 17:03:19 -0500 From: Brian Rosen To: "David A. Bryan" Message-ID: Thread-Topic: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC Thread-Index: Acp6rb8/bxiyckGwvkqYH4KCOnhUBw== In-Reply-To: <8b2769930912111253q423f8d30h161900f38b2d28a5@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: P2PSIP WG Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 11 Dec 2009 22:03:39 -0000 Sorry, don't buy it. There is no flaw in SIP wrt what we are discussing. TLS is "mandatory to implement", but it's not integral to the protocol. I don't want to go down the path of yet another insecure protocol. Suppose there were 7 RTs for each branch of direct response, although that isn't true for a null ciphersuite, right? For the use cases we have so far considered, who cares? You are trying to optimize something that doesn't seem to matter enough to lose the security of knowing who you are talking to. One peer won't see that much traffic, and the total of all of them isn't really much of an issue. If it's a big deal to you, keep persistent connections for all the fingers (or equivalent). Brian On 12/11/09 3:53 PM, "David A. Bryan" wrote: > >=20 > The problem here is that this isn't SIP or a protocol like it, and so > the design and deployment lessons don't precisely apply. While people > often call SIP "peer-to-peer", it isn't in the same sense as we use > that term when talking about a DHT. Assuming we make a protocol that > works for a variety of routing techniques and DHT types, rather than > the somewhat narrow subspace of just recursive response chord-like, > the way messages are routed is highly variable. In many cases, several > new connections may be required for each transaction, just to get a > reference to reach the remote party (then connecting to the remote > party becomes very SIP like, and yes, (D)TLS may make sense once you > are establishing a communications connection...) >=20 > We got burned with a design flaw for SIP, but that doesn't mean that > what would have worked for SIP is the right answer for every protocol. >=20 > Direct response. Parallel search with direct response. Iterative > search, Parallel iterative search...all of these are valid P2P > mechanisms in the literature, and in the deployed 'net, yet for all > three, the overhead of DTLS, 7 messages per hop (and there could be > many hops in iterative parallel search) as I cited in my reference in > the initial email, is too much for a connection that may only be used > once. Keep in mind it still at that point hasn't provided end-to-end > security either (although obviously we can)... >=20 > I have a paper in submission for publication that shows that even for > networks with many NATs, direct response results in reduced message > counts, and for large overlays, even reduces mean search time (overlay > wide) in some cases, depending on the fraction behind NATs. While I > believe in v6-v6 NATs, over time, direct will make increasing sense in > a less NAT filled world, and the cost of TLS will not make sense as > the one and only security mechanism for such a system. >=20 > Security makes sense...but mandating one and only one mechanism will > do one of two things: "Future-proof" the protocol (meaning the > protocol protects itself against the pesky future and just doesn't get > used), or ensure that people will just break the spec. I'd rather > avoid both outcomes... >=20 > David >=20 > On Fri, Dec 11, 2009 at 2:29 PM, Brian Rosen wrote: >> >> Lots of implementations of a protocol like, say, SIP, don't "care" to us= e >> tls. =A0It gets low on the implementation priority list, many implementati= ons >> don't have it, and then even the ones that do can't use it because the o= ther >> side doesn't. =A0We have lousy, very lousy experience with security option= s >> like that. =A0We KNOW what happens when we don't make it integral to the >> operation of the protocol. =A0I don't want to go through that again. >>=20 >> While there is no such thing as protocol police, I think the notion that >> p2pip ALWAYS uses D/TLS is a very useful, powerful, and important >> characteristic of the protocol. =A0If you don't need much security, negoti= ate >> a null cipher suite. =A0The overhead is low, the benefits are great. >>=20 >> Brian >>=20 >>=20 >> On 12/11/09 2:07 PM, "jc" wrote: >>=20 >>> Some individuals may not care to use tls or dtls. These standards >>> aren't practical in all cases. Encrypted transports a MUST but >>> mechanism should be optional. This is better than people not using >>> this draft and resolves conearns about the underlying transports lack >>> of performance in certain use cases. >>>=20 >>> Thinking Chord only as a topology plugin is too narrow from a security >>> performance perspective. I have bad experience with Kademlia as a >>> topology plugin. If you understand Kademlia you should understand how >>> the routing table functions and how the transports reflect that. All >>> topology plugins will be forced to tune themselves to d/tls which the >>> result is a less efficient system. >>>=20 >>> I don't see where anyone mentioned throw out encryption entirely but I >>> may be wrong. >>>=20 >>> Julian >>>=20 >>> Sent from my iPhone >>>=20 >>> On Dec 11, 2009, at 1:16 PM, Brian Rosen wrote: >>>=20 >>>> >>>> I disagree. >>>>=20 >>>> The problem is that we have a whole lot of history and experience. >>>>=20 >>>> The experience is that if we don't insist, and make security >>>> integral to the >>>> protocol, it doesn't get implemented and we have a majority of >>>> insecure >>>> systems. >>>>=20 >>>> If we do insist, the cost of the security is reasonable: the dire >>>> predictions that it's too costly, too hard, ... don't happen. >>>>=20 >>>> No amount of text explaining when the security mechanism is or isn't >>>> appropriate works. =A0You have to make the mechanism integral to the >>>> operation >>>> of the protocol, as we have done here. >>>>=20 >>>> I don't see anything in p2psip which would be different then our >>>> history and >>>> experience. =A0The costs aren't as bad as you fear. =A0The probability >>>> of nearly >>>> every system being implemented insecurely is very high if you make it >>>> optional. >>>>=20 >>>> Don't do that. >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>> On 12/11/09 12:49 PM, "Michael Chen" wrote: >>>>=20 >>>>> I too agree with the three of you. D/TLS should be optional. >>>>> Several of my >>>>> previous post voice concerns about redundancy and efficiency of the >>>>> transport >>>>> layer. >>>>>=20 >>>>> --Michael >>>>>> -------- Original Message -------- >>>>>> Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as >>>>>> part of the WGLC >>>>>> From: jc >>>>>> Date: Fri, December 11, 2009 7:26 am >>>>>> To: Ari Keranen >>>>>> Cc: P2PSIP WG >>>>>>=20 >>>>>> I said this about 7 months ago and I still agree that there should >>>>>> be >>>>>> no mandatory transport layer encryption as this should be provided >>>>>> outside of the scope of this draft. >>>>>>=20 >>>>>> Julian >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>> On Dec 11, 2009, at 5:39 AM, Ari Keranen >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> David A. Bryan wrote: >>>>>>>> Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts >>>>>>>> I=B9ve raised this issue before, but I=B9m hoping that now that >>>>>>>> people have had a bit more time to think about all the use cases, >>>>>>>> see what it means in the real world, etc., there might be a bit mo >>>>>>>> re support for modifying the requirement for TLS/DTLS. TLS/DTLS ma >>>>>>>> kes sense in some cases, but if we are expecting RELOAD to be reus >>>>>>>> able, it is clear to me that it does not make sense in all cases. >>>>>>>> It was familiar >>>>>>>> to the editors, and well understood, so it made sense as a >>>>>>>> proposal, >>>>>>>> but I disagree with it being the mandatory/only solution. >>>>>>>=20 >>>>>>> I fully agree with David that making (D)TLS mandatory is not a good >>>>>>> idea, especially concerning re-usability of the protocol in >>>>>>> scenarios >>>>>>> where you already have similar security features provided by the >>>>>>> underlying system. >>>>>>>=20 >>>>>>>=20 >>>>>>> Cheers, >>>>>>> Ari >>>>>>> _______________________________________________ >>>>>>> P2PSIP mailing list >>>>>>> P2PSIP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>>> _______________________________________________ >>>>>> P2PSIP mailing list >>>>>> P2PSIP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>=20 >>=20 >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >>=20 From davidbryan@gmail.com Fri Dec 11 16:20:54 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C30CA3A6831 for ; Fri, 11 Dec 2009 16:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 LM6DCWAjuh0f for ; Fri, 11 Dec 2009 16:20:53 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 02BA13A676A for ; Fri, 11 Dec 2009 16:20:52 -0800 (PST) Received: by yxe30 with SMTP id 30so1527886yxe.29 for ; Fri, 11 Dec 2009 16:20:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=FQWzBX6wwDdeSV5GDwssGyw9B4GYo/gkVRnMYnooTSc=; b=h7Ro/yVc59IBwjqudqlS0Uw8XX2oz9PyQZlykyjbsoQFL2wMauKGLJEYywQYiXB+9w o4Qx54Em4bSbwqRIUQq76OLfrzht+DqvzCJu2DUXZFXeKU3QpVJLV1RKQ1xvu18AK2rf /OhqVBNMD2TKL159HJjCynvE799BapcU/qM5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=M+KIHP9WBMhnjYnGbmmaSb2MqL7rApZYSoeZgr/8FyekYllECJwtgXqbmNYOK3QEW6 l/18snohsx5WQFkHqIRL2/0zVD8In9W0Cup4RLHAuzodCyz8jl4UzSHCmMIqCyueE6s4 adXH7V7h8PHHveMOzWTWaA/nMMI1nQzyGFQK0= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.125.3 with SMTP id x3mr3615201ybc.28.1260577237610; Fri, 11 Dec 2009 16:20:37 -0800 (PST) In-Reply-To: References: <8b2769930912111253q423f8d30h161900f38b2d28a5@mail.gmail.com> Date: Fri, 11 Dec 2009 19:20:37 -0500 X-Google-Sender-Auth: a7ef4384e5852a17 Message-ID: <8b2769930912111620i21590a17xe7d5ddc665924104@mail.gmail.com> From: "David A. Bryan" To: Brian Rosen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 12 Dec 2009 00:20:55 -0000 inline... On Fri, Dec 11, 2009 at 5:03 PM, Brian Rosen wrote: > > > Sorry, don't buy it. > > There is no flaw in SIP wrt what we are discussing. =A0TLS is "mandatory = to > implement", but it's not integral to the protocol. =A0I don't want to go = down > the path of yet another insecure protocol. Sorry, I didn't mean to claim there was some big flaw or anything. By flaw, I just meant your assertion that not designing the protocol to require TLS was wrong. Sorry for the confusion. What if someone has a desire to use another security mechanism? (we come up with something else, an industry standard gets brought in ala XMPP, we have hardware optimized for IP sec, etc.) Currently we are forcing the protocol -- forever -- to exactly one possible security mechanism. This is silly. Folks can run this without a cypher suite (or just ignore the speak and run UDP). If they don't add end-to-end security or hop-to-hop security, they are doing something dumb. If we assume we are smart enough to determine that one mechanism will be perfect for every deployment, forever, we are doing something arrogant. In the end, I'm concerned we'll have lots of people doing "work arounds" that will truly be non-standard, or they will just decide to look elsewhere for a DHT protocol. > Suppose there were 7 RTs for each branch of direct response, although tha= t > isn't true for a null ciphersuite, right? Good question/point. Not actually sure with the null suite. Can anyone comment on the message count? That would be useful for getting a better handle on the discussion, actually. I'd particularly like to know if you could spoof the behavior if not running a cypher. (i.e., can you do it without a TLS stack if I am running another security mechanism). Still seems like an ugly hack, but an interesting point of debate. > For the use cases we have so far considered, who cares? =A0You are trying= to > optimize something that doesn't seem to matter enough to lose the securit= y > of knowing who you are talking to. I think it matters a whole heck of a lot. The group's main use case is a distributed registrar. I think we can show that in systems that are not completely NATed direct response works better (and if we use clients for the peers behind NATs, even better). We can certainly show that some DHTs will want ot make connections to new peers with each transaction. Unless you REALLY trust the peers, we need end-to-end security. With signed routing blocks, there may be deployments (particularly those that are providing alternate link security) that don't need software hop-to-hop security. That can be accomplished much less expensively with other techniques. If you mean the case RELOAD seems most optimized for now (one that assumes we must use recursive or that we want a persistent connection to the peer storing the registration, after returning it) then maybe no, but that isn't actually quite the primary use case the group specified. It's an interesting case, but I don't think it quite fits the primary use case of the WG perfectly, actually. We should make sure we allow for all the possible scenarios. > One peer won't see that much traffic, and the total of all of them isn't > really much of an issue. =A0If it's a big deal to you, keep persistent > connections for all the fingers (or equivalent). Sorry, for this one point, I actually don't quite understand what you are trying to say. I'm arguing that in some some (often more efficient) routing techniques, you need to connect to peers that aren't persistent fingers, so saying keep them doesn't quite make sense. I may just be missing this line of reasoning... Thanks, David > Brian > > On 12/11/09 3:53 PM, "David A. Bryan" wrote: > >> >> >> The problem here is that this isn't SIP or a protocol like it, and so >> the design and deployment lessons don't precisely apply. While people >> often call SIP "peer-to-peer", it isn't in the same sense as we use >> that term when talking about a DHT. Assuming we make a protocol that >> works for a variety of routing techniques and DHT types, rather than >> the somewhat narrow subspace of just recursive response chord-like, >> the way messages are routed is highly variable. In many cases, several >> new connections may be required for each transaction, just to get a >> reference to reach the remote party (then connecting to the remote >> party becomes very SIP like, and yes, (D)TLS may make sense once you >> are establishing a communications connection...) >> >> We got burned with a design flaw for SIP, but that doesn't mean that >> what would have worked for SIP is the right answer for every protocol. >> >> Direct response. Parallel search with direct response. Iterative >> search, Parallel iterative search...all of these are valid P2P >> mechanisms in the literature, and in the deployed 'net, yet for all >> three, the overhead of DTLS, 7 messages per hop (and there could be >> many hops in iterative parallel search) as I cited in my reference in >> the initial email, is too much for a connection that may only be used >> once. Keep in mind it still at that point hasn't provided end-to-end >> security either (although obviously we can)... >> >> I have a paper in submission for publication that shows that even for >> networks with many NATs, direct response results in reduced message >> counts, and for large overlays, even reduces mean search time (overlay >> wide) in some cases, depending on the fraction behind NATs. While I >> believe in v6-v6 NATs, over time, direct will make increasing sense in >> a less NAT filled world, and the cost of TLS will not make sense as >> the one and only security mechanism for such a system. >> >> Security makes sense...but mandating one and only one mechanism will >> do one of two things: "Future-proof" the protocol (meaning the >> protocol protects itself against the pesky future and just doesn't get >> used), or ensure that people will just break the spec. I'd rather >> avoid both outcomes... >> >> David >> >> On Fri, Dec 11, 2009 at 2:29 PM, Brian Rosen wrote: >>> >>> Lots of implementations of a protocol like, say, SIP, don't "care" to u= se >>> tls. =A0It gets low on the implementation priority list, many implement= ations >>> don't have it, and then even the ones that do can't use it because the = other >>> side doesn't. =A0We have lousy, very lousy experience with security opt= ions >>> like that. =A0We KNOW what happens when we don't make it integral to th= e >>> operation of the protocol. =A0I don't want to go through that again. >>> >>> While there is no such thing as protocol police, I think the notion tha= t >>> p2pip ALWAYS uses D/TLS is a very useful, powerful, and important >>> characteristic of the protocol. =A0If you don't need much security, neg= otiate >>> a null cipher suite. =A0The overhead is low, the benefits are great. >>> >>> Brian >>> >>> >>> On 12/11/09 2:07 PM, "jc" wrote: >>> >>>> Some individuals may not care to use tls or dtls. These standards >>>> aren't practical in all cases. Encrypted transports a MUST but >>>> mechanism should be optional. This is better than people not using >>>> this draft and resolves conearns about the underlying transports lack >>>> of performance in certain use cases. >>>> >>>> Thinking Chord only as a topology plugin is too narrow from a security >>>> performance perspective. I have bad experience with Kademlia as a >>>> topology plugin. If you understand Kademlia you should understand how >>>> the routing table functions and how the transports reflect that. All >>>> topology plugins will be forced to tune themselves to d/tls which the >>>> result is a less efficient system. >>>> >>>> I don't see where anyone mentioned throw out encryption entirely but I >>>> may be wrong. >>>> >>>> Julian >>>> >>>> Sent from my iPhone >>>> >>>> On Dec 11, 2009, at 1:16 PM, Brian Rosen wrote: >>>> >>>>> >>>>> I disagree. >>>>> >>>>> The problem is that we have a whole lot of history and experience. >>>>> >>>>> The experience is that if we don't insist, and make security >>>>> integral to the >>>>> protocol, it doesn't get implemented and we have a majority of >>>>> insecure >>>>> systems. >>>>> >>>>> If we do insist, the cost of the security is reasonable: the dire >>>>> predictions that it's too costly, too hard, ... don't happen. >>>>> >>>>> No amount of text explaining when the security mechanism is or isn't >>>>> appropriate works. =A0You have to make the mechanism integral to the >>>>> operation >>>>> of the protocol, as we have done here. >>>>> >>>>> I don't see anything in p2psip which would be different then our >>>>> history and >>>>> experience. =A0The costs aren't as bad as you fear. =A0The probabilit= y >>>>> of nearly >>>>> every system being implemented insecurely is very high if you make it >>>>> optional. >>>>> >>>>> Don't do that. >>>>> >>>>> Brian >>>>> >>>>> >>>>> On 12/11/09 12:49 PM, "Michael Chen" wrote= : >>>>> >>>>>> I too agree with the three of you. D/TLS should be optional. >>>>>> Several of my >>>>>> previous post voice concerns about redundancy and efficiency of the >>>>>> transport >>>>>> layer. >>>>>> >>>>>> --Michael >>>>>>> -------- Original Message -------- >>>>>>> Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 a= s >>>>>>> part of the WGLC >>>>>>> From: jc >>>>>>> Date: Fri, December 11, 2009 7:26 am >>>>>>> To: Ari Keranen >>>>>>> Cc: P2PSIP WG >>>>>>> >>>>>>> I said this about 7 months ago and I still agree that there should >>>>>>> be >>>>>>> no mandatory transport layer encryption as this should be provided >>>>>>> outside of the scope of this draft. >>>>>>> >>>>>>> Julian >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>> On Dec 11, 2009, at 5:39 AM, Ari Keranen >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> David A. Bryan wrote: >>>>>>>>> Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts >>>>>>>>> I=B9ve raised this issue before, but I=B9m hoping that now that >>>>>>>>> people have had a bit more time to think about all the use cases, >>>>>>>>> see what it means in the real world, etc., there might be a bit m= o >>>>>>>>> re support for modifying the requirement for TLS/DTLS. TLS/DTLS m= a >>>>>>>>> kes sense in some cases, but if we are expecting RELOAD to be reu= s >>>>>>>>> able, it is clear to me that it does not make sense in all cases. >>>>>>>>> It was familiar >>>>>>>>> to the editors, and well understood, so it made sense as a >>>>>>>>> proposal, >>>>>>>>> but I disagree with it being the mandatory/only solution. >>>>>>>> >>>>>>>> I fully agree with David that making (D)TLS mandatory is not a goo= d >>>>>>>> idea, especially concerning re-usability of the protocol in >>>>>>>> scenarios >>>>>>>> where you already have similar security features provided by the >>>>>>>> underlying system. >>>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Ari >>>>>>>> _______________________________________________ >>>>>>>> P2PSIP mailing list >>>>>>>> P2PSIP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>>>> _______________________________________________ >>>>>>> P2PSIP mailing list >>>>>>> P2PSIP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> P2PSIP mailing list >>>>>> P2PSIP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>> >>>>> >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>> >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> > > > From Even.roni@huawei.com Fri Dec 11 17:33:54 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720403A6834 for ; Fri, 11 Dec 2009 17:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.253 X-Spam-Level: * X-Spam-Status: No, score=1.253 tagged_above=-999 required=5 tests=[AWL=3.852, BAYES_00=-2.599] 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 f4ick8qgy-VK for ; Fri, 11 Dec 2009 17:33:53 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B9A5F3A67FC for ; Fri, 11 Dec 2009 17:33:52 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUI009CQN03EM@szxga03-in.huawei.com> for p2psip@ietf.org; Sat, 12 Dec 2009 09:33:39 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUI001SCN033K@szxga03-in.huawei.com> for p2psip@ietf.org; Sat, 12 Dec 2009 09:33:39 +0800 (CST) Received: from windows8d787f9 (bzq-79-180-103-127.red.bezeqint.net [79.180.103.127]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUI002F5MZXZ1@szxml02-in.huawei.com>; Sat, 12 Dec 2009 09:33:39 +0800 (CST) Date: Sat, 12 Dec 2009 03:30:33 +0200 From: Roni Even In-reply-to: To: 'Brian Rosen' , "'David A. Bryan'" Message-id: <013b01ca7aca$b64c0be0$22e423a0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=windows-1255 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: Acp6rb8/bxiyckGwvkqYH4KCOnhUBwAHJDiA References: <8b2769930912111253q423f8d30h161900f38b2d28a5@mail.gmail.com> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 12 Dec 2009 01:33:54 -0000 Brian, If the reason for security is to not lose security about let others know = who I am talking too I would except that all "411" directory services will = be encrypted. Probably people do not care for that.=20 Roni > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf Of Brian Rosen > Sent: Saturday, December 12, 2009 12:03 AM > To: David A. Bryan > Cc: P2PSIP WG > Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as > part of the WGLC >=20 > >=20 > Sorry, don't buy it. >=20 > There is no flaw in SIP wrt what we are discussing. TLS is "mandatory > to > implement", but it's not integral to the protocol. I don't want to go > down > the path of yet another insecure protocol. >=20 > Suppose there were 7 RTs for each branch of direct response, although > that > isn't true for a null ciphersuite, right? >=20 > For the use cases we have so far considered, who cares? You are = trying > to > optimize something that doesn't seem to matter enough to lose the > security > of knowing who you are talking to. >=20 > One peer won't see that much traffic, and the total of all of them > isn't > really much of an issue. If it's a big deal to you, keep persistent > connections for all the fingers (or equivalent). >=20 > Brian >=20 > On 12/11/09 3:53 PM, "David A. Bryan" wrote: >=20 > > > > > > The problem here is that this isn't SIP or a protocol like it, and = so > > the design and deployment lessons don't precisely apply. While = people > > often call SIP "peer-to-peer", it isn't in the same sense as we use > > that term when talking about a DHT. Assuming we make a protocol that > > works for a variety of routing techniques and DHT types, rather than > > the somewhat narrow subspace of just recursive response chord-like, > > the way messages are routed is highly variable. In many cases, > several > > new connections may be required for each transaction, just to get a > > reference to reach the remote party (then connecting to the remote > > party becomes very SIP like, and yes, (D)TLS may make sense once you > > are establishing a communications connection...) > > > > We got burned with a design flaw for SIP, but that doesn't mean that > > what would have worked for SIP is the right answer for every > protocol. > > > > Direct response. Parallel search with direct response. Iterative > > search, Parallel iterative search...all of these are valid P2P > > mechanisms in the literature, and in the deployed 'net, yet for all > > three, the overhead of DTLS, 7 messages per hop (and there could be > > many hops in iterative parallel search) as I cited in my reference = in > > the initial email, is too much for a connection that may only be = used > > once. Keep in mind it still at that point hasn't provided end-to-end > > security either (although obviously we can)... > > > > I have a paper in submission for publication that shows that even = for > > networks with many NATs, direct response results in reduced message > > counts, and for large overlays, even reduces mean search time > (overlay > > wide) in some cases, depending on the fraction behind NATs. While I > > believe in v6-v6 NATs, over time, direct will make increasing sense > in > > a less NAT filled world, and the cost of TLS will not make sense as > > the one and only security mechanism for such a system. > > > > Security makes sense...but mandating one and only one mechanism will > > do one of two things: "Future-proof" the protocol (meaning the > > protocol protects itself against the pesky future and just doesn't > get > > used), or ensure that people will just break the spec. I'd rather > > avoid both outcomes... > > > > David > > > > On Fri, Dec 11, 2009 at 2:29 PM, Brian Rosen > wrote: > >> > >> Lots of implementations of a protocol like, say, SIP, don't "care" > to use > >> tls. =A0It gets low on the implementation priority list, many > implementations > >> don't have it, and then even the ones that do can't use it because > the other > >> side doesn't. =A0We have lousy, very lousy experience with security > options > >> like that. =A0We KNOW what happens when we don't make it integral = to > the > >> operation of the protocol. =A0I don't want to go through that = again. > >> > >> While there is no such thing as protocol police, I think the notion > that > >> p2pip ALWAYS uses D/TLS is a very useful, powerful, and important > >> characteristic of the protocol. =A0If you don't need much security, > negotiate > >> a null cipher suite. =A0The overhead is low, the benefits are = great. > >> > >> Brian > >> > >> > >> On 12/11/09 2:07 PM, "jc" wrote: > >> > >>> Some individuals may not care to use tls or dtls. These standards > >>> aren't practical in all cases. Encrypted transports a MUST but > >>> mechanism should be optional. This is better than people not using > >>> this draft and resolves conearns about the underlying transports > lack > >>> of performance in certain use cases. > >>> > >>> Thinking Chord only as a topology plugin is too narrow from a > security > >>> performance perspective. I have bad experience with Kademlia as a > >>> topology plugin. If you understand Kademlia you should understand > how > >>> the routing table functions and how the transports reflect that. > All > >>> topology plugins will be forced to tune themselves to d/tls which > the > >>> result is a less efficient system. > >>> > >>> I don't see where anyone mentioned throw out encryption entirely > but I > >>> may be wrong. > >>> > >>> Julian > >>> > >>> Sent from my iPhone > >>> > >>> On Dec 11, 2009, at 1:16 PM, Brian Rosen = wrote: > >>> > >>>> > >>>> I disagree. > >>>> > >>>> The problem is that we have a whole lot of history and = experience. > >>>> > >>>> The experience is that if we don't insist, and make security > >>>> integral to the > >>>> protocol, it doesn't get implemented and we have a majority of > >>>> insecure > >>>> systems. > >>>> > >>>> If we do insist, the cost of the security is reasonable: the dire > >>>> predictions that it's too costly, too hard, ... don't happen. > >>>> > >>>> No amount of text explaining when the security mechanism is or > isn't > >>>> appropriate works. =A0You have to make the mechanism integral to = the > >>>> operation > >>>> of the protocol, as we have done here. > >>>> > >>>> I don't see anything in p2psip which would be different then our > >>>> history and > >>>> experience. =A0The costs aren't as bad as you fear. =A0The = probability > >>>> of nearly > >>>> every system being implemented insecurely is very high if you = make > it > >>>> optional. > >>>> > >>>> Don't do that. > >>>> > >>>> Brian > >>>> > >>>> > >>>> On 12/11/09 12:49 PM, "Michael Chen" > wrote: > >>>> > >>>>> I too agree with the three of you. D/TLS should be optional. > >>>>> Several of my > >>>>> previous post voice concerns about redundancy and efficiency of > the > >>>>> transport > >>>>> layer. > >>>>> > >>>>> --Michael > >>>>>> -------- Original Message -------- > >>>>>> Subject: Re: [P2PSIP] Concerns, questions and nits about base - > 06 as > >>>>>> part of the WGLC > >>>>>> From: jc > >>>>>> Date: Fri, December 11, 2009 7:26 am > >>>>>> To: Ari Keranen > >>>>>> Cc: P2PSIP WG > >>>>>> > >>>>>> I said this about 7 months ago and I still agree that there > should > >>>>>> be > >>>>>> no mandatory transport layer encryption as this should be > provided > >>>>>> outside of the scope of this draft. > >>>>>> > >>>>>> Julian > >>>>>> > >>>>>> Sent from my iPhone > >>>>>> > >>>>>> On Dec 11, 2009, at 5:39 AM, Ari Keranen > >>>>>> > >>>>>> wrote: > >>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> David A. Bryan wrote: > >>>>>>>> Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts > >>>>>>>> I=B9ve raised this issue before, but I=B9m hoping that now = that > >>>>>>>> people have had a bit more time to think about all the use > cases, > >>>>>>>> see what it means in the real world, etc., there might be a > bit mo > >>>>>>>> re support for modifying the requirement for TLS/DTLS. > TLS/DTLS ma > >>>>>>>> kes sense in some cases, but if we are expecting RELOAD to be > reus > >>>>>>>> able, it is clear to me that it does not make sense in all > cases. > >>>>>>>> It was familiar > >>>>>>>> to the editors, and well understood, so it made sense as a > >>>>>>>> proposal, > >>>>>>>> but I disagree with it being the mandatory/only solution. > >>>>>>> > >>>>>>> I fully agree with David that making (D)TLS mandatory is not a > good > >>>>>>> idea, especially concerning re-usability of the protocol in > >>>>>>> scenarios > >>>>>>> where you already have similar security features provided by > the > >>>>>>> underlying system. > >>>>>>> > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Ari > >>>>>>> _______________________________________________ > >>>>>>> P2PSIP mailing list > >>>>>>> P2PSIP@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/p2psip > >>>>>> _______________________________________________ > >>>>>> P2PSIP mailing list > >>>>>> P2PSIP@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/p2psip > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> P2PSIP mailing list > >>>>> P2PSIP@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/p2psip > >>>> > >>>> > >>>> _______________________________________________ > >>>> P2PSIP mailing list > >>>> P2PSIP@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/p2psip > >> > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www.ietf.org/mailman/listinfo/p2psip > >> >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From julian@orchidseed.org Fri Dec 11 18:16:29 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767E73A67FC for ; Fri, 11 Dec 2009 18:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ZyKxrqCQy61X for ; Fri, 11 Dec 2009 18:16:28 -0800 (PST) Received: from n25.c05.mtsvc.net (n25.c05.mtsvc.net [70.32.68.25]) by core3.amsl.com (Postfix) with ESMTP id 18A793A6808 for ; Fri, 11 Dec 2009 18:16:28 -0800 (PST) Received: from adsl-66-230-71.asm.bellsouth.net ([98.66.230.71]:36826 helo=[172.16.1.233]) by n25.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NJHWl-0002tt-1K; Fri, 11 Dec 2009 18:16:12 -0800 References: <8b2769930912111253q423f8d30h161900f38b2d28a5@mail.gmail.com> <013b01ca7aca$b64c0be0$22e423a0$%roni@huawei.com> Message-Id: <1BA285D9-A0C8-4164-B131-6FF02628DA7F@orchidseed.org> From: jc To: Roni Even In-Reply-To: <013b01ca7aca$b64c0be0$22e423a0$%roni@huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Fri, 11 Dec 2009 21:16:02 -0500 X-Authenticated-User: 72798 julian@orchidseed.org Cc: P2PSIP WG Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 12 Dec 2009 02:16:29 -0000 The overlay should obtain the transport layer security mechanism from the configuration file. I was a senior engineer at gizmo5 recently aquired by google. One thing that occured prior to my arrival was that we had bricked ourselfs off via TLS and this could only decrypt/encrypt gizmo to gizmo. Skype has a hard coded security mechanism of the base overlay protocol. Let's not do the same. Julian From audet.francois@gmail.com Fri Dec 11 20:15:45 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3CBE3A6955 for ; Fri, 11 Dec 2009 20:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 NCQ0x5wWeBmQ for ; Fri, 11 Dec 2009 20:15:40 -0800 (PST) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 301983A679F for ; Fri, 11 Dec 2009 20:15:27 -0800 (PST) Received: by ywh38 with SMTP id 38so1503988ywh.6 for ; Fri, 11 Dec 2009 20:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=4MId2AdRQkkRg6KLqruDqoopJGLs3WBJ0gihNJ4j8kU=; b=WR54l9+h3lGcf7fzbWxh88h6R4fAsUFpycnbO+hGN90EYyMFntRGCtLwtk9P+LXJbI X+I3QZ08zSp8JL/vMpQMc5mrMTeY3tNMtNeYQ4Lx+UoHA79GBGQtT+zDK72knCAX0Fi2 8qPBZTSY0ls35Ts9dgpP0rAGIr/IRfsYp57Uc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=j4nHDbp5UTKBSTDFRBvhGGD9wdQopyCsSs79eWN4V1SpkArXfn/pop7s2lydoxWCCK RKpkPlbHVoN8t/dnhnVb9VAFRoF6mQ/7g/GSAV4JsbqmSTxb5KSMqmoJPG6mBwyQA4SO YFhlCVS6D0lsnbpInXEsnaK+OvuNodPrb5w14= Received: by 10.101.28.1 with SMTP id f1mr764987anj.18.1260591311889; Fri, 11 Dec 2009 20:15:11 -0800 (PST) Received: from ?192.168.15.100? (adsl-75-55-213-208.dsl.pltn13.sbcglobal.net [75.55.213.208]) by mx.google.com with ESMTPS id 22sm1152864yxe.3.2009.12.11.20.15.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 11 Dec 2009 20:15:10 -0800 (PST) Message-Id: <401A34AA-561A-4779-8535-60CF2F98CD4B@gmail.com> From: Francois Audet To: P2PSIP WG In-Reply-To: <1BA285D9-A0C8-4164-B131-6FF02628DA7F@orchidseed.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 11 Dec 2009 20:15:06 -0800 References: <8b2769930912111253q423f8d30h161900f38b2d28a5@mail.gmail.com> <013b01ca7aca$b64c0be0$22e423a0$%roni@huawei.com> <1BA285D9-A0C8-4164-B131-6FF02628DA7F@orchidseed.org> X-Mailer: Apple Mail (2.936) Cc: Roni Even Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 12 Dec 2009 04:15:45 -0000 Perhaps what should be done is mandate TLS for now, and leave it open for alternative mechanisms to be later standardized. On Dec 11, 2009, at 18:16 , jc wrote: > The overlay should obtain the transport layer security mechanism > from the configuration file. > > I was a senior engineer at gizmo5 recently aquired by google. One > thing that occured prior to my arrival was that we had bricked > ourselfs off via TLS and this could only decrypt/encrypt gizmo to > gizmo. Skype has a hard coded security mechanism of the base overlay > protocol. > > Let's not do the same. > > Julian_______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From Even.roni@huawei.com Fri Dec 11 23:15:33 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1363A67EF for ; Fri, 11 Dec 2009 23:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.673 X-Spam-Level: X-Spam-Status: No, score=-0.673 tagged_above=-999 required=5 tests=[AWL=1.926, BAYES_00=-2.599] 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 OmD7Pdsy+ghA for ; Fri, 11 Dec 2009 23:15:31 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 4EF563A680C for ; Fri, 11 Dec 2009 23:15:31 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUJ00CKC2TGBE@szxga01-in.huawei.com> for p2psip@ietf.org; Sat, 12 Dec 2009 15:15:17 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUJ00D7N2TGO2@szxga01-in.huawei.com> for p2psip@ietf.org; Sat, 12 Dec 2009 15:15:16 +0800 (CST) Received: from windows8d787f9 (bzq-79-180-103-127.red.bezeqint.net [79.180.103.127]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUJ00DQH2T8AP@szxml01-in.huawei.com>; Sat, 12 Dec 2009 15:15:16 +0800 (CST) Date: Sat, 12 Dec 2009 09:12:10 +0200 From: Roni Even In-reply-to: <401A34AA-561A-4779-8535-60CF2F98CD4B@gmail.com> To: 'Francois Audet' , 'P2PSIP WG' Message-id: <014301ca7afa$7028dfa0$507a9ee0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acp64bZoISyl2EyoSByEA+mTodLxKgAGEZHA References: <8b2769930912111253q423f8d30h161900f38b2d28a5@mail.gmail.com> <013b01ca7aca$b64c0be0$22e423a0$%roni@huawei.com> <1BA285D9-A0C8-4164-B131-6FF02628DA7F@orchidseed.org> <401A34AA-561A-4779-8535-60CF2F98CD4B@gmail.com> Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 12 Dec 2009 07:15:33 -0000 If you mandate using TLS you are stuck with it. You can mandate implementing it which will allow alternative mechanisms, today and in the future. The fear is that implementers will not do it but the same concerns should have been about implementing Chord in Reload Roni > -----Original Message----- > From: Francois Audet [mailto:audet.francois@gmail.com] > Sent: Saturday, December 12, 2009 6:15 AM > To: P2PSIP WG > Cc: Roni Even; jc > Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as > part of the WGLC > > Perhaps what should be done is mandate TLS for now, and leave it open > for alternative mechanisms to be later standardized. > > > On Dec 11, 2009, at 18:16 , jc wrote: > > > The overlay should obtain the transport layer security mechanism > > from the configuration file. > > > > I was a senior engineer at gizmo5 recently aquired by google. One > > thing that occured prior to my arrival was that we had bricked > > ourselfs off via TLS and this could only decrypt/encrypt gizmo to > > gizmo. Skype has a hard coded security mechanism of the base overlay > > protocol. > > > > Let's not do the same. > > > > Julian_______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip From sunchw@gmail.com Mon Dec 14 18:16:21 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 361EB3A6964 for ; Mon, 14 Dec 2009 18:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.528 X-Spam-Level: **** X-Spam-Status: No, score=4.528 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FR_IMPORT_CSS=1.889, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 Zu33v3RJY7BD for ; Mon, 14 Dec 2009 18:16:20 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 953153A6976 for ; Mon, 14 Dec 2009 18:16:15 -0800 (PST) Received: by yxe30 with SMTP id 30so4013019yxe.29 for ; Mon, 14 Dec 2009 18:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:x-mailer:mime-version:content-type; bh=tlPWVDLaVcy4P3gn9+skxg6YCOu45/cpWvqI99HsPyk=; b=FjBdwztfQVaedHqVTnpK8ohH+5JrPTy00w8+8BCK+hbI3l6FAX055+iy14Zdnx5iFP C6JwfHplN3dNuO3HgqO+bKvQdtv9u4FFIMCSv1XHnfyAEiJgWQkzqzYjfkyQaPlA730f AFJXrS32kCEbZR9srOA51OiyCKmmGE4mCUVD8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:x-mailer:mime-version :content-type; b=rqXrRpjkvLf97+sVh0LwheffsLO0eOPvbv8gw4YRprzdkVltauWqgHDxU2v6L2xNHq 3biHuCoveURoy443yYal71GwSCxZ2dU+OWw6ufw8wbmxoHQb6Qm6cuCjG2r2CgmNWS9e Yeq5mBqJmVt7yv8Orx0A9BNBGVhVzdvD5Z8N8= Received: by 10.150.174.10 with SMTP id w10mr4382739ybe.259.1260843359525; Mon, 14 Dec 2009 18:15:59 -0800 (PST) Received: from f9e13547cc5d43e ([123.117.179.196]) by mx.google.com with ESMTPS id 20sm2140338yxe.20.2009.12.14.18.15.55 (version=SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 18:15:58 -0800 (PST) Date: Tue, 15 Dec 2009 10:16:02 +0800 From: "sunchw" To: "Even.roni" Message-ID: <200912151015579374842@gmail.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon554814100615_=====" Cc: p2psip Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 15 Dec 2009 02:16:21 -0000 This is a multi-part message in MIME format. --=====003_Dragon554814100615_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCiAgDQpJIGFtIHF1aXRlIGFncmVlIHdpdGggeW91oaN0YWtlIFRMUy9EVExTIG1lY2hhbmlz bSBhcyBhIG9wdGlvbmFsIGlzc3VlIG5vdCBhIG1hbmRhdG9yeSBvbmUgd2lsbCBiZSBiZXR0ZXIg LlRoZW4gd2UgY2FuIGltcG9ydCBtb3JlIGFwcHJvcHJpYXRlIG1ldGhvZHMgZm9yIHNvbWUgc2l0 dWF0aW9ucyBpbiB0aGUgZnV0dXJloaNzdWNoIGFzIGdyb3VwIGNvbW11bmljYXRpb25zoaNyaWdo dD8NCg0KDQoNCg0KT24gMTIvMTEvMDkgMjowNSBQTSwgIlJvbmkgRXZlbiIgPEV2ZW4ucm9uaSBh dCBodWF3ZWkuY29tPiB3cm90ZToNCj4gQnJpYW4sDQo+IFRoZSBpc3N1ZSBpcyBub3QgaWYgdG8g aGF2ZSBvciBub3QgdG8gaGF2ZSBzZWN1cml0eS4gSXQgaXMgd2hhdCBsZXZlbCBvZg0KPiBzZWN1 cml0eSBpcyBzYXRpc2ZhY3RvcnkgYW5kIHRoZXJlIGlzIG5vIG9uZSBzb2x1dGlvbiBmaXRzIGFs bCwgbm90ZSBhbHNvDQo+IHRoYXQgdGhlIHAycHNpcCBzb2x1dGlvbiBzaG91bGQgYWxzbyBtYWtl IGl0IGVhc2llciB0byBub2RlcyB0byBzZXJ2ZSBhcw0KPiBwZWVycyBieSBub3QgcHV0dGluZyB0 b28gbXVjaCBidXJkZW4gb24gdGhlbS4NCj4gRGVwbG95bWVudCBvZiBzZWN1cml0eSBpcyBtb3Rp dmF0ZWQgYnkgcmVxdWlyZW1lbnRzIG9mIHRoZSBzcGVjaWZpYw0KPiBkZXBsb3ltZW50IGFuZCBu b3QgYmVjYXVzZSBvZiB0aGUgc3RhbmRhcmQsIHdoYXQgd2lsbCBoYXBwZW4gaXMgdGhhdCB5b3UN Cj4gd2lsbCBzZWUgbm8gY29tcGxpYW5jZSBpbiBjYXNlcyB3aGVyZSBwMnAgc29sdXRpb24gd2ls bCBiZSBkZXBsb3llZCBidXQNCj4gd291bGQgcHJlZmVyIGRpZmZlcmVudCBzZWN1cml0eSBtZWNo YW5pc20uIFdlIGFsc28gbmVlZCB0byBzZWUgdGhhdCB0aGVyZQ0KPiBtYXkgYmUgb3RoZXIgcDJw IG92ZXJsYXlzIGFuZCBqb2luaW5nIHBvbGljaWVzIGFzIHdlbGwgYXMgb3RoZXIgdXNhZ2VzIHdo aWNoDQo+IG1heSBoYXZlIGRpZmZlcmVudCBzZWN1cml0eSByZXF1aXJlbWVudHMuDQo+IEkgdGhp bmsgdGhhdCB0aGUgcDJwcmcgZHJhZnQgdGhhdCBvdXRsaW5lIHRoZSBzZWN1cml0eSBvcHRpb24g YXMgd2VsbCBhcw0KPiBoYXZpbmcgYSBzZWN1cml0eSBhbmFseXNpcyBmb3IgcDJwc2lwIHdpbGwg YmUgZW5vdWdoLiBNeSB0aG91Z2h0IHdhcyB0aGF0DQo+IHNwZWNpZnlpbmcgVExTL0RUTFMgd2Fz IHRvIGFkZHJlc3MgaW50ZXJvcGVyYWJpbGl0eSBidXQgdGhpcyBjYW4gYmUgZG9uZSBieQ0KPiBt YW5kYXRpbmcgaW1wbGVtZW50YXRpb24gYW5kIG5vdCB1c2FnZS4NCj4gDQo+IFJvbmkgRXZlbg0K MjAwOS0xMi0xNSANCg0KDQoNCnN1bmNodyANCg== --=====003_Dragon554814100615_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zOm8gPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6 b2ZmaWNlIj48SEVBRD4NCjxTVFlMRSB0eXBlPXRleHQvY3NzPkBpbXBvcnQgdXJsKCBDOlxEb2N1 bWVudHMgYW5kIFNldHRpbmdzXGRlbGxcTG9jYWwgU2V0dGluZ3NcVGVtcG9yYXJ5IEludGVybmV0 IEZpbGVzXHNjcm9sbGJhci5jc3MgKTsNCjwvU1RZTEU+DQoNCjxNRVRBIGh0dHAtZXF1aXY9Q29u dGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1HQjIzMTIiPg0KPE1FVEEgY29u dGVudD0iTVNIVE1MIDYuMDAuMjkwMC41ODgwIiBuYW1lPUdFTkVSQVRPUj48TElOSyANCmhyZWY9 IkJMT0NLUVVPVEV7bWFyZ2luLVRvcDogMHB4OyBtYXJnaW4tQm90dG9tOiAwcHg7IG1hcmdpbi1M ZWZ0OiAyZW19IiANCnJlbD1zdHlsZXNoZWV0PjwvSEVBRD4NCjxCT0RZIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IE1BUkdJTjogMTBweDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJVj48Rk9O VCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPjwhLS1TdGFydEZyYWdtZW50LS0+PEZPTlQgZmFjZT0iy87M5SwgTVMgU29uZyIg c2l6ZT0zPiZuYnNwOzwvRk9OVD4gDQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9 IlRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBQQUdFLUJSRUFLLUJFRk9SRTogYXV0bzsg TUFSR0lOOiAwcHQ7IFBBR0UtQlJFQUstQUZURVI6IGF1dG87IExBWU9VVC1HUklELU1PREU6IGJv dGg7IFdPUkQtQlJFQUs6IG5vcm1hbDsgRElSRUNUSU9OOiBsdHI7IFRFWFQtSU5ERU5UOiAwcHQ7 IExJTkUtSEVJR0hUOiBub3JtYWw7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVtZXJpYzsg VEVYVC1BTElHTjoganVzdGlmeTsgbXNvLXBhZ2luYXRpb246IG5vbmU7IG1zby1vdXRsaW5lLWxl dmVsOiBib2R5LXRleHQ7IG1zby1oeXBoZW5hdGU6IGF1dG87IG1zby1sYXlvdXQtZ3JpZC1hbGln bjogYXV0bzsgcHVuY3R1YXRpb24tdHJpbTogbm9uZTsgcHVuY3R1YXRpb24td3JhcDogaGFuZ2lu ZzsgbXNvLWxpbmUtYnJlYWstb3ZlcnJpZGU6IG5vbmU7IG1zby12ZXJ0aWNhbC1hbGlnbi1hbHQ6 IGF1dG8iPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTAuNXB0OyBWRVJUSUNBTC1BTElHTjog YmFzZWxpbmU7IFRFWFQtVFJBTlNGT1JNOiBub25lOyBDT0xPUjogd2luZG93dGV4dDsgRk9OVC1G QU1JTFk6IFRpbWVzIE5ldyBSb21hbjsgRk9OVC1WQVJJQU5UOiBub3JtYWw7IG1zby1hc2NpaS1m b250LWZhbWlseTogVGltZXMgTmV3IFJvbWFuOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogy87M 5SI+SSANCmFtIHF1aXRlIGFncmVlIHdpdGggeW91oaN0YWtlIFRMUy9EVExTIG1lY2hhbmlzbSBh cyBhIG9wdGlvbmFsIGlzc3VlIG5vdCBhIA0KbWFuZGF0b3J5IG9uZSB3aWxsIGJlIGJldHRlciAu VGhlbiB3ZSBjYW4gaW1wb3J0IG1vcmUgYXBwcm9wcmlhdGUgbWV0aG9kcyBmb3IgDQpzb21lIHNp dHVhdGlvbnMgaW4gdGhlIGZ1dHVyZaGjc3VjaCBhcyBncm91cCANCmNvbW11bmljYXRpb25zoaNy aWdodD88bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9I2MwYzBjMCBzaXplPTI+DQo8RElWPk9u Jm5ic3A7MTIvMTEvMDkmbmJzcDsyOjA1Jm5ic3A7UE0sJm5ic3A7IlJvbmkmbmJzcDtFdmVuIiZu YnNwOyZsdDtFdmVuLnJvbmkmbmJzcDthdCZuYnNwO2h1YXdlaS5jb20mZ3Q7Jm5ic3A7d3JvdGU6 PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7QnJpYW4sPC9ESVY+DQo8RElWPiZn dDsmbmJzcDtUaGUmbmJzcDtpc3N1ZSZuYnNwO2lzJm5ic3A7bm90Jm5ic3A7aWYmbmJzcDt0byZu YnNwO2hhdmUmbmJzcDtvciZuYnNwO25vdCZuYnNwO3RvJm5ic3A7aGF2ZSZuYnNwO3NlY3VyaXR5 LiZuYnNwO0l0Jm5ic3A7aXMmbmJzcDt3aGF0Jm5ic3A7bGV2ZWwmbmJzcDtvZjwvRElWPg0KPERJ Vj4mZ3Q7Jm5ic3A7c2VjdXJpdHkmbmJzcDtpcyZuYnNwO3NhdGlzZmFjdG9yeSZuYnNwO2FuZCZu YnNwO3RoZXJlJm5ic3A7aXMmbmJzcDtubyZuYnNwO29uZSZuYnNwO3NvbHV0aW9uJm5ic3A7Zml0 cyZuYnNwO2FsbCwmbmJzcDtub3RlJm5ic3A7YWxzbzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7dGhh dCZuYnNwO3RoZSZuYnNwO3AycHNpcCZuYnNwO3NvbHV0aW9uJm5ic3A7c2hvdWxkJm5ic3A7YWxz byZuYnNwO21ha2UmbmJzcDtpdCZuYnNwO2Vhc2llciZuYnNwO3RvJm5ic3A7bm9kZXMmbmJzcDt0 byZuYnNwO3NlcnZlJm5ic3A7YXM8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3BlZXJzJm5ic3A7Ynkm bmJzcDtub3QmbmJzcDtwdXR0aW5nJm5ic3A7dG9vJm5ic3A7bXVjaCZuYnNwO2J1cmRlbiZuYnNw O29uJm5ic3A7dGhlbS48L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0RlcGxveW1lbnQmbmJzcDtvZiZu YnNwO3NlY3VyaXR5Jm5ic3A7aXMmbmJzcDttb3RpdmF0ZWQmbmJzcDtieSZuYnNwO3JlcXVpcmVt ZW50cyZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c3BlY2lmaWM8L0RJVj4NCjxESVY+Jmd0OyZuYnNw O2RlcGxveW1lbnQmbmJzcDthbmQmbmJzcDtub3QmbmJzcDtiZWNhdXNlJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtzdGFuZGFyZCwmbmJzcDt3aGF0Jm5ic3A7d2lsbCZuYnNwO2hhcHBlbiZuYnNwO2lz Jm5ic3A7dGhhdCZuYnNwO3lvdTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7d2lsbCZuYnNwO3NlZSZu YnNwO25vJm5ic3A7Y29tcGxpYW5jZSZuYnNwO2luJm5ic3A7Y2FzZXMmbmJzcDt3aGVyZSZuYnNw O3AycCZuYnNwO3NvbHV0aW9uJm5ic3A7d2lsbCZuYnNwO2JlJm5ic3A7ZGVwbG95ZWQmbmJzcDti dXQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3dvdWxkJm5ic3A7cHJlZmVyJm5ic3A7ZGlmZmVyZW50 Jm5ic3A7c2VjdXJpdHkmbmJzcDttZWNoYW5pc20uJm5ic3A7V2UmbmJzcDthbHNvJm5ic3A7bmVl ZCZuYnNwO3RvJm5ic3A7c2VlJm5ic3A7dGhhdCZuYnNwO3RoZXJlPC9ESVY+DQo8RElWPiZndDsm bmJzcDttYXkmbmJzcDtiZSZuYnNwO290aGVyJm5ic3A7cDJwJm5ic3A7b3ZlcmxheXMmbmJzcDth bmQmbmJzcDtqb2luaW5nJm5ic3A7cG9saWNpZXMmbmJzcDthcyZuYnNwO3dlbGwmbmJzcDthcyZu YnNwO290aGVyJm5ic3A7dXNhZ2VzJm5ic3A7d2hpY2g8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO21h eSZuYnNwO2hhdmUmbmJzcDtkaWZmZXJlbnQmbmJzcDtzZWN1cml0eSZuYnNwO3JlcXVpcmVtZW50 cy48L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0kmbmJzcDt0aGluayZuYnNwO3RoYXQmbmJzcDt0aGUm bmJzcDtwMnByZyZuYnNwO2RyYWZ0Jm5ic3A7dGhhdCZuYnNwO291dGxpbmUmbmJzcDt0aGUmbmJz cDtzZWN1cml0eSZuYnNwO29wdGlvbiZuYnNwO2FzJm5ic3A7d2VsbCZuYnNwO2FzPC9ESVY+DQo8 RElWPiZndDsmbmJzcDtoYXZpbmcmbmJzcDthJm5ic3A7c2VjdXJpdHkmbmJzcDthbmFseXNpcyZu YnNwO2ZvciZuYnNwO3AycHNpcCZuYnNwO3dpbGwmbmJzcDtiZSZuYnNwO2Vub3VnaC4mbmJzcDtN eSZuYnNwO3Rob3VnaHQmbmJzcDt3YXMmbmJzcDt0aGF0PC9ESVY+DQo8RElWPiZndDsmbmJzcDtz cGVjaWZ5aW5nJm5ic3A7VExTL0RUTFMmbmJzcDt3YXMmbmJzcDt0byZuYnNwO2FkZHJlc3MmbmJz cDtpbnRlcm9wZXJhYmlsaXR5Jm5ic3A7YnV0Jm5ic3A7dGhpcyZuYnNwO2NhbiZuYnNwO2JlJm5i c3A7ZG9uZSZuYnNwO2J5PC9ESVY+DQo8RElWPiZndDsmbmJzcDttYW5kYXRpbmcmbmJzcDtpbXBs ZW1lbnRhdGlvbiZuYnNwO2FuZCZuYnNwO25vdCZuYnNwO3VzYWdlLjwvRElWPg0KPERJVj4mZ3Q7 Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtSb25pJm5ic3A7RXZlbjwvRElWPjIwMDktMTIt MTUgPC9GT05UPjwvRElWPjxGT05UIGZhY2U9VmVyZGFuYSANCnNpemU9Mj4NCjxIUiBzdHlsZT0i V0lEVEg6IDEyMnB4OyBIRUlHSFQ6IDJweCIgYWxpZ249bGVmdCBTSVpFPTI+DQoNCjxESVY+PEZP TlQgZmFjZT1WZXJkYW5hIGNvbG9yPSNjMGMwYzAgc2l6ZT0yPjxTUEFOPnN1bmNodzwvU1BBTj4g DQo8L0ZPTlQ+PC9ESVY+PC9GT05UPjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon554814100615_=====-- From melodysong@huawei.com Wed Dec 16 19:51:53 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45E33A692A for ; Wed, 16 Dec 2009 19:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.707 X-Spam-Level: X-Spam-Status: No, score=0.707 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 fQ5R7nDTRzKW for ; Wed, 16 Dec 2009 19:51:52 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 62D893A690F for ; Wed, 16 Dec 2009 19:51:52 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUS00JJE2PRU6@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 17 Dec 2009 11:51:27 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUS00BR22PQ15@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 17 Dec 2009 11:51:27 +0800 (CST) Received: from s64081a ([10.164.12.24]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUS002VE2PNG7@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 17 Dec 2009 11:51:26 +0800 (CST) Date: Thu, 17 Dec 2009 11:51:23 +0800 From: Song Haibin In-reply-to: To: 'Salman Abdul Baset' , 'jc' Message-id: <000d01ca7ecc$3399dc30$180ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acp6mNwd95GFmiBMRtmkOFHSGxT4dQELCnwg Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 17 Dec 2009 03:51:54 -0000 TLS/DTLS is not good to the DHT algorithms that use iterative routing. And it also prevents using of direct response to a certain extent. Having a security analysis draft for p2psip for deployers to consider threats and possible solution in their deployment scenarios will qualify. For interoperability, it depends on both the standard and the number of deployers who want to obey the standard. Thanks, Haibin > -----Original Message----- > From: p2psip-bounces@ietf.org > [mailto:p2psip-bounces@ietf.org] On Behalf Of Salman Abdul Baset > Sent: Saturday, December 12, 2009 3:33 AM > To: jc > Cc: P2PSIP WG > Subject: Re: [P2PSIP] Concerns, questions and nits about base > -06 as part of the WGLC > > Kademlia does iterative routing with parallel requests, and > iterative routing has to pay the penalty of TLS/DTLS > connection establishment at every hop which is at least 1.5 RTT. > > The alternative is to devise a secure transport protocol or > optimize DTLS/TLS to reduce the connection establishment > penalty. Security folks may argue that it is a non-starter at IETF. > > Yet, another alternative is to design a custom secure > transport. But interoperability is the obvious looser. > > In general, for Internet scale deployment, the idea of trying > to make all nodes, no matter what their connectivity, fully > participate in the overlay as a peer is highly questionable. > > -s > > On Fri, 11 Dec 2009, jc wrote: > > > Some individuals may not care to use tls or dtls. These standards > > aren't practical in all cases. Encrypted transports a MUST but > > mechanism should be optional. This is better than people not using > > this draft and resolves conearns about the underlying > transports lack > > of performance in certain use cases. > > > > Thinking Chord only as a topology plugin is too narrow from > a security > > performance perspective. I have bad experience with Kademlia as a > > topology plugin. If you understand Kademlia you should > understand how > > the routing table functions and how the transports reflect > that. All > > topology plugins will be forced to tune themselves to d/tls > which the > > result is a less efficient system. > > > > I don't see where anyone mentioned throw out encryption > entirely but I > > may be wrong. > > > > Julian > > > > Sent from my iPhone > > > > On Dec 11, 2009, at 1:16 PM, Brian Rosen wrote: > > > >> > >> I disagree. > >> > >> The problem is that we have a whole lot of history and experience. > >> > >> The experience is that if we don't insist, and make > security integral > >> to the protocol, it doesn't get implemented and we have a > majority of > >> insecure systems. > >> > >> If we do insist, the cost of the security is reasonable: the dire > >> predictions that it's too costly, too hard, ... don't happen. > >> > >> No amount of text explaining when the security mechanism > is or isn't > >> appropriate works. You have to make the mechanism integral to the > >> operation of the protocol, as we have done here. > >> > >> I don't see anything in p2psip which would be different then our > >> history and experience. The costs aren't as bad as you fear. The > >> probability of nearly every system being implemented insecurely is > >> very high if you make it optional. > >> > >> Don't do that. > >> > >> Brian > >> > >> > >> On 12/11/09 12:49 PM, "Michael Chen" > wrote: > >> > >>> I too agree with the three of you. D/TLS should be optional. > >>> Several of my > >>> previous post voice concerns about redundancy and > efficiency of the > >>> transport layer. > >>> > >>> --Michael > >>>> -------- Original Message -------- > >>>> Subject: Re: [P2PSIP] Concerns, questions and nits about > base -06 > >>>> as part of the WGLC > >>>> From: jc > >>>> Date: Fri, December 11, 2009 7:26 am > >>>> To: Ari Keranen > >>>> Cc: P2PSIP WG > >>>> > >>>> I said this about 7 months ago and I still agree that > there should > >>>> be no mandatory transport layer encryption as this should be > >>>> provided outside of the scope of this draft. > >>>> > >>>> Julian > >>>> > >>>> Sent from my iPhone > >>>> > >>>> On Dec 11, 2009, at 5:39 AM, Ari Keranen > >>>> > >>>> wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> David A. Bryan wrote: > >>>>>> Concern 1: Mandatory TLS/DTLS Inappropriate in some > Contexts I've > >>>>>> raised this issue before, but I'm hoping that now that people > >>>>>> have had a bit more time to think about all the use cases, see > >>>>>> what it means in the real world, etc., there might be > a bit mo re > >>>>>> support for modifying the requirement for TLS/DTLS. > TLS/DTLS ma > >>>>>> kes sense in some cases, but if we are expecting RELOAD to be > >>>>>> reus able, it is clear to me that it does not make > sense in all cases. > >>>>>> It was familiar > >>>>>> to the editors, and well understood, so it made sense as a > >>>>>> proposal, but I disagree with it being the mandatory/only > >>>>>> solution. > >>>>> > >>>>> I fully agree with David that making (D)TLS mandatory is not a > >>>>> good idea, especially concerning re-usability of the > protocol in > >>>>> scenarios where you already have similar security features > >>>>> provided by the underlying system. > >>>>> > >>>>> > >>>>> Cheers, > >>>>> Ari > >>>>> _______________________________________________ > >>>>> P2PSIP mailing list > >>>>> P2PSIP@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/p2psip > >>>> _______________________________________________ > >>>> P2PSIP mailing list > >>>> P2PSIP@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/p2psip > >>> > >>> > >>> _______________________________________________ > >>> P2PSIP mailing list > >>> P2PSIP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/p2psip > >> > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > > > From julian@orchidseed.org Thu Dec 17 13:20:09 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BCDA28C13D for ; Thu, 17 Dec 2009 13:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 vnQ+tngOim8u for ; Thu, 17 Dec 2009 13:20:07 -0800 (PST) Received: from n26.c05.mtsvc.net (n26.c05.mtsvc.net [70.32.68.26]) by core3.amsl.com (Postfix) with ESMTP id 0F5CD3A6778 for ; Thu, 17 Dec 2009 13:20:07 -0800 (PST) Received: from adsl-66-230-71.asm.bellsouth.net ([98.66.230.71]:36573 helo=[172.16.1.230]) by n26.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NLNlG-0008VG-Ob; Thu, 17 Dec 2009 13:19:52 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: jc In-Reply-To: <000d01ca7ecc$3399dc30$180ca40a@china.huawei.com> Date: Thu, 17 Dec 2009 16:19:42 -0500 Content-Transfer-Encoding: 7bit Message-Id: <798A2C13-3755-4D09-8546-5689305889A3@orchidseed.org> References: <000d01ca7ecc$3399dc30$180ca40a@china.huawei.com> To: Song Haibin X-Mailer: Apple Mail (2.1077) X-Authenticated-User: 72798 julian@orchidseed.org Cc: 'Salman Abdul Baset' , 'P2PSIP WG' Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 17 Dec 2009 21:20:09 -0000 Nor is ICE good for overlays making use of iterative routing. Julian On Dec 16, 2009, at 10:51 PM, Song Haibin wrote: > > TLS/DTLS is not good to the DHT algorithms that use iterative routing. And > it also prevents using of direct response to a certain extent. Having a > security analysis draft for p2psip for deployers to consider threats and > possible solution in their deployment scenarios will qualify. > > For interoperability, it depends on both the standard and the number of > deployers who want to obey the standard. > > Thanks, > Haibin > >> -----Original Message----- >> From: p2psip-bounces@ietf.org >> [mailto:p2psip-bounces@ietf.org] On Behalf Of Salman Abdul Baset >> Sent: Saturday, December 12, 2009 3:33 AM >> To: jc >> Cc: P2PSIP WG >> Subject: Re: [P2PSIP] Concerns, questions and nits about base >> -06 as part of the WGLC >> >> Kademlia does iterative routing with parallel requests, and >> iterative routing has to pay the penalty of TLS/DTLS >> connection establishment at every hop which is at least 1.5 RTT. > >> >> The alternative is to devise a secure transport protocol or >> optimize DTLS/TLS to reduce the connection establishment >> penalty. Security folks may argue that it is a non-starter at IETF. >> >> Yet, another alternative is to design a custom secure >> transport. But interoperability is the obvious looser. >> >> In general, for Internet scale deployment, the idea of trying >> to make all nodes, no matter what their connectivity, fully >> participate in the overlay as a peer is highly questionable. >> >> -s >> >> On Fri, 11 Dec 2009, jc wrote: >> >>> Some individuals may not care to use tls or dtls. These standards >>> aren't practical in all cases. Encrypted transports a MUST but >>> mechanism should be optional. This is better than people not using >>> this draft and resolves conearns about the underlying >> transports lack >>> of performance in certain use cases. >>> >>> Thinking Chord only as a topology plugin is too narrow from >> a security >>> performance perspective. I have bad experience with Kademlia as a >>> topology plugin. If you understand Kademlia you should >> understand how >>> the routing table functions and how the transports reflect >> that. All >>> topology plugins will be forced to tune themselves to d/tls >> which the >>> result is a less efficient system. >>> >>> I don't see where anyone mentioned throw out encryption >> entirely but I >>> may be wrong. >>> >>> Julian >>> >>> Sent from my iPhone >>> >>> On Dec 11, 2009, at 1:16 PM, Brian Rosen wrote: >>> >>>> >>>> I disagree. >>>> >>>> The problem is that we have a whole lot of history and experience. >>>> >>>> The experience is that if we don't insist, and make >> security integral >>>> to the protocol, it doesn't get implemented and we have a >> majority of >>>> insecure systems. >>>> >>>> If we do insist, the cost of the security is reasonable: the dire >>>> predictions that it's too costly, too hard, ... don't happen. >>>> >>>> No amount of text explaining when the security mechanism >> is or isn't >>>> appropriate works. You have to make the mechanism integral to the >>>> operation of the protocol, as we have done here. >>>> >>>> I don't see anything in p2psip which would be different then our >>>> history and experience. The costs aren't as bad as you fear. The >>>> probability of nearly every system being implemented insecurely is >>>> very high if you make it optional. >>>> >>>> Don't do that. >>>> >>>> Brian >>>> >>>> >>>> On 12/11/09 12:49 PM, "Michael Chen" >> wrote: >>>> >>>>> I too agree with the three of you. D/TLS should be optional. >>>>> Several of my >>>>> previous post voice concerns about redundancy and >> efficiency of the >>>>> transport layer. >>>>> >>>>> --Michael >>>>>> -------- Original Message -------- >>>>>> Subject: Re: [P2PSIP] Concerns, questions and nits about >> base -06 >>>>>> as part of the WGLC >>>>>> From: jc >>>>>> Date: Fri, December 11, 2009 7:26 am >>>>>> To: Ari Keranen >>>>>> Cc: P2PSIP WG >>>>>> >>>>>> I said this about 7 months ago and I still agree that >> there should >>>>>> be no mandatory transport layer encryption as this should be >>>>>> provided outside of the scope of this draft. >>>>>> >>>>>> Julian >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On Dec 11, 2009, at 5:39 AM, Ari Keranen >>>>>> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> David A. Bryan wrote: >>>>>>>> Concern 1: Mandatory TLS/DTLS Inappropriate in some >> Contexts I've >>>>>>>> raised this issue before, but I'm hoping that now that people >>>>>>>> have had a bit more time to think about all the use cases, see >>>>>>>> what it means in the real world, etc., there might be >> a bit mo re >>>>>>>> support for modifying the requirement for TLS/DTLS. >> TLS/DTLS ma >>>>>>>> kes sense in some cases, but if we are expecting RELOAD to be >>>>>>>> reus able, it is clear to me that it does not make >> sense in all cases. >>>>>>>> It was familiar >>>>>>>> to the editors, and well understood, so it made sense as a >>>>>>>> proposal, but I disagree with it being the mandatory/only >>>>>>>> solution. >>>>>>> >>>>>>> I fully agree with David that making (D)TLS mandatory is not a >>>>>>> good idea, especially concerning re-usability of the >> protocol in >>>>>>> scenarios where you already have similar security features >>>>>>> provided by the underlying system. >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Ari >>>>>>> _______________________________________________ >>>>>>> P2PSIP mailing list >>>>>>> P2PSIP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>>> _______________________________________________ >>>>>> P2PSIP mailing list >>>>>> P2PSIP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>> >>>>> >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> > > From michaelc@IDSSOFTWARE.COM Thu Dec 17 15:13:05 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA90028C163 for ; Thu, 17 Dec 2009 15:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.826 X-Spam-Level: X-Spam-Status: No, score=-0.826 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 uh33DSO4rsP0 for ; Thu, 17 Dec 2009 15:13:04 -0800 (PST) Received: from smtpoutwbe06.prod.mesa1.secureserver.net (smtpoutwbe06.prod.mesa1.secureserver.net [208.109.78.208]) by core3.amsl.com (Postfix) with SMTP id AF6CC28C169 for ; Thu, 17 Dec 2009 15:13:04 -0800 (PST) Received: (qmail 25514 invoked from network); 17 Dec 2009 23:12:50 -0000 Received: from unknown (HELO gem-wbe15.prod.mesa1.secureserver.net) (64.202.189.223) by smtpoutwbe06.prod.mesa1.secureserver.net with SMTP; 17 Dec 2009 23:12:49 -0000 Received: (qmail 23360 invoked by uid 99); 17 Dec 2009 23:12:49 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 12.175.188.225 User-Agent: Web-Based Email 5.1.31 Message-Id: <20091217161249.61e8c06078a3b23a733c71e914c0b9df.ce3a221ac6.wbe@email.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Thu, 17 Dec 2009 16:12:49 -0700 Mime-Version: 1.0 Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 17 Dec 2009 23:13:06 -0000

On that note, doesn't IPv6 make ICE obsolete? = and yet this draft mandates ICE.

--Michael
=

-------- Original Message --------
Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as
part of the WGLC
From: jc <julian@orchidseed.org>
Date: Thu, December 17, 2009 1:19 pm
To: Song Haibin <melodysong@huawei.com>
Cc: 'Salman Abdul Baset' <sa2086@columbia.edu>, 'P2PSIP WG'
<p2psip@ietf.org>

Nor is ICE good for overlays making use of iterative routing.

Julian

On Dec 16, 2009, at 10:51 PM, Song Haibin wrote:

>
> TLS/DTLS is not good to the DHT algorithms that use iterative routing.= And
> it also prevents using of direct response to a certain extent. Having = a
> security analysis draft for p2psip for deployers to consider threats a= nd
> possible solution in their deployment scenarios will qualify.
>
> For interoperability, it depends on both the standard and the number o= f
> deployers who want to obey the standard.
>
> Thanks,
> Haibin
>
>> -----Original Message-----
>> From: p2psip-bounces@ietf.org
>> [mailto:p2psip-bounces@ietf.org] O= n Behalf Of Salman Abdul Baset
>> Sent: Saturday, December 12, 2009 3:33 AM
>> To: jc
>> Cc: P2PSIP WG
>> Subject: Re: [P2PSIP] Concerns, questions and nits about base
>> -06 as part of the WGLC
>>
>> Kademlia does iterative routing with parallel requests, and
>> iterative routing has to pay the penalty of TLS/DTLS
>> connection establishment at every hop which is at least 1.5 RTT. >
>>
>> The alternative is to devise a secure transport protocol or
>> optimize DTLS/TLS to reduce the connection establishment
>> penalty. Security folks may argue that it is a non-starter at IETF= .
>>
>> Yet, another alternative is to design a custom secure
>> transport. But interoperability is the obvious looser.
>>
>> In general, for Internet scale deployment, the idea of trying
>> to make all nodes, no matter what their connectivity, fully
>> participate in the overlay as a peer is highly questionable.
>>
>> -s
>>
>> On Fri, 11 Dec 2009, jc wrote:
>>
>>> Some individuals may not care to use tls or dtls. These standa= rds
>>> aren't practical in all cases. Encrypted transports a MUST but=
>>> mechanism should be optional. This is better than people not u= sing
>>> this draft and resolves conearns about the underlying
>> transports lack
>>> of performance in certain use cases.
>>>
>>> Thinking Chord only as a topology plugin is too narrow from >> a security
>>> performance perspective. I have bad experience with Kademlia a= s a
>>> topology plugin. If you understand Kademlia you should
>> understand how
>>> the routing table functions and how the transports reflect >> that. All
>>> topology plugins will be forced to tune themselves to d/tls >> which the
>>> result is a less efficient system.
>>>
>>> I don't see where anyone mentioned throw out encryption
>> entirely but I
>>> may be wrong.
>>>
>>> Julian
>>>
>>> Sent from my iPhone
>>>
>>> On Dec 11, 2009, at 1:16 PM, Brian Rosen <br@brianrosen.net= > wrote:
>>>
>>>> <as individual>
>>>> I disagree.
>>>>
>>>> The problem is that we have a whole lot of history and exp= erience.
>>>>
>>>> The experience is that if we don't insist, and make
>> security integral
>>>> to the protocol, it doesn't get implemented and we have a =
>> majority of
>>>> insecure systems.
>>>>
>>>> If we do insist, the cost of the security is reasonable: t= he dire
>>>> predictions that it's too costly, too hard, ... don't happ= en.
>>>>
>>>> No amount of text explaining when the security mechanism <= br> >> is or isn't
>>>> appropriate works. You have to make the mechanism integra= l to the
>>>> operation of the protocol, as we have done here.
>>>>
>>>> I don't see anything in p2psip which would be different th= en our
>>>> history and experience. The costs aren't as bad as you fe= ar. The
>>>> probability of nearly every system being implemented insec= urely is
>>>> very high if you make it optional.
>>>>
>>>> Don't do that.
>>>>
>>>> Brian
>>>>
>>>>
>>>> On 12/11/09 12:49 PM, "Michael Chen"
>> <michaelc@idssoftware.com> wrote:
>>>>
>>>>> I too agree with the three of you. D/TLS should be opt= ional.
>>>>> Several of my
>>>>> previous post voice concerns about redundancy and
>> efficiency of the
>>>>> transport layer.
>>>>>
>>>>> --Michael
>>>>>> -------- Original Message --------
>>>>>> Subject: Re: [P2PSIP] Concerns, questions and nits= about
>> base -06
>>>>>> as part of the WGLC
>>>>>> From: jc <julian@orchidseed.org>
>>>>>> Date: Fri, December 11, 2009 7:26 am
>>>>>> To: Ari Keranen <ari.keranen@nomadiclab.com>=
>>>>>> Cc: P2PSIP WG <p2psip@ietf.org>
>>>>>>
>>>>>> I said this about 7 months ago and I still agree t= hat
>> there should
>>>>>> be no mandatory transport layer encryption as this= should be
>>>>>> provided outside of the scope of this draft.
>>>>>>
>>>>>> Julian
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Dec 11, 2009, at 5:39 AM, Ari Keranen
>>>>>> <ari.keranen@nomadiclab.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> David A. Bryan wrote:
>>>>>>>> Concern 1: Mandatory TLS/DTLS Inappropriat= e in some
>> Contexts I've
>>>>>>>> raised this issue before, but I'm hoping t= hat now that people
>>>>>>>> have had a bit more time to think about al= l the use cases, see
>>>>>>>> what it means in the real world, etc., the= re might be
>> a bit mo re
>>>>>>>> support for modifying the requirement for = TLS/DTLS.
>> TLS/DTLS ma
>>>>>>>> kes sense in some cases, but if we are exp= ecting RELOAD to be
>>>>>>>> reus able, it is clear to me that it does = not make
>> sense in all cases.
>>>>>>>> It was familiar
>>>>>>>> to the editors, and well understood, so it= made sense as a
>>>>>>>> proposal, but I disagree with it being the= mandatory/only
>>>>>>>> solution.
>>>>>>>
>>>>>>> I fully agree with David that making (D)TLS ma= ndatory is not a
>>>>>>> good idea, especially concerning re-usability = of the
>> protocol in
>>>>>>> scenarios where you already have similar secur= ity features
>>>>>>> provided by the underlying system.
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ari
>>>>>>> ______________________________________________= _
>>>>>>> P2PSIP mailing list
>>>>>>> P2PSIP@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>>>> _______________________________________________ >>>>>> P2PSIP mailing list
>>>>>> P2PSIP@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>>
>>>>>
>>>>> _______________________________________________
>>>>> P2PSIP mailing list
>>>>> P2PSIP@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>>
>>>>
>>>> _______________________________________________
>>>> P2PSIP mailing list
>>>> P2PSIP@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/p2psip
>>> _______________________________________________
>>> P2PSIP mailing list
>>> P2PSIP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>
>>
>
>

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
= https://www.ietf.org/mailman/listinfo/p2psip
 From emcho@sip-communicator.org Thu Dec 17 15:38:20 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA973A69FC for ; Thu, 17 Dec 2009 15:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Rvp2xtvytNO4 for ; Thu, 17 Dec 2009 15:38:19 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 1D1683A68F5 for ; Thu, 17 Dec 2009 15:38:17 -0800 (PST) Received: by fxm7 with SMTP id 7so2484272fxm.29 for ; Thu, 17 Dec 2009 15:37:57 -0800 (PST) Received: by 10.223.132.207 with SMTP id c15mr4056183fat.56.1261093077460; Thu, 17 Dec 2009 15:37:57 -0800 (PST) Received: from ?192.168.54.104? ([78.90.66.189]) by mx.google.com with ESMTPS id g28sm4215354fkg.8.2009.12.17.15.37.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Dec 2009 15:37:56 -0800 (PST) References: <20091217161249.61e8c06078a3b23a733c71e914c0b9df.ce3a221ac6.wbe@email.secureserver.net> Message-Id: <32812E4E-0F58-4FE1-9E2D-CB84FBB25F9E@sip-communicator.org> From: Emil Ivov To: Michael Chen In-Reply-To: <20091217161249.61e8c06078a3b23a733c71e914c0b9df.ce3a221ac6.wbe@email.secureserver.net> Content-Type: multipart/alternative; boundary=Apple-Mail-1--682073690 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7D11) Date: Fri, 18 Dec 2009 01:36:03 +0200 X-Mailer: iPhone Mail (7D11) Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 17 Dec 2009 23:38:21 -0000 --Apple-Mail-1--682073690 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On 18 d=C3=A9c. 2009, at 01:12, "Michael Chen" = =20 wrote: > > On that note, doesn't IPv6 make ICE obsolete? and yet this draft =20 > mandates ICE. In an IPv6 only world, probably. Until then, and I really hope we both =20= get to live that long, IPv6 is just one more reason to use ICE. Cheers, Emil > > --Michael > > -------- Original Message -------- > Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as > part of the WGLC > From: jc > Date: Thu, December 17, 2009 1:19 pm > To: Song Haibin > Cc: 'Salman Abdul Baset' , 'P2PSIP WG' > > > Nor is ICE good for overlays making use of iterative routing. > > Julian > > On Dec 16, 2009, at 10:51 PM, Song Haibin wrote: > > > > > TLS/DTLS is not good to the DHT algorithms that use iterative =20 > routing. And > > it also prevents using of direct response to a certain extent. =20 > Having a > > security analysis draft for p2psip for deployers to consider =20 > threats and > > possible solution in their deployment scenarios will qualify. > > > > For interoperability, it depends on both the standard and the =20 > number of > > deployers who want to obey the standard. > > > > Thanks, > > Haibin > > > >> -----Original Message----- > >> From: p2psip-bounces@ietf.org > >> [mailto:p2psip-bounces@ietf.org] On Behalf Of Salman Abdul Baset > >> Sent: Saturday, December 12, 2009 3:33 AM > >> To: jc > >> Cc: P2PSIP WG > >> Subject: Re: [P2PSIP] Concerns, questions and nits about base > >> -06 as part of the WGLC > >> > >> Kademlia does iterative routing with parallel requests, and > >> iterative routing has to pay the penalty of TLS/DTLS > >> connection establishment at every hop which is at least 1.5 RTT. > > > >> > >> The alternative is to devise a secure transport protocol or > >> optimize DTLS/TLS to reduce the connection establishment > >> penalty. Security folks may argue that it is a non-starter at IETF. > >> > >> Yet, another alternative is to design a custom secure > >> transport. But interoperability is the obvious looser. > >> > >> In general, for Internet scale deployment, the idea of trying > >> to make all nodes, no matter what their connectivity, fully > >> participate in the overlay as a peer is highly questionable. > >> > >> -s > >> > >> On Fri, 11 Dec 2009, jc wrote: > >> > >>> Some individuals may not care to use tls or dtls. These standards > >>> aren't practical in all cases. Encrypted transports a MUST but > >>> mechanism should be optional. This is better than people not using > >>> this draft and resolves conearns about the underlying > >> transports lack > >>> of performance in certain use cases. > >>> > >>> Thinking Chord only as a topology plugin is too narrow from > >> a security > >>> performance perspective. I have bad experience with Kademlia as a > >>> topology plugin. If you understand Kademlia you should > >> understand how > >>> the routing table functions and how the transports reflect > >> that. All > >>> topology plugins will be forced to tune themselves to d/tls > >> which the > >>> result is a less efficient system. > >>> > >>> I don't see where anyone mentioned throw out encryption > >> entirely but I > >>> may be wrong. > >>> > >>> Julian > >>> > >>> Sent from my iPhone > >>> > >>> On Dec 11, 2009, at 1:16 PM, Brian Rosen =20 > wrote: > >>> > >>>> > >>>> I disagree. > >>>> > >>>> The problem is that we have a whole lot of history and =20 > experience. > >>>> > >>>> The experience is that if we don't insist, and make > >> security integral > >>>> to the protocol, it doesn't get implemented and we have a > >> majority of > >>>> insecure systems. > >>>> > >>>> If we do insist, the cost of the security is reasonable: the dire > >>>> predictions that it's too costly, too hard, ... don't happen. > >>>> > >>>> No amount of text explaining when the security mechanism > >> is or isn't > >>>> appropriate works. You have to make the mechanism integral to the > >>>> operation of the protocol, as we have done here. > >>>> > >>>> I don't see anything in p2psip which would be different then our > >>>> history and experience. The costs aren't as bad as you fear. The > >>>> probability of nearly every system being implemented insecurely =20= > is > >>>> very high if you make it optional. > >>>> > >>>> Don't do that. > >>>> > >>>> Brian > >>>> > >>>> > >>>> On 12/11/09 12:49 PM, "Michael Chen" > >> wrote: > >>>> > >>>>> I too agree with the three of you. D/TLS should be optional. > >>>>> Several of my > >>>>> previous post voice concerns about redundancy and > >> efficiency of the > >>>>> transport layer. > >>>>> > >>>>> --Michael > >>>>>> -------- Original Message -------- > >>>>>> Subject: Re: [P2PSIP] Concerns, questions and nits about > >> base -06 > >>>>>> as part of the WGLC > >>>>>> From: jc > >>>>>> Date: Fri, December 11, 2009 7:26 am > >>>>>> To: Ari Keranen > >>>>>> Cc: P2PSIP WG > >>>>>> > >>>>>> I said this about 7 months ago and I still agree that > >> there should > >>>>>> be no mandatory transport layer encryption as this should be > >>>>>> provided outside of the scope of this draft. > >>>>>> > >>>>>> Julian > >>>>>> > >>>>>> Sent from my iPhone > >>>>>> > >>>>>> On Dec 11, 2009, at 5:39 AM, Ari Keranen > >>>>>> > >>>>>> wrote: > >>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> David A. Bryan wrote: > >>>>>>>> Concern 1: Mandatory TLS/DTLS Inappropriate in some > >> Contexts I've > >>>>>>>> raised this issue before, but I'm hoping that now that people > >>>>>>>> have had a bit more time to think about all the use cases, =20= > see > >>>>>>>> what it means in the real world, etc., there might be > >> a bit mo re > >>>>>>>> support for modifying the requirement for TLS/DTLS. > >> TLS/DTLS ma > >>>>>>>> kes sense in some cases, but if we are expecting RELOAD to be > >>>>>>>> reus able, it is clear to me that it does not make > >> sense in all cases. > >>>>>>>> It was familiar > >>>>>>>> to the editors, and well understood, so it made sense as a > >>>>>>>> proposal, but I disagree with it being the mandatory/only > >>>>>>>> solution. > >>>>>>> > >>>>>>> I fully agree with David that making (D)TLS mandatory is not a > >>>>>>> good idea, especially concerning re-usability of the > >> protocol in > >>>>>>> scenarios where you already have similar security features > >>>>>>> provided by the underlying system. > >>>>>>> > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Ari > >>>>>>> _______________________________________________ > >>>>>>> P2PSIP mailing list > >>>>>>> P2PSIP@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/p2psip > >>>>>> _______________________________________________ > >>>>>> P2PSIP mailing list > >>>>>> P2PSIP@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/p2psip > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> P2PSIP mailing list > >>>>> P2PSIP@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/p2psip > >>>> > >>>> > >>>> _______________________________________________ > >>>> P2PSIP mailing list > >>>> P2PSIP@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/p2psip > >>> _______________________________________________ > >>> P2PSIP mailing list > >>> P2PSIP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/p2psip > >>> > >> > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail-1--682073690 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 18 = d=C3=A9c. 2009, at 01:12, "Michael Chen" <michaelc@idssoftware.com> = wrote:


On that note, = doesn't IPv6 make ICE obsolete? and yet this draft mandates = ICE.

In an IPv6 only = world, probably. Until then, and I really hope we both get to live that = long, IPv6 is just one more reason to use = ICE.

Cheers,
Emil 


--Michael

-------- Original Message --------
Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as
part of the WGLC
From: jc <julian@orchidseed.org>
Date: Thu, December 17, 2009 1:19 pm
To: Song Haibin <melodysong@huawei.com>
Cc: 'Salman Abdul Baset' <sa2086@columbia.edu>, 'P2PSIP = WG'
<p2psip@ietf.org>

Nor is ICE good for overlays making use of iterative routing.

Julian

On Dec 16, 2009, at 10:51 PM, Song Haibin wrote:

>
> TLS/DTLS is not good to the DHT algorithms that use iterative = routing. And
> it also prevents using of direct response to a certain extent. = Having a
> security analysis draft for p2psip for deployers to consider = threats and
> possible solution in their deployment scenarios will qualify.
>
> For interoperability, it depends on both the standard and the = number of
> deployers who want to obey the standard.
>
> Thanks,
> Haibin
>
>> -----Original Message-----
>> From: p2psip-bounces@ietf.org
>> [mailto:p2psip-bounces@ietf.org] = On Behalf Of Salman Abdul Baset
>> Sent: Saturday, December 12, 2009 3:33 AM
>> To: jc
>> Cc: P2PSIP WG
>> Subject: Re: [P2PSIP] Concerns, questions and nits about base =
>> -06 as part of the WGLC
>>
>> Kademlia does iterative routing with parallel requests, and =
>> iterative routing has to pay the penalty of TLS/DTLS
>> connection establishment at every hop which is at least 1.5 = RTT.
>
>>
>> The alternative is to devise a secure transport protocol or =
>> optimize DTLS/TLS to reduce the connection establishment
>> penalty. Security folks may argue that it is a non-starter at = IETF.
>>
>> Yet, another alternative is to design a custom secure
>> transport. But interoperability is the obvious looser.
>>
>> In general, for Internet scale deployment, the idea of trying =
>> to make all nodes, no matter what their connectivity, fully =
>> participate in the overlay as a peer is highly = questionable.
>>
>> -s
>>
>> On Fri, 11 Dec 2009, jc wrote:
>>
>>> Some individuals may not care to use tls or dtls. These = standards
>>> aren't practical in all cases. Encrypted transports a MUST = but
>>> mechanism should be optional. This is better than people = not using
>>> this draft and resolves conearns about the underlying
>> transports lack
>>> of performance in certain use cases.
>>>
>>> Thinking Chord only as a topology plugin is too narrow from =
>> a security
>>> performance perspective. I have bad experience with = Kademlia as a
>>> topology plugin. If you understand Kademlia you should
>> understand how
>>> the routing table functions and how the transports reflect =
>> that. All
>>> topology plugins will be forced to tune themselves to d/tls =
>> which the
>>> result is a less efficient system.
>>>
>>> I don't see where anyone mentioned throw out encryption =
>> entirely but I
>>> may be wrong.
>>>
>>> Julian
>>>
>>> Sent from my iPhone
>>>
>>> On Dec 11, 2009, at 1:16 PM, Brian Rosen <br@brianrosen.net> wrote:
>>>
>>>> <as individual>
>>>> I disagree.
>>>>
>>>> The problem is that we have a whole lot of history and = experience.
>>>>
>>>> The experience is that if we don't insist, and make =
>> security integral
>>>> to the protocol, it doesn't get implemented and we have = a
>> majority of
>>>> insecure systems.
>>>>
>>>> If we do insist, the cost of the security is = reasonable: the dire
>>>> predictions that it's too costly, too hard, ... don't = happen.
>>>>
>>>> No amount of text explaining when the security = mechanism
>> is or isn't
>>>> appropriate works. You have to make the mechanism = integral to the
>>>> operation of the protocol, as we have done here.
>>>>
>>>> I don't see anything in p2psip which would be different = then our
>>>> history and experience. The costs aren't as bad as you = fear. The
>>>> probability of nearly every system being implemented = insecurely is
>>>> very high if you make it optional.
>>>>
>>>> Don't do that.
>>>>
>>>> Brian
>>>>
>>>>
>>>> On 12/11/09 12:49 PM, "Michael Chen"
>> <michaelc@idssoftware.com> = wrote:
>>>>
>>>>> I too agree with the three of you. D/TLS should be = optional.
>>>>> Several of my
>>>>> previous post voice concerns about redundancy and =
>> efficiency of the
>>>>> transport layer.
>>>>>
>>>>> --Michael
>>>>>> -------- Original Message --------
>>>>>> Subject: Re: [P2PSIP] Concerns, questions and = nits about
>> base -06
>>>>>> as part of the WGLC
>>>>>> From: jc <julian@orchidseed.org>
>>>>>> Date: Fri, December 11, 2009 7:26 am
>>>>>> To: Ari Keranen <ari.keranen@nomadiclab.com&= gt;
>>>>>> Cc: P2PSIP WG <p2psip@ietf.org>
>>>>>>
>>>>>> I said this about 7 months ago and I still = agree that
>> there should
>>>>>> be no mandatory transport layer encryption as = this should be
>>>>>> provided outside of the scope of this = draft.
>>>>>>
>>>>>> Julian
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Dec 11, 2009, at 5:39 AM, Ari Keranen
>>>>>> <ari.keranen@nomadiclab.com&= gt;
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> David A. Bryan wrote:
>>>>>>>> Concern 1: Mandatory TLS/DTLS = Inappropriate in some
>> Contexts I've
>>>>>>>> raised this issue before, but I'm = hoping that now that people
>>>>>>>> have had a bit more time to think about = all the use cases, see
>>>>>>>> what it means in the real world, etc., = there might be
>> a bit mo re
>>>>>>>> support for modifying the requirement = for TLS/DTLS.
>> TLS/DTLS ma
>>>>>>>> kes sense in some cases, but if we are = expecting RELOAD to be
>>>>>>>> reus able, it is clear to me that it = does not make
>> sense in all cases.
>>>>>>>> It was familiar
>>>>>>>> to the editors, and well understood, so = it made sense as a
>>>>>>>> proposal, but I disagree with it being = the mandatory/only
>>>>>>>> solution.
>>>>>>>
>>>>>>> I fully agree with David that making (D)TLS = mandatory is not a
>>>>>>> good idea, especially concerning = re-usability of the
>> protocol in
>>>>>>> scenarios where you already have similar = security features
>>>>>>> provided by the underlying system.
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ari
>>>>>>> = _______________________________________________
>>>>>>> P2PSIP mailing list
>>>>>>> P2PSIP@ietf.org
>>>>>>> https://www.ietf.org= /mailman/listinfo/p2psip
>>>>>> = _______________________________________________
>>>>>> P2PSIP mailing list
>>>>>> P2PSIP@ietf.org
>>>>>> https://www.ietf.org= /mailman/listinfo/p2psip
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> P2PSIP mailing list
>>>>> P2PSIP@ietf.org
>>>>> https://www.ietf.org= /mailman/listinfo/p2psip
>>>>
>>>>
>>>> _______________________________________________
>>>> P2PSIP mailing list
>>>> P2PSIP@ietf.org
>>>> https://www.ietf.org= /mailman/listinfo/p2psip
>>> _______________________________________________
>>> P2PSIP mailing list
>>> P2PSIP@ietf.org
>>> https://www.ietf.org= /mailman/listinfo/p2psip
>>>
>>
>
>

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org= /mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org= /mailman/listinfo/p2psip
= --Apple-Mail-1--682073690-- From john.buford@gmail.com Thu Dec 17 19:44:02 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56EF3A67DD for ; Thu, 17 Dec 2009 19:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 ZLYt9DnRiT+1 for ; Thu, 17 Dec 2009 19:44:01 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id AA89E3A67CC for ; Thu, 17 Dec 2009 19:44:00 -0800 (PST) Received: by fxm7 with SMTP id 7so2576167fxm.29 for ; Thu, 17 Dec 2009 19:43:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ddqYp0I1Q2wuLfrJz10JPMvKRpfOpz7BHTro37Vub1I=; b=URjCg4DElBAnDUHPRjWQpqUGD7lONl29QzCFDZoMXmaE2E8q6cVRPZaKXBln3pyBlh 7qunMTo6bj5DYTUd6G+H+gth7Ob5ds+rhN6/b6Z7t3IRaa2sw+GQyMSMwMOSdvk0EuPp lI28npBeqzDb7NVsqz4mHfe2wbR82/x401PmI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; b=B+besdvlXMpW6WODgQWCpLlABs0oF5x5bS7ZiktP0vPBCyS3keXHEQeMq2XtLkUfMy 0GEE2DDfUm6Q2ANv3Z1/6rc05NNZm3ccjCX35e0Ra5xSG51Qm531af7AYbo0uNQAYKcM fWz1N6pS2/DWnq4CJUiCxtQ77/AE8bNx4LpR4= MIME-Version: 1.0 Sender: john.buford@gmail.com Received: by 10.239.181.165 with SMTP id m37mr313222hbg.11.1261107822731; Thu, 17 Dec 2009 19:43:42 -0800 (PST) Date: Thu, 17 Dec 2009 22:43:42 -0500 X-Google-Sender-Auth: b2d631ae8bdac091 Message-ID: <4ce32a820912171943i7d8493f5x3932a9c37460ed9f@mail.gmail.com> From: John Buford To: P2PSIP WG Content-Type: multipart/alternative; boundary=001485f774d8cc2346047af88bde Subject: [P2PSIP] review of draft-ietf-p2psip-base-06.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: buford@samrg.org List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 03:44:02 -0000 --001485f774d8cc2346047af88bde Content-Type: text/plain; charset=ISO-8859-1 Here is my review of draft-ietf-p2psip-base-06 that I agreed to provide at IETF76 WG meeting. John General ======= 1.4 Structure of the Document Adding a new usage - it would be useful to have a section on this Adding a new overlay algorithm - it would be useful to have a section on this 3.2 Clients How does a peer transition to a client? 3.3 Routing "Client promotion" - is there client demotion? 4.1.1 Storage Permissions This limits the storage load which another peer can impose, but doesn't address loading due to frequency of write/fetches another peer can impose. 6.3 Access Control Policies How is access control managed for replicated values? It might be helpful for implementers to have a table in an appendix listing the various config parameters and their default / max values, etc, such as: holdown_time 30 sec periodic Update requests 10 min Ping interval 3000 sec Partition detection Max Message size etc. Detailed Comments ================= 1.1 "partly connected graph" -- connected graph subsumes partly connected case 1.2.5 "a packet" => a message 3.3 "In all cases, the response to a request needs ..." -- should this be written as a MUST? 4 Application Support Overview "To form direct connections ..." -- why "direct"? 5.1.1 Responsible ID (2nd bullet) "If the message is a response ... the state is reinserted ... first" -- 5.3.2 Forward Header relo_token = 0xc2454c4f, i.e., 'RELO' with msb set in first byte. Shouldn't this be 0xd2454c4f ? (this was commented on the list already in July 2008) transaction_id "unique" - globally unique in the overlay or unique respect to transaction ids generated by this peer? 5.3.2.2 "This may be one of "peer", ..." -- should be node instead of peer "A DestinationData can be one of three types ... peer A Node-id" -- change "peer" to "node" for consistency with the select statement 5.3.2.2 bottom p. 44 to top of p. 45 "the encoding MUST include a generation counter designed ..." -- since this is opaque, I don't see how it is "MUST". there could be other ways for nodes to prevent misrouting due to dynamics of the connection table. 5.3.2.3 should the flags be defined as enums in the notation? 5.3.3 message_code 0x8000 .. 0xfffe seems to be omitted 5.3.3.1 Response Codes and Response Errors There seem to be a number of cases where "peer" is used in the text where it should be "node": Error_Forbidden: The requesting _peer_ does not have permission to make this request. Error_Not_Found: The resource or _peer_ cannot be found ... Error_Request_Timeout: ...The requesting _peer_ MAY resend the request at a later time. Also it is not clear whether clients can receive some requests, such as update_req, stat_req, or ping. If so, some of the other Response Error text may need to be changed to refer to "node" instead of "peer". Finally, these definitions appear here but are not in section 13.7: ERror_Response_Too_Large, Error_Config_Too_Old, Error_Config_Too_New. 5.4.1 Topology Plugin Requirements "The length of the Resource-IDs and Node-IDs". -- Doesn't RELOAD fix these to 128 bits? 5.4.2.5.1 "The two currently defined..." -- strike "two". Also should "peer" be "node" in this section, at least for uptime? If so, this would effect usage of peer in sec. 5.4.2.5.2 as well. 5.5.3.1 Request Definition should it be "requesting node" instead of "requesting peer"? (also in 5.5.4.1) 5.5.5 Ping what are the operational semantics of Ping to broadcast Node-ID? 5.5.6.2 Config_UpdateReq This could potentially be used to attack the overlay by disabling nodes with erroneous configurations. 5.6.2.1 if we replace N-M with N-M-1, then the bit numberings are 0..N-1 instead of 1..N in the mask, which is the usual convention. 5.6.2.2 "Another would be to implement the _AIMD_ scheme described in Appendix B". 6 Data Storage Protocol storage_time what about a store request whose time equals the time of the current value? lifetime can a usage define a max_lifetime for a kind? 6.3 Access Control Policies what about control of fetch access? 6.4.1.1 Request Definition resource: The _Resource-ID_ to store at. 6.4..4.2 Response Definition "... it SHOULD return a 404 error" -- replace 404 with a RELOAD error code 9.4 "joining party" -- "joining node" seems clearer and more consistent terminology A statement that the enrollment server assigns the Node-Id could be useful here. "numBitsInNodeId" - this is already fixed to 128, so should we drop the variable use here? 9.6.3 Receiving Updates "The UpdateReq defines peers that indicate a neighbor table further away from N than some of its neighbor table" -- could be made clearer, e.g., => The UpdateReq contains peers that are further away from N than some of the peers in N's neighbor table. 11. Message Flow Example PPP, PP, NP, NNP acronyms should be defined Some other examples that could be useful: client-peer interaction bootstrap with enrollment server interactions between the node internal architecture elements 12.6.5 Residual Attacks enrollment server is a central point of failure (as implied by 3.6.2) 13.6 Message codes remove_req and remove_ans seem to be no longer used according to 6.4.1.3 14 Acknowledgements - "Michael Chen" is listed twice. Spelling/Grammar ================ 1.2 "To clarify the role of the various layer,..." => layers 4.1.3 "on the its" => "on its" 5.3 "introduce new potential" => introduces 5.3.1 "the ability to mechanically (compile)..." -- is a verb missing here, such as generate or translate? 5.5.2.4 "be done be doing" => be done by doing 5.6.2.1 "that the sender to figure" => "that the sender can figure" 5.6.2.2 "no more aggressive then" => "no more aggressive than" also add "(see Appendix C)" after [RFC5348] in this sentence. 9.1 "entreis" => entries 9.6.3 "These Update requests are what ends up" => end up 9.8 extentions => extensions (also several places in 10.1) 10.1 "boradcast" => broadcast 10.3 "[RFC5272])" => "[RFC5272]" 10.3 "HTTP stats codes" => HTTP status codes 12.3 "certificates are signed by _require_ a central enrollment...." -- ? 12.6.3 "Replay is typical prevented ..." => typically Will be resolved by RFC Editor, or before WGLC? ==================================== 1.2.1 "this draft" 2 "are marked with an asterisk" 5.3.1 "This presentation is to some extent a placeholder.... We expect this to be a question for the WG to decide." 5.6.1 Future Support for HIP "We leave this work as a topic for another draft". Is this to be addressed before WGLC? --001485f774d8cc2346047af88bde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here is my review of draft-ietf-p2psip-base-06
that I agreed to provide = at IETF76 WG meeting.

John


General
=3D=3D=3D=3D=3D=3D= =3D

1.4 Structure of the Document
=A0=A0 Adding a new usage - it = would be useful to have a section on this
=A0=A0 Adding a new overlay algorithm - it would be useful to have a sectio= n on this

3.2 Clients
=A0=A0 How does a peer transition to a clie= nt?

3.3 Routing
=A0=A0 "Client promotion" - is there cl= ient demotion?

4.1.1 Storage Permissions
=A0 This limits the storage load which ano= ther peer can impose,
=A0 but doesn't address loading due to frequen= cy of
=A0 write/fetches another peer can impose.

6.3 Access Contr= ol Policies
=A0 How is access control managed for replicated values?


It migh= t be helpful for implementers to have a table
in an appendix listing the= various config parameters
and their default / max values, etc, such as:=

holdown_time 30 sec
periodic Update requests 10 min
Ping interval= =A0 3000 sec
Partition detection
Max Message size
etc.

Deta= iled Comments
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

1.1 "partly connected graph" -- connected graph subsumes par= tly connected case

1.2.5 "a packet" =3D> a message


3.3 "In al= l cases, the response to
=A0 a request needs ..."=A0 -- should this= be written as a MUST?

4 Application Support Overview
=A0 "T= o form direct connections ..." -- why "direct"?

5.1.1 Responsible ID (2nd bullet)
"If the message is a response= ... the state
is reinserted ... first" -- <before forwarding or=
before sending to the upper layer?>

5.3.2 Forward Header
relo_token =3D 0xc2454c4f, i.e., 'RELO' with msb set in first byte.=
=A0 Shouldn't this be 0xd2454c4f ?=A0 (this was commented on the =A0 list already in July 2008)

transaction_id "unique" -= globally unique in the overlay or unique
=A0=A0=A0 respect to transaction ids generated by this peer?

5.3.2.2=
"This may be one of "peer", ..."=A0 -- should be n= ode instead of peer
=A0
"A DestinationData can be one of three t= ypes ...=A0 peer
=A0=A0 A Node-id"=A0 -- change "peer" to "node" fo= r consistency with
=A0=A0 the select statement

5.3.2.2 bottom p.= 44 to top of p. 45
=A0"the encoding MUST include a generation coun= ter designed ..."
=A0 -- since this is opaque, I don't see how it is "MUST".=A0=A0=A0=A0 there could be other ways for nodes to prevent misrouting
= =A0=A0=A0=A0 due to dynamics of the connection table.

5.3.2.3
=A0= =A0 should the flags be defined as enums in the notation?

5.3.3
=A0=A0 message_code=A0 0x8000 .. 0xfffe seems to be omitted
5.3.3.1 Response Codes and Response Errors

=A0 There seem to be= a number of cases where "peer" is used in the
=A0 text where = it should be "node":

Error_Forbidden: The requesting _peer_ does not have permission to
= =A0 make this request.
Error_Not_Found: The resource or _peer_ cannot b= e found ...
Error_Request_Timeout: ...The requesting _peer_ MAY resend t= he
=A0 request at a later time.

Also it is not clear whether clients ca= n receive some requests,
such as update_req, stat_req, or ping.=A0 If so= , some of the other
Response Error text may need to be changed to refer = to "node" instead
of "peer".

Finally, these definitions appear here but are = not in section 13.7:
ERror_Response_Too_Large, Error_Config_Too_Old, Err= or_Config_Too_New.

5.4.1 Topology Plugin Requirements
"The l= ength of the Resource-IDs and Node-IDs".=A0 -- Doesn't RELOAD fix = these
=A0=A0 to 128 bits?

5.4.2.5.1

"The two currently defined= ..."=A0 -- strike "two".
Also should "peer" be = "node" in this section, at least for uptime?
If so, this would= effect usage of peer in sec. 5.4.2.5.2 as well.


5.5.3.1 Request Definition
should it be "requesting node&qu= ot; instead of "requesting peer"?
(also in 5.5.4.1)

5.5= .5 Ping
=A0 what are the operational semantics of Ping to broadcast Node= -ID?

5.5.6.2 Config_UpdateReq
=A0 This could potentially be used to attac= k the overlay by disabling nodes
=A0=A0 with erroneous configurations.
5.6.2.1=A0
=A0 if we replace N-M with N-M-1, then the bit numberi= ngs are 0..N-1
=A0 instead of 1..N in the mask, which is the usual convention.

5.6.= 2.2
=A0 "Another would be to implement the _AIMD_ scheme described= in
=A0=A0 Appendix B".

6 Data Storage Protocol

stora= ge_time
=A0=A0 what about a store request whose time equals the time of the
=A0= =A0 current value?

lifetime
=A0=A0 can a usage define a max_lifet= ime for a kind?

6.3 Access Control Policies
=A0=A0 what about con= trol of fetch access?

6.4.1.1=A0 Request Definition
=A0
=A0 resource: The _Resource-ID_= to store at.

6.4..4.2 Response Definition

=A0 "... it S= HOULD return a 404 error"=A0 -- replace 404 with a RELOAD error code

9.4 "joining party" -- "joining node" seems clearer= and more consistent terminology
=A0 A statement that the enrollment ser= ver assigns the Node-Id could be useful here.

"numBitsInNodeId&= quot; - this is already fixed to 128, so should we drop the variable use he= re?

9.6.3 Receiving Updates
=A0 "The UpdateReq defines peers that i= ndicate a neighbor table further away from
=A0=A0 N than some of its nei= ghbor table" -- could be made clearer, e.g.,
=A0=A0 =3D> The Upd= ateReq contains peers that are further away from N than some of the
=A0=A0=A0=A0=A0=A0 peers in N's neighbor table.

11. Message Flow= Example

PPP, PP, NP, NNP acronyms should be defined

Some oth= er examples that could be useful:
client-peer interaction
bootstrap w= ith enrollment server
interactions between the node internal architecture elements

12.6.5 = Residual Attacks

enrollment server is a central point of failure
= (as implied by 3.6.2)

13.6
Message codes remove_req and remove_an= s seem to
be no longer used according to 6.4.1.3

14 Acknowledgements - "M= ichael Chen" is listed twice.

Spelling/Grammar
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

1.2
"To clarify the rol= e of the various layer,..." =3D> layers

4.1.3 "on the its" =3D> "on its"

5.3 &quo= t;introduce new potential" =3D> introduces

5.3.1 "the a= bility to mechanically (compile)..."
=A0=A0=A0=A0=A0 -- is a verb m= issing here, such as generate or translate?

5.5.2.4=A0 "be done be doing"=A0 =3D> be done by doing
=
5.6.2.1 "that the sender to figure"=A0 =3D> "that the= sender can figure"

5.6.2.2 "no more aggressive then"= =3D> "no more aggressive than"
=A0=A0=A0 also add "(see Appendix C)" after [RFC5348] in this sen= tence.

9.1 "entreis" =3D> entries

9.6.3 "Th= ese Update requests are what ends up" =3D> end up

9.8 extent= ions =3D> extensions (also several places in 10.1)

10.1 "boradcast" =3D> broadcast

10.3 "[RFC5272= ])" =3D> "[RFC5272]"

10.3=A0 "HTTP stats code= s" =3D> HTTP status codes

12.3 "certificates are signed= by _require_ a central enrollment...." -- ?

12.6.3=A0 "Replay is typical prevented ..." =3D> typically=

Will be resolved by RFC Editor, or before WGLC?
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
1.2.1 "this draft"
2 "are marked wi= th an asterisk"
5.3.1=A0 "This presentation is to some extent a placeholder....
=A0= =A0 We expect this to be a question for the WG to decide."

5.6.= 1 Future Support for HIP
=A0 "We leave this work as a topic for ano= ther draft".
=A0 Is this to be addressed before WGLC?
--001485f774d8cc2346047af88bde-- From julian@orchidseed.org Thu Dec 17 20:28:09 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 692153A683E for ; Thu, 17 Dec 2009 20:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 2yaFKfFY+xHf for ; Thu, 17 Dec 2009 20:28:07 -0800 (PST) Received: from n13.c05.mtsvc.net (n13.c05.mtsvc.net [70.32.68.13]) by core3.amsl.com (Postfix) with ESMTP id AE7753A691E for ; Thu, 17 Dec 2009 20:28:07 -0800 (PST) Received: from adsl-66-230-71.asm.bellsouth.net ([98.66.230.71]:47873 helo=[172.16.1.230]) by n13.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NLURS-0003fj-QP for p2psip@ietf.org; Thu, 17 Dec 2009 20:27:53 -0800 From: jc Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-1--664574339 Date: Thu, 17 Dec 2009 23:27:47 -0500 In-Reply-To: <20091217161249.61e8c06078a3b23a733c71e914c0b9df.ce3a221ac6.wbe@email.secureserver.net> To: P2PSIP WG References: <20091217161249.61e8c06078a3b23a733c71e914c0b9df.ce3a221ac6.wbe@email.secureserver.net> Message-Id: <4D4ABEF5-A603-4602-B317-847D15925B8C@orchidseed.org> X-Mailer: Apple Mail (2.1077) X-Authenticated-User: 72798 julian@orchidseed.org Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 18 Dec 2009 04:28:09 -0000 --Apple-Mail-1--664574339 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 17, 2009, at 6:12 PM, Michael Chen wrote: >=20 > On that note, doesn't IPv6 make ICE obsolete? and yet this draft = mandates ICE. It does, however it's irrelevant if you cannot obtain an IPv6 address = which constitutes most of the world's ISP's. There are only three IPv6 = capable pops in the intercontinental United States as of April 2009 and = the DoD has failed to meet their deadline last year. I'm not sure why = ICE was made mandatory in RELOAD as a base protocol but would love to = know the rational. ICE should be used "less" going forward not "more", = however that sadly isn't the case. >=20 > --Michael >=20 > -------- Original Message -------- > Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as > part of the WGLC > From: jc > Date: Thu, December 17, 2009 1:19 pm > To: Song Haibin > Cc: 'Salman Abdul Baset' , 'P2PSIP WG' > >=20 > Nor is ICE good for overlays making use of iterative routing. >=20 > Julian >=20 > On Dec 16, 2009, at 10:51 PM, Song Haibin wrote: >=20 > >=20 > > TLS/DTLS is not good to the DHT algorithms that use iterative = routing. And > > it also prevents using of direct response to a certain extent. = Having a > > security analysis draft for p2psip for deployers to consider threats = and > > possible solution in their deployment scenarios will qualify. > >=20 > > For interoperability, it depends on both the standard and the number = of > > deployers who want to obey the standard. > >=20 > > Thanks, > > Haibin=20 > >=20 > >> -----Original Message----- > >> From: p2psip-bounces@ietf.org=20 > >> [mailto:p2psip-bounces@ietf.org] On Behalf Of Salman Abdul Baset > >> Sent: Saturday, December 12, 2009 3:33 AM > >> To: jc > >> Cc: P2PSIP WG > >> Subject: Re: [P2PSIP] Concerns, questions and nits about base=20 > >> -06 as part of the WGLC > >>=20 > >> Kademlia does iterative routing with parallel requests, and=20 > >> iterative routing has to pay the penalty of TLS/DTLS=20 > >> connection establishment at every hop which is at least 1.5 RTT. > >=20 > >>=20 > >> The alternative is to devise a secure transport protocol or=20 > >> optimize DTLS/TLS to reduce the connection establishment=20 > >> penalty. Security folks may argue that it is a non-starter at IETF. > >>=20 > >> Yet, another alternative is to design a custom secure=20 > >> transport. But interoperability is the obvious looser. > >>=20 > >> In general, for Internet scale deployment, the idea of trying=20 > >> to make all nodes, no matter what their connectivity, fully=20 > >> participate in the overlay as a peer is highly questionable. > >>=20 > >> -s > >>=20 > >> On Fri, 11 Dec 2009, jc wrote: > >>=20 > >>> Some individuals may not care to use tls or dtls. These standards=20= > >>> aren't practical in all cases. Encrypted transports a MUST but=20 > >>> mechanism should be optional. This is better than people not using=20= > >>> this draft and resolves conearns about the underlying=20 > >> transports lack=20 > >>> of performance in certain use cases. > >>>=20 > >>> Thinking Chord only as a topology plugin is too narrow from=20 > >> a security=20 > >>> performance perspective. I have bad experience with Kademlia as a=20= > >>> topology plugin. If you understand Kademlia you should=20 > >> understand how=20 > >>> the routing table functions and how the transports reflect=20 > >> that. All=20 > >>> topology plugins will be forced to tune themselves to d/tls=20 > >> which the=20 > >>> result is a less efficient system. > >>>=20 > >>> I don't see where anyone mentioned throw out encryption=20 > >> entirely but I=20 > >>> may be wrong. > >>>=20 > >>> Julian > >>>=20 > >>> Sent from my iPhone > >>>=20 > >>> On Dec 11, 2009, at 1:16 PM, Brian Rosen = wrote: > >>>=20 > >>>> > >>>> I disagree. > >>>>=20 > >>>> The problem is that we have a whole lot of history and = experience. > >>>>=20 > >>>> The experience is that if we don't insist, and make=20 > >> security integral=20 > >>>> to the protocol, it doesn't get implemented and we have a=20 > >> majority of=20 > >>>> insecure systems. > >>>>=20 > >>>> If we do insist, the cost of the security is reasonable: the dire=20= > >>>> predictions that it's too costly, too hard, ... don't happen. > >>>>=20 > >>>> No amount of text explaining when the security mechanism=20 > >> is or isn't=20 > >>>> appropriate works. You have to make the mechanism integral to the=20= > >>>> operation of the protocol, as we have done here. > >>>>=20 > >>>> I don't see anything in p2psip which would be different then our=20= > >>>> history and experience. The costs aren't as bad as you fear. The=20= > >>>> probability of nearly every system being implemented insecurely = is=20 > >>>> very high if you make it optional. > >>>>=20 > >>>> Don't do that. > >>>>=20 > >>>> Brian > >>>>=20 > >>>>=20 > >>>> On 12/11/09 12:49 PM, "Michael Chen"=20 > >> wrote: > >>>>=20 > >>>>> I too agree with the three of you. D/TLS should be optional.=20 > >>>>> Several of my > >>>>> previous post voice concerns about redundancy and=20 > >> efficiency of the=20 > >>>>> transport layer. > >>>>>=20 > >>>>> --Michael > >>>>>> -------- Original Message -------- > >>>>>> Subject: Re: [P2PSIP] Concerns, questions and nits about=20 > >> base -06=20 > >>>>>> as part of the WGLC > >>>>>> From: jc > >>>>>> Date: Fri, December 11, 2009 7:26 am > >>>>>> To: Ari Keranen > >>>>>> Cc: P2PSIP WG > >>>>>>=20 > >>>>>> I said this about 7 months ago and I still agree that=20 > >> there should=20 > >>>>>> be no mandatory transport layer encryption as this should be=20 > >>>>>> provided outside of the scope of this draft. > >>>>>>=20 > >>>>>> Julian > >>>>>>=20 > >>>>>> Sent from my iPhone > >>>>>>=20 > >>>>>> On Dec 11, 2009, at 5:39 AM, Ari Keranen=20 > >>>>>> > >>>>>> wrote: > >>>>>>=20 > >>>>>>> Hi, > >>>>>>>=20 > >>>>>>> David A. Bryan wrote: > >>>>>>>> Concern 1: Mandatory TLS/DTLS Inappropriate in some=20 > >> Contexts I've=20 > >>>>>>>> raised this issue before, but I'm hoping that now that people=20= > >>>>>>>> have had a bit more time to think about all the use cases, = see=20 > >>>>>>>> what it means in the real world, etc., there might be=20 > >> a bit mo re=20 > >>>>>>>> support for modifying the requirement for TLS/DTLS.=20 > >> TLS/DTLS ma=20 > >>>>>>>> kes sense in some cases, but if we are expecting RELOAD to be=20= > >>>>>>>> reus able, it is clear to me that it does not make=20 > >> sense in all cases. > >>>>>>>> It was familiar > >>>>>>>> to the editors, and well understood, so it made sense as a=20 > >>>>>>>> proposal, but I disagree with it being the mandatory/only=20 > >>>>>>>> solution. > >>>>>>>=20 > >>>>>>> I fully agree with David that making (D)TLS mandatory is not a=20= > >>>>>>> good idea, especially concerning re-usability of the=20 > >> protocol in=20 > >>>>>>> scenarios where you already have similar security features=20 > >>>>>>> provided by the underlying system. > >>>>>>>=20 > >>>>>>>=20 > >>>>>>> Cheers, > >>>>>>> Ari > >>>>>>> _______________________________________________ > >>>>>>> P2PSIP mailing list > >>>>>>> P2PSIP@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/p2psip > >>>>>> _______________________________________________ > >>>>>> P2PSIP mailing list > >>>>>> P2PSIP@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/p2psip > >>>>>=20 > >>>>>=20 > >>>>> _______________________________________________ > >>>>> P2PSIP mailing list > >>>>> P2PSIP@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/p2psip > >>>>=20 > >>>>=20 > >>>> _______________________________________________ > >>>> P2PSIP mailing list > >>>> P2PSIP@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/p2psip > >>> _______________________________________________ > >>> P2PSIP mailing list > >>> P2PSIP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/p2psip > >>>=20 > >>=20 > >=20 > >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail-1--664574339 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On that note, = doesn't IPv6 make ICE obsolete? and yet this draft mandates = ICE.

It does, however = it's irrelevant if you cannot obtain an IPv6 address which constitutes = most of the world's ISP's. There are only three IPv6 capable pops in the = intercontinental United States as of April 2009 and the DoD has failed = to meet their deadline last year. I'm not sure why ICE was made = mandatory in RELOAD as a base protocol but would love to know the = rational. ICE should be used "less" going forward not "more", however = that sadly isn't the case.


--Michael

-------- Original Message --------
Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as
part of the WGLC
From: jc <julian@orchidseed.org>
Date: Thu, December 17, 2009 1:19 pm
To: Song Haibin <melodysong@huawei.com>
Cc: 'Salman Abdul Baset' <sa2086@columbia.edu>, 'P2PSIP = WG'
<p2psip@ietf.org>

Nor is ICE good for overlays making use of iterative routing.

Julian

On Dec 16, 2009, at 10:51 PM, Song Haibin wrote:

>
> TLS/DTLS is not good to the DHT algorithms that use iterative = routing. And
> it also prevents using of direct response to a certain extent. = Having a
> security analysis draft for p2psip for deployers to consider = threats and
> possible solution in their deployment scenarios will qualify.
>
> For interoperability, it depends on both the standard and the = number of
> deployers who want to obey the standard.
>
> Thanks,
> Haibin
>
>> -----Original Message-----
>> From: p2psip-bounces@ietf.org
>> [mailto:p2psip-bounces@ietf.org] = On Behalf Of Salman Abdul Baset
>> Sent: Saturday, December 12, 2009 3:33 AM
>> To: jc
>> Cc: P2PSIP WG
>> Subject: Re: [P2PSIP] Concerns, questions and nits about base =
>> -06 as part of the WGLC
>>
>> Kademlia does iterative routing with parallel requests, and =
>> iterative routing has to pay the penalty of TLS/DTLS
>> connection establishment at every hop which is at least 1.5 = RTT.
>
>>
>> The alternative is to devise a secure transport protocol or =
>> optimize DTLS/TLS to reduce the connection establishment
>> penalty. Security folks may argue that it is a non-starter at = IETF.
>>
>> Yet, another alternative is to design a custom secure
>> transport. But interoperability is the obvious looser.
>>
>> In general, for Internet scale deployment, the idea of trying =
>> to make all nodes, no matter what their connectivity, fully =
>> participate in the overlay as a peer is highly = questionable.
>>
>> -s
>>
>> On Fri, 11 Dec 2009, jc wrote:
>>
>>> Some individuals may not care to use tls or dtls. These = standards
>>> aren't practical in all cases. Encrypted transports a MUST = but
>>> mechanism should be optional. This is better than people = not using
>>> this draft and resolves conearns about the underlying
>> transports lack
>>> of performance in certain use cases.
>>>
>>> Thinking Chord only as a topology plugin is too narrow from =
>> a security
>>> performance perspective. I have bad experience with = Kademlia as a
>>> topology plugin. If you understand Kademlia you should
>> understand how
>>> the routing table functions and how the transports reflect =
>> that. All
>>> topology plugins will be forced to tune themselves to d/tls =
>> which the
>>> result is a less efficient system.
>>>
>>> I don't see where anyone mentioned throw out encryption =
>> entirely but I
>>> may be wrong.
>>>
>>> Julian
>>>
>>> Sent from my iPhone
>>>
>>> On Dec 11, 2009, at 1:16 PM, Brian Rosen <br@brianrosen.net> wrote:
>>>
>>>> <as individual>
>>>> I disagree.
>>>>
>>>> The problem is that we have a whole lot of history and = experience.
>>>>
>>>> The experience is that if we don't insist, and make =
>> security integral
>>>> to the protocol, it doesn't get implemented and we have = a
>> majority of
>>>> insecure systems.
>>>>
>>>> If we do insist, the cost of the security is = reasonable: the dire
>>>> predictions that it's too costly, too hard, ... don't = happen.
>>>>
>>>> No amount of text explaining when the security = mechanism
>> is or isn't
>>>> appropriate works. You have to make the mechanism = integral to the
>>>> operation of the protocol, as we have done here.
>>>>
>>>> I don't see anything in p2psip which would be different = then our
>>>> history and experience. The costs aren't as bad as you = fear. The
>>>> probability of nearly every system being implemented = insecurely is
>>>> very high if you make it optional.
>>>>
>>>> Don't do that.
>>>>
>>>> Brian
>>>>
>>>>
>>>> On 12/11/09 12:49 PM, "Michael Chen"
>> <michaelc@idssoftware.com> = wrote:
>>>>
>>>>> I too agree with the three of you. D/TLS should be = optional.
>>>>> Several of my
>>>>> previous post voice concerns about redundancy and =
>> efficiency of the
>>>>> transport layer.
>>>>>
>>>>> --Michael
>>>>>> -------- Original Message --------
>>>>>> Subject: Re: [P2PSIP] Concerns, questions and = nits about
>> base -06
>>>>>> as part of the WGLC
>>>>>> From: jc <julian@orchidseed.org>
>>>>>> Date: Fri, December 11, 2009 7:26 am
>>>>>> To: Ari Keranen <ari.keranen@nomadiclab.com&= gt;
>>>>>> Cc: P2PSIP WG <p2psip@ietf.org>
>>>>>>
>>>>>> I said this about 7 months ago and I still = agree that
>> there should
>>>>>> be no mandatory transport layer encryption as = this should be
>>>>>> provided outside of the scope of this = draft.
>>>>>>
>>>>>> Julian
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Dec 11, 2009, at 5:39 AM, Ari Keranen
>>>>>> <ari.keranen@nomadiclab.com&= gt;
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> David A. Bryan wrote:
>>>>>>>> Concern 1: Mandatory TLS/DTLS = Inappropriate in some
>> Contexts I've
>>>>>>>> raised this issue before, but I'm = hoping that now that people
>>>>>>>> have had a bit more time to think about = all the use cases, see
>>>>>>>> what it means in the real world, etc., = there might be
>> a bit mo re
>>>>>>>> support for modifying the requirement = for TLS/DTLS.
>> TLS/DTLS ma
>>>>>>>> kes sense in some cases, but if we are = expecting RELOAD to be
>>>>>>>> reus able, it is clear to me that it = does not make
>> sense in all cases.
>>>>>>>> It was familiar
>>>>>>>> to the editors, and well understood, so = it made sense as a
>>>>>>>> proposal, but I disagree with it being = the mandatory/only
>>>>>>>> solution.
>>>>>>>
>>>>>>> I fully agree with David that making (D)TLS = mandatory is not a
>>>>>>> good idea, especially concerning = re-usability of the
>> protocol in
>>>>>>> scenarios where you already have similar = security features
>>>>>>> provided by the underlying system.
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ari
>>>>>>> = _______________________________________________
>>>>>>> P2PSIP mailing list
>>>>>>> P2PSIP@ietf.org
>>>>>>> https://www.ietf.org= /mailman/listinfo/p2psip
>>>>>> = _______________________________________________
>>>>>> P2PSIP mailing list
>>>>>> P2PSIP@ietf.org
>>>>>> https://www.ietf.org= /mailman/listinfo/p2psip
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> P2PSIP mailing list
>>>>> P2PSIP@ietf.org
>>>>> https://www.ietf.org= /mailman/listinfo/p2psip
>>>>
>>>>
>>>> _______________________________________________
>>>> P2PSIP mailing list
>>>> P2PSIP@ietf.org
>>>> https://www.ietf.org= /mailman/listinfo/p2psip
>>> _______________________________________________
>>> P2PSIP mailing list
>>> P2PSIP@ietf.org
>>> https://www.ietf.org= /mailman/listinfo/p2psip
>>>
>>
>
>

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org= /mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing = list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip

= --Apple-Mail-1--664574339-- From michaelc@IDSSOFTWARE.COM Sat Dec 19 08:20:33 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735E03A6AE2 for ; Sat, 19 Dec 2009 08:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.654 X-Spam-Level: X-Spam-Status: No, score=-0.654 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_20=-0.74] 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 LdDBckQ70d7P for ; Sat, 19 Dec 2009 08:20:29 -0800 (PST) Received: from smtpoutwbe08.prod.mesa1.secureserver.net (smtpoutwbe08.prod.mesa1.secureserver.net [208.109.78.210]) by core3.amsl.com (Postfix) with SMTP id DBC753A68B8 for ; Sat, 19 Dec 2009 08:20:28 -0800 (PST) Received: (qmail 15593 invoked from network); 19 Dec 2009 16:20:13 -0000 Received: from unknown (HELO gem-wbe41.prod.mesa1.secureserver.net) (64.202.189.120) by smtpoutwbe08.prod.mesa1.secureserver.net with SMTP; 19 Dec 2009 16:20:13 -0000 Received: (qmail 19781 invoked by uid 99); 19 Dec 2009 16:20:10 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.1.31 Message-Id: <20091219092010.61e8c06078a3b23a733c71e914c0b9df.c115908e28.wbe@email.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Sat, 19 Dec 2009 09:20:10 -0700 Mime-Version: 1.0 Subject: [P2PSIP] Clarify the 2nd bullet of section 5.1.1 Responsible ID X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 19 Dec 2009 16:20:33 -0000 Hi, In the current -06 draft, the second bullet of 5.1.1 states, "If the entry is a Node-ID which belongs to this node..." A peer may be responsible for a number of Resource-IDs but one and only one Node-ID, its own. The 3rd bullet talks about routing to clients, and 5.1.3 talks about private IDs. Therefore, this 2nd bullet should only be about the top Node-ID in the destination list equals peer's own Node-ID. I suggest change the work "belongs" to "is equal", which matches the wording of the 3rd bullet. o If the entry is a Node-ID which is equal to this node, then ... Also, the first sentence of section 5.1.2 seems to refer to the 3 bullets in section 5.1.1. It that is true, then: "If neither of the other two cases applies, then ..." should be "If neither of the three cases applies, then ..." --Michael From frederic.metz@gmail.com Mon Dec 21 03:53:50 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B5328C0DD for ; Mon, 21 Dec 2009 03:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 NswOQVADVZXb for ; Mon, 21 Dec 2009 03:53:50 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id E8EE13A69FB for ; Mon, 21 Dec 2009 03:53:49 -0800 (PST) Received: by gxk28 with SMTP id 28so4872772gxk.9 for ; Mon, 21 Dec 2009 03:53:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Z/FNxazdmh2wtGqkS1QNhEIPoGDF3A4OpuPLhwrufeM=; b=juw52/HEaDryvM5oYVJ+jaxgDbgSkzFMf62PWJEETGYPMbzzcdQCevZkW2UqCBohR8 Xrw/XhYrjbF648cvnQQ5yDVoAgn+a3lkAbmguhtjybnrQ41074BbsJNgrCna9MwWKQTr 6mRCEhqLY//nk0SLzjqLf1UI4s2WZm16gVIlk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Ql+xHOjwaj4D0l5m3J3JFpYK43FtWZPcKIob4ad7JRGtUsSR0OXtaaqk9qNFthUZYO O94C0hBFbULu47TCrFvvpeF1sfkBd3MVNk8EXI36QkFaHNtc/Wzqh83iZrmz60829Cbi 95WDEStFtJt5hXVcGwl5XN7p2qZjnyYxF+taI= MIME-Version: 1.0 Received: by 10.90.43.4 with SMTP id q4mr3289874agq.31.1261396387844; Mon, 21 Dec 2009 03:53:07 -0800 (PST) Date: Mon, 21 Dec 2009 12:53:07 +0100 Message-ID: <7e65308b0912210353m6e8485eag9c5e13a46e15b13c@mail.gmail.com> From: Frederic-Philippe Metz To: p2psip@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] Question on Roles of: Enrollment-, Credential- & Config-Server X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 21 Dec 2009 13:06:00 -0000 Hi all, within the context of a centralized enrollement, I have some questions abut rules and functionalities: Section 3.6.1. figures out that for first time setup, the user queries DNS on the overlay name and gets the address of a configuration server. The configuration server in then contacted and a configuration document is provided to the user, having the content of a bootstrap node and an enrollment server. The configuration document is described in section 10.1. Correct so far ? But the user needs a certificate first. So Section 3.6.2 says that the user performs a connection to the enrollment server (with username/pw) to obtain a certificate (with node-id, etc.). Correct so far ? In conflict to that, section 10.2. states that the adress of the enrollment server is found with a DNS query, not with the content of a configuration document and, furthermore, the configuration document is downloaded from enrollment server and the certificate, according to section 10.3, is assigned by an credential-server. Please help me clarifying this conflict. >From my understanding by now, there is: 1. initially one server providing a configuration document, including the bootstrap-nodes (and some other things for joining the overlay). The address is resolved by querying the overlay name. 2. The user then queries the service name p2psip_enroll and get the address of an Enrollment server. The user performs a connection to get a certificate (with node-id etc.). This certificate is assigned by the enrollment server. 3. The user then joins the overlay with the given certificate. But this lacks some understanding of a credential-server and/or Rules on the other elements/servers/functionalities. Regards, frederic From jouni.maenpaa@ericsson.com Mon Dec 21 05:34:45 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6764C3A689A for ; Mon, 21 Dec 2009 05:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 2plAWNh8L0PK for ; Mon, 21 Dec 2009 05:34:43 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id F196E3A69E8 for ; Mon, 21 Dec 2009 05:34:42 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-fa-4b2f79617260 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id E1.0B.14961.1697F2B4; Mon, 21 Dec 2009 14:34:25 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 14:34:25 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 14:34:25 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3865024F1 for ; Mon, 21 Dec 2009 15:34:25 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E7E1F21A31 for ; Mon, 21 Dec 2009 15:34:24 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A8E87219D0 for ; Mon, 21 Dec 2009 15:34:24 +0200 (EET) Message-ID: <4B2F7961.3020303@ericsson.com> Date: Mon, 21 Dec 2009 15:34:25 +0200 From: =?ISO-8859-1?Q?Jouni_M=E4enp=E4=E4?= User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: "p2psip@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 21 Dec 2009 13:34:25.0477 (UTC) FILETIME=[4FFACF50:01CA8242] X-Brightmail-Tracker: AAAAAA== Subject: [P2PSIP] RELOAD overlay configuration document X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 21 Dec 2009 13:34:45 -0000 Hi, One question about the "bootstrap-node" element in the RELOAD overlay configuration document. In the example configuration document included in the RELOAD base draft, the bootstrap-node element has the following contents: 192.0.0.1:5678 My question is that should the element also specify whether the bootstrap node should be contacted using DTLS or TLS? In that case, the element could perhaps look as follows:
192.0.0.1
5678 TLS Or is the assumption that the bootstrap node uses the same port for both TLS and DTLS? The above format would also make the bootstrap-node element more extensible. Cheers, Jouni From julian@orchidseed.org Mon Dec 21 08:37:17 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E7A3A6A46 for ; Mon, 21 Dec 2009 08:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 DLdQ9ebiAGOv for ; Mon, 21 Dec 2009 08:37:16 -0800 (PST) Received: from n19.c05.mtsvc.net (n19.c05.mtsvc.net [70.32.68.19]) by core3.amsl.com (Postfix) with ESMTP id C22523A67F6 for ; Mon, 21 Dec 2009 08:37:16 -0800 (PST) Received: from adsl-66-230-71.asm.bellsouth.net ([98.66.230.71]:33041 helo=[172.16.1.230]) by n19.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NMlFj-0003Lm-Aa; Mon, 21 Dec 2009 08:37:00 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: jc In-Reply-To: <4B2F7961.3020303@ericsson.com> Date: Mon, 21 Dec 2009 11:36:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B2F7961.3020303@ericsson.com> To: =?iso-8859-1?Q?Jouni_M=E4enp=E4=E4?= X-Mailer: Apple Mail (2.1077) X-Authenticated-User: 72798 julian@orchidseed.org Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] RELOAD overlay configuration document X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 21 Dec 2009 16:37:17 -0000 On Dec 21, 2009, at 8:34 AM, Jouni M=E4enp=E4=E4 wrote: > Hi, >=20 > One question about the "bootstrap-node" element in the RELOAD overlay > configuration document. In the example configuration document included > in the RELOAD base draft, the bootstrap-node element has the following > contents: >=20 > 192.0.0.1:5678 >=20 > My question is that should the element also specify whether the > bootstrap node should be contacted using DTLS or TLS? In that case, = the > element could perhaps look as follows: >=20 > >
192.0.0.1
> 5678 > TLS > >=20 > Or is the assumption that the bootstrap node uses the same port for = both > TLS and DTLS? The same port is to be used, ideally it would be the RELOAD port. > The above format would also make the bootstrap-node element more = extensible. There is debate about mandatory D(TLS) as THE base "secure" protocol = which if not mandated MUST be placed in the XML configuration document. = This would not be placed in a bootstrap-node element but rather in the = root of the XML. >=20 > Cheers, > Jouni > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From julian@orchidseed.org Mon Dec 21 09:40:10 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 306403A68AA for ; Mon, 21 Dec 2009 09:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 P3KXs29m--dI for ; Mon, 21 Dec 2009 09:40:09 -0800 (PST) Received: from n25.c05.mtsvc.net (n25.c05.mtsvc.net [70.32.68.25]) by core3.amsl.com (Postfix) with ESMTP id 665B23A6895 for ; Mon, 21 Dec 2009 09:40:09 -0800 (PST) Received: from adsl-66-230-71.asm.bellsouth.net ([98.66.230.71]:41666 helo=[172.16.1.230]) by n25.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NMmEW-0002HV-QC; Mon, 21 Dec 2009 09:39:53 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: jc In-Reply-To: <4B2F7961.3020303@ericsson.com> Date: Mon, 21 Dec 2009 12:39:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <03E40FD3-3893-4980-96D2-882F217CD7C3@orchidseed.org> References: <4B2F7961.3020303@ericsson.com> To: =?iso-8859-1?Q?Jouni_M=E4enp=E4=E4?= X-Mailer: Apple Mail (2.1077) X-Authenticated-User: 72798 julian@orchidseed.org Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] RELOAD overlay configuration document X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 21 Dec 2009 17:40:10 -0000 Jouni, I should have mentioned that I use a dual-stack (IPv4 and IPv6) and = ALWAYS accept both DTLS and TLS connections. So every node has (if = applicable) a transport acceptor on IPv6 & IPv4 both TLS and DTLS = capable and bound to the RELOAD port. ICE handles choosing DTLS and TLS = out of the box via Attach for all other Nodes however I leave the DTLS = or TLS decision for bootstrap up to the Node and use TCP first. Julian Cain On Dec 21, 2009, at 8:34 AM, Jouni M=E4enp=E4=E4 wrote: > Hi, >=20 > One question about the "bootstrap-node" element in the RELOAD overlay > configuration document. In the example configuration document included > in the RELOAD base draft, the bootstrap-node element has the following > contents: >=20 > 192.0.0.1:5678 >=20 > My question is that should the element also specify whether the > bootstrap node should be contacted using DTLS or TLS? In that case, = the > element could perhaps look as follows: >=20 > >
192.0.0.1
> 5678 > TLS > >=20 > Or is the assumption that the bootstrap node uses the same port for = both > TLS and DTLS? >=20 > The above format would also make the bootstrap-node element more = extensible. >=20 > Cheers, > Jouni > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From bbl@lowekamp.net Mon Dec 21 10:06:30 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161653A6A93 for ; Mon, 21 Dec 2009 10:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 ehrZ22yn6crq for ; Mon, 21 Dec 2009 10:06:29 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id E9F1E3A6A8E for ; Mon, 21 Dec 2009 10:06:28 -0800 (PST) Received: by fxm7 with SMTP id 7so5179476fxm.29 for ; Mon, 21 Dec 2009 10:06:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.125.35 with SMTP id c35mr3657682mun.30.1261418768785; Mon, 21 Dec 2009 10:06:08 -0800 (PST) In-Reply-To: <20091219092010.61e8c06078a3b23a733c71e914c0b9df.c115908e28.wbe@email.secureserver.net> References: <20091219092010.61e8c06078a3b23a733c71e914c0b9df.c115908e28.wbe@email.secureserver.net> Date: Mon, 21 Dec 2009 10:06:08 -0800 Message-ID: From: Bruce Lowekamp To: Michael Chen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Clarify the 2nd bullet of section 5.1.1 Responsible ID X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 21 Dec 2009 18:06:30 -0000 Michael, Thanks for the comment. There are some overlay algorithms where a single node/process might have more than one Node-ID, so section 5 should be written to allow that. You're entirely right that it's not consistent right now. Bruce On Sat, Dec 19, 2009 at 8:20 AM, Michael Chen wr= ote: > Hi, > > In the current -06 draft, the second bullet of 5.1.1 states, > > =C2=A0"If the entry is a Node-ID which belongs to this node..." > > A peer may be responsible for a number of Resource-IDs but one and only > one Node-ID, its own. > > The 3rd bullet talks about routing to clients, and 5.1.3 talks about > private IDs. Therefore, this 2nd bullet should only be about the top > Node-ID in the destination list equals peer's own Node-ID. I suggest > change the work "belongs" to "is equal", which matches the wording of > the 3rd bullet. > > =C2=A0 o =C2=A0If the entry is a Node-ID which is equal to this node, the= n ... > > Also, the first sentence of section 5.1.2 seems to refer to the 3 > bullets in section 5.1.1. It that is true, then: > > =C2=A0"If neither of the other two cases applies, then ..." > > should be > > =C2=A0"If neither of the three cases applies, then ..." > > > --Michael > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From bbl@lowekamp.net Mon Dec 21 10:35:34 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56FAA3A67FE for ; Mon, 21 Dec 2009 10:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 EzyI0qNz0psi for ; Mon, 21 Dec 2009 10:35:33 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 55F8C3A6405 for ; Mon, 21 Dec 2009 10:35:33 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 19so1910990fgg.13 for ; Mon, 21 Dec 2009 10:35:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.205.13 with SMTP id h13mr3192700muq.121.1261420512664; Mon, 21 Dec 2009 10:35:12 -0800 (PST) In-Reply-To: <7e65308b0912210353m6e8485eag9c5e13a46e15b13c@mail.gmail.com> References: <7e65308b0912210353m6e8485eag9c5e13a46e15b13c@mail.gmail.com> Date: Mon, 21 Dec 2009 10:35:12 -0800 Message-ID: From: Bruce Lowekamp To: Frederic-Philippe Metz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Question on Roles of: Enrollment-, Credential- & Config-Server X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 21 Dec 2009 18:35:34 -0000 Section 10.2 needs some clarification. First, as the last paragraph points out, an enrollment server is not the only way to get a configuration document. Secondly, as is buried in the middle paragraph, the DNS lookup is done when a URL is not provided. The intent was to allow as much flexibility as possible while still providing a standard way of locating configuration information. However, you're right that the section is really unclear. Bruce On Mon, Dec 21, 2009 at 3:53 AM, Frederic-Philippe Metz wrote: > Hi all, > > within the context of a centralized enrollement, I have some questions > abut rules and functionalities: > > Section 3.6.1. figures out that for first time setup, the user queries > DNS on the overlay name and gets the address of a configuration > server. The configuration server in then contacted and a configuration > document is provided to the user, having the content of a bootstrap > node and an enrollment server. The configuration document is described > in section 10.1. > > Correct so far ? > > But the user needs a certificate first. So Section 3.6.2 says that the > user performs a connection to the enrollment server (with username/pw) > to obtain a certificate (with node-id, etc.). > > Correct so far ? > > In conflict to that, section 10.2. states that the adress of the > enrollment server is found with a DNS query, not with the content of a > configuration document and, furthermore, the configuration document is > downloaded from enrollment server and the certificate, according to > section 10.3, is assigned by an credential-server. > > Please help me clarifying this conflict. > > From my understanding by now, there is: > > 1. initially one server providing a configuration document, including > the bootstrap-nodes (and some other things for joining the overlay). > The address is resolved by querying the overlay name. > 2. The user then queries the service name p2psip_enroll and get the > address of an Enrollment server. The user performs a connection to get > a certificate (with node-id etc.). This certificate is assigned by the > enrollment server. > 3. The user then joins the overlay with the given certificate. > > But this lacks some understanding of a credential-server and/or Rules > on the other elements/servers/functionalities. > > Regards, > =C2=A0frederic > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From julian@orchidseed.org Tue Dec 22 10:04:49 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C573A6A4A for ; Tue, 22 Dec 2009 10:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] 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 QWUmUv0uJt1R for ; Tue, 22 Dec 2009 10:04:48 -0800 (PST) Received: from n26.c05.mtsvc.net (n26.c05.mtsvc.net [70.32.68.26]) by core3.amsl.com (Postfix) with ESMTP id C87BD3A6866 for ; Tue, 22 Dec 2009 10:04:48 -0800 (PST) Received: from adsl-66-230-71.asm.bellsouth.net ([98.66.230.71]:34596 helo=[172.16.1.230]) by n26.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NN95x-0003gd-J1; Tue, 22 Dec 2009 10:04:32 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: jc In-Reply-To: <1261486213.5565.16.camel@ari.nomadiclab.com> Date: Tue, 22 Dec 2009 13:04:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B2F7961.3020303@ericsson.com> <1261486213.5565.16.camel@ari.nomadiclab.com> To: Ari Keranen X-Mailer: Apple Mail (2.1077) X-Authenticated-User: 72798 julian@orchidseed.org Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] RELOAD overlay configuration document X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 22 Dec 2009 18:04:49 -0000 On Dec 22, 2009, at 7:50 AM, Ari Keranen wrote: >=20 > Is this (explicitly) stated somewhere in the draft? If so, also I have > missed it. If it isn't, perhaps it should be. The RELOAD port is clearly documented in draft. Isn't this enough? >=20 > And what about if a node wants to use a different port number for TLS > and DTLS? I think Jouni's proposal for explicit port numbers per > protocol and structured bootstrap-node element makes sense. Nowhere in the draft is dual-stack nor dual-transport ever mentioned. = Having said that a Bootstrap Node would never listen on two ports with = two different transport protocols, its one transport protocol or the = other. My implementation decision doesn't roll over into the draft. Keep = in mind that the draft doesn't outline this scenario whatsoever and it = introduces several caveats. IMHO the topology-plugin element should provide transport and or = ciphersuite information because RELOAD isn't smart enough to choose DTLS = over TLS and so on. Only the topology plugin can supply this = recommendation to the underlying base. Julian >=20 >=20 > Cheers, > Ari >=20 From ari.keranen@nomadiclab.com Tue Dec 22 14:17:20 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768273A6A80 for ; Tue, 22 Dec 2009 14:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 9qSa5ELGsFdv for ; Tue, 22 Dec 2009 14:17:19 -0800 (PST) Received: from n2.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 76C2E3A68B0 for ; Tue, 22 Dec 2009 14:17:19 -0800 (PST) Received: from [10.0.0.250] (n250.nomadiclab.com [10.0.0.250]) by n2.nomadiclab.com (Postfix) with ESMTPSA id 1F69E1EF12E; Tue, 22 Dec 2009 14:52:42 +0200 (EET) From: Ari Keranen To: "p2psip@ietf.org" In-Reply-To: References: <4B2F7961.3020303@ericsson.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 22 Dec 2009 14:50:13 +0200 Message-ID: <1261486213.5565.16.camel@ari.nomadiclab.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [P2PSIP] RELOAD overlay configuration document X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 22 Dec 2009 22:17:20 -0000 On Mon, 2009-12-21 at 11:36 -0500, jc wrote: > On Dec 21, 2009, at 8:34 AM, Jouni Mäenpää wrote: > > > Hi, > > > > One question about the "bootstrap-node" element in the RELOAD overlay > > configuration document. In the example configuration document included > > in the RELOAD base draft, the bootstrap-node element has the following > > contents: > > > > 192.0.0.1:5678 > > > > My question is that should the element also specify whether the > > bootstrap node should be contacted using DTLS or TLS? In that case, the > > element could perhaps look as follows: > > > > > >
192.0.0.1
> > 5678 > > TLS > > > > > > Or is the assumption that the bootstrap node uses the same port for both > > TLS and DTLS? > > The same port is to be used, ideally it would be the RELOAD port. > Is this (explicitly) stated somewhere in the draft? If so, also I have missed it. If it isn't, perhaps it should be. And what about if a node wants to use a different port number for TLS and DTLS? I think Jouni's proposal for explicit port numbers per protocol and structured bootstrap-node element makes sense. Cheers, Ari From frederic.metz@gmail.com Wed Dec 23 02:52:43 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA2C83A6853 for ; Wed, 23 Dec 2009 02:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[AWL=-1.287, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45] 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 DceHzYU7S1A2 for ; Wed, 23 Dec 2009 02:52:42 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id C70D63A67E1 for ; Wed, 23 Dec 2009 02:52:42 -0800 (PST) Received: by gxk28 with SMTP id 28so930230gxk.9 for ; Wed, 23 Dec 2009 02:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HoSt5cJZr55b+73HyqZ1dhTmipsiRTwovCp8qqw0C7Q=; b=qciUusMtKHGcm7UUC7Ebj+gl9g3BIxalHpj/y3Z4P340cEjtGFWTU6i/T3Cq0EoWWW ZgdTdzToMUyys67mqtXHegIWLRSyMXjJdivfvrmrUhB38I1fdXz7jp3cIthMALZFRq97 kyAivLMpD0E+grPOl2mp1IycaN6m5S3XjLPcA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pvAd/ovZxzz84imhKczQclVSoHvJHR/byFs3WibDZK2AXiQ3UjWwJRvTB9gYru59qr R6A7XusJy0bScas1SA1x2UOXOD8Tkll8rRTVU7mbX4SkI4UCNKfJ0j1ibLBVo7BOnjHO CbewobMISu9ttH9IO2nh8yaLgsDokXxdDGrto= MIME-Version: 1.0 Received: by 10.91.162.8 with SMTP id p8mr5555805ago.58.1261565541813; Wed, 23 Dec 2009 02:52:21 -0800 (PST) In-Reply-To: References: <7e65308b0912210353m6e8485eag9c5e13a46e15b13c@mail.gmail.com> Date: Wed, 23 Dec 2009 11:52:21 +0100 Message-ID: <7e65308b0912230252y53b4d266nfe84b19631f45e7e@mail.gmail.com> From: Frederic-Philippe Metz To: =?GB2312?B?y++z586w?= Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Question on Roles of: Enrollment-, Credential- & Config-Server X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 23 Dec 2009 10:52:43 -0000 See comments inline. 2009/12/23 =CB=EF=B3=E7=CE=B0 : > > > 2009/12/21 Frederic-Philippe Metz >> >> Hi all, >> >> within the context of a centralized enrollement, I have some questions >> abut rules and functionalities: >> >> Section 3.6.1. figures out that for first time setup, the user queries >> DNS on the overlay name and gets the address of a configuration >> server. The configuration server in then contacted and a configuration >> document is provided to the user, having the content of a bootstrap >> node and an enrollment server. The configuration document is described >> in section 10.1. >> >> Correct so far ? >> >> But the user needs a certificate first. So Section 3.6.2 says that the >> user performs a connection to the enrollment server (with username/pw) >> to obtain a certificate (with node-id, etc.). >> >> Correct so far ? >> >> In conflict to that, section 10.2. states that the adress of the >> enrollment server is found with a DNS query, not with the content of a >> configuration document and, furthermore, the configuration document is >> downloaded from enrollment server and the certificate, according to >> section 10.3, is assigned by an credential-server. >> >> Please help me clarifying this conflict. >> >> From my understanding by now, there is: >> >> 1. initially one server providing a configuration document, including >> the bootstrap-nodes (and some other things for joining the overlay). >> The address is resolved by querying the overlay name. > > in 10.1 =A3=A8the second latest paragraph of page 110=A3=A9=A3=ACthe draf= t said=A3=BA"this > element represents the address of one of the bootstrap nodes. It has an > attribute called "address" that represents the IP address".so it is no ne= ed > to resolve the address by querying the overlay name. Yes, I meant the server providing the config document. This name is resolved by DNS. >> >> 2. The user then queries the service name p2psip_enroll and get the >> address of an Enrollment server. The user performs a connection to get >> a certificate (with node-id etc.). This certificate is assigned by the >> enrollment server. > > Do you mean both the certification assignment and node-ID assignment are > achieved by the enrollment server=A3=BFright=A3=BF Yes. >> >> 3. The user then joins the overlay with the given certificate. >> >> But this lacks some understanding of a credential-server and/or Rules >> on the other elements/servers/functionalities. >> >> Regards, >> frederic >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > > > -- > Sun Chongwei > Mobile LIfe and New Media Lab > Beijing University of Posts and Telecommunications > From julian@orchidseed.org Wed Dec 23 09:15:21 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26BD228C0F1 for ; Wed, 23 Dec 2009 09:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] 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 V-f0b+qHGksd for ; Wed, 23 Dec 2009 09:15:20 -0800 (PST) Received: from n25.c05.mtsvc.net (n25.c05.mtsvc.net [70.32.68.25]) by core3.amsl.com (Postfix) with ESMTP id 3560F3A68F1 for ; Wed, 23 Dec 2009 09:15:19 -0800 (PST) Received: from adsl-66-230-71.asm.bellsouth.net ([98.66.230.71]:40095 helo=[172.16.1.230]) by n25.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NNUnc-0002mR-Nl; Wed, 23 Dec 2009 09:15:02 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: jc In-Reply-To: <4B31CB80.9000204@nomadiclab.com> Date: Wed, 23 Dec 2009 12:14:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B2F7961.3020303@ericsson.com> <1261486213.5565.16.camel@ari.nomadiclab.com> <4B31CB80.9000204@nomadiclab.com> To: Ari Keranen X-Mailer: Apple Mail (2.1077) X-Authenticated-User: 72798 julian@orchidseed.org Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] RELOAD overlay configuration document X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 23 Dec 2009 17:15:21 -0000 On Dec 23, 2009, at 2:49 AM, Ari Keranen wrote: > jc wrote: >> On Dec 22, 2009, at 7:50 AM, Ari Keranen wrote: >>> Is this (explicitly) stated somewhere in the draft? If so, also I >>> have missed it. If it isn't, perhaps it should be. >> The RELOAD port is clearly documented in draft. Isn't this enough? >=20 > IMHO, not really. >=20 > There many are cases where you could want to run RELOAD on a = non-standard port. For example, if the RELOAD port is already reserved = by some other application (everyone doesn't follow the IANA = recommendations), or you want to run multiple instances of RELOAD on a = single machine using different ports, or perhaps you are behind a = middlebox from which you can get a port forwarded but can't decide the = exact port number, or maybe you just don't want your ISP to easily = detect (by looking just into port numbers) that you're using RELOAD. >=20 >>> And what about if a node wants to use a different port number for >>> TLS and DTLS? I think Jouni's proposal for explicit port numbers >>> per protocol and structured bootstrap-node element makes sense. >> Nowhere in the draft is dual-stack nor dual-transport ever mentioned. >=20 > For example AttachReq lets you define the transport protocol to use. = Doesn't that imply that you are free to mix UDP and TCP (DTLS and TLS) = connections in the overlay? Your assuming all connection setup uses AttachReq which is false. You = may have missed what I said, if you re-read you will see that I mix TCP = and UDP freely but it isn't discussed in draft. >=20 >> Having said that a Bootstrap Node would never listen on two ports >> with two different transport protocols, its one transport protocol or >> the other. My implementation decision doesn't roll over into the >> draft. Keep in mind that the draft doesn't outline this scenario >> whatsoever and it introduces several caveats. >=20 > I think it would make sense to do like your implementation does; but = in addition support different ports. What kind of caveats did you have = in mind? Well for one the discussion on which transport to use for bootstrap and = under what conditions? I currently use UDP and fallback to TCP for = bootstrapping. I prefer UDP however it very well may be blocked. >=20 >> IMHO the topology-plugin element should provide transport and or >> ciphersuite information because RELOAD isn't smart enough to choose >> DTLS over TLS and so on. Only the topology plugin can supply this >> recommendation to the underlying base. >=20 > Maybe, but likely even the topology plugin can't know whether TCP or = UDP is a better choice before running ICE. ICE is generally run before anything by the topology plugin. It is up to = the topology plugin to decide which of the ICE transports to use once = ICE negotiation has completed. >=20 >=20 > Cheers, > Ari From michaelc@IDSSOFTWARE.COM Sat Dec 26 17:16:04 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78633A6940 for ; Sat, 26 Dec 2009 17:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.439 X-Spam-Level: X-Spam-Status: No, score=0.439 tagged_above=-999 required=5 tests=[AWL=-1.020, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 P9a9iE+BsN8S for ; Sat, 26 Dec 2009 17:16:04 -0800 (PST) Received: from smtpoutwbe09.prod.mesa1.secureserver.net (smtpoutwbe09.prod.mesa1.secureserver.net [208.109.78.21]) by core3.amsl.com (Postfix) with SMTP id D10143A6405 for ; Sat, 26 Dec 2009 17:16:03 -0800 (PST) Received: (qmail 20021 invoked from network); 27 Dec 2009 01:15:44 -0000 Received: from unknown (HELO gem-wbe37.prod.mesa1.secureserver.net) (64.202.189.51) by smtpoutwbe09.prod.mesa1.secureserver.net with SMTP; 27 Dec 2009 01:15:44 -0000 Received: (qmail 6914 invoked by uid 99); 27 Dec 2009 01:15:44 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.2.01 Message-Id: <20091226181544.61e8c06078a3b23a733c71e914c0b9df.1119f19ca5.wbe@email.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Sat, 26 Dec 2009 18:15:44 -0700 Mime-Version: 1.0 Subject: [P2PSIP] Remove StoreReq.resource, FetchReq.resource, etc. X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 27 Dec 2009 01:16:05 -0000
Hi,

The resource IDs in these reques= t structures should be removed and be provided only from the Destination li= st in the forwarding header.

    St= oreReq.resource
    FetchReq.resource
&n= bsp;   StatReq.resource
    FindReq.reso= urce

This can avoid the possible inconsistency bet= ween the header and the message. It may make the request structure seemingl= y incomplete, but less is more.

Thanks
<= br>
--Michael
 From ekr@rtfm.com Sat Dec 26 17:20:57 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3009E3A68BC for ; Sat, 26 Dec 2009 17:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.396 X-Spam-Level: X-Spam-Status: No, score=0.396 tagged_above=-999 required=5 tests=[AWL=-1.853, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, SARE_SPEC_REPLICA_OBFU=1.812] 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 CUYZsX9RLTGC for ; Sat, 26 Dec 2009 17:20:56 -0800 (PST) Received: from mail-yw0-f196.google.com (mail-yw0-f196.google.com [209.85.211.196]) by core3.amsl.com (Postfix) with ESMTP id 584F03A6405 for ; Sat, 26 Dec 2009 17:20:56 -0800 (PST) Received: by ywh34 with SMTP id 34so1752580ywh.31 for ; Sat, 26 Dec 2009 17:20:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.63.34 with SMTP id q34mr4771679agk.13.1261876835040; Sat, 26 Dec 2009 17:20:35 -0800 (PST) In-Reply-To: <20091226181544.61e8c06078a3b23a733c71e914c0b9df.1119f19ca5.wbe@email.secureserver.net> References: <20091226181544.61e8c06078a3b23a733c71e914c0b9df.1119f19ca5.wbe@email.secureserver.net> Date: Sat, 26 Dec 2009 17:20:35 -0800 Message-ID: From: Eric Rescorla To: Michael Chen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Remove StoreReq.resource, FetchReq.resource, etc. X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 27 Dec 2009 01:20:57 -0000 On Sat, Dec 26, 2009 at 5:15 PM, Michael Chen wr= ote: > Hi, > The resource IDs in these request structures should be removed and be > provided only from the Destination list in the forwarding header. > =A0=A0=A0 StoreReq.resource > =A0=A0=A0 FetchReq.resource > =A0=A0=A0 StatReq.resource > =A0=A0=A0 FindReq.resource > This can avoid the possible inconsistency between the header and the > message. It may make the request structure seemingly incomplete, but less= is > more. These aren't actually redundant. There are times when you want to do a Store or a Fetch to the non-responsible node (e.g., replica stores). -Ekr From michaelc@IDSSOFTWARE.COM Sat Dec 26 19:23:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5E63A68E7 for ; Sat, 26 Dec 2009 19:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[AWL=-1.848, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, SARE_SPEC_REPLICA_OBFU=1.812] 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 wdAZ69lX7Uxm for ; Sat, 26 Dec 2009 19:23:30 -0800 (PST) Received: from smtpoutwbe01.prod.mesa1.secureserver.net (smtpoutwbe01.prod.mesa1.secureserver.net [208.109.78.112]) by core3.amsl.com (Postfix) with SMTP id 9B39B3A67AE for ; Sat, 26 Dec 2009 19:23:30 -0800 (PST) Received: (qmail 2641 invoked from network); 27 Dec 2009 03:23:10 -0000 Received: from unknown (HELO gem-wbe28.prod.mesa1.secureserver.net) (64.202.189.162) by smtpoutwbe01.prod.mesa1.secureserver.net with SMTP; 27 Dec 2009 03:23:10 -0000 Received: (qmail 11798 invoked by uid 99); 27 Dec 2009 03:23:10 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.2.01 Message-Id: <20091226202310.61e8c06078a3b23a733c71e914c0b9df.5707a89ef5.wbe@email.secureserver.net> From: "Michael Chen" To: "Eric Rescorla" Date: Sat, 26 Dec 2009 20:23:10 -0700 Mime-Version: 1.0 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Remove StoreReq.resource, FetchReq.resource, etc. X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 27 Dec 2009 03:23:31 -0000
Eric,

You are right. I forgot about = replica store.

However, I was also thinking about = the possibility that some implementation may fall victim of a malicious mes= sage in which the resource ID in the destination list and the resource ID i= n these structures are carefully chosen.

For examp= le, a StoreReq message is routed based on the destination list that arrived= at a peer responsible for the last entry (a resource ID) in the list. = ; When that peer reads StoreReq.resource, it realized that it is not respon= sible for this resource nor as a replica.(because this ID was purposely cho= sen not to be such).

An implementation may natural= ly determined that this StoreReq message should be forwarded to the peer re= sponsible for StoreReq.resource. I will not be surprised if this is done by= a generic forwarding layer that will preserve the last entry of the destin= ation list (the first resource ID) and simply add the responsible/closest p= eer of StoreReq.resource on the top of the list.

T= he result is that this message will be routed right back to this peer. I do= n't recall any guidance from the draft for this situation or route-loop det= ection. This peer may repeat the same mistake and keep the message looping = in the ring.

If we want to protect against th= at, some explicit rules should be spelled out here. Any thoughts?

--Michael

-------- Original Message --------
Subject: Re: [P2PSIP] Remove StoreReq.resource, FetchReq.resource, etc.
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, December 26, 2009 5:20 pm
To: Michael Chen <michaelc@idssoftware.com>
Cc: p2psip@ietf.org

On Sat, Dec 26, 2009 at 5:15 PM, Michael Chen <michaelc@idssoftware.com&= gt; wrote:
> Hi,
> The resource IDs in these request structures should be removed and be<= br> > provided only from the Destination list in the forwarding header.
>     StoreReq.resource
>     FetchReq.resource
>     StatReq.resource
>     FindReq.resource
> This can avoid the possible inconsistency between the header and the > message. It may make the request structure seemingly incomplete, but l= ess is
> more.

These aren't actually redundant. There are times when you want to do a
Store or a Fetch to the non-responsible node (e.g., replica stores).

-Ekr
 From ekr@rtfm.com Sat Dec 26 21:20:04 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33DBE3A66B4 for ; Sat, 26 Dec 2009 21:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.705 X-Spam-Level: X-Spam-Status: No, score=0.705 tagged_above=-999 required=5 tests=[AWL=-1.544, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, SARE_SPEC_REPLICA_OBFU=1.812] 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 9EXENjwflF8c for ; Sat, 26 Dec 2009 21:20:03 -0800 (PST) Received: from mail-yw0-f196.google.com (mail-yw0-f196.google.com [209.85.211.196]) by core3.amsl.com (Postfix) with ESMTP id 1BEF33A63C9 for ; Sat, 26 Dec 2009 21:20:03 -0800 (PST) Received: by ywh34 with SMTP id 34so1833863ywh.31 for ; Sat, 26 Dec 2009 21:19:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.161.31 with SMTP id n31mr5371768ago.96.1261891181997; Sat, 26 Dec 2009 21:19:41 -0800 (PST) In-Reply-To: <20091226202310.61e8c06078a3b23a733c71e914c0b9df.5707a89ef5.wbe@email.secureserver.net> References: <20091226202310.61e8c06078a3b23a733c71e914c0b9df.5707a89ef5.wbe@email.secureserver.net> Date: Sat, 26 Dec 2009 21:19:41 -0800 Message-ID: From: Eric Rescorla To: Michael Chen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Remove StoreReq.resource, FetchReq.resource, etc. X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 27 Dec 2009 05:20:04 -0000 On Sat, Dec 26, 2009 at 7:23 PM, Michael Chen wr= ote: > Eric, > You are right. I forgot about replica store. > However, I was also thinking about the possibility that some implementati= on > may fall victim of a malicious message in which the resource ID in the > destination list and the resource ID in these structures are carefully > chosen. > For example, a StoreReq message is routed based on the destination list t= hat > arrived at a peer responsible for the last entry (a resource ID) in the > list.=A0 When that peer reads StoreReq.resource, it realized that it is n= ot > responsible for this resource nor as a replica.(because this ID was > purposely chosen not to be such). Right. At this point it should (MUST; see 6.4.1.1) reject the request: If the replica number is zero, then the peer MUST check that it is responsible for the resource and, if not, reject the request. If the replica number is nonzero, then the peer MUST check that it expects to be a replica for the resource and that the request sender is consistent with being the responsible node (i.e., that the receiving peer does not know of a better node) and, if not, reject the request. > An implementation may naturally determined that this StoreReq message sho= uld > be forwarded to the peer responsible for StoreReq.resource. I will not be > surprised if this is done by a generic forwarding layer that will preserv= e > the last entry of the destination list (the first resource ID) and simply > add the responsible/closest peer of StoreReq.resource on the top of the > list. > The result is that this message will be routed right back to this peer. I > don't recall any guidance from the draft for this situation or route-loop > detection. This peer may repeat the same mistake and keep the message > looping in the ring. > > If we want to protect against that, some explicit rules should be spelled > out here. Any thoughts? I may have missed something, but the existing rules are intended to stop th= is from happening. Best, -Ekr From frederic.metz@gmail.com Sun Dec 27 06:29:26 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29BC43A679C for ; Sun, 27 Dec 2009 06:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_50=0.001] 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 wj9461k5f0Ji for ; Sun, 27 Dec 2009 06:29:25 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 3CF0A3A6782 for ; Sun, 27 Dec 2009 06:29:25 -0800 (PST) Received: by yxe30 with SMTP id 30so11104910yxe.29 for ; Sun, 27 Dec 2009 06:29:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=G5xohXO1SNwvQrSCjiV1+naj/LPAB8wou+7eE9VR9Ws=; b=sgN1dnuGqDpHD5t+cXvHEJHxnsnOA9HkPlZTObw1dgq5EWZawcRS7r1GTe+wme6ivd JN8L3IFDAgDgX0uzd1VLvNXbewt2J3mI2W2YmVH5l3TpL76+thY/YHCaom/DLK9kWuHk ybls+hSIXZlF7FUfymAGDDpjV5ZO5H79GNhZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SutftpryM1i/DImPbOSDs7MrHPdokYv/g2t6i4vAWgH7WKgeK0xjTdnFOF5TNG4+aO zYakjdvmCnhEQa2L8BMu+hyVGtcCl4ULP8BfCgmcxG+BMh8/RHBU7E1lKHNPw+8lBmRr 6ssn5b3YfiY+UOS/EsEiTyptmBjPIRoOKkIh0= MIME-Version: 1.0 Received: by 10.90.17.2 with SMTP id 2mr6755393agq.100.1261924142221; Sun, 27 Dec 2009 06:29:02 -0800 (PST) Date: Sun, 27 Dec 2009 15:29:02 +0100 Message-ID: <7e65308b0912270629wd01766cg20b6b4b6cb57b98c@mail.gmail.com> From: Frederic-Philippe Metz To: p2psip@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] RELOAD Interconnection X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 27 Dec 2009 14:29:26 -0000 Hi all, I have some questions respective interconnection Szenarios. Consider a situation where two independant overlays exist. Let's call them O#1 and O#2. Consider also this situation on base of a SIP-Call. One Node participating in O#1 is not able to connect to a node in O#2, unless this Node is not Joining O#1 AND O#2. Consider now multiple Overlays. Clients may do not want to join every RELOAD network, i.e. due to diffent Overlay algorithms they have to implement then. So it is not quite far away to have a certain amount of RELOAD-"Border"-Gateways acting as a Dual-RELOAD-Node. It has a node-ID on O#1 and a Node-ID on O#2. (Any better ideas than that ?). It is some sort of i.e. RELOAD Back-2-Back Node. But: Every RELOAD Node stores it's AOR in the overlay. What should this Border-Node store in the overlay on behalf of the other overlay and vice versa ? Let's assume that a Fetch of a AOR leads to the node-ID of the Border-Node. But the appattach does not contain the AOR again to do a new fetch in the other Overlay, right ? Does that mean that the fetch has go through the border-Node (always with translation of node-id at the border-node). How could that look like ? Sample Call Flow ? Better ideas ? Cheers, Frederic P.S.: Little Diagram for discussion (please note that node 20 is in both): +-------+ +-------+ +-------+ +-------+ |Node 10|-----|Node 20|---+ +---|Node 11|-----|Node 20| +-------+ +-------+ |Border Node| +-------+ +-------+ | | +-------+-------+ | Overlay O#1 | |Node 30|Node 51| | | +-------+-------+ +-------+ +-------+ | | +-------+ +-------+ |Node 50|-----|Node 40|---+ +---|Node 41|-----|Node 31| +-------+ +-------+ +-------+ +-------+ From julian@orchidseed.org Sun Dec 27 06:58:55 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7D3E3A6826 for ; Sun, 27 Dec 2009 06:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 p0B8V2ep3C0l for ; Sun, 27 Dec 2009 06:58:54 -0800 (PST) Received: from n25.c05.mtsvc.net (n25.c05.mtsvc.net [70.32.68.25]) by core3.amsl.com (Postfix) with ESMTP id E45FB3A679C for ; Sun, 27 Dec 2009 06:58:54 -0800 (PST) Received: from adsl-176-252-235.asm.bellsouth.net ([74.176.252.235]:43972 helo=[172.16.1.233]) by n25.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NOuZm-0004p6-P3; Sun, 27 Dec 2009 06:58:36 -0800 References: <7e65308b0912270629wd01766cg20b6b4b6cb57b98c@mail.gmail.com> Message-Id: From: jc To: Frederic-Philippe Metz In-Reply-To: <7e65308b0912270629wd01766cg20b6b4b6cb57b98c@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Sun, 27 Dec 2009 09:58:27 -0500 X-Authenticated-User: 72798 julian@orchidseed.org Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] RELOAD Interconnection X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 27 Dec 2009 14:58:55 -0000 Call routing doesn't span overlays. There is also no mechanism to bridge overlays that are unique. You must join or peer each overlay that your node is interested in calling through. Peering is the cheapest way to perform this operation currently. Sent from my iPhone On Dec 27, 2009, at 9:29 AM, Frederic-Philippe Metz wrote: > Hi all, > > I have some questions respective interconnection Szenarios. > > Consider a situation where two independant overlays exist. Let's call > them O#1 and O#2. Consider also this situation on base of a SIP-Call. > > One Node participating in O#1 is not able to connect to a node in O#2, > unless this Node is not Joining O#1 AND O#2. > > Consider now multiple Overlays. Clients may do not want to join every > RELOAD network, i.e. due to diffent Overlay algorithms they have to > implement then. > > So it is not quite far away to have a certain amount of > RELOAD-"Border"-Gateways acting as a Dual-RELOAD-Node. It has a > node-ID on O#1 and a Node-ID on O#2. (Any better ideas than that ?). > It is some sort of i.e. RELOAD Back-2-Back Node. > > But: > > Every RELOAD Node stores it's AOR in the overlay. What should this > Border-Node store in the overlay on behalf of the other overlay and > vice versa ? Let's assume that a Fetch of a AOR leads to the node-ID > of the Border-Node. But the appattach does not contain the AOR again > to do a new fetch in the other Overlay, right ? > Does that mean that the fetch has go through the border-Node (always > with translation of node-id at the border-node). How could that look > like ? Sample Call Flow ? Better ideas ? > > Cheers, > Frederic > > > P.S.: Little Diagram for discussion (please note that node 20 is in > both): > > +-------+ +-------+ +-------+ +-------+ > |Node 10|-----|Node 20|---+ +---|Node 11|-----|Node 20| > +-------+ +-------+ |Border Node| +-------+ +-------+ > | | +-------+-------+ > | Overlay O#1 | |Node 30|Node 51| > | | +-------+-------+ > +-------+ +-------+ | | +-------+ +-------+ > |Node 50|-----|Node 40|---+ +---|Node 41|-----|Node 31| > +-------+ +-------+ +-------+ +-------+ > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From sa2086@columbia.edu Sun Dec 27 08:35:15 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDF873A68CC for ; Sun, 27 Dec 2009 08:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 830zdA7uPdzg for ; Sun, 27 Dec 2009 08:35:14 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 582593A63EC for ; Sun, 27 Dec 2009 08:35:14 -0800 (PST) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nBRGYrjN026739; Sun, 27 Dec 2009 11:34:54 -0500 (EST) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nBRGYr9r000011; Sun, 27 Dec 2009 11:34:53 -0500 (EST) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.3/8.14.3/Submit) with ESMTP id nBRGYr4j000008; Sun, 27 Dec 2009 11:34:53 -0500 (EST) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Sun, 27 Dec 2009 11:34:53 -0500 (EST) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: jc In-Reply-To: Message-ID: References: <7e65308b0912270629wd01766cg20b6b4b6cb57b98c@mail.gmail.com> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: Frederic-Philippe Metz , "p2psip@ietf.org" Subject: Re: [P2PSIP] RELOAD Interconnection X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 27 Dec 2009 16:35:15 -0000 This problem lies with the realm of service discovery; how does a peer discover those gateway peers. There is nothing in the draft that will explicitly prevent this. -s On Sun, 27 Dec 2009, jc wrote: > Call routing doesn't span overlays. There is also no mechanism to bridge > overlays that are unique. You must join or peer each overlay that your node > is interested in calling through. > > Peering is the cheapest way to perform this operation currently. > > Sent from my iPhone > > On Dec 27, 2009, at 9:29 AM, Frederic-Philippe Metz > wrote: > >> Hi all, >> >> I have some questions respective interconnection Szenarios. >> >> Consider a situation where two independant overlays exist. Let's call >> them O#1 and O#2. Consider also this situation on base of a SIP-Call. >> >> One Node participating in O#1 is not able to connect to a node in O#2, >> unless this Node is not Joining O#1 AND O#2. >> >> Consider now multiple Overlays. Clients may do not want to join every >> RELOAD network, i.e. due to diffent Overlay algorithms they have to >> implement then. >> >> So it is not quite far away to have a certain amount of >> RELOAD-"Border"-Gateways acting as a Dual-RELOAD-Node. It has a >> node-ID on O#1 and a Node-ID on O#2. (Any better ideas than that ?). >> It is some sort of i.e. RELOAD Back-2-Back Node. >> >> But: >> >> Every RELOAD Node stores it's AOR in the overlay. What should this >> Border-Node store in the overlay on behalf of the other overlay and >> vice versa ? Let's assume that a Fetch of a AOR leads to the node-ID >> of the Border-Node. But the appattach does not contain the AOR again >> to do a new fetch in the other Overlay, right ? >> Does that mean that the fetch has go through the border-Node (always >> with translation of node-id at the border-node). How could that look >> like ? Sample Call Flow ? Better ideas ? >> >> Cheers, >> Frederic >> >> >> P.S.: Little Diagram for discussion (please note that node 20 is in both): >> >> +-------+ +-------+ +-------+ +-------+ >> |Node 10|-----|Node 20|---+ +---|Node 11|-----|Node 20| >> +-------+ +-------+ |Border Node| +-------+ +-------+ >> | | +-------+-------+ >> | Overlay O#1 | |Node 30|Node 51| >> | | +-------+-------+ >> +-------+ +-------+ | | +-------+ +-------+ >> |Node 50|-----|Node 40|---+ +---|Node 41|-----|Node 31| >> +-------+ +-------+ +-------+ +-------+ >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From michaelc@IDSSOFTWARE.COM Sun Dec 27 08:49:17 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B5F3A68FD for ; Sun, 27 Dec 2009 08:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.462 X-Spam-Level: * X-Spam-Status: No, score=1.462 tagged_above=-999 required=5 tests=[AWL=-1.623, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, SARE_SPEC_REPLICA_OBFU=1.812] 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 ieHJwUQL1bGJ for ; Sun, 27 Dec 2009 08:49:16 -0800 (PST) Received: from smtpoutwbe08.prod.mesa1.secureserver.net (smtpoutwbe08.prod.mesa1.secureserver.net [208.109.78.210]) by core3.amsl.com (Postfix) with SMTP id 8219E3A689B for ; Sun, 27 Dec 2009 08:49:16 -0800 (PST) Received: (qmail 24785 invoked from network); 27 Dec 2009 16:48:55 -0000 Received: from unknown (HELO gem-wbe34.prod.mesa1.secureserver.net) (64.202.189.30) by smtpoutwbe08.prod.mesa1.secureserver.net with SMTP; 27 Dec 2009 16:48:55 -0000 Received: (qmail 32401 invoked by uid 99); 27 Dec 2009 16:48:55 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.2.01 Message-Id: <20091227094855.61e8c06078a3b23a733c71e914c0b9df.bef80a94e1.wbe@email.secureserver.net> From: "Michael Chen" To: "Eric Rescorla" Date: Sun, 27 Dec 2009 09:48:55 -0700 Mime-Version: 1.0 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Remove StoreReq.resource, FetchReq.resource, etc. X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 27 Dec 2009 16:49:17 -0000
Eric,

Thanks for pointing out the replica StoreReq par= agraph in 6.4.1.1, but I still have 2 questions:

1. What is the via = and destination list look like for a replica StoreReq?

I believe St= oreReq (replica or not) should not be routed, thus the via list should be e= mpty and the destination list should contain a lone entry of the receiving = peer (i.e. the successor of the responsible peer). If this is true, the dra= ft should enforce it.

2. What are the use cases for the other 3 requ= ests where the resource ID in the message differ from the destination list?=

  FetchReq.resource
  StatReq.resource
  FindR= eq.resource

Replica is not involved in these cases. These messages a= re only meant to be answered by the responsible peer. If this is true, thes= e resource IDs should be removed from the message.

Thanks

--M= ichael
-------- Original Message --------
Subject: Re: [P2PSIP] Remove StoreReq.resource, FetchReq.resource, etc.
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, December 26, 2009 5:20 pm
To: Michael Chen <michaelc@idssoftware.com>
Cc: p2psip@ietf.org

On Sat, Dec 26, 2009 at 5:15 PM, Michael Chen <michaelc@idssoftware.com&= gt; wrote:
> Hi,
> The resource IDs in these request structures should be removed and be<= br> > provided only from the Destination list in the forwarding header.
>     StoreReq.resource
>     FetchReq.resource
>     StatReq.resource
>     FindReq.resource
> This can avoid the possible inconsistency between the header and the > message. It may make the request structure seemingly incomplete, but l= ess is
> more.

These aren't actually redundant. There are times when you want to do a
Store or a Fetch to the non-responsible node (e.g., replica stores).

-Ekr
 From michaelc@IDSSOFTWARE.COM Sun Dec 27 08:55:37 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D193A689B for ; Sun, 27 Dec 2009 08:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.543 X-Spam-Level: X-Spam-Status: No, score=-0.543 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 jLgolBJIIB44 for ; Sun, 27 Dec 2009 08:55:36 -0800 (PST) Received: from smtpoutwbe08.prod.mesa1.secureserver.net (smtpoutwbe08.prod.mesa1.secureserver.net [208.109.78.210]) by core3.amsl.com (Postfix) with SMTP id 744843A63EC for ; Sun, 27 Dec 2009 08:55:36 -0800 (PST) Received: (qmail 27997 invoked from network); 27 Dec 2009 16:55:18 -0000 Received: from unknown (HELO gem-wbe19.prod.mesa1.secureserver.net) (64.202.189.174) by smtpoutwbe08.prod.mesa1.secureserver.net with SMTP; 27 Dec 2009 16:55:16 -0000 Received: (qmail 1752 invoked by uid 99); 27 Dec 2009 16:55:16 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.2.01 Message-Id: <20091227095516.61e8c06078a3b23a733c71e914c0b9df.202b1f6f3f.wbe@email.secureserver.net> From: "Michael Chen" To: "Frederic-Philippe Metz" Date: Sun, 27 Dec 2009 09:55:16 -0700 Mime-Version: 1.0 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] RELOAD Interconnection X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 27 Dec 2009 16:55:37 -0000
Frederic,

One solution is to have th= e border-node treat all peers in one overlay as the client nodes of the oth= er overlay. I think it is beyond the scope of this draft.
--Michael
-------- Original Message --------
Subject: [P2PSIP] RELOAD Interconnection
From: Frederic-Philippe Metz <frederic.metz@gmail.com>
Date: Sun, December 27, 2009 6:29 am
To: p2psip@ietf.org

Hi all,

I have some questions respective interconnection Szenarios.

Consider a situation where two independant overlays exist. Let's call
them O#1 and O#2. Consider also this situation on base of a SIP-Call.

One Node participating in O#1 is not able to connect to a node in O#2,
unless this Node is not Joining O#1 AND O#2.

Consider now multiple Overlays. Clients may do not want to join every
RELOAD network, i.e. due to diffent Overlay algorithms they have to
implement then.

So it is not quite far away to have a certain amount of
RELOAD-"Border"-Gateways acting as a Dual-RELOAD-Node. It has a
node-ID on O#1 and a Node-ID on O#2. (Any better ideas than that ?).
It is some sort of i.e. RELOAD Back-2-Back Node.

But:

Every RELOAD Node stores it's AOR in the overlay. What should this
Border-Node store in the overlay on behalf of the other overlay and
vice versa ? Let's assume that a Fetch of a AOR leads to the node-ID
of the Border-Node. But the appattach does not contain the AOR again
to do a new fetch in the other Overlay, right ?
Does that mean that the fetch has go through the border-Node (always
with translation of node-id at the border-node). How could that look
like ? Sample Call Flow ? Better ideas ?

Cheers,
Frederic


P.S.: Little Diagram for discussion (please note that node 20 is in both):<= br>
+-------+ +-------+ +-------+ +-------+
|Node 10|-----|Node 20|---+ +---|Node 11|-----|Node 20|
+-------+ +-------+ |Border Node| +-------+ +-------+
| | +-------+-------+
| Overlay O#1 | |Node 30|Node 51|
| | +-------+-------+
+-------+ +-------+ | | +-------+ +-------+
|Node 50|-----|Node 40|---+ +---|Node 41|-----|Node 31|
+-------+ +-------+ +-------+ +-------+
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
= https://www.ietf.org/mailman/listinfo/p2psip
 From ekr@rtfm.com Sun Dec 27 09:11:00 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16DCF3A68DD for ; Sun, 27 Dec 2009 09:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.463 X-Spam-Level: X-Spam-Status: No, score=0.463 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, SARE_SPEC_REPLICA_OBFU=1.812] 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 JK4tKQkJf9Me for ; Sun, 27 Dec 2009 09:10:59 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 0AFD53A6831 for ; Sun, 27 Dec 2009 09:10:58 -0800 (PST) Received: by yxe30 with SMTP id 30so11170867yxe.29 for ; Sun, 27 Dec 2009 09:10:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.17.2 with SMTP id 2mr6863234agq.100.1261933837556; Sun, 27 Dec 2009 09:10:37 -0800 (PST) In-Reply-To: <20091227094855.61e8c06078a3b23a733c71e914c0b9df.bef80a94e1.wbe@email.secureserver.net> References: <20091227094855.61e8c06078a3b23a733c71e914c0b9df.bef80a94e1.wbe@email.secureserver.net> Date: Sun, 27 Dec 2009 09:10:37 -0800 Message-ID: From: Eric Rescorla To: Michael Chen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Remove StoreReq.resource, FetchReq.resource, etc. X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 27 Dec 2009 17:11:00 -0000 On Sun, Dec 27, 2009 at 8:48 AM, Michael Chen wr= ote: > Eric, > > Thanks for pointing out the replica StoreReq paragraph in 6.4.1.1, but I > still have 2 questions: > > 1. What is the via and destination list look like for a replica StoreReq? > > I believe StoreReq (replica or not) should not be routed, thus the via li= st > should be empty and the destination list should contain a lone entry of t= he > receiving peer (i.e. the successor of the responsible peer). If this is > true, the draft should enforce it. I had assumed that this question was implementation and overlay dependent. Say for the sake of argument that a node can't establish direct connections with all the replica set, then it would have to route replica stores, no? What do you think would be the advantage of adding this restriction? > 2. What are the use cases for the other 3 requests where the resource ID = in > the message differ from the destination list? > > =A0 FetchReq.resource > =A0 StatReq.resource Both of these can be used by the storing node to explicitly address replica nodes; see 6.4.1.2: The list of other peers at which the data was/will be replicated. In overlays and applications where the responsible peer is intended to store redundant copies, this allows the storing peer to independently verify that the replicas have in fact been stored. It does this verification by using the Stat method. Note that the storing peer is not require to perform this verification. The text probably should say "Stat or Fetch" methods. > =A0 FindReq.resource > > Replica is not involved in these cases. These messages are only meant to = be > answered by the responsible peer. If this is true, these resource IDs sho= uld > be removed from the message. Well, the idea with Find is to allow you to ask a specific node a question,= so it's expected to be addressed to a node directly, not a resourceid, thus requiring the resourceid in the request. -Ekr From li.lichun1@zte.com.cn Sun Dec 27 17:49:42 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18383A6803; Sun, 27 Dec 2009 17:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 UIvyAOiKXUwn; Sun, 27 Dec 2009 17:49:41 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 591C63A6783; Sun, 27 Dec 2009 17:49:39 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111643559614510; Mon, 28 Dec 2009 09:17:15 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 78921.5680175289; Mon, 28 Dec 2009 09:49:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id nBS1n6OC013095; Mon, 28 Dec 2009 09:49:06 +0800 (CST) (envelope-from li.lichun1@zte.com.cn) In-Reply-To: <7e65308b0912270629wd01766cg20b6b4b6cb57b98c@mail.gmail.com> To: Frederic-Philippe Metz MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: li.lichun1@zte.com.cn Date: Mon, 28 Dec 2009 09:48:55 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-12-28 09:49:01, Serialize complete at 2009-12-28 09:49:01 Content-Type: multipart/alternative; boundary="=_alternative 000A1AD64825769A_=" X-MAIL: mse1.zte.com.cn nBS1n6OC013095 Cc: p2psip@ietf.org, p2psip-bounces@ietf.org Subject: Re: [P2PSIP] RELOAD Interconnection X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 28 Dec 2009 01:49:42 -0000 This is a multipart message in MIME format. --=_alternative 000A1AD64825769A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgRnJlZGVyaWMsDQoNCkFsbCBvdmVybGF5cyBmdWxsLW1lc2ggY29ubmVjdGVkPyBPciBhIEZl dGNoIHJlcXVlc3QgY2FuIHJvdXRlIHRob3VnaCANCm11bHRpcGxlIG92ZXJsYXlzIHVudGlsIGl0 IHJlYWNoZXMgdGhlIGRlc3RpbmF0aW9uPyANCkJ5IHRoZSB3YXksIHRoZXJlIGFyZSB0d28gZHJh ZnRzIGFib3V0IFAyUFNJUCBpbnRlcndvcmtpbmcuIE9uZSB1c2VzIEROUyANCnRvIGludGVyd29y aywgdGhlIG90aGVyIGludHJvZHVjZXMgYSB0b3Agb3ZlcmxheSBmb3IgaW50ZXJ3b3JraW5nLg0K DQpDaGVlcnMsDQogIExpY2h1bg0KDQoNCg0KDQoNCkZyZWRlcmljLVBoaWxpcHBlIE1ldHogPGZy ZWRlcmljLm1ldHpAZ21haWwuY29tPiANCreivP7IyzogIHAycHNpcC1ib3VuY2VzQGlldGYub3Jn DQoyMDA5LTEyLTI3IDIyOjI5DQoNCsrVvP7Iyw0KcDJwc2lwQGlldGYub3JnDQqzrcvNDQoNCtb3 zOINCltQMlBTSVBdIFJFTE9BRCBJbnRlcmNvbm5lY3Rpb24NCg0KDQoNCg0KDQoNCkhpIGFsbCwN Cg0KSSBoYXZlIHNvbWUgcXVlc3Rpb25zIHJlc3BlY3RpdmUgaW50ZXJjb25uZWN0aW9uIFN6ZW5h cmlvcy4NCg0KQ29uc2lkZXIgYSBzaXR1YXRpb24gd2hlcmUgdHdvIGluZGVwZW5kYW50IG92ZXJs YXlzIGV4aXN0LiBMZXQncyBjYWxsDQp0aGVtIE8jMSBhbmQgTyMyLiBDb25zaWRlciBhbHNvIHRo aXMgc2l0dWF0aW9uIG9uIGJhc2Ugb2YgYSBTSVAtQ2FsbC4NCg0KT25lIE5vZGUgcGFydGljaXBh dGluZyBpbiBPIzEgaXMgbm90IGFibGUgdG8gY29ubmVjdCB0byBhIG5vZGUgaW4gTyMyLA0KdW5s ZXNzIHRoaXMgTm9kZSBpcyBub3QgSm9pbmluZyBPIzEgQU5EIE8jMi4NCg0KQ29uc2lkZXIgbm93 IG11bHRpcGxlIE92ZXJsYXlzLiBDbGllbnRzIG1heSBkbyBub3Qgd2FudCB0byBqb2luIGV2ZXJ5 DQpSRUxPQUQgbmV0d29yaywgaS5lLiBkdWUgdG8gZGlmZmVudCBPdmVybGF5IGFsZ29yaXRobXMg dGhleSBoYXZlIHRvDQppbXBsZW1lbnQgdGhlbi4NCg0KU28gaXQgaXMgbm90IHF1aXRlIGZhciBh d2F5IHRvIGhhdmUgYSBjZXJ0YWluIGFtb3VudCBvZg0KUkVMT0FELSJCb3JkZXIiLUdhdGV3YXlz IGFjdGluZyBhcyBhIER1YWwtUkVMT0FELU5vZGUuIEl0IGhhcyBhDQpub2RlLUlEIG9uIE8jMSBh bmQgYSBOb2RlLUlEIG9uIE8jMi4gKEFueSBiZXR0ZXIgaWRlYXMgdGhhbiB0aGF0ID8pLg0KSXQg aXMgc29tZSBzb3J0IG9mIGkuZS4gUkVMT0FEIEJhY2stMi1CYWNrIE5vZGUuDQoNCkJ1dDoNCg0K RXZlcnkgUkVMT0FEIE5vZGUgc3RvcmVzIGl0J3MgQU9SIGluIHRoZSBvdmVybGF5LiBXaGF0IHNo b3VsZCB0aGlzDQpCb3JkZXItTm9kZSBzdG9yZSBpbiB0aGUgb3ZlcmxheSBvbiBiZWhhbGYgb2Yg dGhlIG90aGVyIG92ZXJsYXkgYW5kDQp2aWNlIHZlcnNhID8gTGV0J3MgYXNzdW1lIHRoYXQgYSBG ZXRjaCBvZiBhIEFPUiBsZWFkcyB0byB0aGUgbm9kZS1JRA0Kb2YgdGhlIEJvcmRlci1Ob2RlLiBC dXQgdGhlIGFwcGF0dGFjaCBkb2VzIG5vdCBjb250YWluIHRoZSBBT1IgYWdhaW4NCnRvIGRvIGEg bmV3IGZldGNoIGluIHRoZSBvdGhlciBPdmVybGF5LCByaWdodCA/DQpEb2VzIHRoYXQgbWVhbiB0 aGF0IHRoZSBmZXRjaCBoYXMgZ28gdGhyb3VnaCB0aGUgYm9yZGVyLU5vZGUgKGFsd2F5cw0Kd2l0 aCB0cmFuc2xhdGlvbiBvZiBub2RlLWlkIGF0IHRoZSBib3JkZXItbm9kZSkuIEhvdyBjb3VsZCB0 aGF0IGxvb2sNCmxpa2UgPyBTYW1wbGUgQ2FsbCBGbG93ID8gQmV0dGVyIGlkZWFzID8NCg0KQ2hl ZXJzLA0KICBGcmVkZXJpYw0KDQoNClAuUy46IExpdHRsZSBEaWFncmFtIGZvciBkaXNjdXNzaW9u IChwbGVhc2Ugbm90ZSB0aGF0IG5vZGUgMjAgaXMgaW4gYm90aCk6DQoNCiAgKy0tLS0tLS0rICAg ICArLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rICAgICArLS0tLS0tLSsNCiAg fE5vZGUgMTB8LS0tLS18Tm9kZSAyMHwtLS0rICAgICAgICAgICArLS0tfE5vZGUgMTF8LS0tLS18 Tm9kZSAyMHwNCiAgKy0tLS0tLS0rICAgICArLS0tLS0tLSsgICB8Qm9yZGVyIE5vZGV8ICAgKy0t LS0tLS0rICAgICArLS0tLS0tLSsNCiAgICAgfCAgICAgICAgICAgICB8ICAgICAgKy0tLS0tLS0r LS0tLS0tLSsNCiAgICAgfCBPdmVybGF5IE8jMSB8ICAgICAgfE5vZGUgMzB8Tm9kZSA1MXwNCiAg ICAgfCAgICAgICAgICAgICB8ICAgICAgKy0tLS0tLS0rLS0tLS0tLSsNCiAgKy0tLS0tLS0rICAg ICArLS0tLS0tLSsgICB8ICAgICAgICAgICB8ICAgKy0tLS0tLS0rICAgICArLS0tLS0tLSsNCiAg fE5vZGUgNTB8LS0tLS18Tm9kZSA0MHwtLS0rICAgICAgICAgICArLS0tfE5vZGUgNDF8LS0tLS18 Tm9kZSAzMXwNCiAgKy0tLS0tLS0rICAgICArLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0rICAgICArLS0tLS0tLSsNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpQMlBTSVAgbWFpbGluZyBsaXN0DQpQMlBTSVBAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwDQoNCg0KDQoNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJ bmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g dGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9u LiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFt ZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBl cm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRv IG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFy ZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5k aXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRv ciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJl IHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBz Y2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 000A1AD64825769A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIDwvZm9udD48dHQ+PGZvbnQg c2l6ZT0yPkZyZWRlcmljLDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5BbGwgb3ZlcmxheXMgZnVsbC1tZXNoIGNvbm5lY3RlZD8gT3INCmEgRmV0 Y2ggcmVxdWVzdCBjYW4gcm91dGUgdGhvdWdoIG11bHRpcGxlIG92ZXJsYXlzIHVudGlsIGl0IHJl YWNoZXMgdGhlDQpkZXN0aW5hdGlvbj8gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5CeSB0aGUgd2F5LCB0aGVyZSBhcmUgdHdvIGRyYWZ0cyBhYm91dA0KUDJQU0lQ IGludGVyd29ya2luZy4gT25lIHVzZXMgRE5TIHRvIGludGVyd29yaywgdGhlIG90aGVyIGludHJv ZHVjZXMgYQ0KdG9wIG92ZXJsYXkgZm9yIGludGVyd29ya2luZy48YnI+DQo8YnI+DQo8L2ZvbnQ+ PHR0Pjxmb250IHNpemU9Mj5DaGVlcnMsPGJyPg0KICZuYnNwOzwvZm9udD48L3R0Pjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5MaWNodW48YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRo PTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+RnJlZGVyaWMtUGhpbGlwcGUg TWV0eg0KJmx0O2ZyZWRlcmljLm1ldHpAZ21haWwuY29tJmd0OzwvYj4gPC9mb250Pg0KPGJyPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO3AycHNpcC1ib3VuY2Vz QGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDkt MTItMjcgMjI6Mjk8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+cDJwc2lwQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9m b250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bUDJQU0lQXSBSRUxPQUQgSW50ZXJjb25uZWN0 aW9uPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N Cjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj5IaSBhbGwsPGJyPg0KPGJyPg0KSSBoYXZlIHNvbWUgcXVlc3Rpb25zIHJlc3BlY3RpdmUg aW50ZXJjb25uZWN0aW9uIFN6ZW5hcmlvcy48YnI+DQo8YnI+DQpDb25zaWRlciBhIHNpdHVhdGlv biB3aGVyZSB0d28gaW5kZXBlbmRhbnQgb3ZlcmxheXMgZXhpc3QuIExldCdzIGNhbGw8YnI+DQp0 aGVtIE8jMSBhbmQgTyMyLiBDb25zaWRlciBhbHNvIHRoaXMgc2l0dWF0aW9uIG9uIGJhc2Ugb2Yg YSBTSVAtQ2FsbC48YnI+DQo8YnI+DQpPbmUgTm9kZSBwYXJ0aWNpcGF0aW5nIGluIE8jMSBpcyBu b3QgYWJsZSB0byBjb25uZWN0IHRvIGEgbm9kZSBpbiBPIzIsPGJyPg0KdW5sZXNzIHRoaXMgTm9k ZSBpcyBub3QgSm9pbmluZyBPIzEgQU5EIE8jMi48YnI+DQo8YnI+DQpDb25zaWRlciBub3cgbXVs dGlwbGUgT3ZlcmxheXMuIENsaWVudHMgbWF5IGRvIG5vdCB3YW50IHRvIGpvaW4gZXZlcnk8YnI+ DQpSRUxPQUQgbmV0d29yaywgaS5lLiBkdWUgdG8gZGlmZmVudCBPdmVybGF5IGFsZ29yaXRobXMg dGhleSBoYXZlIHRvPGJyPg0KaW1wbGVtZW50IHRoZW4uPGJyPg0KPGJyPg0KU28gaXQgaXMgbm90 IHF1aXRlIGZhciBhd2F5IHRvIGhhdmUgYSBjZXJ0YWluIGFtb3VudCBvZjxicj4NClJFTE9BRC0m cXVvdDtCb3JkZXImcXVvdDstR2F0ZXdheXMgYWN0aW5nIGFzIGEgRHVhbC1SRUxPQUQtTm9kZS4g SXQgaGFzDQphPGJyPg0Kbm9kZS1JRCBvbiBPIzEgYW5kIGEgTm9kZS1JRCBvbiBPIzIuIChBbnkg YmV0dGVyIGlkZWFzIHRoYW4gdGhhdCA/KS48YnI+DQpJdCBpcyBzb21lIHNvcnQgb2YgaS5lLiBS RUxPQUQgQmFjay0yLUJhY2sgTm9kZS48YnI+DQo8YnI+DQpCdXQ6PGJyPg0KPGJyPg0KRXZlcnkg UkVMT0FEIE5vZGUgc3RvcmVzIGl0J3MgQU9SIGluIHRoZSBvdmVybGF5LiBXaGF0IHNob3VsZCB0 aGlzPGJyPg0KQm9yZGVyLU5vZGUgc3RvcmUgaW4gdGhlIG92ZXJsYXkgb24gYmVoYWxmIG9mIHRo ZSBvdGhlciBvdmVybGF5IGFuZDxicj4NCnZpY2UgdmVyc2EgPyBMZXQncyBhc3N1bWUgdGhhdCBh IEZldGNoIG9mIGEgQU9SIGxlYWRzIHRvIHRoZSBub2RlLUlEPGJyPg0Kb2YgdGhlIEJvcmRlci1O b2RlLiBCdXQgdGhlIGFwcGF0dGFjaCBkb2VzIG5vdCBjb250YWluIHRoZSBBT1IgYWdhaW48YnI+ DQp0byBkbyBhIG5ldyBmZXRjaCBpbiB0aGUgb3RoZXIgT3ZlcmxheSwgcmlnaHQgPzxicj4NCkRv ZXMgdGhhdCBtZWFuIHRoYXQgdGhlIGZldGNoIGhhcyBnbyB0aHJvdWdoIHRoZSBib3JkZXItTm9k ZSAoYWx3YXlzPGJyPg0Kd2l0aCB0cmFuc2xhdGlvbiBvZiBub2RlLWlkIGF0IHRoZSBib3JkZXIt bm9kZSkuIEhvdyBjb3VsZCB0aGF0IGxvb2s8YnI+DQpsaWtlID8gU2FtcGxlIENhbGwgRmxvdyA/ IEJldHRlciBpZGVhcyA/PGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCiAmbmJzcDtGcmVkZXJpYzxi cj4NCjxicj4NCjxicj4NClAuUy46IExpdHRsZSBEaWFncmFtIGZvciBkaXNjdXNzaW9uIChwbGVh c2Ugbm90ZSB0aGF0IG5vZGUgMjAgaXMgaW4gYm90aCk6PGJyPg0KPGJyPg0KICZuYnNwOystLS0t LS0tKyAmbmJzcDsgJm5ic3A7ICstLS0tLS0tKyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgKy0tLS0tLS0rICZuYnNwOyAmbmJz cDsgKy0tLS0tLS0rPGJyPg0KICZuYnNwO3xOb2RlIDEwfC0tLS0tfE5vZGUgMjB8LS0tKyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICstLS18Tm9kZQ0KMTF8LS0tLS18Tm9kZSAy MHw8YnI+DQogJm5ic3A7Ky0tLS0tLS0rICZuYnNwOyAmbmJzcDsgKy0tLS0tLS0rICZuYnNwOyB8 Qm9yZGVyIE5vZGV8ICZuYnNwOyArLS0tLS0tLSsNCiZuYnNwOyAmbmJzcDsgKy0tLS0tLS0rPGJy Pg0KICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyB8ICZuYnNwOyAmbmJzcDsNCiZuYnNwOystLS0tLS0tKy0tLS0tLS0rPGJyPg0KICZuYnNw OyAmbmJzcDsgfCBPdmVybGF5IE8jMSB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7fE5vZGUgMzB8Tm9k ZSA1MXw8YnI+DQogJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOw0KJm5ic3A7Ky0tLS0tLS0rLS0tLS0tLSs8YnI+ DQogJm5ic3A7Ky0tLS0tLS0rICZuYnNwOyAmbmJzcDsgKy0tLS0tLS0rICZuYnNwOyB8ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICstLS0tLS0tKyAmbmJzcDsg Jm5ic3A7ICstLS0tLS0tKzxicj4NCiAmbmJzcDt8Tm9kZSA1MHwtLS0tLXxOb2RlIDQwfC0tLSsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyArLS0tfE5vZGUNCjQxfC0tLS0tfE5v ZGUgMzF8PGJyPg0KICZuYnNwOystLS0tLS0tKyAmbmJzcDsgJm5ic3A7ICstLS0tLS0tKyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgKy0tLS0tLS0rICZuYnNwOyAmbmJzcDsgKy0tLS0tLS0rPGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpQMlBTSVAgbWFpbGluZyBsaXN0 PGJyPg0KUDJQU0lQQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9wMnBzaXA8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhl Jm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDtt YWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtj b21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZu YnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNw O21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Bl cm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNw O29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRo aXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0 ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQm bmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8m bmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNw O3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2lu Jm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5h dG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5i c3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNw O3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhp cyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZu YnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRp LVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 000A1AD64825769A_=-- From li.lichun1@zte.com.cn Mon Dec 28 01:19:09 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BB183A67CF for ; Mon, 28 Dec 2009 01:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.657 X-Spam-Level: X-Spam-Status: No, score=-94.657 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 cSNQUx4JZQv0 for ; Mon, 28 Dec 2009 01:19:08 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 3CEC43A67E9 for ; Mon, 28 Dec 2009 01:19:06 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111642075036648; Mon, 28 Dec 2009 16:46:41 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 78921.4195597427; Mon, 28 Dec 2009 17:18:41 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id nBS9If4v074224; Mon, 28 Dec 2009 17:18:42 +0800 (CST) (envelope-from li.lichun1@zte.com.cn) In-Reply-To: <7e65308b0912280053s4c71c2f9k147365bf736d8aa2@mail.gmail.com> To: Frederic-Philippe Metz MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: li.lichun1@zte.com.cn Date: Mon, 28 Dec 2009 17:18:21 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-12-28 17:18:27, Serialize complete at 2009-12-28 17:18:27 Content-Type: multipart/alternative; boundary="=_alternative 003340474825769A_=" X-MAIL: mse2.zte.com.cn nBS9If4v074224 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] RELOAD Interconnection X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 28 Dec 2009 09:19:09 -0000 This is a multipart message in MIME format. --=_alternative 003340474825769A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFyb2Njby1wMnBzaXAtaW50ZXJ3b3Jr LTAxDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaGktcDJwc2lwLWhpZXItYXJj aC0wMA0KDQpUaGVzZSB0d28gZHJhZnRzIGFyZSBleHBpcmVkLiBUaGV5IGludGVyd29yayBQMlBT SVAgaW4gU0lQIGxheWVyLiANClRoZXJlIGlzIGFsc28gYSBwYXBlciBhYm91dCBQMlBTSVAgaW5l dGVyd29ya2luZzogDQpodHRwOi8vZS1hcmNoaXZvLnVjM20uZXM6ODA4MC9kc3BhY2UvYml0c3Ry ZWFtLzEwMDE2LzMzOTAvMS9ILVAyUFNJUC5wZGYgDQoNCg0KDQoNCg0KRnJlZGVyaWMtUGhpbGlw cGUgTWV0eiA8ZnJlZGVyaWMubWV0ekBnbWFpbC5jb20+IA0KMjAwOS0xMi0yOCAxNjo1Mw0KDQrK 1bz+yMsNCmxpLmxpY2h1bjFAenRlLmNvbS5jbg0Ks63LzQ0KDQrW98ziDQpSZTogW1AyUFNJUF0g UkVMT0FEIEludGVyY29ubmVjdGlvbg0KDQoNCg0KDQoNCg0KDQoNCjIwMDkvMTIvMjggPGxpLmxp Y2h1bjFAenRlLmNvbS5jbj4NCg0KSGkgRnJlZGVyaWMsIA0KDQpBbGwgb3ZlcmxheXMgZnVsbC1t ZXNoIGNvbm5lY3RlZD8gT3IgYSBGZXRjaCByZXF1ZXN0IGNhbiByb3V0ZSB0aG91Z2ggDQptdWx0 aXBsZSBvdmVybGF5cyB1bnRpbCBpdCByZWFjaGVzIHRoZSBkZXN0aW5hdGlvbj8gDQoNCkkgV29u J3Qgc3VnZ2VzdCBhbnkgb2YgdGhlbSBieSBub3cuIEkgaGFkIG9ubHkgc29tZSB0aG91Z2h0cyAo cmVnYXJkaW5nIGEgDQpSJkQgcHJvamVjdCkgb2YgaG93IHRvIGRvIHRoYXQuDQogDQpCeSB0aGUg d2F5LCB0aGVyZSBhcmUgdHdvIGRyYWZ0cyBhYm91dCBQMlBTSVAgaW50ZXJ3b3JraW5nLiBPbmUg dXNlcyBETlMgDQp0byBpbnRlcndvcmssIHRoZSBvdGhlciBpbnRyb2R1Y2VzIGEgdG9wIG92ZXJs YXkgZm9yIGludGVyd29ya2luZy4NCg0KDQpQbGVhc2UsIEkgY291bGRuJ3QgZmluZCBhIHZhbGlk IG9uZSBhdCBJRVRGIHJlZmxlY3RpbmcgUkVMT0FELiBDb3VsZCB5b3UgDQpnaXZlIG1lIHNvbWUg bGlua3MuIFRoYW5rcy4NCiANCkNoZWVycywNCiBMaWNodW4NCg0KDQoNCg0KRnJlZGVyaWMtUGhp bGlwcGUgTWV0eiA8ZnJlZGVyaWMubWV0ekBnbWFpbC5jb20+IA0Kt6K8/sjLOiAgcDJwc2lwLWJv dW5jZXNAaWV0Zi5vcmcgDQoyMDA5LTEyLTI3IDIyOjI5IA0KDQoNCsrVvP7Iyw0KcDJwc2lwQGll dGYub3JnIA0Ks63LzQ0KDQrW98ziDQpbUDJQU0lQXSBSRUxPQUQgSW50ZXJjb25uZWN0aW9uDQoN Cg0KDQoNCg0KDQoNCg0KSGkgYWxsLA0KDQpJIGhhdmUgc29tZSBxdWVzdGlvbnMgcmVzcGVjdGl2 ZSBpbnRlcmNvbm5lY3Rpb24gU3plbmFyaW9zLg0KDQpDb25zaWRlciBhIHNpdHVhdGlvbiB3aGVy ZSB0d28gaW5kZXBlbmRhbnQgb3ZlcmxheXMgZXhpc3QuIExldCdzIGNhbGwNCnRoZW0gTyMxIGFu ZCBPIzIuIENvbnNpZGVyIGFsc28gdGhpcyBzaXR1YXRpb24gb24gYmFzZSBvZiBhIFNJUC1DYWxs Lg0KDQpPbmUgTm9kZSBwYXJ0aWNpcGF0aW5nIGluIE8jMSBpcyBub3QgYWJsZSB0byBjb25uZWN0 IHRvIGEgbm9kZSBpbiBPIzIsDQp1bmxlc3MgdGhpcyBOb2RlIGlzIG5vdCBKb2luaW5nIE8jMSBB TkQgTyMyLg0KDQpDb25zaWRlciBub3cgbXVsdGlwbGUgT3ZlcmxheXMuIENsaWVudHMgbWF5IGRv IG5vdCB3YW50IHRvIGpvaW4gZXZlcnkNClJFTE9BRCBuZXR3b3JrLCBpLmUuIGR1ZSB0byBkaWZm ZW50IE92ZXJsYXkgYWxnb3JpdGhtcyB0aGV5IGhhdmUgdG8NCmltcGxlbWVudCB0aGVuLg0KDQpT byBpdCBpcyBub3QgcXVpdGUgZmFyIGF3YXkgdG8gaGF2ZSBhIGNlcnRhaW4gYW1vdW50IG9mDQpS RUxPQUQtIkJvcmRlciItR2F0ZXdheXMgYWN0aW5nIGFzIGEgRHVhbC1SRUxPQUQtTm9kZS4gSXQg aGFzIGENCm5vZGUtSUQgb24gTyMxIGFuZCBhIE5vZGUtSUQgb24gTyMyLiAoQW55IGJldHRlciBp ZGVhcyB0aGFuIHRoYXQgPykuDQpJdCBpcyBzb21lIHNvcnQgb2YgaS5lLiBSRUxPQUQgQmFjay0y LUJhY2sgTm9kZS4NCg0KQnV0Og0KDQpFdmVyeSBSRUxPQUQgTm9kZSBzdG9yZXMgaXQncyBBT1Ig aW4gdGhlIG92ZXJsYXkuIFdoYXQgc2hvdWxkIHRoaXMNCkJvcmRlci1Ob2RlIHN0b3JlIGluIHRo ZSBvdmVybGF5IG9uIGJlaGFsZiBvZiB0aGUgb3RoZXIgb3ZlcmxheSBhbmQNCnZpY2UgdmVyc2Eg PyBMZXQncyBhc3N1bWUgdGhhdCBhIEZldGNoIG9mIGEgQU9SIGxlYWRzIHRvIHRoZSBub2RlLUlE DQpvZiB0aGUgQm9yZGVyLU5vZGUuIEJ1dCB0aGUgYXBwYXR0YWNoIGRvZXMgbm90IGNvbnRhaW4g dGhlIEFPUiBhZ2Fpbg0KdG8gZG8gYSBuZXcgZmV0Y2ggaW4gdGhlIG90aGVyIE92ZXJsYXksIHJp Z2h0ID8NCkRvZXMgdGhhdCBtZWFuIHRoYXQgdGhlIGZldGNoIGhhcyBnbyB0aHJvdWdoIHRoZSBi b3JkZXItTm9kZSAoYWx3YXlzDQp3aXRoIHRyYW5zbGF0aW9uIG9mIG5vZGUtaWQgYXQgdGhlIGJv cmRlci1ub2RlKS4gSG93IGNvdWxkIHRoYXQgbG9vaw0KbGlrZSA/IFNhbXBsZSBDYWxsIEZsb3cg PyBCZXR0ZXIgaWRlYXMgPw0KDQpDaGVlcnMsDQogRnJlZGVyaWMNCg0KDQpQLlMuOiBMaXR0bGUg RGlhZ3JhbSBmb3IgZGlzY3Vzc2lvbiAocGxlYXNlIG5vdGUgdGhhdCBub2RlIDIwIGlzIGluIGJv dGgpOg0KDQogKy0tLS0tLS0rICAgICArLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgKy0tLS0t LS0rICAgICArLS0tLS0tLSsNCiB8Tm9kZSAxMHwtLS0tLXxOb2RlIDIwfC0tLSsgICAgICAgICAg ICstLS18Tm9kZSAxMXwtLS0tLXxOb2RlIDIwfA0KICstLS0tLS0tKyAgICAgKy0tLS0tLS0rICAg fEJvcmRlciBOb2RlfCAgICstLS0tLS0tKyAgICAgKy0tLS0tLS0rDQogICAgfCAgICAgICAgICAg ICB8ICAgICAgKy0tLS0tLS0rLS0tLS0tLSsNCiAgICB8IE92ZXJsYXkgTyMxIHwgICAgICB8Tm9k ZSAzMHxOb2RlIDUxfA0KICAgIHwgICAgICAgICAgICAgfCAgICAgICstLS0tLS0tKy0tLS0tLS0r DQogKy0tLS0tLS0rICAgICArLS0tLS0tLSsgICB8ICAgICAgICAgICB8ICAgKy0tLS0tLS0rICAg ICArLS0tLS0tLSsNCiB8Tm9kZSA1MHwtLS0tLXxOb2RlIDQwfC0tLSsgICAgICAgICAgICstLS18 Tm9kZSA0MXwtLS0tLXxOb2RlIDMxfA0KICstLS0tLS0tKyAgICAgKy0tLS0tLS0rICAgICAgICAg ICAgICAgICAgICstLS0tLS0tKyAgICAgKy0tLS0tLS0rDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KUDJQU0lQIG1haWxpbmcgbGlzdA0KUDJQU0lQQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0KDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBtYWlsIGlzIA0Kc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBv cmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIA0KY29uZmlkZW50aWFsLiBS ZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBh bmQgDQphcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBj b21tdW5pY2F0aW9uIHRvIA0Kb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5z bWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgDQpzb2xlbHkgZm9y IHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRk cmVzc2VkLiANCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNl IG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiANCnRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVz c2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIA0KaW5kaXZpZHVhbCBzZW5kZXIu DQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBa VEUgQW50aS1TcGFtIA0Kc3lzdGVtLg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJp dHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xl bHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11 bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxp Z2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xv c2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVt YWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFu ZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5 IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2Uu IEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5k aXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNl cyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 003340474825769A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LW1hcm9jY28tcDJwc2lwLWludGVyd29yay0wMTwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtc2hpLXAycHNpcC1oaWVyLWFyY2gtMDA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NClRoZXNlIHR3byBkcmFmdHMgYXJlIGV4cGlyZWQuIFRoZXkgaW50 ZXJ3b3JrIFAyUFNJUCBpbiBTSVAgbGF5ZXIuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+VGhlcmUgaXMgYWxzbyBhIHBhcGVyIGFib3V0IFAyUFNJUCBpbmV0ZXJ3 b3JraW5nOg0KaHR0cDovL2UtYXJjaGl2by51YzNtLmVzOjgwODAvZHNwYWNlL2JpdHN0cmVhbS8x MDAxNi8zMzkwLzEvSC1QMlBTSVAucGRmDQo8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2 JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+RnJlZGVyaWMtUGhpbGlwcGUgTWV0 eg0KJmx0O2ZyZWRlcmljLm1ldHpAZ21haWwuY29tJmd0OzwvYj4gPC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDktMTItMjggMTY6NTM8L2ZvbnQ+DQo8dGQgd2lk dGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+bGkubGljaHVuMUB6dGUu Y29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj5SZTogW1AyUFNJUF0gUkVMT0FEIEludGVyY29ubmVjdGlvbjwvZm9udD48L3RhYmxl Pg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxi cj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjIwMDkv MTIvMjggJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpsaS5saWNodW4xQHp0ZS5jb20uY24+PGZv bnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+bGkubGljaHVuMUB6dGUu Y29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZndDs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkhpIDwvZm9u dD48dHQ+PGZvbnQgc2l6ZT0yPkZyZWRlcmljLDwvZm9udD48L3R0Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KQWxsIG92ZXJsYXlzIGZ1bGwtbWVzaCBjb25uZWN0ZWQ/IE9yIGEgRmV0Y2ggcmVx dWVzdCBjYW4gcm91dGUgdGhvdWdoIG11bHRpcGxlDQpvdmVybGF5cyB1bnRpbCBpdCByZWFjaGVz IHRoZSBkZXN0aW5hdGlvbj8gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj48YnI+DQpJIFdvbid0IHN1Z2dlc3QgYW55IG9mIHRoZW0gYnkgbm93LiBJIGhhZCBvbmx5 IHNvbWUgdGhvdWdodHMgKHJlZ2FyZGluZw0KYSBSJmFtcDtEIHByb2plY3QpIG9mIGhvdyB0byBk byB0aGF0Ljxicj4NCiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PkJ5IHRoZSB3YXksIHRoZXJlIGFyZSB0d28gZHJhZnRzIGFib3V0DQpQMlBTSVAgaW50ZXJ3b3Jr aW5nLiBPbmUgdXNlcyBETlMgdG8gaW50ZXJ3b3JrLCB0aGUgb3RoZXIgaW50cm9kdWNlcyBhDQp0 b3Agb3ZlcmxheSBmb3IgaW50ZXJ3b3JraW5nLjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KUGxlYXNlLCBJIGNvdWxkbid0IGZpbmQgYSB2YWxp ZCBvbmUgYXQgSUVURiByZWZsZWN0aW5nIFJFTE9BRC4gQ291bGQgeW91DQpnaXZlIG1lIHNvbWUg bGlua3MuIFRoYW5rcy48YnI+DQogPC9mb250Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Q2hlZXJz LDxicj4NCiA8L2ZvbnQ+PC90dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TGljaHVu PGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8 YnI+DQo8L2ZvbnQ+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTYwJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+RnJlZGVyaWMtUGhpbGlw cGUgTWV0eg0KJmx0OzwvYj48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZnJlZGVyaWMubWV0ekBnbWFp bC5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNl cmlmIj48Yj48dT5mcmVkZXJpYy5tZXR6QGdtYWlsLmNvbTwvdT48L2I+PC9mb250PjwvYT48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Jmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDs8L2ZvbnQ+PGEgaHJlZj0i bWFpbHRvOnAycHNpcC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9 MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PnAycHNpcC1ib3VuY2VzQGlldGYub3Jn PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDktMTItMjcgMjI6Mjk8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTM5JT4N Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MTUl Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjL PC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTg0JT48YSBocmVmPW1haWx0bzpwMnBzaXBAaWV0Zi5v cmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlm Ij48dT5wMnBzaXBAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPltQMlBTSVBdIFJFTE9BRCBJbnRlcmNvbm5lY3Rpb248L2ZvbnQ+PC90YWJs ZT4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQg d2lkdGg9NTAlPg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPkhpIGFsbCw8YnI+DQo8YnI+DQpJIGhhdmUgc29tZSBxdWVzdGlvbnMgcmVz cGVjdGl2ZSBpbnRlcmNvbm5lY3Rpb24gU3plbmFyaW9zLjxicj4NCjxicj4NCkNvbnNpZGVyIGEg c2l0dWF0aW9uIHdoZXJlIHR3byBpbmRlcGVuZGFudCBvdmVybGF5cyBleGlzdC4gTGV0J3MgY2Fs bDxicj4NCnRoZW0gTyMxIGFuZCBPIzIuIENvbnNpZGVyIGFsc28gdGhpcyBzaXR1YXRpb24gb24g YmFzZSBvZiBhIFNJUC1DYWxsLjxicj4NCjxicj4NCk9uZSBOb2RlIHBhcnRpY2lwYXRpbmcgaW4g TyMxIGlzIG5vdCBhYmxlIHRvIGNvbm5lY3QgdG8gYSBub2RlIGluIE8jMiw8YnI+DQp1bmxlc3Mg dGhpcyBOb2RlIGlzIG5vdCBKb2luaW5nIE8jMSBBTkQgTyMyLjxicj4NCjxicj4NCkNvbnNpZGVy IG5vdyBtdWx0aXBsZSBPdmVybGF5cy4gQ2xpZW50cyBtYXkgZG8gbm90IHdhbnQgdG8gam9pbiBl dmVyeTxicj4NClJFTE9BRCBuZXR3b3JrLCBpLmUuIGR1ZSB0byBkaWZmZW50IE92ZXJsYXkgYWxn b3JpdGhtcyB0aGV5IGhhdmUgdG88YnI+DQppbXBsZW1lbnQgdGhlbi48YnI+DQo8YnI+DQpTbyBp dCBpcyBub3QgcXVpdGUgZmFyIGF3YXkgdG8gaGF2ZSBhIGNlcnRhaW4gYW1vdW50IG9mPGJyPg0K UkVMT0FELSZxdW90O0JvcmRlciZxdW90Oy1HYXRld2F5cyBhY3RpbmcgYXMgYSBEdWFsLVJFTE9B RC1Ob2RlLiBJdCBoYXMNCmE8YnI+DQpub2RlLUlEIG9uIE8jMSBhbmQgYSBOb2RlLUlEIG9uIE8j Mi4gKEFueSBiZXR0ZXIgaWRlYXMgdGhhbiB0aGF0ID8pLjxicj4NCkl0IGlzIHNvbWUgc29ydCBv ZiBpLmUuIFJFTE9BRCBCYWNrLTItQmFjayBOb2RlLjxicj4NCjxicj4NCkJ1dDo8YnI+DQo8YnI+ DQpFdmVyeSBSRUxPQUQgTm9kZSBzdG9yZXMgaXQncyBBT1IgaW4gdGhlIG92ZXJsYXkuIFdoYXQg c2hvdWxkIHRoaXM8YnI+DQpCb3JkZXItTm9kZSBzdG9yZSBpbiB0aGUgb3ZlcmxheSBvbiBiZWhh bGYgb2YgdGhlIG90aGVyIG92ZXJsYXkgYW5kPGJyPg0KdmljZSB2ZXJzYSA/IExldCdzIGFzc3Vt ZSB0aGF0IGEgRmV0Y2ggb2YgYSBBT1IgbGVhZHMgdG8gdGhlIG5vZGUtSUQ8YnI+DQpvZiB0aGUg Qm9yZGVyLU5vZGUuIEJ1dCB0aGUgYXBwYXR0YWNoIGRvZXMgbm90IGNvbnRhaW4gdGhlIEFPUiBh Z2Fpbjxicj4NCnRvIGRvIGEgbmV3IGZldGNoIGluIHRoZSBvdGhlciBPdmVybGF5LCByaWdodCA/ PGJyPg0KRG9lcyB0aGF0IG1lYW4gdGhhdCB0aGUgZmV0Y2ggaGFzIGdvIHRocm91Z2ggdGhlIGJv cmRlci1Ob2RlIChhbHdheXM8YnI+DQp3aXRoIHRyYW5zbGF0aW9uIG9mIG5vZGUtaWQgYXQgdGhl IGJvcmRlci1ub2RlKS4gSG93IGNvdWxkIHRoYXQgbG9vazxicj4NCmxpa2UgPyBTYW1wbGUgQ2Fs bCBGbG93ID8gQmV0dGVyIGlkZWFzID88YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KIEZyZWRlcmlj PGJyPg0KPGJyPg0KPGJyPg0KUC5TLjogTGl0dGxlIERpYWdyYW0gZm9yIGRpc2N1c3Npb24gKHBs ZWFzZSBub3RlIHRoYXQgbm9kZSAyMCBpcyBpbiBib3RoKTo8YnI+DQo8YnI+DQogKy0tLS0tLS0r ICZuYnNwOyAmbmJzcDsgKy0tLS0tLS0rICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyArLS0tLS0tLSsgJm5ic3A7ICZuYnNwOyAr LS0tLS0tLSs8YnI+DQogfE5vZGUgMTB8LS0tLS18Tm9kZSAyMHwtLS0rICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgKy0tLXxOb2RlDQoxMXwtLS0tLXxOb2RlIDIwfDxicj4NCiAr LS0tLS0tLSsgJm5ic3A7ICZuYnNwOyArLS0tLS0tLSsgJm5ic3A7IHxCb3JkZXIgTm9kZXwgJm5i c3A7ICstLS0tLS0tKw0KJm5ic3A7ICZuYnNwOyArLS0tLS0tLSs8YnI+DQogJm5ic3A7ICZuYnNw O3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5i c3A7DQombmJzcDsrLS0tLS0tLSstLS0tLS0tKzxicj4NCiAmbmJzcDsgJm5ic3A7fCBPdmVybGF5 IE8jMSB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7fE5vZGUgMzB8Tm9kZSA1MXw8YnI+DQogJm5ic3A7 ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJz cDsgJm5ic3A7DQombmJzcDsrLS0tLS0tLSstLS0tLS0tKzxicj4NCiArLS0tLS0tLSsgJm5ic3A7 ICZuYnNwOyArLS0tLS0tLSsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgfCAmbmJzcDsgKy0tLS0tLS0rICZuYnNwOyAmbmJzcDsgKy0tLS0tLS0rPGJyPg0KIHxO b2RlIDUwfC0tLS0tfE5vZGUgNDB8LS0tKyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICstLS18Tm9kZQ0KNDF8LS0tLS18Tm9kZSAzMXw8YnI+DQogKy0tLS0tLS0rICZuYnNwOyAm bmJzcDsgKy0tLS0tLS0rICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwOyArLS0tLS0tLSsgJm5ic3A7ICZuYnNwOyArLS0tLS0tLSs8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUDJQU0lQIG1haWxpbmcgbGlzdDwvZm9udD48 L3R0Pjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dT48YnI+DQo8L3U+PC9mb250PjwvdHQ+ PGEgaHJlZj1tYWlsdG86UDJQU0lQQGlldGYub3JnIHRhcmdldD1fYmxhbms+PHR0Pjxmb250IHNp emU9MiBjb2xvcj1ibHVlPjx1PlAyUFNJUEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC90dD48L2E+PHR0 Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PC90dD48YSBocmVm PWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwIHRhcmdldD1fYmxh bms+PHR0Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcDJwc2lwPC91PjwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0y Pjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48 YnI+DQo8L2ZvbnQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mz4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsDQpp cyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWls IGNvbW11bmljYXRpb24NCmlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBh cmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kNCmFuZCBhcmUgbm90IHBlcm1pdHRlZCB0 byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvDQpvdGhlcnMu PGJyPg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNv bmZpZGVudGlhbCBhbmQgaW50ZW5kZWQNCnNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuDQpJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Ig b2YNCnRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUg dGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwNCnNlbmRlci48YnI+DQpUaGlzIG1lc3NhZ2UgaGFzIGJl ZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS48 YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9y bWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRp b24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJz cDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJz cDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5i c3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7 YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7 c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3Rv Jm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZu YnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZu YnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5i c3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZu YnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7 dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUm bmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJz cDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJz cDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5i c3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2Um bmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJz cDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0 ZW0uDQo8L3ByZT4= --=_alternative 003340474825769A_=-- From ekr@networkresonance.com Mon Dec 28 12:11:57 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A178D3A6920 for ; Mon, 28 Dec 2009 12:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.705 X-Spam-Level: X-Spam-Status: No, score=0.705 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, J_CHICKENPOX_51=0.6, RDNS_NONE=0.1] 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 jkNvTUndg7FM for ; Mon, 28 Dec 2009 12:11:54 -0800 (PST) Received: from kilo.networkresonance.com (unknown [216.187.66.243]) by core3.amsl.com (Postfix) with ESMTP id 30F4E3A67B2 for ; Mon, 28 Dec 2009 12:11:54 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 3E7D76C96F6; Sat, 26 Dec 2009 07:14:15 -0800 (PST) Date: Sat, 26 Dec 2009 07:14:14 -0800 From: Eric Rescorla To: "David A. Bryan" In-Reply-To: <8b2769930912070957x4f8dc91av13c6088134d96146@mail.gmail.com> References: <8b2769930912070957x4f8dc91av13c6088134d96146@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20091226151416.3E7D76C96F6@kilo.networkresonance.com> Cc: P2PSIP WG Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 28 Dec 2009 20:11:57 -0000 While I don't find any of the arguments below particularly convincing, I'm not sure it's worth arguing about it. You agree we need security and TLS/DTLS is what we've got. If your concern is purely to allow for extensibility than I propose the following: - Adjacencies in a RELOAD network MUST be secured by a mechanism that provides at minimum + Peer authentication + Message integrity + Confidentiality - Implementations MUST support TLS/DTLS. - An overlay MAY specify any alternate mechanism in their configuration files (and we'll provide some syntax for it) Would that be satisfactory? -Ekr At Mon, 7 Dec 2009 12:57:54 -0500, David A. Bryan wrote: > Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts >=20 > I?ve raised this issue before, but I?m hoping that now that people > have had a bit more time to think about all the use cases, see what it > means in the real world, etc., there might be a bit more support for > modifying the requirement for TLS/DTLS. TLS/DTLS makes sense in some > cases, but if we are expecting RELOAD to be reusable, it is clear to > me that it does not make sense in all cases. It was familiar to the > editors, and well understood, so it made sense as a proposal, but I > disagree with it being the mandatory/only solution. > > I am not advocating we allow unsecured system. There needs to be a way > to do that for development/debugging, but you can do that with a null > cipher, so that concern is addressed. >=20 > Instead my concerns are two-fold: >=20 > 1) TLS/DTLS is too heavy for query-response systems using > direct-response routing. > 2) There are applications that may want to secure at a different level > or using a different technology. >=20 > First, looking at DTLS for query-response systems using direct routing. >=20 > A bit of background: Clearly, RELOAD should work for query-response > systems, where the only use of the DHT is to obtain a small item of > information (e.g. obtaining a registration or a certificate). > Similarly, while there has been discussion about whether the current > individual draft is the appropriate mechanism, the group hummed in > Minneapolis to include direct routing in the protocol, and in SF the > hum was repeated, with strong consensus to include it as an extension > and ensure base draft doesn?t preclude it. >=20 > Establishing a TLS/DTLS connection is a very heavy way to establish a > connection between two peers for a simple response, particularly if > using direct where the connection is used only to convey that > response. (7 messages for DTLS [1]) With recursive response, it makes > sense, since the connection is persistent, but a lighter mechanism > (for example, including the requestors public cert in the request, and > having the responder encrypt the reply) is far more appropriate for a > direct routed response. The current draft mandates TLS/DTLS and only > TLS/DTLS, leading to an artificially high cost for direct response > routing. Based on my work with potential real-world users of P2PSIP > going back almost 4 years, request-response is a very likely scenario. > While the TLS-PSK/TLS-SRP stuff helps here, other mechanisms would > still be more efficient. > > Similarly, we should allow alternate mechanisms: >=20 > Even if one is using the recursive response approach for routing, > there may be other architectures. A system of persistent peers (for > example provisioned set-top boxes using reload to share information) > may have ISP assigned IDs, and persistent peers connected to one > another, and use hardware based encryption, VPNs, etc. between the > peers. > > There are many ways to encrypt a connection, and mandating one and > only one seems inappropriate. A better design is to provide a > mechanism in the draft for an alternate encryption technique, > recommend DTLS, provide information, and require some encryption be > used. While someone could choose to build without encryption, the > argument seems weak. They could also just ignore the requirement in > the first place. In my opinion, we are more likely to have problems > later (extensions that will have to modify the original draft to use a > different security mechanism, deployments that are ?almost? RELOAD but > with different security etc.) if we proceed with the current draft?s > approach. >=20 > [1] Modadugu, N., Rescorla, E., "The Design and Implementation of > Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004. From sunchw@gmail.com Mon Dec 28 17:24:09 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDEA13A6914 for ; Mon, 28 Dec 2009 17:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.277 X-Spam-Level: ** X-Spam-Status: No, score=2.277 tagged_above=-999 required=5 tests=[AWL=3.675, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_51=0.6] 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 bsNY-pmtVvaO for ; Mon, 28 Dec 2009 17:24:08 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id E6BFD3A6868 for ; Mon, 28 Dec 2009 17:24:07 -0800 (PST) Received: by ewy6 with SMTP id 6so9141716ewy.29 for ; Mon, 28 Dec 2009 17:23:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=pJYLg0Nt6afnF9ijln730n9+MvRFp++vnc5klrTMYCA=; b=nE+6fQcctDhHSEO4DmRALbQiZn/YvAI7ZmjdFGTqCCq62qMzY9nfhZyYOyjQVbotcp s3Ilp7ws8SGvfbWjW5BDzSdJRFChyxOpkIg9WLR24knr9Axo81lyvR3oTctYTa7IJIXq BrbeHEnuYf4Txq8uXW8cv+4CxvQQdTX09iJ94= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VquuzVBHryQJhhOnsXdpNNUDJBzAjqC8XOufUxRkvqESYwjDKduF7F88RFnGvp0axz Y931jibhRvQzxh/7wLH919LWh4pjiyE6JchV50sw596GT5+wAfpMMX9KXfydQ6DpTSko fYiuQZkdhWdngf8KfXHKiWTJ6AnaKnQjIDQrM= MIME-Version: 1.0 Received: by 10.216.90.67 with SMTP id d45mr5152251wef.42.1262049825189; Mon, 28 Dec 2009 17:23:45 -0800 (PST) In-Reply-To: <20091226151416.3E7D76C96F6@kilo.networkresonance.com> References: <8b2769930912070957x4f8dc91av13c6088134d96146@mail.gmail.com> <20091226151416.3E7D76C96F6@kilo.networkresonance.com> Date: Tue, 29 Dec 2009 09:23:45 +0800 Message-ID: From: Sun Chongwei To: Eric Rescorla Content-Type: multipart/alternative; boundary=0016e6d7df7884efed047bd3df2d Cc: P2PSIP WG Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 29 Dec 2009 01:24:09 -0000 --0016e6d7df7884efed047bd3df2d Content-Type: text/plain; charset=ISO-8859-1 I do not think the argument is not worth. Many people expressed their desire for a opening security mechanism in RELOAD. Many of them agree TLS/DTLS should not be mandatory. That is an acheivement of this discussion. Am I right? 2009/12/26 Eric Rescorla > While I don't find any of the arguments below particularly convincing, > I'm not sure it's worth arguing about it. You agree we need security > and TLS/DTLS is what we've got. If your concern is purely to allow > for extensibility than I propose the following: > > - Adjacencies in a RELOAD network MUST be secured by a mechanism > that provides at minimum > + Peer authentication > + Message integrity > + Confidentiality > - Implementations MUST support TLS/DTLS. > - An overlay MAY specify any alternate mechanism in their configuration > files (and we'll provide some syntax for it) > > Would that be satisfactory? > > -Ekr > > > At Mon, 7 Dec 2009 12:57:54 -0500, > David A. Bryan wrote: > > Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts > > > > I?ve raised this issue before, but I?m hoping that now that people > > have had a bit more time to think about all the use cases, see what it > > means in the real world, etc., there might be a bit more support for > > modifying the requirement for TLS/DTLS. TLS/DTLS makes sense in some > > cases, but if we are expecting RELOAD to be reusable, it is clear to > > me that it does not make sense in all cases. It was familiar to the > > editors, and well understood, so it made sense as a proposal, but I > > disagree with it being the mandatory/only solution. > > > > I am not advocating we allow unsecured system. There needs to be a way > > to do that for development/debugging, but you can do that with a null > > cipher, so that concern is addressed. > > > > Instead my concerns are two-fold: > > > > 1) TLS/DTLS is too heavy for query-response systems using > > direct-response routing. > > 2) There are applications that may want to secure at a different level > > or using a different technology. > > > > First, looking at DTLS for query-response systems using direct routing. > > > > A bit of background: Clearly, RELOAD should work for query-response > > systems, where the only use of the DHT is to obtain a small item of > > information (e.g. obtaining a registration or a certificate). > > Similarly, while there has been discussion about whether the current > > individual draft is the appropriate mechanism, the group hummed in > > Minneapolis to include direct routing in the protocol, and in SF the > > hum was repeated, with strong consensus to include it as an extension > > and ensure base draft doesn?t preclude it. > > > > Establishing a TLS/DTLS connection is a very heavy way to establish a > > connection between two peers for a simple response, particularly if > > using direct where the connection is used only to convey that > > response. (7 messages for DTLS [1]) With recursive response, it makes > > sense, since the connection is persistent, but a lighter mechanism > > (for example, including the requestors public cert in the request, and > > having the responder encrypt the reply) is far more appropriate for a > > direct routed response. The current draft mandates TLS/DTLS and only > > TLS/DTLS, leading to an artificially high cost for direct response > > routing. Based on my work with potential real-world users of P2PSIP > > going back almost 4 years, request-response is a very likely scenario. > > While the TLS-PSK/TLS-SRP stuff helps here, other mechanisms would > > still be more efficient. > > > > Similarly, we should allow alternate mechanisms: > > > > Even if one is using the recursive response approach for routing, > > there may be other architectures. A system of persistent peers (for > > example provisioned set-top boxes using reload to share information) > > may have ISP assigned IDs, and persistent peers connected to one > > another, and use hardware based encryption, VPNs, etc. between the > > peers. > > > > There are many ways to encrypt a connection, and mandating one and > > only one seems inappropriate. A better design is to provide a > > mechanism in the draft for an alternate encryption technique, > > recommend DTLS, provide information, and require some encryption be > > used. While someone could choose to build without encryption, the > > argument seems weak. They could also just ignore the requirement in > > the first place. In my opinion, we are more likely to have problems > > later (extensions that will have to modify the original draft to use a > > different security mechanism, deployments that are ?almost? RELOAD but > > with different security etc.) if we proceed with the current draft?s > > approach. > > > > [1] Modadugu, N., Rescorla, E., "The Design and Implementation of > > Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004. > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > -- Sun Chongwei Mobile LIfe and New Media Lab Beijing University of Posts and Telecommunications --0016e6d7df7884efed047bd3df2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I do not think the argument is not worth. Many people expressed their = desire for a opening security mechanism in RELOAD.
Many of th= em agree TLS/DTLS should not be mandatory. That is an acheivement =A0of thi= s discussion.

Am I right?

2009/12= /26 Eric Rescorla <ekr@networkresonance.com>
While I don't find any of the arguments below particularly convincing,<= br> I'm not sure it's worth arguing about it. You agree we need securit= y
and TLS/DTLS is what we've got. If your concern is purely to allow
for extensibility than I propose the following:

- Adjacencies in a RELOAD network MUST be secured by a mechanism
=A0that provides at minimum
=A0+ Peer authentication
=A0+ Message integrity
=A0+ Confidentiality
- Implementations MUST support TLS/DTLS.
- An overlay MAY specify any alternate mechanism in their configuration
=A0files (and we'll provide some syntax for it)

Would that be satisfactory?

-Ekr


At Mon, 7 Dec 2009 12:57:54 -0500,
David A. Bryan wrote:
> Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts
>
> I?ve raised this issue before, but I?m hoping that now that people
> have had a bit more time to think about all the use cases, see what it=
> means in the real world, etc., there might be a bit more support for > modifying the requirement for TLS/DTLS. TLS/DTLS makes sense in some > cases, but if we are expecting RELOAD to be reusable, it is clear to > me that it does not make sense in all cases. It was familiar to the > editors, and well understood, so it made sense as a proposal, but I > disagree with it being the mandatory/only solution.
>
> I am not advocating we allow unsecured system. There needs to be a way=
> to do that for development/debugging, but you can do that with a null<= br> > cipher, so that concern is addressed.
>
> Instead my concerns are two-fold:
>
> 1) TLS/DTLS is too heavy for query-response systems using
> direct-response routing.
> 2) There are applications that may want to secure at a different level=
> or using a different technology.
>
> First, looking at DTLS for query-response systems using direct routing= .
>
> A bit of background: Clearly, RELOAD should work for query-response > systems, where the only use of the DHT is to obtain a small item of > information (e.g. obtaining a registration or a certificate).
> Similarly, while there has been discussion about whether the current > individual draft is the appropriate mechanism, the group hummed in
> Minneapolis to include direct routing in the protocol, and in SF the > hum was repeated, with strong consensus to include it as an extension<= br> > and ensure base draft doesn?t preclude it.
>
> Establishing a TLS/DTLS connection is a very heavy way to establish a<= br> > connection between two peers for a simple response, particularly if > using direct where the connection is used only to convey that
> response. (7 messages for DTLS [1]) With recursive response, it makes<= br> > sense, since the connection is persistent, but a lighter mechanism
> (for example, including the requestors public cert in the request, and=
> having the responder encrypt the reply) is far more appropriate for a<= br> > direct routed response. The current draft mandates TLS/DTLS and only > TLS/DTLS, leading to an artificially high cost for direct response
> routing. Based on my work with potential real-world users of P2PSIP > going back almost 4 years, request-response is a very likely scenario.=
> While the TLS-PSK/TLS-SRP stuff helps here, other mechanisms would
> still be more efficient.
>
> Similarly, we should allow alternate mechanisms:
>
> Even if one is using the recursive response approach for routing,
> there may be other architectures. A system of persistent peers (for > example provisioned set-top boxes using reload to share information) > may have ISP assigned IDs, and persistent peers connected to one
> another, and use hardware based encryption, VPNs, etc. between the
> peers.
>
> There are many ways to encrypt a connection, and mandating one and
> only one seems inappropriate. A better design is to provide a
> mechanism in the draft for an alternate encryption technique,
> recommend DTLS, provide information, and require some encryption be > used. While someone could choose to build without encryption, the
> argument seems weak. They could also just ignore the requirement in > the first place. In my opinion, we are more likely to have problems > later (extensions that will have to modify the original draft to use a=
> different security mechanism, deployments that are ?almost? RELOAD but=
> with different security etc.) if we proceed with the current draft?s > approach.
>
> [1] Modadugu, N., Rescorla, E., "The Design and Implementation of=
> Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004.
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
= https://www.ietf.org/mailman/listinfo/p2psip



--
Sun Chongwei
Mobile = LIfe and New Media Lab
Beijing University of Posts and Telecommunication= s
--0016e6d7df7884efed047bd3df2d-- From ari.keranen@nomadiclab.com Tue Dec 29 00:35:13 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3F2F3A6977 for ; Tue, 29 Dec 2009 00:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 91FDbGtR9Ph0 for ; Tue, 29 Dec 2009 00:35:10 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 72EB73A6858 for ; Tue, 29 Dec 2009 00:35:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 72D641EF13D; Tue, 29 Dec 2009 10:34:45 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCduVydGSiv2; Tue, 29 Dec 2009 10:34:44 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 605351EF12F; Tue, 29 Dec 2009 10:34:44 +0200 (EET) Message-ID: <4B39BF24.1070307@nomadiclab.com> Date: Tue, 29 Dec 2009 10:34:44 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: jc References: <4B2F7961.3020303@ericsson.com> <1261486213.5565.16.camel@ari.nomadiclab.com> <4B31CB80.9000204@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Jouni_M=E4enp=E4?=, "p2psip@ietf.org" Subject: Re: [P2PSIP] RELOAD overlay configuration document X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 29 Dec 2009 08:35:13 -0000 jc wrote: > On Dec 23, 2009, at 2:49 AM, Ari Keranen wrote: > >> jc wrote: >>> On Dec 22, 2009, at 7:50 AM, Ari Keranen wrote: >>>> Is this (explicitly) stated somewhere in the draft? If so, also >>>> I have missed it. If it isn't, perhaps it should be. >>> The RELOAD port is clearly documented in draft. Isn't this >>> enough? >> IMHO, not really. >> >> There many are cases where you could want to run RELOAD on a >> non-standard port. For example, if the RELOAD port is already >> reserved by some other application (everyone doesn't follow the >> IANA recommendations), or you want to run multiple instances of >> RELOAD on a single machine using different ports, or perhaps you >> are behind a middlebox from which you can get a port forwarded but >> can't decide the exact port number, or maybe you just don't want >> your ISP to easily detect (by looking just into port numbers) that >> you're using RELOAD. >> >>>> And what about if a node wants to use a different port number >>>> for TLS and DTLS? I think Jouni's proposal for explicit port >>>> numbers per protocol and structured bootstrap-node element >>>> makes sense. >>> Nowhere in the draft is dual-stack nor dual-transport ever >>> mentioned. >> For example AttachReq lets you define the transport protocol to >> use. Doesn't that imply that you are free to mix UDP and TCP (DTLS >> and TLS) connections in the overlay? > > Your assuming all connection setup uses AttachReq which is false. You > may have missed what I said, if you re-read you will see that I mix > TCP and UDP freely but it isn't discussed in draft. What other ways except Attach did you have in mind for setting up a RELOAD connection? Or are you referring to bootstrapping procedures? Anyway, my point was that even the current draft, while not being too explicit about it, supports simultaneous TCP and UDP (with different port numbers too) for setting up connections between peers so the configuration document should be in line with this. Or at least it would not hurt. >>> Having said that a Bootstrap Node would never listen on two ports >>> with two different transport protocols, its one transport >>> protocol or the other. My implementation decision doesn't roll >>> over into the draft. Keep in mind that the draft doesn't outline >>> this scenario whatsoever and it introduces several caveats. >> I think it would make sense to do like your implementation does; >> but in addition support different ports. What kind of caveats did >> you have in mind? > > Well for one the discussion on which transport to use for bootstrap > and under what conditions? I currently use UDP and fallback to TCP > for bootstrapping. I prefer UDP however it very well may be blocked. Implementation should try one and if that doesn't work, try the other; which one to try first would be up to the implementation, and your approach would fit well into that idea. >>> IMHO the topology-plugin element should provide transport and or >>> ciphersuite information because RELOAD isn't smart enough to >>> choose DTLS over TLS and so on. Only the topology plugin can >>> supply this recommendation to the underlying base. >> Maybe, but likely even the topology plugin can't know whether TCP >> or UDP is a better choice before running ICE. > > ICE is generally run before anything by the topology plugin. It is up > to the topology plugin to decide which of the ICE transports to use > once ICE negotiation has completed. Yes, something like that should work. But back to the original question: wouldn't you also, considering all the points we have discussed, prefer the following format (or something similar) for the bootstrap-node element:
192.0.0.1
5678 TLS over the original format: 192.0.0.1:5678 With the new format you are free to use the same port for both TLS and DTLS, but you are not forced to do so. Also, this makes the element much more extensible. Cheers, Ari From julian@orchidseed.org Tue Dec 29 08:16:22 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A9633A694E for ; Tue, 29 Dec 2009 08:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 7TU-tmpNhtiD for ; Tue, 29 Dec 2009 08:16:21 -0800 (PST) Received: from n13.c05.mtsvc.net (n13.c05.mtsvc.net [70.32.68.13]) by core3.amsl.com (Postfix) with ESMTP id 409243A68DB for ; Tue, 29 Dec 2009 08:16:21 -0800 (PST) Received: from adsl-176-252-235.asm.bellsouth.net ([74.176.252.235]:47208 helo=[172.16.1.230]) by n13.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NPejM-0000Kj-8R; Tue, 29 Dec 2009 08:15:34 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-1-328261845 From: jc In-Reply-To: <4B39BF24.1070307@nomadiclab.com> Date: Tue, 29 Dec 2009 11:15:03 -0500 Message-Id: References: <4B2F7961.3020303@ericsson.com> <1261486213.5565.16.camel@ari.nomadiclab.com> <4B31CB80.9000204@nomadiclab.com> <4B39BF24.1070307@nomadiclab.com> To: Ari Keranen X-Mailer: Apple Mail (2.1077) X-Authenticated-User: 72798 julian@orchidseed.org Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] RELOAD overlay configuration document X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 29 Dec 2009 16:16:22 -0000 --Apple-Mail-1-328261845 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 29, 2009, at 3:34 AM, Ari Keranen wrote: >=20 > But back to the original question: wouldn't you also, considering all = the points we have discussed, prefer the following format (or something = similar) for the bootstrap-node element: >=20 > >
192.0.0.1
> 5678 > TLS > >=20 > over the original format: >=20 > 192.0.0.1:5678 >=20 > With the new format you are free to use the same port for both TLS and = DTLS, but you are not forced to do so. Also, this makes the element much = more extensible. >=20 I don't prefer this format. I see no value in adding and moving = the port, at least not in my working implementation. You may want to get = input from others. >=20 > Cheers, > Ari --Apple-Mail-1-328261845 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

But back to the = original question: wouldn't you also, considering all the points we have = discussed, prefer the following format (or something similar) for the = bootstrap-node element:

<bootstrap-node>
=  <address>192.0.0.1</address>
=  <port>5678</port>
=  <proto>TLS</proto>
</bootstrap-node>

ove= r the original = format:

<bootstrap-node>192.0.0.1:5678</bootstrap-node>=

With the new format you are free to use the same port for both = TLS and DTLS, but you are not forced to do so. Also, this makes the = element much more = extensible.


I don't prefer = this format. I see no value in adding <proto> and moving the port, = at least not in my working implementation. You may want to get input = from others.


Cheers,
Ari

= --Apple-Mail-1-328261845-- From ekr@networkresonance.com Tue Dec 29 23:21:51 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D4B23A683B for ; Tue, 29 Dec 2009 23:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.046 X-Spam-Level: X-Spam-Status: No, score=-0.046 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] 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 XWgDGcxdB-dZ for ; Tue, 29 Dec 2009 23:21:50 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 1FB063A67F5 for ; Tue, 29 Dec 2009 23:21:50 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 61E8B6CA1AE; Mon, 28 Dec 2009 17:31:21 -0800 (PST) Date: Mon, 28 Dec 2009 17:31:20 -0800 From: Eric Rescorla To: Sun Chongwei In-Reply-To: References: <8b2769930912070957x4f8dc91av13c6088134d96146@mail.gmail.com> <20091226151416.3E7D76C96F6@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091229013121.61E8B6CA1AE@kilo.networkresonance.com> Cc: P2PSIP WG Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 30 Dec 2009 07:21:51 -0000 At Tue, 29 Dec 2009 09:23:45 +0800, Sun Chongwei wrote: > > [1 ] > I do not think the argument is not worth. Many people expressed their desire > for a opening security mechanism in RELOAD. > Many of them agree TLS/DTLS should not be mandatory. That is an acheivement > of this discussion. > > Am I right? There's mandatory to implement and mandatory to use. I'm willing to accept mandatory to implement but not to use via the mechanism I described in my original message. I am strongly against removing the mandatory to implement. -Ekr From ari.keranen@nomadiclab.com Tue Dec 29 23:38:53 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED8503A6939 for ; Tue, 29 Dec 2009 23:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 mdwnD6e13N3b for ; Tue, 29 Dec 2009 23:38:53 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id F3C123A6974 for ; Tue, 29 Dec 2009 23:38:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id B246B1EF1EB; Wed, 30 Dec 2009 09:38:32 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ufz41e2aV4q9; Wed, 30 Dec 2009 09:38:32 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 4D7771EF12F; Wed, 30 Dec 2009 09:38:32 +0200 (EET) Message-ID: <4B3B0378.40700@nomadiclab.com> Date: Wed, 30 Dec 2009 09:38:32 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Eric Rescorla References: <4B2F7961.3020303@ericsson.com> <1261486213.5565.16.camel@ari.nomadiclab.com> <4B31CB80.9000204@nomadiclab.com> <4B39BF24.1070307@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] RELOAD overlay configuration document X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 30 Dec 2009 07:38:54 -0000 Eric Rescorla wrote: > On Tue, Dec 29, 2009 at 12:34 AM, Ari Keranen >> But back to the original question: wouldn't you also, considering all the >> points we have discussed, prefer the following format (or something similar) >> for the bootstrap-node element: >> >> >>
192.0.0.1
>> 5678 >> TLS >> >> >> over the original format: >> >> 192.0.0.1:5678 >> >> With the new format you are free to use the same port for both TLS and DTLS, >> but you are not forced to do so. Also, this makes the element much more >> extensible. > > I have no problem with this suggestion. > OK, thanks! Cheers, Ari From jouni.maenpaa@ericsson.com Tue Dec 29 23:42:32 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B44CA3A67A8 for ; Tue, 29 Dec 2009 23:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.124 X-Spam-Level: X-Spam-Status: No, score=-5.124 tagged_above=-999 required=5 tests=[AWL=0.825, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 O1ytFWjTtW4B for ; Tue, 29 Dec 2009 23:42:32 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id B51203A63C9 for ; Tue, 29 Dec 2009 23:42:31 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-64-4b3b0451ac50 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 9B.0F.14961.1540B3B4; Wed, 30 Dec 2009 08:42:09 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Dec 2009 08:42:09 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Dec 2009 08:42:09 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1D4B42325; Wed, 30 Dec 2009 09:42:09 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DC0EB21A31; Wed, 30 Dec 2009 09:42:08 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 97ECD219D0; Wed, 30 Dec 2009 09:42:08 +0200 (EET) Message-ID: <4B3B0450.4050203@ericsson.com> Date: Wed, 30 Dec 2009 09:42:08 +0200 From: =?ISO-8859-1?Q?Jouni_M=E4enp=E4=E4?= User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: "p2psip@ietf.org" References: <4B2F7961.3020303@ericsson.com> <1261486213.5565.16.camel@ari.nomadiclab.com> <4B31CB80.9000204@nomadiclab.com> <4B39BF24.1070307@nomadiclab.com> In-Reply-To: <4B39BF24.1070307@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 30 Dec 2009 07:42:09.0367 (UTC) FILETIME=[97981E70:01CA8923] X-Brightmail-Tracker: AAAAAA== Subject: Re: [P2PSIP] RELOAD overlay configuration document X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 30 Dec 2009 07:42:32 -0000 Hi, Ari Keranen wrote: > But back to the original question: wouldn't you also, considering all > the points we have discussed, prefer the following format (or > something similar) for the bootstrap-node element: > > >
192.0.0.1
> 5678 > TLS > > > over the original format: > > 192.0.0.1:5678 > > With the new format you are free to use the same port for both TLS and > DTLS, but you are not forced to do so. Also, this makes the element > much more extensible. I like the new format since it is easy to extend. Cheers, Jouni