From petithug@acm.org Sun Mar 3 13:09:14 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C1B21F8865 for ; Sun, 3 Mar 2013 13:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CLR3r7q8EMb for ; Sun, 3 Mar 2013 13:09:13 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 0A00A21F8860 for ; Sun, 3 Mar 2013 13:09:12 -0800 (PST) Received: from [IPv6:2601:9:4b80:32:a1f1:ed52:9113:f4ab] (unknown [IPv6:2601:9:4b80:32:a1f1:ed52:9113:f4ab]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 6BBA6204C2 for ; Sun, 3 Mar 2013 21:09:11 +0000 (UTC) Message-ID: <5133BB4F.6030604@acm.org> Date: Sun, 03 Mar 2013 13:06:23 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: P2PSIP Mailing List References: <20130114232302.20758.60139.idtracker@ietfa.amsl.com> <50F49761.7000408@acm.org> <512CF5E8.5000604@acm.org> In-Reply-To: <512CF5E8.5000604@acm.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] Bootstrap redirection authentication [was Re: Fwd: I-D Action: draft-petithuguenin-p2psip-reload-one-to-many-00.txt] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 21:09:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/26/2013 09:50 AM, Marc Petit-Huguenin wrote: > I did not release a new version of this draft because as I was working on > improving it I discovered some issues and I was not able to decide on the > right solution. So I will present this in Orlando if I get presentation > time, but I would like to start the discussion now. > > The problem with Anycast is that there is no guarantee on the long term > that the same physical endpoint will be reached when using such address. > This is not a problem for short-term association, and even TCP is known to > work fine in this case. But in some cases (RELOAD section 3.2.1 second > bullet) a client can establish a long-term association with a bootstrap > server, and this association may fail. So the solution used in > -one-to-many-00 is to first send a STUN binding to the Anycast address > which will be answered with a 300 redirect that contains a Unicast address > that can be used for long term association. This also works fine with > multicast and broadcast. No problem so far. > > The problem is that it is relatively easy to redirect the client to the > wrong IP address, which is why this kind of mechanism requires some form > of authentication, so the client knows that the answer is from the real > server. Note that the client will anyway quickly discover that the IP > address does not use a correct certificate, so perhaps this attack is > harmless. > > One solution is to use the long-term authentication mechanism of STUN, > using the same username and password that was used to acquire the RELOAD > certificate. The client checks the MESSAGE-INTEGRITY in the response to > verify that the server really knows the password. I do not really like > this solution, because it requires to distribute and synchronize the > usernames/passwords on a lot of different servers. > > Another solution may be to use the fact that the bootstrap servers are > contacted after a certificate is retrieved from the enrollment server > (although an implementation may want to query the real address in parallel) > to establish a DTLS connection with the Anycast address, using this newly > acquired certificate, and then send the STUN Binding over it. That's my > preferred solution, but that looks a little bit complex for that purpose > (although it does not add more code to an implementation, as DTLS is > required for RELOAD anyway). Reading the notes I took when trying to implement this, there is another issue which is that DTLS was never defined as transport for STUN (or TURN). So that would require an additional draft. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRM7tOAAoJECnERZXWan7ENs8P+wdo8mIB+0HXQDVI7KNKa2d4 iGxgNyrIbR53+gQum7n00LHjl0xP0hKuSa/INbCcWP7JY7EH1O5Z4VI4Bej4QRHA SlRc6MOrlB2c6Zjk/z/IxVeYQjXVhyKAejhRdlO9HzyKkF5BNnJHm6InQV/40J5s jGM7WiSXo0NzF2qXcVAcRf03UNPw5rGJtUQHSfY9u5ufjM89gi/a7/tuyoCgQMne zmQh0MUDF2hETth0XVXuM1W2mTeRsRN/DwLSrlvnF4jWDihDvrh6czvXWzvue1tf fzBiCeaj/j/eKiixODeSwSnlLqbuEodRVT0jPvqErAgzCLuoc6Ys8HboEQuQf/k9 h19uPeY9h4n/nTr8otZCt5jJUZbT6QPNyV8GNbT5yoaVXqrjEFzuyr9u567UcphJ 6vd+NOIzwT8y9PIrRdqC8bVGa1FhiYc3EVrdoex/M2Q26Vhxd9hHEG9W/tuuc6ot PhLEOjzK5ZBmhzaVSXK7r64AfLI/10nSMc/RUw96u5WoOKxyZpRVVki0y2EBQ14p UNIdvhw/fnRXEkIPCV85oYEeKXCXecZoSg4DhYfmesHJhWJ5CWf1CWcUrR1AF/Zv 0aPHCtF083yAoGIJeis/oxdkYqrkp3rXXOu0DwX0pxTIuM4iaq1Nj+DB+l3KR6rh w1hpklilL/clrGf0463g =dEOO -----END PGP SIGNATURE----- From cjbc@it.uc3m.es Wed Mar 6 01:35:01 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9491921F8682 for ; Wed, 6 Mar 2013 01:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fv-fxJvuGhmj for ; Wed, 6 Mar 2013 01:35:01 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id ED56521F8651 for ; Wed, 6 Mar 2013 01:35:00 -0800 (PST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4FCC0CC5BCD; Wed, 6 Mar 2013 10:34:59 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 436FCCC58CD; Wed, 6 Mar 2013 10:34:59 +0100 (CET) Message-ID: <1362562499.5102.13.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: P2PSIP WG Date: Wed, 06 Mar 2013 10:34:59 +0100 In-Reply-To: <1361990714.4326.28.camel@acorde.it.uc3m.es> References: <1361990714.4326.28.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19692.002 X-TM-AS-Result: No--23.781-7.0-31-1 X-imss-scan-details: No--23.781-7.0-31-1 Cc: p2psip-chairs@tools.ietf.org Subject: Re: [P2PSIP] Draft agenda posted for IETF86 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 09:35:01 -0000 Hi all, The final agenda (we just did a minor update) is posted on the IETF datatracker site. Presenters: (if you have not done it already) please send your slides to the chairs Sunday afternoon the latest. Thanks! Brian and Carlos On Wed, 2013-02-27 at 19:45 +0100, Carlos Jesús Bernardos Cano wrote: > Hi all, > > You can find a first version of the agenda for Orlando at the end of > this e-mail. Note that most updated version can always be found at: > http://www.ietf.org/proceedings/86/agenda/agenda-86-p2psip > > If we missed any request or assigned a wrong slot, please let us know. > Note that the presentation slots may change by +-5 min or so. > > -- Brian and Carlos > > ------------------------------------------------------------------------- > Agenda of the P2PSIP WG meeting at IETF 86 > MONDAY, March 11, 2013 > 1540-1710 (Afternoon Session II), Caribbean 6 > Conflicts: history, netconf, pce, oauth, tsvwg > > ------------------------------------------------------------------------- > > 15:40 Administrativia ........................................... 5 min > B. Rosen, CJ. Bernardos > > 15:45 WG Status Update .......................................... 20 min > B. Rosen, CJ. Bernardos > > 16:05 A SIP Usage for RELOAD .................................... 10 min > o draft-ietf-p2psip-sip-09 > * Presenter: Thomas C. Schmidt > > 16:15 A Usage for Shared Resources in RELOAD (ShaRe) ............ 10 min > o draft-ietf-p2psip-share-01 > * Presenter: Thomas C. Schmidt > > 16:25 Configuration of Access Control Policy in RELOAD .......... 10 min > o draft-ietf-p2psip-access-control-00 > * Presenter: Marc Petit-Huguenin > > 16:35 Anycast, Multicast or Broadcast Bootstrap Nodes for RELOAD 15 min > o draft-petithuguenin-p2psip-reload-one-to-many-00 > * Presenter: Marc Petit-Huguenin > > 16:50 SCTP Overlay link for for RELOAD .......................... 10 min > o draft-petithuguenin-p2psip-reload-sctp-00 > * Presenter: Marc Petit-Huguenin > > 17:00 Anonymization for RELOAD .................................. 5 min > o draft-petithuguenin-p2psip-reload-anonymous-02 > * Presenter: Marc Petit-Huguenin > > 17:05 Next steps ................................................ 5 min > B. Rosen, CJ. Bernardos > > ------------------------------------------------------------------------- > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From cjbc@it.uc3m.es Mon Mar 11 07:07:05 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E712F21F8A3E for ; Mon, 11 Mar 2013 07:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivvJVWwDUJfk for ; Mon, 11 Mar 2013 07:07:05 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 44B0421F8A3D for ; Mon, 11 Mar 2013 07:07:05 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D809DFA98D1 for ; Mon, 11 Mar 2013 15:07:02 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [130.129.10.64] (dhcp-9240.meeting.ietf.org [130.129.10.64]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 48D32FA98C6 for ; Mon, 11 Mar 2013 15:07:02 +0100 (CET) Message-ID: <1363010819.4430.16.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: P2PSIP WG Date: Mon, 11 Mar 2013 15:06:59 +0100 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19708.006 X-TM-AS-Result: No--0.280-7.0-31-1 X-imss-scan-details: No--0.280-7.0-31-1 Subject: [P2PSIP] Materials for today's session posted X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 14:07:06 -0000 Hi folks, The materials are now available on the meetings material site. Thanks to all presenters for providing the slides timely in advance: https://datatracker.ietf.org/meeting/86/materials.html For those here in Orlando, we would need a couple of minute takers and a jabber scribe. If you can kindly volunteer in advance, that would be highly appreciated. Thanks! -- Brian & Carlos From ron.even.tlv@gmail.com Wed Mar 13 05:46:09 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56A621F848B for ; Wed, 13 Mar 2013 05:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmivcyzPhtKg for ; Wed, 13 Mar 2013 05:46:08 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1CB421F8477 for ; Wed, 13 Mar 2013 05:46:08 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id wz12so988094pbc.17 for ; Wed, 13 Mar 2013 05:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=XDPmvJ6kofFigF/gby95TmePKh2ftlomHHQm5ZR4glU=; b=RGEwxIQ23YofKnMNjx08s+oBe0ZEqGlR7ZZGPDl/AyuF5ylEbLXcN08iT3IYI6Ldcd D26kzLDPgolts3eHfuhbaN6Tirn4LfDraInYRVhHmvcZ9TgWoL8cT7aay4UJ33SLsxPz IS+P5VTYf3p3XVf0SEap49JE8o33D/6mh4Gw/iYqhRj/5GOE+QwhRmjEoeZ/M8G/T/Sd NvWcHGuzy5pkB8U7vYDig0/Qv4A7Y/Ty8hgiUF2Xo8C8S6xT7TOEiYwbQiLLhzL8wBAW P+5R/OonDqHp46w8levxkl014G+nAbw2jz4r7OUnBDd5gNo60oS0u1jmHWS4w0yGW0cr eGog== X-Received: by 10.68.213.104 with SMTP id nr8mr46068559pbc.200.1363178768051; Wed, 13 Mar 2013 05:46:08 -0700 (PDT) Received: from RoniE ([2001:df8:0:64:4571:a157:5673:fb54]) by mx.google.com with ESMTPS id xz5sm97220pbb.25.2013.03.13.05.46.04 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 13 Mar 2013 05:46:06 -0700 (PDT) From: "Roni Even" To: , References: <1358855465.4174.24.camel@acorde.it.uc3m.es> In-Reply-To: <1358855465.4174.24.camel@acorde.it.uc3m.es> Date: Wed, 13 Mar 2013 14:45:42 +0200 Message-ID: <008f01ce1fe8$aedf0c10$0c9d2430$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJJctlInCoLwT4KekX9uZ6cgNVklpes6wTw Content-Language: en-us Cc: draft-ietf-p2psip-drr@tools.ietf.org, draft-ietf-p2psip-rpr@tools.ietf.org Subject: Re: [P2PSIP] Review of DRR and RPR documents X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 12:46:09 -0000 Hi Carlos, You made a comment about registering the forward option flag and forward = option type with IANA. These parameters are defined in the p2psip base draft and flags values = are assigned over there. So if there is a need for IANA registry this = should be specified in the base draft which is the main document Roni -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf = Of Carlos Jes?s Bernardos Cano Sent: 22 January, 2013 1:51 PM To: p2psip@ietf.org Cc: draft-ietf-p2psip-drr@tools.ietf.org; = draft-ietf-p2psip-rpr@tools.ietf.org Subject: [P2PSIP] Review of DRR and RPR documents Hi, As agreed during the last meeting, I've performed a review of = draft-ietf-p2psip-drr and draft-ietf-p2psip-rpr documents, prior to = shipping them to the IESG for publication. My reviews are attached to = this e-mail (I added comments to the PDF version of each draft, hope = this is fine). I'd like authors to go through the comments before sending the documents = to the IESG. There might be some issues that need to be brought to the = WG for discussion. I'd also like to ask the WG for opinion on one particular aspect. I'm = wondering if it would be better to merge both documents into a single = one. Currently, both documents make quite a lot of cross-references, but = still there is duplicate text in both of them, so I'd be more in favor = of merging (personal opinion). Please, comment on this on the mailing = list. Thanks, Carlos From cjbc@it.uc3m.es Thu Mar 14 15:25:42 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A083D11E814D for ; Thu, 14 Mar 2013 15:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBIpJ1lx+n6A for ; Thu, 14 Mar 2013 15:25:42 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id E62B411E812B for ; Thu, 14 Mar 2013 15:25:41 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 93E0011BDD1D for ; Thu, 14 Mar 2013 23:25:40 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [130.129.85.5] (dhcp-5505.meeting.ietf.org [130.129.85.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 0CA0F11BCA3E for ; Thu, 14 Mar 2013 23:25:39 +0100 (CET) Message-ID: <1363299937.4328.51.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: P2PSIP WG Date: Thu, 14 Mar 2013 23:25:37 +0100 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19718.002 X-TM-AS-Result: No--1.560-7.0-31-1 X-imss-scan-details: No--1.560-7.0-31-1 Subject: [P2PSIP] Draft of meeting minutes uploaded X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 22:25:42 -0000 Hi, A draft of the minutes is available: http://www.ietf.org/proceedings/86/minutes/minutes-86-p2psip Many thanks Dean for providing the minutes. Please provide your feedback by the end of next week. Thanks, Brian & Carlos From internet-drafts@ietf.org Sun Mar 24 23:05:03 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E0021F8E6B; Sun, 24 Mar 2013 23:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyNbV53qccBl; Sun, 24 Mar 2013 23:04:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BEF21F867D; Sun, 24 Mar 2013 23:04:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130325060434.29105.64036.idtracker@ietfa.amsl.com> Date: Sun, 24 Mar 2013 23:04:34 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-11.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 06:05:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Protocol = Working Group of the IETF. Title : P2P Overlay Diagnostics Author(s) : Haibin Song Jiang Xingfeng Roni Even David A. Bryan Filename : draft-ietf-p2psip-diagnostics-11.txt Pages : 30 Date : 2013-03-24 Abstract: This document describes mechanisms for P2P overlay diagnostics. It defines extensions to the RELOAD P2PSIP base protocol RELOAD [I-D.ietf-p2psip-base] to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in a P2PSIP overlay networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-diagnostics-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ron.even.tlv@gmail.com Sat Mar 30 00:46:40 2013 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874B421F8B98 for ; Sat, 30 Mar 2013 00:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=-2.527, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, J_CHICKENPOX_31=0.6, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6-+POwoRCXS for ; Sat, 30 Mar 2013 00:46:39 -0700 (PDT) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED9421F8B61 for ; Sat, 30 Mar 2013 00:46:39 -0700 (PDT) Received: by mail-ea0-f181.google.com with SMTP id z10so438413ead.26 for ; Sat, 30 Mar 2013 00:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=TAMPWowPspN1oQtkvbKV72QMF0xDBVruBMgfRpCnSXo=; b=MFmJGhdOZdBPlh3XrwCUKf6hSqqsuqwrH769KmDO8YqSQy2bmIynwi9ARTmBlxZUg3 sRXvpNDSsrIPvkPh5PXbrqqZ8v4BZH+Er44/2HcCs64TYJntAqqYEBSRfxPBh/vFFG1P PhoUUVQ231ePPrGhUVgvEYa83CmyrsVdoKOc8ro1a3v4zGjevhY/jU0qaNBq/euSQg28 cBVyb1EryMuwbmK7Zy0ZqBKgY653WUDu2e3kEPz0OEKeMiAYl1EUFAwKDPbBsxSJX4Pf h+3EA/mVGdzokpQI5jvUqcXwCyV8DR9yWkigRrqHm2YWsFWDzHfUyW70yL6GMF3ZTnVV Oe5w== X-Received: by 10.14.202.71 with SMTP id c47mr15437097eeo.39.1364629598621; Sat, 30 Mar 2013 00:46:38 -0700 (PDT) Received: from RoniE ([109.65.179.201]) by mx.google.com with ESMTPS id ca4sm8238205eeb.15.2013.03.30.00.46.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 30 Mar 2013 00:46:37 -0700 (PDT) From: "Roni Even" To: , References: <1358855465.4174.24.camel@acorde.it.uc3m.es> In-Reply-To: <1358855465.4174.24.camel@acorde.it.uc3m.es> Date: Sat, 30 Mar 2013 10:46:06 +0300 Message-ID: <058001ce2d1a$a9012ff0$fb038fd0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 thread-index: AQJJctlInCoLwT4KekX9uZ6cgNVklpfGUuyw Content-Language: en-us Cc: draft-ietf-p2psip-drr@tools.ietf.org, draft-ietf-p2psip-rpr@tools.ietf.org Subject: Re: [P2PSIP] Review of DRR and RPR documents X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 07:46:40 -0000 Hi Carlos, The current text in the security section of both drafts is "As a routing alternative, the security part of RPR conforms to section = 13.6 in based draft[I-D.ietf-p2psip-base] which describes routing = security." I saw you comment "I think this sections has to be extended. It is not = clear to me how the proposed approach conforms to -base security without = providing more details. How DoS attachs would be avoided for example, by = trying to forge the destination address". I am not sure what we can add here. The security section of the base = draft starts with an overview that references RFC5765. DRR and RPR are = only adding routing options. DRR provides a direct path back to the source and as such reduce the = problem on malicious nodes on the route to affect the route back. The = digital signatures defined in the based draft protects against changes = of the forwarding header.=20 RPR as specified in the draft (section3.2) is using a trusted node = close to the initiating node, using a trusted nodes is recommended as a = security policy. We can look at RPR as DRR in the direction toward the = destination and since it is not an arbitrary node in the middle but one = that should be trusted (managed network, bootstrap peers or configured = relay) and using the based security recommendation will suffice. We can try to add more text based on the above observation for DRR "As a routing alternative, the security part of DRR conforms to section = 13 with emphasis one section 13.6 in based draft[I-D.ietf-p2psip-base] = which describes routing security. The DRR routing option provide the = information about the route back to the source. According to section 13 = of the base drat the forwarding header MUST be digitally signed = protecting the DRR routing information." For RPR =20 "As a routing alternative, the security part of RPR conforms to section = 13 with emphasis one section 13.6 in based draft[I-D.ietf-p2psip-base] = which describes routing security. RPR behave like a DRR requesting node = towards the destination node. The RPR relay node is not an arbitrary = node but should be a trusted one (managed network, bootstrap peers or = configured relay) which will make it less of a risk as outlined in = section13 of the based draft." Thanks Roni Even -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf = Of Carlos Jes?s Bernardos Cano Sent: 22 January, 2013 1:51 PM To: p2psip@ietf.org Cc: draft-ietf-p2psip-drr@tools.ietf.org; = draft-ietf-p2psip-rpr@tools.ietf.org Subject: [P2PSIP] Review of DRR and RPR documents Hi, As agreed during the last meeting, I've performed a review of = draft-ietf-p2psip-drr and draft-ietf-p2psip-rpr documents, prior to = shipping them to the IESG for publication. My reviews are attached to = this e-mail (I added comments to the PDF version of each draft, hope = this is fine). I'd like authors to go through the comments before sending the documents = to the IESG. There might be some issues that need to be brought to the = WG for discussion. I'd also like to ask the WG for opinion on one particular aspect. I'm = wondering if it would be better to merge both documents into a single = one. Currently, both documents make quite a lot of cross-references, but = still there is duplicate text in both of them, so I'd be more in favor = of merging (personal opinion). Please, comment on this on the mailing = list. Thanks, Carlos