From nobody Thu Apr 7 14:26:50 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7F312D10C; Thu, 7 Apr 2016 14:26:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160407212647.10085.36550.idtracker@ietfa.amsl.com> Date: Thu, 07 Apr 2016 14:26:47 -0700 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-sip-18.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 21:26:47 -0000 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 of the IETF. Title : A SIP Usage for RELOAD Authors : Cullen Jennings Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Thomas C. Schmidt Filename : draft-ietf-p2psip-sip-18.txt Pages : 20 Date : 2016-04-07 Abstract: This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay. It also defines Globally Routable User Agent URIs (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a peer, the RELOAD AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-p2psip-sip-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-sip-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 15 13:56:38 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABA412DE99; Fri, 15 Apr 2016 13:56:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160415205634.17444.33950.idtracker@ietfa.amsl.com> Date: Fri, 15 Apr 2016 13:56:34 -0700 Archived-At: Cc: p2psip-chairs@ietf.org, draft-ietf-p2psip-sip@ietf.org, p2psip@ietf.org Subject: [P2PSIP] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-p2psip-sip-18=3A_=28with_COMMENT=29?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 15 Apr 2016 20:56:34 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-p2psip-sip-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The privacy issues text in the security consideration section sounds not very convincing: 8.2.4. Privacy Issues All RELOAD SIP registration data is visible to all nodes in the overlay. Methods of providing location and identity privacy are still being studied. Location privacy can be gained from using anonymous GRUUs. Can you give more details or a reference regarding the methods that are still under study? From nobody Sat Apr 16 10:15:23 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8863F12D586; Fri, 8 Apr 2016 11:29:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160408182952.23007.88985.idtracker@ietfa.amsl.com> Date: Fri, 08 Apr 2016 11:29:52 -0700 Archived-At: X-Mailman-Approved-At: Sat, 16 Apr 2016 10:15:22 -0700 Cc: p2psip-chairs@ietf.org, draft-ietf-p2psip-sip@ietf.org, p2psip@ietf.org Subject: [P2PSIP] Alexey Melnikov's Discuss on draft-ietf-p2psip-sip-18: (with DISCUSS and COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 18:29:52 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-p2psip-sip-18: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I will move to No Objection once my comments are discussed. They should be easy to address. In Section 7: Access Control USER-NODE-MATCH. Note that this matches the SIP AOR against the rfc822Name in the X509v3 certificate. The rfc822Name does not include the scheme so that the "sip:" prefix needs to be removed from the SIP AOR before matching. In general the advice of stripping "sip:" is misleading, because URIs might have %-encoding, which is not present in rfc822Name, which is an email address. I think adding text that %-encoding should be decoded would be a good idea. Also, the first reference to rfc822Name (earlier in the document) needs a normative reference to RFC 5280. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In 3.2: If the registration is of type "sip_registration_uri", then the contents are an opaque string containing the AOR as specified in Section 2. Is the reference correct? Section 2 is "Terminology". What does "opaque string" means here? You still need to define syntax of the field. In 3.3: Before a Store is permitted, the storing peer MUST check that: o The AOR of the request is a valid Resource Name with respect to the namespaces defined in the overlay configuration document. o The certificate contains a username that is a SIP AOR which hashes to the Resource-ID it is being stored at. o The certificate contains a Node-ID that is the same as the dictionary key it is being stored at. Is there a document that defines how exactly a username and a Node-ID can be represented in an X.509 certificate? If yes, adding a normative reference here would be useful. If not, adding specific details here would be useful. On page 10: Inclusion of a element in an overlay configuration document is OPTIONAL. If the element is not included, the default behavior is to accept any AOR. If the element is included and the "enable" attribute is not set or set to false, the overlay MUST only accept AORs that match the domain name of the overlay. What happens if "enable" is false/unspecified and patter subelements are included? Are they ignored? The element serves as a container for zero to multiple sub-elements. A element MAY be present if the "enable" attribute of its parent element is set to true. Each element defines a pattern for constructing admissible resource names. It is of type xsd:string and interpreted as a regular expression according to "POSIX Extended Regular Expression" (see the specifications in [IEEE-Posix]). This repeats part of the second paragraph of the same section. Is this repetition needed? From nobody Sun Apr 17 10:11:45 2016 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 C7B3C12DF90; Sun, 17 Apr 2016 10:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTg80VnQo10r; Sun, 17 Apr 2016 10:11:40 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD0312E0F7; Sun, 17 Apr 2016 10:11:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,498,1454972400"; d="scan'208";a="28169594" Received: from post.haw-hamburg.de (HELO HUB02.mailcluster.haw-hamburg.de) ([141.22.24.51]) by mail3.is.haw-hamburg.de with ESMTP/TLS/AES256-SHA; 17 Apr 2016 19:11:37 +0200 Received: from CAS04.mailcluster.haw-hamburg.de (2002:8d16:183f::8d16:183f) by HUB02.mailcluster.haw-hamburg.de (2002:8d16:1833::8d16:1833) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 17 Apr 2016 19:11:37 +0200 Received: from [192.168.178.90] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.63) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 17 Apr 2016 19:11:36 +0200 To: Mirja Kuehlewind , The IESG References: <6c28177619b64d5abf49446a5c5ffdac@HUB01.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: <5713C3BF.4090804@haw-hamburg.de> Date: Sun, 17 Apr 2016 19:11:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <6c28177619b64d5abf49446a5c5ffdac@HUB01.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-sip@ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-p2psip-sip-18=3A_=28with_COMMENT=29?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 17 Apr 2016 17:11:44 -0000 Hi Mirja, o.k., the text is a bit sloppy. What it probably should say is that anonymity measures are not considered here. A proposed re-write could be: 8.2.4. Privacy Issues All RELOAD SIP registration data is visible to all nodes in the overlay. Location privacy can be gained from using anonymous GRUUs. Methods of providing anonymity or deploying pseudonyms exist, but are beyond the scope of this document. Would you agree on that? Thomas On 15.04.2016 22:56, Mirja Kuehlewind wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-p2psip-sip-18: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The privacy issues text in the security consideration section sounds not > very convincing: > > 8.2.4. Privacy Issues > > All RELOAD SIP registration data is visible to all nodes in the > overlay. Methods of providing location and identity privacy are > still being studied. Location privacy can be gained from using > anonymous GRUUs. > > Can you give more details or a reference regarding the methods that are > still under study? > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Sun Apr 17 14:08:17 2016 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 9826412DC12; Sun, 17 Apr 2016 14:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSpH353KfH19; Sun, 17 Apr 2016 14:08:10 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB1312DC0B; Sun, 17 Apr 2016 14:08:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,498,1454972400"; d="scan'208";a="38940127" Received: from post.haw-hamburg.de (HELO HUB01.mailcluster.haw-hamburg.de) ([141.22.24.50]) by mail6.is.haw-hamburg.de with ESMTP/TLS/AES256-SHA; 17 Apr 2016 23:08:07 +0200 Received: from CAS02.mailcluster.haw-hamburg.de (2002:8d16:183d::8d16:183d) by HUB01.mailcluster.haw-hamburg.de (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 17 Apr 2016 23:08:07 +0200 Received: from [192.168.178.90] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.61) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 17 Apr 2016 23:08:06 +0200 To: Alexey Melnikov , The IESG References: <2995d676192d4d1ca3a22232ec6995cd@HUB02.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: <5713FB2D.2020405@haw-hamburg.de> Date: Sun, 17 Apr 2016 23:07:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <2995d676192d4d1ca3a22232ec6995cd@HUB02.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-sip@ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] Alexey Melnikov's Discuss on draft-ietf-p2psip-sip-18: (with DISCUSS and COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 17 Apr 2016 21:08:12 -0000 Hi Alexey, many thanks for your careful review. Please see inline: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I will move to No Objection once my comments are discussed. They should > be easy to address. > > In Section 7: > > Access Control USER-NODE-MATCH. Note that this matches the SIP > AOR > against the rfc822Name in the X509v3 certificate. The rfc822Name > does not include the scheme so that the "sip:" prefix needs to be > removed from the SIP AOR before matching. > > In general the advice of stripping "sip:" is misleading, because URIs > might have %-encoding, which is not present in rfc822Name, which is an > email address. I think adding text that %-encoding should be decoded > would be a good idea. > Thanks for pointing at this: We added "Escaped characters ('%' encoding) in the SIP AOR also need to be decoded prior to matching." > Also, the first reference to rfc822Name (earlier in the document) needs a > normative reference to RFC 5280. > We added the ref. in Section 2. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In 3.2: > > If the registration is of type "sip_registration_uri", then the > contents are an opaque string containing the AOR as specified in > Section 2. > > Is the reference correct? Section 2 is "Terminology". > Nope, this is a historic editing mistake -> removed. > What does "opaque string" means here? You still need to define syntax of > the field. > "opaque string" is the appropriate (single valued) data type of RELOAD (see https://tools.ietf.org/html/rfc6940#section-7.2). Further specifications are given as "the AOR". > In 3.3: > > Before a Store is permitted, the storing peer MUST check that: > > o The AOR of the request is a valid Resource Name with respect to > the namespaces defined in the overlay configuration document. > > o The certificate contains a username that is a SIP AOR which hashes > to the Resource-ID it is being stored at. > > o The certificate contains a Node-ID that is the same as the > dictionary key it is being stored at. > > Is there a document that defines how exactly a username and a Node-ID can > be represented in an X.509 certificate? If yes, adding a normative > reference here would be useful. If not, adding specific details here > would be useful. > Username is a SIP AOR as specified in RFC 3261 (this is normatively referenced in Section 2). A Node-ID is an Overlay Hash, which is defined in RFC 6940 (also normatively referenced in Section 2). > On page 10: > > Inclusion of a element in an overlay > configuration document is OPTIONAL. If the element is not included, > the default behavior is to accept any AOR. If the element is > included and the "enable" attribute is not set or set to false, the > overlay MUST only accept AORs that match the domain name of the > overlay. > > What happens if "enable" is false/unspecified and patter subelements are > included? Are they ignored? > According to the writing, this means that " the overlay MUST only accept AORs that match the domain name of the overlay." The case you are describing is an inconsistently extended overlay configuration document. Hence, this spec tells to ignore inconsistent extensions (isolated pattern subelements), which I believe makes sense. Any counter-arguments? > The element serves as a container for zero to > multiple sub-elements. A element MAY be present > if the "enable" attribute of its parent element is set to true. Each > element defines a pattern for constructing admissible > resource names. It is of type xsd:string and interpreted as a > regular expression according to "POSIX Extended Regular Expression" > (see the specifications in [IEEE-Posix]). > > This repeats part of the second paragraph of the same section. Is this > repetition needed? > Oopsi - no. This is an editing mistake, most likely from copying a block while revising text. It is removed now. Thanks again for finding these lapses! We revise and submit. Cheers, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Sun Apr 17 14:12:28 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1B012DCEC; Sun, 17 Apr 2016 14:12:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160417211224.28660.31303.idtracker@ietfa.amsl.com> Date: Sun, 17 Apr 2016 14:12:24 -0700 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-sip-19.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 17 Apr 2016 21:12:24 -0000 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 of the IETF. Title : A SIP Usage for RELOAD Authors : Cullen Jennings Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Thomas C. Schmidt Filename : draft-ietf-p2psip-sip-19.txt Pages : 21 Date : 2016-04-17 Abstract: This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay. It also defines Globally Routable User Agent URIs (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a peer, the RELOAD AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-p2psip-sip-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-sip-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 18 00:33:49 2016 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 3E48912DE55 for ; Mon, 18 Apr 2016 00:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=FxowTKBy; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=UTZDDsrz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kKyVlo9L0uS for ; Mon, 18 Apr 2016 00:33:41 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62FDD12DE5F for ; Mon, 18 Apr 2016 00:33:41 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CC69420724 for ; Mon, 18 Apr 2016 03:33:40 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Mon, 18 Apr 2016 03:33:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=OZsaCGmpTwcBQ4hQ6gFqz7fsQSY=; b=FxowTK BybqZgZf62bwALyOT1KQ2Ac1C6aXgVfgxiJa+rMbXJdu/+3mmLiJkOtNuAIs9yX7 urvBcCNHRQoFknZKSjQrYhsO6WnO1vP4wEVSzFQgW7SbixDC/7Dqoi0b/alGax9h P5rMautNN55XTITPcnvsAlVeepabDc1sSGtsA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=OZsaCGmpTwcBQ4h Q6gFqz7fsQSY=; b=UTZDDsrzm68o/JlYcYLSt/uzcWKrLdGEeiUPbdDqKgPC/YK UEg7aPPjmRqrG2Yiw1EicxLexZbYRWJpEVtK0Uhy2T/0L3Mi3mdQIKTh7dNcGyjW m4Jj5d+eIp/QWVK5QCUIK1JY+4NlwOoeNCccpc2RBZgnGK9w+jRwAf1sjb14= X-Sasl-enc: 5Fsr6TTYKOQV46YcT0UetZym6N3voUY1nsKjKk1mT0Fs 1460964820 Received: from [10.0.151.254] (unknown [212.183.128.129]) by mail.messagingengine.com (Postfix) with ESMTPA id 518A5C00018; Mon, 18 Apr 2016 03:33:40 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13E238) In-Reply-To: <5713FB2D.2020405@haw-hamburg.de> Date: Mon, 18 Apr 2016 08:37:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6078AE17-8D6E-4F51-B6FC-BDFA4F0A512A@fastmail.fm> References: <2995d676192d4d1ca3a22232ec6995cd@HUB02.mailcluster.haw-hamburg.de> <5713FB2D.2020405@haw-hamburg.de> To: "Thomas C. Schmidt" Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-sip@ietf.org" , The IESG , "p2psip@ietf.org" Subject: Re: [P2PSIP] Alexey Melnikov's Discuss on draft-ietf-p2psip-sip-18: (with DISCUSS and COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 18 Apr 2016 07:33:43 -0000 Hi Thomas, > On 17 Apr 2016, at 22:07, Thomas C. Schmidt wro= te: >=20 > Hi Alexey, >=20 > many thanks for your careful review. Please see inline: >=20 >>=20 >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >> I will move to No Objection once my comments are discussed. They should >> be easy to address. >>=20 >> In Section 7: >>=20 >> Access Control USER-NODE-MATCH. Note that this matches the SIP >> AOR >> against the rfc822Name in the X509v3 certificate. The rfc822Name >> does not include the scheme so that the "sip:" prefix needs to be >> removed from the SIP AOR before matching. >>=20 >> In general the advice of stripping "sip:" is misleading, because URIs >> might have %-encoding, which is not present in rfc822Name, which is an >> email address. I think adding text that %-encoding should be decoded >> would be a good idea. >=20 > Thanks for pointing at this: We added >=20 > "Escaped characters ('%' encoding) in the SIP AOR also need to be decoded= prior to matching." Adding a reference to RFC 3986 would be good here. >=20 >> Also, the first reference to rfc822Name (earlier in the document) needs a= >> normative reference to RFC 5280. >=20 > We added the ref. in Section 2. >=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> In 3.2: >>=20 >> If the registration is of type "sip_registration_uri", then the >> contents are an opaque string containing the AOR as specified in >> Section 2. >>=20 >> Is the reference correct? Section 2 is "Terminology". >=20 > Nope, this is a historic editing mistake -> removed. >=20 >> What does "opaque string" means here? You still need to define syntax of >> the field. >=20 > "opaque string" is the appropriate (single valued) data type of RELOAD (se= e https://tools.ietf.org/html/rfc6940#section-7.2). Further specifications a= re given as "the AOR". Ok. Maybe put in quotes or point this out in the terminology section? >=20 >> In 3.3: >>=20 >> Before a Store is permitted, the storing peer MUST check that: >>=20 >> o The AOR of the request is a valid Resource Name with respect to >> the namespaces defined in the overlay configuration document. >>=20 >> o The certificate contains a username that is a SIP AOR which hashes >> to the Resource-ID it is being stored at. >>=20 >> o The certificate contains a Node-ID that is the same as the >> dictionary key it is being stored at. >>=20 >> Is there a document that defines how exactly a username and a Node-ID can= >> be represented in an X.509 certificate? If yes, adding a normative >> reference here would be useful. If not, adding specific details here >> would be useful. >=20 > Username is a SIP AOR as specified in RFC 3261 (this is normatively refere= nced in Section 2). A Node-ID is an Overlay Hash, which is defined in RFC 69= 40 (also normatively referenced in Section 2). Ok. >=20 >> On page 10: >>=20 >> Inclusion of a element in an overlay >> configuration document is OPTIONAL. If the element is not included, >> the default behavior is to accept any AOR. If the element is >> included and the "enable" attribute is not set or set to false, the >> overlay MUST only accept AORs that match the domain name of the >> overlay. >>=20 >> What happens if "enable" is false/unspecified and patter subelements are >> included? Are they ignored? >=20 > According to the writing, this means that >=20 > " the > overlay MUST only accept AORs that match the domain name of the > overlay." >=20 > The case you are describing is an inconsistently extended overlay configur= ation document. Hence, this spec tells to ignore inconsistent extensions (is= olated pattern subelements), which I believe makes sense. Any counter-argume= nts? No, this sounds entirely sensible. >=20 >> The element serves as a container for zero to >> multiple sub-elements. A element MAY be present >> if the "enable" attribute of its parent element is set to true. Each >> element defines a pattern for constructing admissible >> resource names. It is of type xsd:string and interpreted as a >> regular expression according to "POSIX Extended Regular Expression" >> (see the specifications in [IEEE-Posix]). >>=20 >> This repeats part of the second paragraph of the same section. Is this >> repetition needed? >=20 > Oopsi - no. This is an editing mistake, most likely from copying a block w= hile revising text. It is removed now. >=20 > Thanks again for finding these lapses! >=20 > We revise and submit. Thank you! From nobody Tue Apr 19 07:03:15 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 177C012DAA8; Tue, 19 Apr 2016 07:03:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419140314.31496.8662.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 07:03:14 -0700 Archived-At: Cc: p2psip-chairs@ietf.org, draft-ietf-p2psip-sip@ietf.org, p2psip@ietf.org Subject: [P2PSIP] Spencer Dawkins' Yes on draft-ietf-p2psip-sip-19: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 14:03:14 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-p2psip-sip-19: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This was a bit confusing to me. AOR domain not supported by overlay? If the domain part of the AOR is not supported in the current overlay, the user SHOULD query the DNS (or other discovery services at hand) to search for an alternative overlay that services the AOR under request. Alternatively, standard SIP procedures for contacting the callee SHOULD be used. If you don't query the DNS (or other discovery services), and you don't use standard SIP procedures, are there any other choices? With both of these being SHOULDs, a conformant implementation might not do either of them. Is that expected? If you need this to be RFC 2119 language, I'm guessing this would be "MUST either do X or Y", but I'm not sure it needs to be RFC 2119. If you really do need two alternative SHOULDs, it's not required to explain why a SHOULD is not a MUST, but since the goal is that an implementer is making an informed choice, helping the implementer understand why one might not want to do what one SHOULD do is usually helpful. I think that A callee MAY choose to listen on both SIP and SIPS ports and accept calls from either SIP schemes, or select a single one. is using "SIP schemes" generically, but this might be clearer if you just said "either scheme". I'm not on top of SIPS these days, but I didn't think SIPS requires end-to-end protection that may include client links and endpoint certificates. was "end-to-end protection". Is it? I thought that it was protected-hop-by-protected-hop. Or maybe you only mean SIPS in P2PSIP? Sorry if I'm confused (and the SIP Forum will be thrilled to hear this, if I'm just confused). I can figure out what "fork explosion" and "fork bomb" are, but are these terms in common usage in the SIP community? Is there a definition or reference for them? From nobody Tue Apr 19 08:29:13 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 270E112D669; Tue, 19 Apr 2016 08:29:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419152909.31573.30501.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 08:29:09 -0700 Archived-At: Cc: p2psip-chairs@ietf.org, draft-ietf-p2psip-sip@ietf.org, p2psip@ietf.org Subject: [P2PSIP] Alexey Melnikov's No Objection on draft-ietf-p2psip-sip-19: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 15:29:09 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-p2psip-sip-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Mentioning "opaque string" in the terminology section would be good. In 3.3: Before a Store is permitted, the storing peer MUST check that: o The AOR of the request is a valid Resource Name with respect to the namespaces defined in the overlay configuration document. o The certificate contains a username that is a SIP AOR which hashes to the Resource-ID it is being stored at. o The certificate contains a Node-ID that is the same as the dictionary key it is being stored at. Is there a document that defines how exactly a username and a Node-ID can be represented in an X.509 certificate? If yes, adding a normative reference here would be useful. If not, adding specific details here would be useful. In Section 7: Access Control USER-NODE-MATCH. Note that this matches the SIP AOR against the rfc822Name in the X509v3 certificate. The rfc822Name does not include the scheme so that the "sip:" prefix needs to be removed from the SIP AOR before matching. In general the advice of stripping "sip:" is misleading, because URIs might have %-encoding, which is not present in rfc822Name, which is an email address. Thank you for adding text that %-encoding should be decoded, but I also think this should point to RFC 3986. On page 10: Inclusion of a element in an overlay configuration document is OPTIONAL. If the element is not included, the default behavior is to accept any AOR. If the element is included and the "enable" attribute is not set or set to false, the overlay MUST only accept AORs that match the domain name of the overlay. What happens if "enable" is false/unspecified and patter subelements are included? Are they ignored? From nobody Tue Apr 19 10:20:33 2016 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 1696412ED44; Tue, 19 Apr 2016 10:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XD1cHzfFKrjo; Tue, 19 Apr 2016 10:20:29 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22BBB12EDE0; Tue, 19 Apr 2016 10:20:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,506,1454972400"; d="scan'208";a="28190264" Received: from post.haw-hamburg.de (HELO HUB01.mailcluster.haw-hamburg.de) ([141.22.24.50]) by mail3.is.haw-hamburg.de with ESMTP/TLS/AES256-SHA; 19 Apr 2016 19:20:25 +0200 Received: from CAS02.mailcluster.haw-hamburg.de (2002:8d16:183d::8d16:183d) by HUB01.mailcluster.haw-hamburg.de (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 19 Apr 2016 19:20:25 +0200 Received: from [141.22.57.242] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.61) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 19 Apr 2016 19:20:24 +0200 To: Alexey Melnikov References: <2995d676192d4d1ca3a22232ec6995cd@HUB02.mailcluster.haw-hamburg.de> <5713FB2D.2020405@haw-hamburg.de> <03ce1ff85a2d46fa8c19c1bc6abbae85@HUB02.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: <571668CD.2090704@haw-hamburg.de> Date: Tue, 19 Apr 2016 19:20:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <03ce1ff85a2d46fa8c19c1bc6abbae85@HUB02.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-sip@ietf.org" , The IESG , "p2psip@ietf.org" Subject: Re: [P2PSIP] Alexey Melnikov's Discuss on draft-ietf-p2psip-sip-18: (with DISCUSS and COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 17:20:32 -0000 Hi Alexey, please see the two open answers inline. On 18.04.2016 09:37, Alexey Melnikov wrote: > Hi Thomas, > >> On 17 Apr 2016, at 22:07, Thomas C. Schmidt wrote: >> >> Hi Alexey, >> >> many thanks for your careful review. Please see inline: >> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> I will move to No Objection once my comments are discussed. They should >>> be easy to address. >>> >>> In Section 7: >>> >>> Access Control USER-NODE-MATCH. Note that this matches the SIP >>> AOR >>> against the rfc822Name in the X509v3 certificate. The rfc822Name >>> does not include the scheme so that the "sip:" prefix needs to be >>> removed from the SIP AOR before matching. >>> >>> In general the advice of stripping "sip:" is misleading, because URIs >>> might have %-encoding, which is not present in rfc822Name, which is an >>> email address. I think adding text that %-encoding should be decoded >>> would be a good idea. >> >> Thanks for pointing at this: We added >> >> "Escaped characters ('%' encoding) in the SIP AOR also need to be decoded prior to matching." > > Adding a reference to RFC 3986 would be good here. O.K. - we added. >> >>> Also, the first reference to rfc822Name (earlier in the document) needs a >>> normative reference to RFC 5280. >> >> We added the ref. in Section 2. >> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> In 3.2: >>> >>> If the registration is of type "sip_registration_uri", then the >>> contents are an opaque string containing the AOR as specified in >>> Section 2. >>> >>> Is the reference correct? Section 2 is "Terminology". >> >> Nope, this is a historic editing mistake -> removed. >> >>> What does "opaque string" means here? You still need to define syntax of >>> the field. >> >> "opaque string" is the appropriate (single valued) data type of RELOAD (see https://tools.ietf.org/html/rfc6940#section-7.2). Further specifications are given as "the AOR". > > Ok. Maybe put in quotes or point this out in the terminology section? Actually, in the terminology section is an explicit mentioning of the AOR from RFC 3261 and how to use it here. From my understanding, any additional marking might rather generate confusion than clarity - in particular since an understanding of SIP terminology is rather natural in the context of this document ("SIP Usage"). Do you agree? Best, Thomas >> >>> In 3.3: >>> >>> Before a Store is permitted, the storing peer MUST check that: >>> >>> o The AOR of the request is a valid Resource Name with respect to >>> the namespaces defined in the overlay configuration document. >>> >>> o The certificate contains a username that is a SIP AOR which hashes >>> to the Resource-ID it is being stored at. >>> >>> o The certificate contains a Node-ID that is the same as the >>> dictionary key it is being stored at. >>> >>> Is there a document that defines how exactly a username and a Node-ID can >>> be represented in an X.509 certificate? If yes, adding a normative >>> reference here would be useful. If not, adding specific details here >>> would be useful. >> >> Username is a SIP AOR as specified in RFC 3261 (this is normatively referenced in Section 2). A Node-ID is an Overlay Hash, which is defined in RFC 6940 (also normatively referenced in Section 2). > > Ok. >> >>> On page 10: >>> >>> Inclusion of a element in an overlay >>> configuration document is OPTIONAL. If the element is not included, >>> the default behavior is to accept any AOR. If the element is >>> included and the "enable" attribute is not set or set to false, the >>> overlay MUST only accept AORs that match the domain name of the >>> overlay. >>> >>> What happens if "enable" is false/unspecified and patter subelements are >>> included? Are they ignored? >> >> According to the writing, this means that >> >> " the >> overlay MUST only accept AORs that match the domain name of the >> overlay." >> >> The case you are describing is an inconsistently extended overlay configuration document. Hence, this spec tells to ignore inconsistent extensions (isolated pattern subelements), which I believe makes sense. Any counter-arguments? > > No, this sounds entirely sensible. >> >>> The element serves as a container for zero to >>> multiple sub-elements. A element MAY be present >>> if the "enable" attribute of its parent element is set to true. Each >>> element defines a pattern for constructing admissible >>> resource names. It is of type xsd:string and interpreted as a >>> regular expression according to "POSIX Extended Regular Expression" >>> (see the specifications in [IEEE-Posix]). >>> >>> This repeats part of the second paragraph of the same section. Is this >>> repetition needed? >> >> Oopsi - no. This is an editing mistake, most likely from copying a block while revising text. It is removed now. >> >> Thanks again for finding these lapses! >> >> We revise and submit. > > Thank you! > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Tue Apr 19 12:32:38 2016 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 5DCFA12DD7C; Tue, 19 Apr 2016 12:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvVg3VTCuxID; Tue, 19 Apr 2016 12:32:29 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D10112E7E6; Tue, 19 Apr 2016 12:32:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,507,1454972400"; d="scan'208";a="28191399" Received: from post.haw-hamburg.de (HELO HUB02.mailcluster.haw-hamburg.de) ([141.22.24.51]) by mail3.is.haw-hamburg.de with ESMTP/TLS/AES256-SHA; 19 Apr 2016 21:32:26 +0200 Received: from CAS02.mailcluster.haw-hamburg.de (2002:8d16:183d::8d16:183d) by HUB02.mailcluster.haw-hamburg.de (2002:8d16:1833::8d16:1833) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 19 Apr 2016 21:32:25 +0200 Received: from [141.22.28.186] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.61) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 19 Apr 2016 21:32:24 +0200 To: Spencer Dawkins , The IESG References: <1f2c375f331244cda4173088497a309b@HUB02.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: <571687BE.4030102@haw-hamburg.de> Date: Tue, 19 Apr 2016 21:32:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1f2c375f331244cda4173088497a309b@HUB02.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-sip@ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] Spencer Dawkins' Yes on draft-ietf-p2psip-sip-19: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 19:32:31 -0000 Hi Spencer, many thanks for the feedback - please see inline. On 19.04.2016 16:03, Spencer Dawkins wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This was a bit confusing to me. > > AOR domain not supported by overlay? If the domain part of the AOR > is not supported in the current overlay, the user SHOULD query the > DNS (or other discovery services at hand) to search for an > alternative overlay that services the AOR under request. > Alternatively, standard SIP procedures for contacting the callee > SHOULD be used. > > If you don't query the DNS (or other discovery services), and you don't > use standard SIP procedures, are there any other choices? With both of > these being SHOULDs, a conformant implementation might not do either of > them. Is that expected? > > If you need this to be RFC 2119 language, I'm guessing this would be > "MUST either do X or Y", but I'm not sure it needs to be RFC 2119. > > If you really do need two alternative SHOULDs, it's not required to > explain why a SHOULD is not a MUST, but since the goal is that an > implementer is making an informed choice, helping the implementer > understand why one might not want to do what one SHOULD do is usually > helpful. > I see - the normative SHOULDs appear indeed a bit strong. The described case is "you query the wrong overlay, so we give some hints on what else you could do". Suggested rephrase: AOR domain not supported by overlay? If the domain part of the AOR is not supported in the current overlay, the user MAY query the DNS (or other discovery services at hand) to search for an alternative overlay that services the AOR under request. Alternatively, standard SIP procedures for contacting the callee might be used. O.K.? > I think that > > A callee MAY choose to listen on both > SIP and SIPS ports and accept calls from either SIP schemes, or > select a single one. > > is using "SIP schemes" generically, but this might be clearer if you just > said "either scheme". > O.K., done. > I'm not on top of SIPS these days, but I didn't think > > SIPS requires end-to-end protection that may include client links and > endpoint certificates. > > was "end-to-end protection". Is it? I thought that it was > protected-hop-by-protected-hop. Or maybe you only mean SIPS in P2PSIP? > oops, that's a lapse. It should be all links including client links (if present). So we propose to rephrase SIPS requires protection of all links that may include client links (if present) and endpoint certificates. > Sorry if I'm confused (and the SIP Forum will be thrilled to hear this, > if I'm just confused). > > I can figure out what "fork explosion" and "fork bomb" are, but are these > terms in common usage in the SIP community? Is there a definition or > reference for them? > I could not find a document defining exactly these terms (or equivalents), but the phenomena are broadly discussed (e.g. RFC 5393). I'm happy to rephrase, if there is a term striking better - any suggestions? Thanks again, thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Tue Apr 19 12:42:15 2016 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 0DF4D12EA86; Tue, 19 Apr 2016 12:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV7iJ4qzLNmm; Tue, 19 Apr 2016 12:42:08 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2850612EA39; Tue, 19 Apr 2016 12:42:08 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id j74so26329253ywg.1; Tue, 19 Apr 2016 12:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=s+U//AYAdD6Ls0BRo5rXEDC0Trygxf3Xdy2UN+V/UZM=; b=f34u+xAkkpKpU3bay7P/bcRORf3X9WB01FuDwlCoTs93hbugt19EDRMJDXRIWDeK91 v/TSt8ogIW/5OrhXnjG47q+P0uhtuSRdB3RzFeoslAqQyI8rg1a9jSfVBPSPoHhrtDzu c/w1aXbObVDpgV5HpEx7AFzN3jwbOzy2hDYauZpUdkyOISG8ST/4KxPxesXdUTL2sYsx reb/Or+5T+x7hGXVfPNa4mYyi49t+6qbZw2YKwOzoBBzFhMqwgA9Pgpvij3xurEOIPea C4mQSqOAmAfaGvUZ2JQQ4RBbCtcWSs3Qb05pVO5Zh4iUOLl3ifbR5/YJ21IoQ5V+oFbY rb5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=s+U//AYAdD6Ls0BRo5rXEDC0Trygxf3Xdy2UN+V/UZM=; b=DMvYH0nBP2JhvLp10kiHNxvhQRY1ywsy/rWV+IJ/3Lk47fpfHPj53z4dFLqAazREAj BNjfd49Tq+18DoFXA7t6T97p/1jynvq0lhgW6Grlpgc6FOFmmyqyhocRJlCUic4QzPt9 TKx2/eps66aZ/ysF8Rb5N+GrSRwfbPcNQo+Q3hSTRmd6JXquhGyOPf8FkK/wZWSuXFcl PFkQxvqttYNQzQ2Iz5+Ayt190tE8jSCFUJDDwjvdpXw5rq/VbpvyJlZoIa2QnCZdMoSq Zq6EKkORyUFMafdpobUw++7gflQ+PUvFhuZfCsSr5TrEft8AR5XiFVda3vGhGA7h83ja ckcg== X-Gm-Message-State: AOPr4FVShAL7W8REbaf2lpqtyiADBRsI5ZUcn+RieRZMF4Cx6fTJ80EYD9CbSQUm5ydZhuYfciAxbixWOpFkZw== MIME-Version: 1.0 X-Received: by 10.129.122.66 with SMTP id v63mr2860246ywc.219.1461094927327; Tue, 19 Apr 2016 12:42:07 -0700 (PDT) Received: by 10.37.224.212 with HTTP; Tue, 19 Apr 2016 12:42:07 -0700 (PDT) In-Reply-To: <571687BE.4030102@haw-hamburg.de> References: <1f2c375f331244cda4173088497a309b@HUB02.mailcluster.haw-hamburg.de> <571687BE.4030102@haw-hamburg.de> Date: Tue, 19 Apr 2016 14:42:07 -0500 Message-ID: From: Spencer Dawkins at IETF To: "Thomas C. Schmidt" Content-Type: multipart/alternative; boundary=94eb2c0b1a26206d2f0530dbac59 Archived-At: Cc: "p2psip-chairs@ietf.org" , "p2psip@ietf.org" , Spencer Dawkins , "draft-ietf-p2psip-sip@ietf.org" , The IESG Subject: Re: [P2PSIP] Spencer Dawkins' Yes on draft-ietf-p2psip-sip-19: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 19:42:10 -0000 --94eb2c0b1a26206d2f0530dbac59 Content-Type: text/plain; charset=UTF-8 Hi, Thomas, On Tue, Apr 19, 2016 at 2:32 PM, Thomas C. Schmidt wrote: > Hi Spencer, > > many thanks for the feedback - please see inline. > > On 19.04.2016 16:03, Spencer Dawkins wrote: > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> This was a bit confusing to me. >> >> AOR domain not supported by overlay? If the domain part of the AOR >> is not supported in the current overlay, the user SHOULD query the >> DNS (or other discovery services at hand) to search for an >> alternative overlay that services the AOR under request. >> Alternatively, standard SIP procedures for contacting the callee >> SHOULD be used. >> >> If you don't query the DNS (or other discovery services), and you don't >> use standard SIP procedures, are there any other choices? With both of >> these being SHOULDs, a conformant implementation might not do either of >> them. Is that expected? >> >> If you need this to be RFC 2119 language, I'm guessing this would be >> "MUST either do X or Y", but I'm not sure it needs to be RFC 2119. >> >> If you really do need two alternative SHOULDs, it's not required to >> explain why a SHOULD is not a MUST, but since the goal is that an >> implementer is making an informed choice, helping the implementer >> understand why one might not want to do what one SHOULD do is usually >> helpful. >> >> > I see - the normative SHOULDs appear indeed a bit strong. The described > case is "you query the wrong overlay, so we give some hints on what else > you could do". > > Suggested rephrase: > > AOR domain not supported by overlay? If the domain part of the AOR > is not supported in the current overlay, the user MAY query the > DNS (or other discovery services at hand) to search for an > alternative overlay that services the AOR under request. > Alternatively, standard SIP procedures for contacting the callee > might be used. > > O.K.? Yes, and you might even substitute "might" for the remaining MAY. > > > I think that >> >> A callee MAY choose to listen on both >> SIP and SIPS ports and accept calls from either SIP schemes, or >> select a single one. >> >> is using "SIP schemes" generically, but this might be clearer if you just >> said "either scheme". >> >> > O.K., done. > > I'm not on top of SIPS these days, but I didn't think >> >> SIPS requires end-to-end protection that may include client links and >> endpoint certificates. >> >> was "end-to-end protection". Is it? I thought that it was >> protected-hop-by-protected-hop. Or maybe you only mean SIPS in P2PSIP? >> >> > oops, that's a lapse. It should be all links including client links (if > present). So we propose to rephrase > > SIPS requires protection of all links that may include client links > (if present) and > endpoint certificates. > > Sorry if I'm confused (and the SIP Forum will be thrilled to hear this, >> if I'm just confused). >> >> I can figure out what "fork explosion" and "fork bomb" are, but are these >> terms in common usage in the SIP community? Is there a definition or >> reference for them? >> >> > I could not find a document defining exactly these terms (or equivalents), > but the phenomena are broadly discussed (e.g. RFC 5393). I'm happy to > rephrase, if there is a term striking better - any suggestions? I really like those terms. Could you add a phrase to define them? Perhaps, "an attack using SIP forking to amplify the effect on the intended victim", or some such? (I think "amplify" might be more common in other communities, but I really do like your terms. Somewhere, Dean Willis is smiling) > Thanks again, > > thomas Oh, thank you. I was hoping I remembered this much of P2PSIP! Spencer --94eb2c0b1a26206d2f0530dbac59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Thomas,

On Tue, Apr 19, 2016 at 2:32 PM, Thomas C. Schmidt <t.sc= hmidt@haw-hamburg.de> wrote:


On 19.04.2016 16:03, Spencer Dawkins wrote:


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This was a bit confusing to me.

=C2=A0 =C2=A0 AOR domain not supported by overlay?=C2=A0 If the domain part= of the AOR
=C2=A0 =C2=A0 =C2=A0 =C2=A0is not supported in the current overlay, the use= r SHOULD query the
=C2=A0 =C2=A0 =C2=A0 =C2=A0DNS (or other discovery services at hand) to sea= rch for an
=C2=A0 =C2=A0 =C2=A0 =C2=A0alternative overlay that services the AOR under = request.
=C2=A0 =C2=A0 =C2=A0 =C2=A0Alternatively, standard SIP procedures for conta= cting the callee
=C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD be used.

If you don't query the DNS (or other discovery services), and you don&#= 39;t
use standard SIP procedures, are there any other choices? With both of
these being SHOULDs, a conformant implementation might not do either of
them. Is that expected?

If you need this to be RFC 2119 language, I'm guessing this would be "MUST either do X or Y", but I'm not sure it needs to be RFC = 2119.

If you really do need two alternative SHOULDs, it's not required to
explain why a SHOULD is not a MUST, but since the goal is that an
implementer is making an informed choice, helping the implementer
understand why one might not want to do what one SHOULD do is usually
helpful.


I see - the normative SHOULDs appear indeed a bit strong. The described cas= e is "you query the wrong overlay, so we give some hints on what else = you could do".

Suggested rephrase:

=C2=A0 =C2=A0AOR domain not supported by overlay?=C2=A0 If the domain part = of the AOR
 =C2=A0 =C2=A0 =C2=A0 is not supported in the current overlay, the user MAY = query the
=C2=A0 =C2=A0 =C2=A0 DNS (or other discovery services at hand) to search fo= r an
=C2=A0 =C2=A0 =C2=A0 alternative overlay that services the AOR under reques= t.
=C2=A0 =C2=A0 =C2=A0 Alternatively, standard SIP procedures for contacting = the callee
 =C2=A0 =C2=A0 =C2=A0 might be used.

O.K.?

Yes, and you might even substitute &q= uot;might" for the remaining MAY.=C2=A0
=C2=A0


I think that

=C2=A0 =C2=A0 A callee MAY choose to listen on both
=C2=A0 =C2=A0 SIP and SIPS ports and accept calls from either SIP schemes, = or
=C2=A0 =C2=A0 select a single one.

is using "SIP schemes" generically, but this might be clearer if = you just
said "either scheme".


 O.K., done.

I'm not on top of SIPS these days, but I didn't think

=C2=A0 =C2=A0 SIPS requires end-to-end protection that may include client l= inks and
=C2=A0 =C2=A0 endpoint certificates.

was "end-to-end protection". Is it? I thought that it was
protected-hop-by-protected-hop. Or maybe you only mean SIPS in P2PSIP?


 oops, that's a lapse. It should be all links including client links (if= present). So we propose to rephrase

=C2=A0 =C2=A0 SIPS requires protection of all links that may include client= links (if present) and
=C2=A0 =C2=A0 endpoint certificates.

Sorry if I'm confused (and the SIP Forum will be thrilled to hear this,=
if I'm just confused).

I can figure out what "fork explosion" and "fork bomb" = are, but are these
terms in common usage in the SIP community? Is there a definition or
reference for them?


 I could not find a document defining exactly these terms (or equivalents), = but the phenomena are broadly discussed (e.g. RFC 5393). I'm happy to r= ephrase, if there is a term striking better - any suggestions?=

I really like those terms. Could you add a phrase to de= fine them? Perhaps, "an attack using SIP forking to amplify the effect= on the intended victim", or some such?

(I th= ink "amplify" might be more common in other communities, but I re= ally do like your terms. Somewhere, Dean Willis is smiling)
=C2= =A0
Thanks again,

=C2=A0thomas

Oh, thank you. I was hoping I = remembered this much of P2PSIP!

Spencer
--94eb2c0b1a26206d2f0530dbac59-- From nobody Tue Apr 19 12:56:02 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 684AC12E606; Tue, 19 Apr 2016 12:56:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419195601.31513.69372.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 12:56:01 -0700 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-sip-20.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 19:56:01 -0000 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 of the IETF. Title : A SIP Usage for RELOAD Authors : Cullen Jennings Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Thomas C. Schmidt Filename : draft-ietf-p2psip-sip-20.txt Pages : 21 Date : 2016-04-19 Abstract: This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay. It also defines Globally Routable User Agent URIs (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a peer, the RELOAD AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-p2psip-sip-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-sip-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 19 14:05:37 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C5612E6D3; Tue, 19 Apr 2016 14:05:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419210536.31629.14601.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 14:05:36 -0700 Archived-At: Cc: p2psip-chairs@ietf.org, draft-ietf-p2psip-sip@ietf.org, p2psip@ietf.org Subject: [P2PSIP] Stephen Farrell's No Objection on draft-ietf-p2psip-sip-20: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 21:05:37 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-p2psip-sip-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 5.1: I guess it's too late to ask, but I'll ask anyway, just in case this hasn't yet been implemented and it's not too late... I can see why you want to support SIP URIs and can't e.g. only support SIPS URIs here. But in supporting SIP URIs couldn't you have taken an opportunistic security approach to using TLS and e.g. maybe treated a SIP URI as if it's a SIPS URI except for the certificate validation step? I do get that that might restrict re-use of unmodified SIPS stacks but maybe that'd be ok in this context. Any chance of considering that or is it too late or a case where there's not enough energy/interest? (EIther form of "no" is a very reasonable answer.) - Just out of curiosity, are folks deploying this anywhere? From nobody Tue Apr 19 14:13:39 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB4112E73F; Tue, 19 Apr 2016 14:13:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419211336.31621.28063.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 14:13:36 -0700 Archived-At: Cc: p2psip-chairs@ietf.org, draft-ietf-p2psip-sip@ietf.org, p2psip@ietf.org Subject: [P2PSIP] Ben Campbell's Yes on draft-ietf-p2psip-sip-20: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 21:13:37 -0000 Ben Campbell has entered the following ballot position for draft-ietf-p2psip-sip-20: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm balloting "yes" because I want to see this move forward, but I have a number of comments and questions: Substantive: - Figure 1: It might be helpful to show the R-URI in the INVITE. - 1, 2nd to last paragraph: Please add a citation for GRUU. - 3.3, 7th paragraph from end: "any peer SHOULD verify that the AOR of the request is a valid Resource Name with respect to its domain name " How does that differ from the MUST in the first bullet, below? Also, does SIP over reload support phone numbers? If so, it would be good to include some discussion about how phone numbers fit into the domain scheme. If no, then please say so explicitly. -3.3, 3rd and 4th paragraph from end: What certificate? (Probably covered in RELOAD, but a comment here would be helpful.) - 3.4, first paragraph: The "MAY" looks like a statement of fact. I suggest "might" - 3.4, fourth paragraph: That seems to say that "enable=false" means the restrictions are enabled. Is that the intent? - 4.1, 2nd and 3rd paragraphs from end: Does that mean normal SIP procedures should be used if no overlay is found for the domain, or that normal SIP procedures can be used instead of checking for other overlays? What about the case where the domain is supported by the overlay, but the AOR is not found? Should the caller check for other overlays, or switch to standard SIP? - 5.1, 2nd paragraph: Are SIPS over reload connections assumed to be e2e encrypted? The last sentence says that ordinary SIPS requires e2e encryption, which is simply not true. What are "client links"? - 5.1, 3rd paragraph, last sentence: does "redirect its communication path" mean redirect to classic SIP? - 6, first paragraph: "Globally Routable User Agent URIs (GRUUs) [RFC5627] have been designed to allow direct routing without the indirection of a SIP proxy function. " That’s not really true. 5627 section 3.4 talks about using the proxy to dereference a gruu. - 8.1, first paragraph: "Hence no extra burden is introduced for RELOAD peers beyond loads already present in the base protocol." What about from when a caller chooses to switch to conventional SIP to reach a callee with a domain not supported by the overlay? - 8.2.4: Can you cite something for these methods that exist? Editorial: - IDNits has some comments marking code blocks. The data structure in 3.2 seems to qualify. -2 : It would have been useful to mention that you are intentionally dropping the AoR schemes back at the first AoR example. Otherwise SIP people are going to be confused until they find the comment 5 pages in. - 3.1, first paragraph: "a UA registers its AOR and location" technically, the user’s AOR and the UAs network location. - 3.2, 3rd bullet in first bullet list: It's a bit premature to use the term Callee. Perhaps Registrant? - 4.2, step 3: What is an "external AoR"? - Appendix A: Why is this not in the main body? From nobody Tue Apr 19 14:43:50 2016 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 DE10112E5F4; Tue, 19 Apr 2016 14:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBY8qEMDD0hm; Tue, 19 Apr 2016 14:43:41 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E07F12E74C; Tue, 19 Apr 2016 14:43:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,507,1454972400"; d="scan'208";a="39003775" Received: from post.haw-hamburg.de (HELO HUB02.mailcluster.haw-hamburg.de) ([141.22.24.51]) by mail6.is.haw-hamburg.de with ESMTP/TLS/AES256-SHA; 19 Apr 2016 23:43:38 +0200 Received: from CAS04.mailcluster.haw-hamburg.de (2002:8d16:183f::8d16:183f) by HUB02.mailcluster.haw-hamburg.de (2002:8d16:1833::8d16:1833) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 19 Apr 2016 23:43:38 +0200 Received: from [10.1.0.99] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.63) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 19 Apr 2016 23:43:37 +0200 To: Stephen Farrell , The IESG References: <903bea94d5c1456eb2415a9328fb6f21@HUB01.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: <5716A67E.9010208@haw-hamburg.de> Date: Tue, 19 Apr 2016 23:43:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <903bea94d5c1456eb2415a9328fb6f21@HUB01.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-sip@ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] Stephen Farrell's No Objection on draft-ietf-p2psip-sip-20: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 21:43:44 -0000 Hi Stephen, On 19.04.2016 23:05, Stephen Farrell wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - 5.1: I guess it's too late to ask, but I'll ask > anyway, just in case this hasn't yet been implemented > and it's not too late... I can see why you want to > support SIP URIs and can't e.g. only support SIPS URIs > here. But in supporting SIP URIs couldn't you have > taken an opportunistic security approach to using TLS > and e.g. maybe treated a SIP URI as if it's a SIPS URI > except for the certificate validation step? I do get > that that might restrict re-use of unmodified SIPS > stacks but maybe that'd be ok in this context. Any > chance of considering that or is it too late or a case > where there's not enough energy/interest? (EIther form > of "no" is a very reasonable answer.) > I guess, something similar to opportunistic security is actually happening on the RELOAD overlay. All links are (D)TLS encrypted. Further security additives are out of scope for the moment, I would be tempted to say. > - Just out of curiosity, are folks deploying this > anywhere? > The whole P2PSIP story is suffering from a much delayed standards process (it started in 2006). For example, we had a joint implementation with Deutsche Telekom and quite a number of others had efforts, too. All this seems quite a while ago. Currently, we are more on finishing the work that unfortunately had circulated way too long in the WG. Cheers, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Wed Apr 20 00:08:04 2016 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 55B3B12E73B for ; Wed, 20 Apr 2016 00:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=qEkwxism; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=hEOSFUqA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id If7D9v_UztKM for ; Wed, 20 Apr 2016 00:07:58 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEBE712DF30 for ; Wed, 20 Apr 2016 00:07:57 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3725F20C8B for ; Wed, 20 Apr 2016 03:07:57 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 20 Apr 2016 03:07:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=vP2om2zbcFWhzGpOUkKB001aFfU=; b=qEkwxi smZ3NpUUsZz2OQ6pIH/shUuwuCWeXxyfJklHwhAOstS3tG71rl8cpjw5FzzBD3T1 uHu2sjhwb7tAFKa6T1qczD8b30v5q26T71a/3iW9C7w41fXfHN6ZlZosnuDcwKMq jQJtReRcu1XahKI+Q+aCKnUqFqlhJO1vQi4QE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=vP2om2zbcFWhzGp OUkKB001aFfU=; b=hEOSFUqAydXYwW6QHsv5UDYRw3ck3K+FYcYkvjaZ2q97F64 DawNnVXEzzllh2Y2XdFn+jD2NPUKzlJfv1dxP3jwNrK+Df76M+Kl8MOHllujePov OrWlcqY6scEqWb6he52z1mA/dOfWPOFMDlsO2zjmY1QTxVcQE0ysyb/Gu+eU= X-Sasl-enc: YC+nQulDY4Bh2xlXcHjP5tjUzBEsxPVdo7/1v3Hl6aZw 1461136076 Received: from [10.0.151.254] (unknown [85.255.232.7]) by mail.messagingengine.com (Postfix) with ESMTPA id 94FB1C0001A; Wed, 20 Apr 2016 03:07:56 -0400 (EDT) Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13E238) In-Reply-To: <571668CD.2090704@haw-hamburg.de> Date: Wed, 20 Apr 2016 08:12:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2995d676192d4d1ca3a22232ec6995cd@HUB02.mailcluster.haw-hamburg.de> <5713FB2D.2020405@haw-hamburg.de> <03ce1ff85a2d46fa8c19c1bc6abbae85@HUB02.mailcluster.haw-hamburg.de> <571668CD.2090704@haw-hamburg.de> To: "Thomas C. Schmidt" Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-sip@ietf.org" , The IESG , "p2psip@ietf.org" Subject: Re: [P2PSIP] Alexey Melnikov's Discuss on draft-ietf-p2psip-sip-18: (with DISCUSS and COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 07:08:00 -0000 Hi Thomas, > On 19 Apr 2016, at 18:20, Thomas C. Schmidt wro= te: >=20 > Hi Alexey, >=20 > please see the two open answers inline. >=20 >> On 18.04.2016 09:37, Alexey Melnikov wrote: >> Hi Thomas, >>=20 >>> On 17 Apr 2016, at 22:07, Thomas C. Schmidt w= rote: >>>=20 >>> Hi Alexey, >>>=20 >>> many thanks for your careful review. Please see inline: >>>=20 >>>>=20 >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>>=20 >>>> I will move to No Objection once my comments are discussed. They should= >>>> be easy to address. >>>>=20 >>>> In Section 7: >>>>=20 >>>> Access Control USER-NODE-MATCH. Note that this matches the SIP >>>> AOR >>>> against the rfc822Name in the X509v3 certificate. The rfc822Name= >>>> does not include the scheme so that the "sip:" prefix needs to be= >>>> removed from the SIP AOR before matching. >>>>=20 >>>> In general the advice of stripping "sip:" is misleading, because URIs >>>> might have %-encoding, which is not present in rfc822Name, which is an >>>> email address. I think adding text that %-encoding should be decoded >>>> would be a good idea. >>>=20 >>> Thanks for pointing at this: We added >>>=20 >>> "Escaped characters ('%' encoding) in the SIP AOR also need to be decod= ed prior to matching." >>=20 >> Adding a reference to RFC 3986 would be good here. >=20 > O.K. - we added. Thank you. >>>=20 >>>> Also, the first reference to rfc822Name (earlier in the document) needs= a >>>> normative reference to RFC 5280. >>>=20 >>> We added the ref. in Section 2. >>>=20 >>>>=20 >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>>=20 >>>> In 3.2: >>>>=20 >>>> If the registration is of type "sip_registration_uri", then the >>>> contents are an opaque string containing the AOR as specified in >>>> Section 2. >>>>=20 >>>> Is the reference correct? Section 2 is "Terminology". >>>=20 >>> Nope, this is a historic editing mistake -> removed. >>>=20 >>>> What does "opaque string" means here? You still need to define syntax o= f >>>> the field. >>>=20 >>> "opaque string" is the appropriate (single valued) data type of RELOAD (= see https://tools.ietf.org/html/rfc6940#section-7.2). Further specifications= are given as "the AOR". >>=20 >> Ok. Maybe put in quotes or point this out in the terminology section? >=20 > Actually, in the terminology section is an explicit mentioning of the AOR f= rom RFC 3261 and how to use it here. =46rom my understanding, any additional= marking might rather generate confusion than clarity - in particular since a= n understanding of SIP terminology is rather natural in the context of this d= ocument ("SIP Usage"). >=20 > Do you agree? Works for me. > Best, > Thomas >=20 >>>=20 >>>> In 3.3: >>>>=20 >>>> Before a Store is permitted, the storing peer MUST check that: >>>>=20 >>>> o The AOR of the request is a valid Resource Name with respect to >>>> the namespaces defined in the overlay configuration document. >>>>=20 >>>> o The certificate contains a username that is a SIP AOR which hashe= s >>>> to the Resource-ID it is being stored at. >>>>=20 >>>> o The certificate contains a Node-ID that is the same as the >>>> dictionary key it is being stored at. >>>>=20 >>>> Is there a document that defines how exactly a username and a Node-ID c= an >>>> be represented in an X.509 certificate? If yes, adding a normative >>>> reference here would be useful. If not, adding specific details here >>>> would be useful. >>>=20 >>> Username is a SIP AOR as specified in RFC 3261 (this is normatively refe= renced in Section 2). A Node-ID is an Overlay Hash, which is defined in RFC 6= 940 (also normatively referenced in Section 2). >>=20 >> Ok. >>>=20 >>>> On page 10: >>>>=20 >>>> Inclusion of a element in an overlay >>>> configuration document is OPTIONAL. If the element is not included,= >>>> the default behavior is to accept any AOR. If the element is >>>> included and the "enable" attribute is not set or set to false, the >>>> overlay MUST only accept AORs that match the domain name of the >>>> overlay. >>>>=20 >>>> What happens if "enable" is false/unspecified and patter subelements ar= e >>>> included? Are they ignored? >>>=20 >>> According to the writing, this means that >>>=20 >>> " the >>> overlay MUST only accept AORs that match the domain name of the >>> overlay." >>>=20 >>> The case you are describing is an inconsistently extended overlay config= uration document. Hence, this spec tells to ignore inconsistent extensions (= isolated pattern subelements), which I believe makes sense. Any counter-argu= ments? >>=20 >> No, this sounds entirely sensible. >>>=20 >>>> The element serves as a container for zero to >>>> multiple sub-elements. A element MAY be present= >>>> if the "enable" attribute of its parent element is set to true. Eac= h >>>> element defines a pattern for constructing admissible >>>> resource names. It is of type xsd:string and interpreted as a >>>> regular expression according to "POSIX Extended Regular Expression" >>>> (see the specifications in [IEEE-Posix]). >>>>=20 >>>> This repeats part of the second paragraph of the same section. Is this >>>> repetition needed? >>>=20 >>> Oopsi - no. This is an editing mistake, most likely from copying a block= while revising text. It is removed now. >>>=20 >>> Thanks again for finding these lapses! >>>=20 >>> We revise and submit. >>=20 >> Thank you! >=20 > --=20 >=20 > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner Tor 7= =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, German= y =B0 > =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-845= 2 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-840= 9 =B0 From nobody Wed Apr 20 02:47:29 2016 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 3002912E856; Wed, 20 Apr 2016 02:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZczGNQoRgWHE; Wed, 20 Apr 2016 02:47:25 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8D612DD28; Wed, 20 Apr 2016 02:47:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,509,1454972400"; d="scan'208";a="28195110" Received: from post.haw-hamburg.de (HELO HUB01.mailcluster.haw-hamburg.de) ([141.22.24.50]) by mail3.is.haw-hamburg.de with ESMTP/TLS/AES256-SHA; 20 Apr 2016 11:47:23 +0200 Received: from CAS02.mailcluster.haw-hamburg.de (2002:8d16:183d::8d16:183d) by HUB01.mailcluster.haw-hamburg.de (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 20 Apr 2016 11:47:22 +0200 Received: from [141.22.28.186] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.61) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 20 Apr 2016 11:47:21 +0200 To: Ben Campbell , The IESG References: <844de935e98d4674952705d289db2341@HUB02.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: <5717501E.6060603@haw-hamburg.de> Date: Wed, 20 Apr 2016 11:47:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <844de935e98d4674952705d289db2341@HUB02.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-sip@ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] Ben Campbell's Yes on draft-ietf-p2psip-sip-20: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 09:47:28 -0000 Hi Ben, thanks for the feedback. Please see inline. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm balloting "yes" because I want to see this move forward, but I have a > number of comments and questions: > > Substantive: > > - Figure 1: It might be helpful to show the R-URI in the INVITE. > Mhmm, not sure. This would IMO break the storytelling which focuses on the interplay of RELOAD and remaining protocol operations. > - 1, 2nd to last paragraph: Please add a citation for GRUU. > O.K. - was already in the refs, now at this para, too. > - 3.3, 7th paragraph from end: "any peer SHOULD verify > that the AOR of the request is a valid Resource Name with respect to > its domain name " > How does that differ from the MUST in the first bullet, below? One peer is the requester (the SHOULD), the other peer is the storing peer (the MUST). The storing peer is the entity that persists an entry in the overlay and MUST check and ensure its consistency. > Also, does > SIP over reload support phone numbers? If so, it would be good to include > some discussion about how phone numbers fit into the domain scheme. If > no, then please say so explicitly. > This is basically the question whether AORs containing telephone numbers correspond to valid rfc822Name in X509v3 certificates, which I suppose they do. We've added to the first para of Section 1: This document defines a SIP Usage of RELOAD that allows SIP [RFC3261] user agents (UAs) to establish peer-to-peer SIP (or SIPS) sessions without the requirement for permanent proxy or registration servers, e.g., a fully distributed telephony service. This service transparently supports SIP addressing including telephone numbers. > -3.3, 3rd and 4th paragraph from end: > What certificate? (Probably covered in RELOAD, but a comment here would > be helpful.) > That's the basic RELOAD certificates from the enrollment server. It has been introduced already in the terminology Section 2. > - 3.4, first paragraph: > The "MAY" looks like a statement of fact. I suggest "might" > This very section describes how to restrict the overlay domains - in this sense, the MAY is a statement about the protocol (distr. system) mechanism and should be a MAY, I suppose. It is a precise operational option. > - 3.4, fourth paragraph: > That seems to say that "enable=false" means the restrictions are enabled. > Is that the intent? > What is intended: If a element is present, then these restrictions apply. Further rules can be enabled. Without further rules (or inconsistent parameters), domain names are restricted to those that that match the domain name of the overlay. > - 4.1, 2nd and 3rd paragraphs from end: > Does that mean normal SIP procedures should be used if no overlay is > found for the domain, or that normal SIP procedures can be used instead > of checking for other overlays? > Normative language has been taken out here following a comment of Spencer. The described case is "you query the wrong overlay, so we give some hints on what else you could do". > What about the case where the domain is supported by the overlay, but the > AOR is not found? Should the caller check for other overlays, or switch > to standard SIP? > That's the point "AOR domain is hosted in overlay?" - if the AOR is not present, the requester may search for other contacts supporting this domain name. > - 5.1, 2nd paragraph: > Are SIPS over reload connections assumed to be e2e encrypted? The last > sentence says that ordinary SIPS requires e2e encryption, which is simply > not true. Yep, this has been already corrected after a comment from Spencer: see Version 20. > What are "client links"? > Client links are RELOAD-defined links from clients (not member of the overlay) to the overlay. > - 5.1, 3rd paragraph, last sentence: > does "redirect its communication path" mean redirect to classic SIP? > That refers to the normal SIP contact header field operations. The user can announce an alternate contact point, which may be accessible via classical SIP. > - 6, first paragraph: "Globally Routable User Agent URIs (GRUUs) > [RFC5627] have been > designed to allow direct routing without the indirection of a SIP > proxy function. " > That’s not really true. 5627 section 3.4 talks about using the proxy to > dereference a gruu. > O.K., let's rephrase like this: Globally Routable User Agent URIs (GRUUs) [RFC5627] have been designed to allow direct routing to a specific UA instance without the need for dereferencing by a domain-specific SIP proxy function. That should hit the key of GRUUs. > - 8.1, first paragraph: "Hence no > extra burden is introduced for RELOAD peers beyond loads already > present in the base protocol." > What about from when a caller chooses to switch to conventional SIP to > reach a callee with a domain not supported by the overlay? > Not sure I understand: a caller using conventional SIP would not ask for assistance by RELOAD peers?? > - 8.2.4: Can you cite something for these methods that exist? > Well, one P2P anonymity service would be TOR. Here P2P pseudonym services are more interesting, but I don't see any IETF work ... various references in the scientific literature exist, but discussing this would IMO really lead away from the document. > Editorial: > > - IDNits has some comments marking code blocks. The data structure in 3.2 > seems to qualify. > > -2 : It would have been useful to mention that you are intentionally > dropping the AoR schemes back at the first AoR example. > Otherwise SIP people are going to be confused until they find the comment > 5 pages in. > This is already mentioned in the Terminology Section 2. > - 3.1, first paragraph: "a UA registers its AOR and location" > technically, the user’s AOR and the UAs network location. > O.K., fixed. > - 3.2, 3rd bullet in first bullet list: > It's a bit premature to use the term Callee. Perhaps Registrant? > O.K., fixed. > - 4.2, step 3: > What is an "external AoR"? > Those that are not associated to members of the overlay. > - Appendix A: Why is this not in the main body? > This is a forward pointer to a mechanism beyond the scope of this document (incl. the use of SHARE). Thanks again, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Wed Apr 20 02:52:10 2016 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 D528A12ED03 for ; Wed, 20 Apr 2016 02:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLPh9JPU-sxP for ; Wed, 20 Apr 2016 02:52:07 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1A5312ECDA for ; Wed, 20 Apr 2016 02:52:06 -0700 (PDT) Received: (qmail 8139 invoked from network); 20 Apr 2016 11:52:03 +0200 Received: from p5dec2d8e.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.45.142) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Apr 2016 11:52:02 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <5713C3BF.4090804@haw-hamburg.de> Date: Wed, 20 Apr 2016 11:52:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9298ABC1-FA22-4C24-9395-6CB997E163AC@kuehlewind.net> References: <6c28177619b64d5abf49446a5c5ffdac@HUB01.mailcluster.haw-hamburg.de> <5713C3BF.4090804@haw-hamburg.de> To: "Thomas C. Schmidt" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-sip@ietf.org" , The IESG , "p2psip@ietf.org" Subject: Re: [P2PSIP] =?windows-1252?q?Mirja_K=FChlewind=27s_No_Objection_on_d?= =?windows-1252?q?raft-ietf-p2psip-sip-18=3A_=28with_COMMENT=29?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 09:52:09 -0000 Hi Thomas, that=92s slightly better. However, I would rather like to see a = reference to a solution or a discuss of potential solution. If there is = no solution, this should be stated clearly (as a warning). Mirja > Am 17.04.2016 um 19:11 schrieb Thomas C. Schmidt = : >=20 > Hi Mirja, >=20 > o.k., the text is a bit sloppy. What it probably should say is that = anonymity measures are not considered here. >=20 > A proposed re-write could be: >=20 > 8.2.4. Privacy Issues >=20 > All RELOAD SIP registration data is visible to all nodes in the > overlay. Location privacy can be gained from using > anonymous GRUUs. Methods of providing anonymity or deploying > pseudonyms exist, but are beyond the scope of this document. >=20 > Would you agree on that? >=20 > Thomas >=20 > On 15.04.2016 22:56, Mirja Kuehlewind wrote: >> Mirja K=FChlewind has entered the following ballot position for >> draft-ietf-p2psip-sip-18: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> The privacy issues text in the security consideration section sounds = not >> very convincing: >>=20 >> 8.2.4. Privacy Issues >>=20 >> All RELOAD SIP registration data is visible to all nodes in the >> overlay. Methods of providing location and identity privacy are >> still being studied. Location privacy can be gained from using >> anonymous GRUUs. >>=20 >> Can you give more details or a reference regarding the methods that = are >> still under study? >>=20 >=20 > --=20 >=20 > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner = Tor 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =B0 > =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =B0 >=20 From nobody Wed Apr 20 02:53:36 2016 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 C439D12E5D7; Wed, 20 Apr 2016 02:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFlQP3TP_aze; Wed, 20 Apr 2016 02:53:32 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF6A12DBD6; Wed, 20 Apr 2016 02:53:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E5F2DBE54; Wed, 20 Apr 2016 10:53:30 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sm0J-GHkSDd9; Wed, 20 Apr 2016 10:53:30 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 42189BE2F; Wed, 20 Apr 2016 10:53:30 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1461146010; bh=7pnes4/CmLAsu8feJFoz2Y2lZ4N17BHBd+9IjC3Rv8k=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=JxKPxFWeYIsJRrL/WU2Ss8hiKEMbRNvVmUSlCov5jx7WQv4kvypCPuK+KIhDN0Tm6 vK2lIQhuuVeUXlUML73L2gfpvfLzyZfZ/BVdCrUU7gkFyvT/atGhZEe5d8pXfXSIx5 gmSgjjRwpYptGoi8eu9CgKvtIzPf8aj+0m8sB/M0= To: "Thomas C. Schmidt" , The IESG References: <903bea94d5c1456eb2415a9328fb6f21@HUB01.mailcluster.haw-hamburg.de> <5716A67E.9010208@haw-hamburg.de> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5717519A.7080600@cs.tcd.ie> Date: Wed, 20 Apr 2016 10:53:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5716A67E.9010208@haw-hamburg.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060507020508010800030706" Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-sip@ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] Stephen Farrell's No Objection on draft-ietf-p2psip-sip-20: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 09:53:35 -0000 This is a cryptographically signed message in MIME format. --------------ms060507020508010800030706 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Thomas, On 19/04/16 22:43, Thomas C. Schmidt wrote: > Hi Stephen, >=20 > On 19.04.2016 23:05, Stephen Farrell wrote: >=20 >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> >> - 5.1: I guess it's too late to ask, but I'll ask >> anyway, just in case this hasn't yet been implemented >> and it's not too late... I can see why you want to >> support SIP URIs and can't e.g. only support SIPS URIs >> here. But in supporting SIP URIs couldn't you have >> taken an opportunistic security approach to using TLS >> and e.g. maybe treated a SIP URI as if it's a SIPS URI >> except for the certificate validation step? I do get >> that that might restrict re-use of unmodified SIPS >> stacks but maybe that'd be ok in this context. Any >> chance of considering that or is it too late or a case >> where there's not enough energy/interest? (EIther form >> of "no" is a very reasonable answer.) >> >=20 > I guess, something similar to opportunistic security is actually > happening on the RELOAD overlay. All links are (D)TLS encrypted. Furthe= r > security additives are out of scope for the moment, I would be tempted > to say. >=20 >> - Just out of curiosity, are folks deploying this >> anywhere? >> >=20 > The whole P2PSIP story is suffering from a much delayed standards > process (it started in 2006). For example, we had a joint implementatio= n > with Deutsche Telekom and quite a number of others had efforts, too. Al= l > this seems quite a while ago. Currently, we are more on finishing the > work that unfortunately had circulated way too long in the WG. Understood. In that case, I'm fine with you not trying to polish it more. Cheers, S. >=20 > Cheers, > Thomas --------------ms060507020508010800030706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MjAw OTUzMzBaMC8GCSqGSIb3DQEJBDEiBCCMpc+nHJG2xFmTZVzC2yJYM4L9d9WSaaOayyXQIq/o 1zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCpAWa5xTc2PZf17ERUZ9irEjjd2ZyBV0GGm/MbfUAlCrCxb3tq/E1G 6k17rH0cNGu6esXtGvcjDIH7WSkUcFS7IZfystcMdrmfx/3xIt3m4ZtlmXRH0/9TKB11WLdt 4/CcMrpRDG7zrViSIIYnVobnRh9aeP012PlqneVgkStZuuN+sVOAqpQqbY+ALY8UNM1VpTwP 0PHiTZkAT0VpDFPq2qsxDXlP7MKjXBagMEgsE/lc3hLVW65w8qafD1DXbUe0Ynv2TPl5JHtv HaErAwZ8RTAJNn1+KMf93FIRT93vzOI/BLlfdmpChVofC2ZQZOYgU9vAPRSnjI1GeDLoPYT4 AAAAAAAA --------------ms060507020508010800030706-- From nobody Wed Apr 20 03:09:45 2016 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 8369612D7E7; Wed, 20 Apr 2016 03:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AAnnSwlzADr; Wed, 20 Apr 2016 03:09:42 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4BB512D1E5; Wed, 20 Apr 2016 03:09:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,509,1454972400"; d="scan'208";a="28196121" Received: from post.haw-hamburg.de (HELO HUB02.mailcluster.haw-hamburg.de) ([141.22.24.51]) by mail3.is.haw-hamburg.de with ESMTP/TLS/AES256-SHA; 20 Apr 2016 12:09:40 +0200 Received: from CAS02.mailcluster.haw-hamburg.de (2002:8d16:183d::8d16:183d) by HUB02.mailcluster.haw-hamburg.de (2002:8d16:1833::8d16:1833) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 20 Apr 2016 12:09:39 +0200 Received: from [141.22.28.186] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.61) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 20 Apr 2016 12:09:38 +0200 To: "Mirja Kuehlewind (IETF)" References: <6c28177619b64d5abf49446a5c5ffdac@HUB01.mailcluster.haw-hamburg.de> <5713C3BF.4090804@haw-hamburg.de> <09b5fac92ad24e2dbd95bb28970805c1@HUB02.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: <57175558.1000403@haw-hamburg.de> Date: Wed, 20 Apr 2016 12:09:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <09b5fac92ad24e2dbd95bb28970805c1@HUB02.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-sip@ietf.org" , The IESG , "p2psip@ietf.org" Subject: Re: [P2PSIP] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-p2psip-sip-18=3A_=28with_COMMENT=29?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 10:09:44 -0000 Hi Mirja, actually, I'm a bit confused about this discussion. There is plenty of work out in the wild about P2P anonymity and pseudonym services ... TOR being one prominent example. However, if I'm not mistaken, no IETF standard exists in this area so that we cannot pointer to a standard solution. A discussion of the general state of the art in this field feels well beyond the scope of the document: This security subsection shall only make people aware of this privacy aspect. It is not meant to server as a general purpose guidance on privacy in P2P networks. ;) Cheers, Thomas On 20.04.2016 11:52, Mirja Kuehlewind (IETF) wrote: > Hi Thomas, > > that’s slightly better. However, I would rather like to see a reference to a solution or a discuss of potential solution. If there is no solution, this should be stated clearly (as a warning). > > Mirja > > >> Am 17.04.2016 um 19:11 schrieb Thomas C. Schmidt : >> >> Hi Mirja, >> >> o.k., the text is a bit sloppy. What it probably should say is that anonymity measures are not considered here. >> >> A proposed re-write could be: >> >> 8.2.4. Privacy Issues >> >> All RELOAD SIP registration data is visible to all nodes in the >> overlay. Location privacy can be gained from using >> anonymous GRUUs. Methods of providing anonymity or deploying >> pseudonyms exist, but are beyond the scope of this document. >> >> Would you agree on that? >> >> Thomas >> >> On 15.04.2016 22:56, Mirja Kuehlewind wrote: >>> Mirja Kühlewind has entered the following ballot position for >>> draft-ietf-p2psip-sip-18: No Objection >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> The privacy issues text in the security consideration section sounds not >>> very convincing: >>> >>> 8.2.4. Privacy Issues >>> >>> All RELOAD SIP registration data is visible to all nodes in the >>> overlay. Methods of providing location and identity privacy are >>> still being studied. Location privacy can be gained from using >>> anonymous GRUUs. >>> >>> Can you give more details or a reference regarding the methods that are >>> still under study? >>> >> >> -- >> >> Prof. Dr. Thomas C. Schmidt >> ° Hamburg University of Applied Sciences Berliner Tor 7 ° >> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° >> ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° >> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° >> -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Wed Apr 20 14:42:20 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7A512EE19; Wed, 20 Apr 2016 14:42:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160420214219.851.28955.idtracker@ietfa.amsl.com> Date: Wed, 20 Apr 2016 14:42:19 -0700 Archived-At: Cc: p2psip-chairs@ietf.org, draft-ietf-p2psip-sip@ietf.org, p2psip@ietf.org Subject: [P2PSIP] Suresh Krishnan's No Objection on draft-ietf-p2psip-sip-20 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 21:42:19 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-p2psip-sip-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ There are no remarks associated with this position. From nobody Wed Apr 20 19:51:38 2016 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 E369D12E91A; Wed, 20 Apr 2016 19:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCrmblyesd9p; Wed, 20 Apr 2016 19:51:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0990812E3E3; Wed, 20 Apr 2016 19:51:32 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3L2pQ04044173 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 20 Apr 2016 21:51:27 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Thomas C. Schmidt" Date: Wed, 20 Apr 2016 21:51:26 -0500 Message-ID: In-Reply-To: <5717501E.6060603@haw-hamburg.de> References: <844de935e98d4674952705d289db2341@HUB02.mailcluster.haw-hamburg.de> <5717501E.6060603@haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-sip@ietf.org" , The IESG , "p2psip@ietf.org" Subject: Re: [P2PSIP] Ben Campbell's Yes on draft-ietf-p2psip-sip-20: (with COMMENT) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 02:51:35 -0000 Hi, thanks for the response. Also see inline; I will remove sections that do not seem to need further discussion. On 20 Apr 2016, at 4:47, Thomas C. Schmidt wrote: > Hi Ben, > >> Substantive: >> >> - Figure 1: It might be helpful to show the R-URI in the INVITE. >> > > Mhmm, not sure. This would IMO break the storytelling which focuses on > the interplay of RELOAD and remaining protocol operations. > That's your choice to make, but part of the reason I mentioned it was because I thought that very interplay was unclear, especially around the idea of schemeless AoRs. Should I assume the SIP INVITE is normal SIP, and prefixes the AoR with "sip:", "sips", etc in the r-uri? [...] > >> - 3.3, 7th paragraph from end: "any peer SHOULD verify >> that the AOR of the request is a valid Resource Name with respect >> to >> its domain name " >> How does that differ from the MUST in the first bullet, below? > > One peer is the requester (the SHOULD), the other peer is the storing > peer (the MUST). The storing peer is the entity that persists an entry > in the overlay and MUST check and ensure its consistency. The distinction in the text is subtle. Maybe this is a bit of RELOAD terminology that I missed, but is the "storing peer" different than the "peer that issues a Store request to the overlay"? > >> Also, does >> SIP over reload support phone numbers? If so, it would be good to >> include >> some discussion about how phone numbers fit into the domain scheme. >> If >> no, then please say so explicitly. >> > > This is basically the question whether AORs containing telephone > numbers correspond to valid rfc822Name in X509v3 certificates, which I > suppose they do. > > We've added to the first para of Section 1: > > This document defines a SIP Usage of RELOAD that allows SIP > [RFC3261] > user agents (UAs) to establish peer-to-peer SIP (or SIPS) sessions > without the requirement for permanent proxy or registration > servers, > e.g., a fully distributed telephony service. This service > transparently > supports SIP addressing including telephone numbers. > I think it may be more complicated than that. Phone numbers do not typically have domains. So more to the point, does this support TEL URIs? I think the answer is probably no, and that phone numbers are probably only supported by having AoRs where the local part of the coincidentally looks like a phone number. This brings up another question that may already be answered, but if it, I don't remember. Are URI parameters allowed? (e.g. does "sip:+1234567890@example.com;user=phone" map to "+1234567890@example.com"? This all probably doesn't matter as long as we are talking about reload AoRs, but it may matter if reload UAs need to interact with legacy SIP. >> -3.3, 3rd and 4th paragraph from end: >> What certificate? (Probably covered in RELOAD, but a comment here >> would >> be helpful.) >> > > That's the basic RELOAD certificates from the enrollment server. It > has been introduced already in the terminology Section 2. Let me rephrase the question: A certificate that represents what? The user associated with the AoR? > >> - 3.4, first paragraph: >> The "MAY" looks like a statement of fact. I suggest "might" >> > > This very section describes how to restrict the overlay domains - in > this sense, the MAY is a statement about the protocol (distr. system) > mechanism and should be a MAY, I suppose. It is a precise operational > option. A 2119 "MAY" usually represents an implementation choice. I don't think that's what we are talking about here. To illustrate the point, would it be reasonable for implementors to write software that did not allow the overlay to restrict domain names? > >> - 3.4, fourth paragraph: >> That seems to say that "enable=false" means the restrictions are >> enabled. >> Is that the intent? >> > > What is intended: > > If a element is present, then these > restrictions apply. Further rules can be enabled. Without further > rules (or inconsistent parameters), domain names are restricted to > those that that match the domain name of the overlay. I went back and re-read the section several times. I _think_ it means the following: - If an element without "enable=true" exists, then the domains are limited to the overlay's own domain. - If is present with enable=true. then the child elements define the restrictions. This seems to me to be an odd design choice, and i think implementers are going to get confused about the meaning of "enable". It also leaves open the possibility of having "enable=true" but know elements. The text does not seem to define meaning for that situation. If I had to guess, I would guess that means the same as when enable=false. So, does "enable" really mean anything beyond "check for pattern elements"? > >> - 4.1, 2nd and 3rd paragraphs from end: >> Does that mean normal SIP procedures should be used if no overlay is >> found for the domain, or that normal SIP procedures can be used >> instead >> of checking for other overlays? >> > > Normative language has been taken out here following a comment of > Spencer. > The described case is "you query the wrong overlay, so we give some > hints on what else > you could do". Do you mean that the language in version 19 is a result of Spencer's comment, or that the next version will be different due to a comment from Spencer? > >> What about the case where the domain is supported by the overlay, but >> the >> AOR is not found? Should the caller check for other overlays, or >> switch >> to standard SIP? >> > > That's the point "AOR domain is hosted in overlay?" - if the AOR is > not present, the requester may search for other contacts supporting > this domain name. I'm not sure I understand your answer. Imagine I have a user agent that can do SIP over Reload, and also normal SIP. Someone hands me a business card with "sips:thomas@example.com". I am attached to an overlay that claims to support "example.com". I look for "thomas@example.com", but don't find it. (Perhaps my overlay has been misconfigured to think it supports "example.com".) Would it make sense for me to then try to send an INVITE to sips:thomas@example.com using normal SIP processing? (That is, outside of the overlay?) Along these lines, did I miss guidance about making sure an overlay doesn't hijack other people's domains? (I see 8.2.3 talks about AoR misuse by an attacker, I think this is different. Maybe the enrollment service prevents that? > >> - 5.1, 2nd paragraph: [...[ > >> What are "client links"? >> > > Client links are RELOAD-defined links from clients (not member of the > overlay) to the overlay. > I understand what a reload "client" is. I don't find the term "client link" in 6940. I assume from your answer you mean link in the "network connection" sense and not something along the lines of a "hypertext link". [...] > >> - 6, first paragraph: "Globally Routable User Agent URIs (GRUUs) >> [RFC5627] have been >> designed to allow direct routing without the indirection of a SIP >> proxy function. " >> That’s not really true. 5627 section 3.4 talks about using the >> proxy to >> dereference a gruu. >> > > O.K., let's rephrase like this: > > Globally Routable User Agent URIs (GRUUs) [RFC5627] have been > designed to allow direct routing to a specific UA instance > without the need for dereferencing by a domain-specific SIP > proxy function. > > That should hit the key of GRUUs. That's still not correct. GRUUs have nothing to do with "direct routing". Now, it's entirely possible that being correct here isn't important. But I would suggest language more like: "... have been designed to allow SIP requests to be addressed to a specific UA instance." > >> - 8.1, first paragraph: "Hence no >> extra burden is introduced for RELOAD peers beyond loads already >> present in the base protocol." >> What about from when a caller chooses to switch to conventional SIP >> to >> reach a callee with a domain not supported by the overlay? >> > > Not sure I understand: a caller using conventional SIP would not ask > for assistance by RELOAD peers?? If a reload user agent has the ability to redirect to classical SIP, does that "import" security considerations from classical SIP? > >> Editorial: >> >> - IDNits has some comments marking code blocks. The data structure in >> 3.2 >> seems to qualify. >> >> -2 : It would have been useful to mention that you are intentionally >> dropping the AoR schemes back at the first AoR example. >> Otherwise SIP people are going to be confused until they find the >> comment >> 5 pages in. >> > > This is already mentioned in the Terminology Section 2. My comment is _about_ section 2 :-) My point is, section _1_ talks about AoRs of the form of "bob@dht.example.com". A SIP person reading this will be immediately confused, and think that this is not a valid SIP AoR. They won't learn that this is intentional until several pages later. > >> - 4.2, step 3: >> What is an "external AoR"? >> > > Those that are not associated to members of the overlay. > It would be helpful to say that, either here or in the terms section. From nobody Thu Apr 21 08:01:45 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF27C12E290; Thu, 21 Apr 2016 08:01:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160421150142.19606.4511.idtracker@ietfa.amsl.com> Date: Thu, 21 Apr 2016 08:01:42 -0700 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-concepts-09.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 15:01:43 -0000 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 of the IETF. Title : Concepts and Terminology for Peer to Peer SIP Authors : David A. Bryan Philip Matthews Eunsoo Shim Dean Willis Spencer Dawkins Filename : draft-ietf-p2psip-concepts-09.txt Pages : 19 Date : 2016-04-21 Abstract: This document defines concepts and terminology for the use of the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message routing functions are replaced by a distributed mechanism. These mechanisms may be implemented using a distributed hash table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group and the RELOAD protocol and SIP usage document defined by the working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-concepts/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-p2psip-concepts-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-concepts-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 21 12:58:52 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0749312DD04; Thu, 21 Apr 2016 12:58:51 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160421195851.19517.23857.idtracker@ietfa.amsl.com> Date: Thu, 21 Apr 2016 12:58:51 -0700 Archived-At: Cc: p2psip-chairs@ietf.org, p2psip@ietf.org, draft-ietf-p2psip-concepts@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [P2PSIP] Document Action: 'Concepts and Terminology for Peer to Peer SIP' to Informational RFC (draft-ietf-p2psip-concepts-09.txt) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 19:58:51 -0000 The IESG has approved the following document: - 'Concepts and Terminology for Peer to Peer SIP' (draft-ietf-p2psip-concepts-09.txt) as Informational RFC This document is the product of the Peer-to-Peer Session Initiation Protocol Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-concepts/ Technical Summary: This document defines concepts and terminology for the use of the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message routing functions are replaced by a distributed mechanism. These mechanisms may be implemented using a distributed hash table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group and the RELOAD protocol [RFC6940] and SIP usage. Working Group Summary: This document has had a relatively long gestation period in the working group, and it fact languished for several years. After development of the protocol and other documents, it was felt that completing the concepts document would be helpful for readers of the protocol and other documents to understand the basic concepts behind the protocol. As result, this document was updated to reflect the evolution of the various documents and it now reflects the documented state of the protocol. There were no notable disagreements within the working group over the development of the document. Document Quality: The document was written by one of the original contributors to the entire p2psip effort, and has benefitted from review of the more active workgroup’s participants. I believe it accurately reflects the concepts behind the RELOAD protocol. Personnel: Brian Rosen is the Document Shepherd. Alissa Cooper is the Responsible Area Director. From nobody Fri Apr 22 04:59:26 2016 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 8928212D9F0 for ; Fri, 22 Apr 2016 04:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiY9-fPGONxG for ; Fri, 22 Apr 2016 04:59:23 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC00412D9DB for ; Fri, 22 Apr 2016 04:59:22 -0700 (PDT) Received: (qmail 13645 invoked from network); 22 Apr 2016 13:51:59 +0200 Received: from p5dec2f05.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.47.5) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 22 Apr 2016 13:51:59 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <57175558.1000403@haw-hamburg.de> Date: Fri, 22 Apr 2016 13:52:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3FB78D9E-1C71-4868-8DFD-FB9B8B7FD53B@kuehlewind.net> References: <6c28177619b64d5abf49446a5c5ffdac@HUB01.mailcluster.haw-hamburg.de> <5713C3BF.4090804@haw-hamburg.de> <09b5fac92ad24e2dbd95bb28970805c1@HUB02.mailcluster.haw-hamburg.de> <57175558.1000403@haw-hamburg.de> To: "Thomas C. Schmidt" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "p2psip-chairs@ietf.org" , "draft-ietf-p2psip-sip@ietf.org" , The IESG , "p2psip@ietf.org" Subject: Re: [P2PSIP] =?windows-1252?q?Mirja_K=FChlewind=27s_No_Objection_on_d?= =?windows-1252?q?raft-ietf-p2psip-sip-18=3A_=28with_COMMENT=29?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 22 Apr 2016 11:59:24 -0000 Hi Thomas, yes, you are right, no need to discuss general mechanism that apply to = this doc as well as other similar mechanisms. Sorry also for actually be = unclear about my concerns. My actual point is that I of course need to = transfer private data (email address) but I did not see anything about = encryption of this communication in the doc. (This is not about = anonymity but I=92ve expended to find something about encryption in the = privacy section.) After a second look now, I still didn=92t find = anything... did I miss it? Also, this is nit-picking, but in general saying "Methods of providing = anonymity or deploying pseudonyms exist, but are beyond the scope of = this document.=93 seems not super helpful because it does not give any = hint where someone, who=92d like to apply these kind of methods, would = find any further information. But I agree talking about the methods = itself is out of scope. Mirja > Am 20.04.2016 um 12:09 schrieb Thomas C. Schmidt = : >=20 > Hi Mirja, >=20 > actually, I'm a bit confused about this discussion. There is plenty of = work out in the wild about P2P anonymity and pseudonym services ... TOR = being one prominent example. However, if I'm not mistaken, no IETF = standard exists in this area so that we cannot pointer to a standard = solution. >=20 > A discussion of the general state of the art in this field feels well = beyond the scope of the document: This security subsection shall only = make people aware of this privacy aspect. It is not meant to server as a = general purpose guidance on privacy in P2P networks. ;) >=20 > Cheers, > Thomas >=20 > On 20.04.2016 11:52, Mirja Kuehlewind (IETF) wrote: >> Hi Thomas, >>=20 >> that=92s slightly better. However, I would rather like to see a = reference to a solution or a discuss of potential solution. If there is = no solution, this should be stated clearly (as a warning). >>=20 >> Mirja >>=20 >>=20 >>> Am 17.04.2016 um 19:11 schrieb Thomas C. Schmidt = : >>>=20 >>> Hi Mirja, >>>=20 >>> o.k., the text is a bit sloppy. What it probably should say is that = anonymity measures are not considered here. >>>=20 >>> A proposed re-write could be: >>>=20 >>> 8.2.4. Privacy Issues >>>=20 >>> All RELOAD SIP registration data is visible to all nodes in the >>> overlay. Location privacy can be gained from using >>> anonymous GRUUs. Methods of providing anonymity or deploying >>> pseudonyms exist, but are beyond the scope of this document. >>>=20 >>> Would you agree on that? >>>=20 >>> Thomas >>>=20 >>> On 15.04.2016 22:56, Mirja Kuehlewind wrote: >>>> Mirja K=FChlewind has entered the following ballot position for >>>> draft-ietf-p2psip-sip-18: No Objection >>>>=20 >>>> When responding, please keep the subject line intact and reply to = all >>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>> introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> The privacy issues text in the security consideration section = sounds not >>>> very convincing: >>>>=20 >>>> 8.2.4. Privacy Issues >>>>=20 >>>> All RELOAD SIP registration data is visible to all nodes in the >>>> overlay. Methods of providing location and identity privacy are >>>> still being studied. Location privacy can be gained from using >>>> anonymous GRUUs. >>>>=20 >>>> Can you give more details or a reference regarding the methods that = are >>>> still under study? >>>>=20 >>>=20 >>> -- >>>=20 >>> Prof. Dr. Thomas C. Schmidt >>> =B0 Hamburg University of Applied Sciences = Berliner Tor 7 =B0 >>> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =B0 >>> =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =B0 >>> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =B0 >>>=20 >=20 > --=20 >=20 > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner = Tor 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =B0 > =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =B0 From nobody Wed Apr 27 05:48:19 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBD712D098; Wed, 27 Apr 2016 05:48:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160427124815.25169.95615.idtracker@ietfa.amsl.com> Date: Wed, 27 Apr 2016 05:48:15 -0700 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-sip-21.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 27 Apr 2016 12:48:16 -0000 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 of the IETF. Title : A SIP Usage for RELOAD Authors : Cullen Jennings Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Thomas C. Schmidt Filename : draft-ietf-p2psip-sip-21.txt Pages : 21 Date : 2016-04-27 Abstract: This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay. It also defines Globally Routable User Agent URIs (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a peer, the RELOAD AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-p2psip-sip-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-sip-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 29 16:36:08 2016 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F4D12D501; Fri, 29 Apr 2016 16:36:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160429233607.4855.85201.idtracker@ietfa.amsl.com> Date: Fri, 29 Apr 2016 16:36:07 -0700 Archived-At: Cc: p2psip-chairs@ietf.org, p2psip@ietf.org, draft-ietf-p2psip-sip@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [P2PSIP] Protocol Action: 'A SIP Usage for RELOAD' to Proposed Standard (draft-ietf-p2psip-sip-21.txt) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.17 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, 29 Apr 2016 23:36:07 -0000 The IESG has approved the following document: - 'A SIP Usage for RELOAD' (draft-ietf-p2psip-sip-21.txt) as Proposed Standard This document is the product of the Peer-to-Peer Session Initiation Protocol Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ Technical Summary: This document defines a SIP Usage for RELOAD (RFC6940). This SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay. The document also defines Globally Routable User Agent URIs (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a peer, a direct connection between nodes (to exchange SIP messages) can be established using the AppAttach method. Working Group Summary: The normal WG process was followed and the document has been discussed for several years. The document as it is now, reflects WG consensus, with nothing special worth noting. Document Quality: The document was thoroughly reviewed by Marc Petit-Huguenin. Personnel: Carlos J. Bernardos is the Document Shepherd. Alissa Cooper is the Responsible Area Director