From petithug@acm.org Thu Jan 12 07:14:10 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81B221F8546 for ; Thu, 12 Jan 2012 07:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.912 X-Spam-Level: X-Spam-Status: No, score=-100.912 tagged_above=-999 required=5 tests=[AWL=-1.312, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_SUMOF=5, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DOCv4ky+lsy for ; Thu, 12 Jan 2012 07:14:10 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id E134C21F8545 for ; Thu, 12 Jan 2012 07:14:09 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id E2FA7202D2; Thu, 12 Jan 2012 15:00:40 +0000 (UTC) Message-ID: <4F0EF8BB.6080009@acm.org> Date: Thu, 12 Jan 2012 07:14:03 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: Dean Willis , "Hakim Mehmood (naim)" , Michael Procter , John Ward , 'Mary Barnes' , "Muthu Arul Mozhi Perumal (mperumal)" , Daryl Malas , Jon Peterson Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" Subject: [VIPR] Agenda & Handout for 2012/01/13 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 15:14:11 -0000 A. Agenda - Action item list from Taipei - PVP Entropy - VIPR troubleshooting - Infrastructure overlays - ICE support in VIPR Note that the sum of the time allocated to each topic may exceeds the time allocated to the whole call. The topics that cannot make it to the discussion will be postponed to the next conference call if they are not subsequently decided in the mailing-list. Because the conference bridge as a limited capacity, an individual invitation to the conference will be sent shortly after this email to each member of the design team. Please send me an email if you are not on this list and want to receive an invitation. Note that the design team conference call is not a way to short-circuit the normal process, but a way to accelerate it by increasing face to face time. All decisions made must be confirmed on the mailing-list. This conference call is subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). B. Handout (reading time: 10 min) B.1. Action items list from Taipei This is the list of decisions and TODO extracted from the minutes and the audio recording (The minutes from the meeting in Taipei are available at: http://www.ietf.org/proceedings/82/minutes/vipr.txt) - Eric Burger to send a review of -overview before it can be adopted as WG document. - PVP method priority accepted, but need to decide if in registry or document. - SIP intermediaries: Comments on the list. - Fix the equation in proportional-quota. - Add support to blacklist methods in the configuration (and registry). - OK to store methods in RELOAD. - Remove 3 copies, and use voting algorithm. - Fixes multiplier in reload-usage as soon proportional-quota is done. - Method A: Add text about using EC2 to evaluate the complexity for given cost/phone number. - Create new document for method C: inverted selector/secret, with dynamic allocation of entropy. - General idea of entropy adopted, with minimum default value in configuration. Still need to decide if client support. - Ticket needs to be modified to support crypto agility, with recommended algo. - X.509: Rejected. - Asymmetrical keys: Richard Barnes to do a security review. - Renewal of ticket: Solution proposed adopted. - Infrastructure overlay: will be presented in DISPATCH in Paris. - Troubleshooting: Needs also a test mode for immediate PVP processing. B.2. PVP Entropy The decision in Taipei was to support the entropy mechanism, and to carry the minimal default value in the configuration file. We still have to decide between these two solutions: 1. Entropy is best managed completely in the PVP server. 2. It is best managed in both client and server by using something like a cookie, stored in the ticket. B.3. VIPR troubleshooting One very important point made in draft-jennings-vipr-overview is the troubleshooting problem (section 2.4). Because the provisioning of SIP routes is automatic, there is no possibility to have a interop testing between two domains before the establishment of the fist call. This means that we need to provide help for debugging problems if things go wrong. The main issue is that it is not always possible to troubleshoot a problem only by looking on the logs and traces on the sending side - some kind of cooperation is required by the receiving side. Having a way to retrieve the logs and traces automatically would be a good step in this direction, but we now have a security problem to take care of, as we certainly do not want anybody to be able to retrieve this information. There is also a need to have a mode that permit a immediate execution of the PVP process, for troubleshooting purpose. B.4. Infrastructure overlays A new draft to discuss infrastructure overlays has been submitted to DISPATCH. "[RELOAD] is a peer to peer protocol developed by the P2PSIP Working Group. Each RELOAD instance has a unique name, which is used by the process in section 10.2 of this specification to find the configuration servers, enrollment servers and bootstrap servers needed to join the overlay. The process assumes that the RELOAD instance name is a FQDN, and uses the process in [RFC2782] (SRV RR) to find the IP address of the HTTPS server that serves the configuration document for this overlay. This process is adequate when the management of the overlay does not need to be distinguished from the owner of the FQDN used as the instance name, which is the case most of the time. But there is a special class of overlays that, by definition, requires to be unique on the Internet and for which having the possibility of create instances would defeat their very purpose. This specification calls the kind of overlays that are not domain specific, but application specific "infrastructure overlays". [VIPR] is a technology that is being standardized in the VIPR Working Group and that aims to build bridges between SIP islands by automatically provision SIP routes after the "ownership" of a PSTN phone number has been verified by an actual PSTN phone call. This technology uses an RELOAD overlay as a distributed database where mappings between phone numbers and servers responsible for the validation process are stored. The promise of VIPR to bridge these SIP islands cannot be fulfilled if there is more than one distributed database storing these mappings." B.5. ICE support in VIPR Section 1.2.1 of draft-procter-vipr-privacy-concerns proposes to use TURN to anonymise the source of a PVP validation. This proposal is probably incomplete, but the main problem is that we still do not know what transports will be used on the RELOAD overlay used by VIPR. First here's a list of what we currently know about this overlay: - The algorithm is RELOAD-CHORD - The Node-ID size is 16 bytes (128 bits). - Clients are not authorized because of the quota algorithm. - Self-signed certificates are not authorized. - There will be one or more root-certs. - There will be one or more bootstrap peers (unicast or anycast - no multicast). - Clients are not authorized because of the quota algorithm. - Shared secret are not used. - The overlay link protocol is TLS. - There will be a list of kind and configuration signers. - The urn:ietf:params:xml:ns:p2p:config-chord, urn:ietf:params:xml:ns:p2p:quota and urn:ietf:params:xml:ns:p2p:vipr extensions are mandatory. - The Kind VIPR-REGISTRATION will be authorized. What we do not know yet: - Do we need to authorize the CERTIFICATE-BY-NODE and CERTIFICATE-BY-USER Kinds? - Will TURN server deployed in the overlay? - Will ICE overlay link protocols be used? The important question for this topic is the support of ICE in the RELOAD overlay: Pros: With ICE support the RELOAD nodes, the PVP client and the PVP server can be installed behind a NAT/Firewall without having to put them on the DMZ or to open pinholes (the bootstrap servers will still need to be installed in the DMZ or on the Internet). TURN servers are required for ICE support, so they would also be available for anonymising the connections. Cons: ICE is complex to implement and debug. If we decide to exclude ICE, then the TURN servers are no longer available by default, and the idea of using them for anonymising the connections is moot. An additional consideration is that the RELOAD transports are currently limited to UDP and TCP, neither of them being really well suited to carry RELOAD or PVP messages. If we decide to exclude ICE support, I will then propose to use (D)TLS over SCTP instead (and write the I-D for this). So the initial question is: Do we need ICE or not? From petithug@acm.org Mon Jan 16 07:26:17 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFDF21F8525 for ; Mon, 16 Jan 2012 07:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.318 X-Spam-Level: X-Spam-Status: No, score=-102.318 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y4LypNvkAQQ for ; Mon, 16 Jan 2012 07:26:16 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id DE5DE21F850C for ; Mon, 16 Jan 2012 07:26:15 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 369FA20142 for ; Mon, 16 Jan 2012 15:12:33 +0000 (UTC) Message-ID: <4F144192.1070400@acm.org> Date: Mon, 16 Jan 2012 07:26:10 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Minutes for 2012/01/13 conference call X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 15:26:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 VIPR Design Team conference call on Friday January 13th, from 9:05am to 9:55am PST. o Attendees: Mary Barnes Daryl Malas Hakim Mehmood Marc Petit-Huguenin Jon Peterson Michael Procter John Ward Dean Willis o Regrets Muthu Arul Mozhi Perumal o Agenda - - Action item list from Taipei - - PVP Entropy - - VIPR troubleshooting - - Infrastructure overlays - - ICE support in VIPR o Action items - - Mary to talk to Eric Burger about his review of -overview. - - Methods priorities will be in documents, not in registry. - - SIP intermediaries discussions postponed. - - Add the probability equation in -proportional-quota. - - Blacklist methods in configuration file. - - Add text to say that client must check the replicas at write time. - - Fix the multiplier in reload-usage when proportional-quota is finished. - - Add text for entropy processing on server side. - - Modify ticket to support crypto agility. - - Chairs/Mary to talk to Richard Barnes about security review. - - Add text or new I-D about ticket renewal using the -cs draft. - - Request time in DISPATCH agenda for the infrastructure-overlay draft. - - Work on troubleshooting document with input from Cisco developer. o Minutes - - Action item list from Taipei Marc: It was requested in Taipei for more reviews for the -overview draft before adopting it as a WG item. Eric Burger volunteered. Mary: I'll talk to him. Marc: Do we want more reviews? Mary: That would be great. Do we want an early security review to have their feedback? Marc: Richard Barnes volunteered to do a security review. Mary: I'll talk to him too. Marc: Any other volunteer? [no volunteer on the design team] Marc: Next item; the idea of having a method priority was well receiving. One comment from Jon was if we want the priority on the registry or on the document. Jon: The registry can change but not the documents. Marc: OK, let keep the priority in the document. Marc: I propose that we continue to postpone the discussion about SIP intermediaries. [no comment] Marc: We still need to add the probability equation in -proportional-quota. [no comment] Marc: Someone in Taipei suggested to add the possibility of blacklisting PVP methods, perhaps also in the registry. Jon: Is it implementation specific? Marc: We need first the method registry, to give a name to methods, then we can put the name in a section of the XML configuration file, so neither a PVP client or server use it. This way at least the two sides have to agree to do bad things. Marc: There was support to have the PVP methods inside the RELOAD overlay. [no comment] Marc: We had the final decision on the multiple copies in Taipei, but there was no consensus on what to do about the voting algorithm, which is to use a RELOAD entry only if we retrieve at least two identical copies. Hakim: The idea was to have some sort of redundancy. Marc: Cullen explained in Taipei that it was done because there was very little experience about this, but he did not see any problem, so it's not necessary to keep that. There was also a discussion about making it configurable, and that was not accepted. The only remaining question is about the voting algorithm. A rogue node can fake only the entries it has, so the probability of having two replicas controlled by the same rogue node is low. On the other hand we do not want one rogue node to prevent access to an entry. Michael: If the rogue node is the primary for that key, it could just not propagate the replicas. Marc: Right, so we need to add some text saying that when a node write an entry, it should read back the 3 copies and log an error if the 3 are not identical. Marc: I need to fix the multiplier in reload-usage as soon proportional-quota is done [no comment] Marc: Method A was changed to use bcrypt hash for the caller-id, so it is no longer in clear. We need to add some security text explaining the shortcomings. We still need to decide what is the minimum cost we want for cracking one caller-id. [no comment] Marc: People were interested in the idea of a new method that inverts the selector and the secret and there was an agreement that a new document should be prepared for this. There was also some interesting comments about dynamically allocating parts of the caller-id into the selector. [no comment] Marc: There was consensus in Taipei that entropy should be used, but there was concerns about the minimum entropy so we agreed that the minimum default value must be in the configuration file. What was not decided was between the server side and client side processing. Jon: We should discuss this. Marc: OK, let's finish the discussion about Taipei, then we will go back to this topic. Marc: We agreed in Taipei that the ticket need to be modified to support crypto agility, but must have a recommended algorithm. The X.509 proposal was rejected in Taipei, so the proposal is withdrawn. Another discussion was about asymmetrical keys vs symmetrical keys, but there was no conclusion. Richard Barnes proposed to do a security review. Jon: The chairs will talk to him. Mary: I will too. Marc: I will modify the specification about the crypto agility. Marc: Last topic was renewal of ticket. The solution proposed was to use the - -cs draft from MMUSIC. I will either write a new spec or modify one. [no comment] Marc: Next topic was infrastructure overlay. We had one slide in DISPATCH, but no comments. There was also no comment in the VIPR mailing-list. The document currently only have the requirements but I have a proposal on how to do this. What should we do? Mary: The focus of the DISPATCH discussion will be on the problem and requirements, but sometimes having a solution proposal helps people understand the problem. Marc: I will put my solution inside an appendix of the draft, and I will send an official request to DISPATCH for time in Paris. Any volunteer to help? [no comment] Marc: About troubleshooting, there was one additional request from Cullen to have a way to trigger the PVP process immediately after the call, which is useful not only for troubleshooting but also for demo. We probably need to put this in a separate document, informational or bcp. Is there a volunteer for this? Hakim: We did implement a set of functions to troubleshoot, and I can schedule a call with the developer who implemented this. Marc: That would be very helpful. Marc: Back to the PVP entropy discussion about server side vs client side. Mary: What is the big advantage you see on having it distributed? Marc: The server does not have to manage an additional storage. Also it solved the problem of knowing when to remove old logs. Michael: Does the client present the ticket it received the last time? Marc: Yes. We have to change the protocol in both cases, because the PVP transaction may succeed, but the subsequent ValExchange transaction will not return any ticket and SIP route. Jon: Calling it a ticket is confusing. It more a provisional material. My problem with this is that it does not make much difference, but it's probably not a small change. Marc: To advance the discussion, I propose to add the text for the server-side processing, and we can define the client-side processing as an extension. Michael: I am interested in the proposal as the client can convince itself that it is worth trying a new call with the same server. Marc: Yes, it is part of the common specification. Hakim: OK - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPFEGDAAoJECnERZXWan7ENiEP/1pbfo2FmeNOcj2/dD6C3LnG xDiYm7K+6CbvPyO/O0ALWp3EsJdKFdINlFtvO5GUEX4upWDUelFrOrrm3cwkUjxA nhPQqPPj/0hLqyTZCNdhCjt8QUcMYB+WGGgyglSEBExLjiJQ9tcGzUFUI5BpA6lf yV/6VUUNQO+VI8FGSrgZXO+RDEkoAav8ysicjKF3WcjqEJT250EXMJ8wvcv3Afd5 ghaFcEhTdzko3Zk3KnKqmu9eiRkxnkmqSn0ZngHw9odLZcCh0wDuFnZpWZR76ePS OzfoUibbd2XHMIHAzAyjKZoxtw3y6yRArbk8ogAjBjrz7GS97MRKzkWV9bNf5bzq mw2dQZGT/kKOqSsCak+wKLCZUpXwkTFS3utZopAuFz8LgKTGKcNGQk92h3YA7VOq ddyNo5VZrdZzTL1IfyIg2clfBt1AsN8+LnD3f6xIvDZdM3onSp8IbKgwGzFGQnUT ReXWrRbGFpeDToeCNAac5W+SL6bBqYsQ94SG9DKuODu6yOVQ7HNYSwGKr8KFjpir GzDuEnJ35lU1ezWrLvy69N45qenWAQGm8+QAGttQMsghMulqdgEhTRvMP4EWVe+J U8RJUY+rVy92ZC+xqfY0x46moc6TjgyWHnN6lm3DFw9pgggtWVTywfwwVJ9o/TZo hH+LWbxUXPTkJvvwv9+o =36+s -----END PGP SIGNATURE----- From petithug@acm.org Mon Jan 16 10:25:43 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534B021F86C2; Mon, 16 Jan 2012 10:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeUmXGQZyEYA; Mon, 16 Jan 2012 10:25:42 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id A78A621F86A2; Mon, 16 Jan 2012 10:25:42 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 71B1420142; Mon, 16 Jan 2012 18:11:59 +0000 (UTC) Message-ID: <4F146BA2.2080106@acm.org> Date: Mon, 16 Jan 2012 10:25:38 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: DISPATCH list References: <20120116175444.21776.21853.idtracker@ietfa.amsl.com> In-Reply-To: <20120116175444.21776.21853.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.4 X-Forwarded-Message-Id: <20120116175444.21776.21853.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" , P2PSIP Mailing List Subject: [VIPR] Fwd: I-D Action: draft-petithuguenin-dispatch-unique-overlay-01.txt X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 18:25:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I would like to request a timeslot in the DISPATCH session in Paris to talk about infrastructure overlays, which is a special class of RELOAD overlays that by their own definition require that only one instance of this overlay exists on the Internet (excluding instances deployed for test and experimentation). This kind of overlay could be useful for stuff like bitcoin or boinc, but the main motivation is to support VIPR, which works only if there is a unique overlay instance. The discussion will be around the problems that infrastructure overlays solve and the list of requirements for the mechanism used to implement it but, although this is not part of the discussion, the new version of the draft contains an appendix explaining one possible solution. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-dispatch-unique-overlay-01.txt Date: Mon, 16 Jan 2012 09:54:44 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Infrastructure Overlay Author(s) : Marc Petit-Huguenin Filename : draft-petithuguenin-dispatch-unique-overlay-01.txt Pages : 6 Date : 2012-01-16 This document provides requirements for infrastructure overlays, a special kind of peer-to-peer overlay whose main purpose would be defeated if more than one instance would exist on the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-dispatch-unique-overlay-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-dispatch-unique-overlay-01.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPFGudAAoJECnERZXWan7EDnoQAIdc/tgnhObDZP7iEm8XYN9t 9Eop2B6WQCS9KRjMDagjojY7smAdRkof23Tru+4q+jj7W2f+BbL3/EWex2y8/uRS jZC0Z5pgw6hJrwR+UQni8XfuAWuoBJ6Rl9UHlBKRwyiyZn/mJD8Z1aUWO8FIXdLI zM+x2E2FEeuW9HbvDQ19+5JrBce7VplOvyZz2OOZzvkgBQFDYVJIvvpzE26OuGQa I9sz2EedPn+xnpRC5XtKxQDkkRRreB6xDyaM6heqzqldcBbvIyNFDfmHDOkTVQIi qP5eCwB2vHCN+nlKfhm/F2Bx+coFvYJ628rB4rMcoBCa+VuXspyPMhUaXWQhCioc +N17jsF02q31HO/SBE8vMQRPTZcv/t24d5VZhoxTdBAZt420W2eWNXeDpoWobN9c nN7fkFkTfuK4xP6374GieEmfgOquLXMM556DTJN/5c5l7E7So+udSw0ctIjehBrZ VMLI8GRrISv/mIjOV4cW2Wevn+g5Dw0P3Ptg6N2Dd84CkbRqBkqmfLrvpdhkdhWd wN3kCi6vLF3XfGJrnyyVY15KO+Cg3j9uAmVRZj+Nxdm6hngtklQJwHTiKtDGKgCp 7qoVFmJGVCYNpyBbvKETRhSTsAPz8p/ygU2ququExiaa8DW4/jGxB+xMfqpMMvez MhcXnZzLQmSjdv45ZZaQ =aaO4 -----END PGP SIGNATURE----- From petithug@acm.org Thu Jan 19 07:37:35 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDCB21F85FF for ; Thu, 19 Jan 2012 07:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.353 X-Spam-Level: X-Spam-Status: No, score=-102.353 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95r+l6kYxn70 for ; Thu, 19 Jan 2012 07:37:35 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFCC21F85F1 for ; Thu, 19 Jan 2012 07:37:35 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id DB26E202D2 for ; Thu, 19 Jan 2012 15:23:40 +0000 (UTC) Message-ID: <4F1838B9.4050400@acm.org> Date: Thu, 19 Jan 2012 07:37:29 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] VIPR Privacy X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 15:37:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Restarting the discussion on the subject of VIPR privacy, based on Michael Procter document draft-procter-vipr-privacy-concerns. 1.1. Caller-ID leaks The VIPR drafts have been modified to hash the Caller-ID when method A is used. A new method "C" will also be published in the coming weeks, methods that invert the Caller-ID and the start/stop time. 1.2. Source IP identification One of the solution to hide the source of a PVP request is to use an intermediate TURN server, TURN server which is already available is the RELOAD overlay has to support -ICE transports. Depending on the decision about ICE, we may have to design another mechanism to hide the PVP client IP address. 1.3. Traffic statistics leakage One of the proposed solution is to make random PVP calls to increase the noise. Unfortunately the this would increase the load on the PVP servers without really preventing a motivated party to collect statistical information. 2.1 Obtaining the PVP credentials in an office environment This attack uses the facts that PVP credentials are shared inside an organization (enterprise) and that people assume that nothing bad can happen inside this organization. This is the same fallacy that make people think that they are protected by their firewall. One proposed solution is to not share the credentials between users inside an organization by assigning a different VServiceID to each user. This also makes the case for ICE support, as assigning a VServiceID to each user is equivalent to running a VIPR server in each device. 2.2 Registering multiple PVP servers to validate based on time tolerance The idea is to register enough PVP servers to increase the probability of guessing the right start/stop time for a call. If the maximum duration of the calls is D and the rounding is R then registering (D/R * (D/R - 1) / 2) PVP servers permits to validate 100% of the calls made inside this duration. Not sharing PVP credentials inside an organization also makes this attack less interesting. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPGDi1AAoJECnERZXWan7EkfoP/ipfb32y+PbRjkYW8kRnB9bV yGdU5GvLH0pqWzPXZ22RR4ckkuajTjToPNUV7QulwxU0e7015cMYEgkbM1tMyZBO 0/574QbT7PEUF+S83HhTqG55Htvb3NAjxp8B4x4zjVlpvN0Ful54ciIq8laGkjHC UweIiQn9I3LKtzks9/rxhWnzqajbA3gzHaLyWYUu7UVr8B3u7pEqZ9NiUTGhFpmC AqR0pmCkbmWUypDbm5SU2UqlADFC+maTu63587/TOx8o5AGxvM24WKccdtS7tbPM wiQEMi/bX6nLtz4eqFxMHFzaAOoQo/dYEan/5vsslz6VaYSnla20Mm1JwRTcBnI1 NpJR07RjT1NXV4FlHj43Q0ZIxrJiBl6UkvUpTpvzA/eteI1RomBh3kix3QD6OYYW HZ5VBYv0i42ii5qxVQ0sFDk+BTajaybFxBlC3zLOzCoGXovDnDbp0Q8li9FiIGn3 2mTZxx9IEjBjwYRxycFmoDN3UNDcAq8hfMfh1vqTkHBxxf7DmGQ5ZgcBfzS4qIgE 6MFGplu/FYTICV7pCtSObPiV2vNrmjbSbly2gDc6Ubomcz0kiLFMQObkOW0Lhj5c Az+V9j925afZLLfB9ceLesLjzUBT+gSiimvGxcMyhu5FIsZq1XdfxmQyiIH3/ytB FEwK1PmW13bK6WfFjHhf =cRJu -----END PGP SIGNATURE----- From petithug@acm.org Thu Jan 19 08:05:53 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C287F21F869D for ; Thu, 19 Jan 2012 08:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.868 X-Spam-Level: X-Spam-Status: No, score=-100.868 tagged_above=-999 required=5 tests=[AWL=-1.268, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_SUMOF=5, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1h6iYdkF2Tf for ; Thu, 19 Jan 2012 08:05:53 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id CACA821F8698 for ; Thu, 19 Jan 2012 08:05:52 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 5B69E202D2; Thu, 19 Jan 2012 15:51:58 +0000 (UTC) Message-ID: <4F183F5C.4070604@acm.org> Date: Thu, 19 Jan 2012 08:05:48 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: Dean Willis , "Hakim Mehmood (naim)" , Michael Procter , John Ward , 'Mary Barnes' , "Muthu Arul Mozhi Perumal (mperumal)" , Daryl Malas , Jon Peterson X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" Subject: [VIPR] Agenda & Handout for 2012/01/20 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 16:05:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 A. Agenda - - ICE support in VIPR - - Traffic statistics leakage - - Obtaining the PVP credentials in an office environment - - Registering multiple PVP servers to validate based on time tolerance Note that the sum of the time allocated to each topic may exceeds the time allocated to the whole call. The topics that cannot make it to the discussion will be postponed to the next conference call if they are not subsequently decided in the mailing-list. Because the conference bridge as a limited capacity, an individual invitation to the conference will be sent shortly after this email to each member of the design team. Please send me an email if you are not on this list and want to receive an invitation. Note that the design team conference call is not a way to short-circuit the normal process, but a way to accelerate it by increasing face to face time. All decisions made must be confirmed on the mailing-list. This conference call is subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). B. Handout (reading time: 5 min) B.1. ICE support in VIPR Section 1.2.1 of draft-procter-vipr-privacy-concerns proposes to use TURN to anonymise the source of a PVP validation. This proposal is probably incomplete, but the main problem is that we still do not know what transports will be used on the RELOAD overlay used by VIPR. First here's a list of what we currently know about this overlay: - - The algorithm is RELOAD-CHORD - - The Node-ID size is 16 bytes (128 bits). - - Clients are not authorized because of the quota algorithm. - - Self-signed certificates are not authorized. - - There will be one or more root-certs. - - There will be one or more bootstrap peers (unicast or anycast - no multicast). - - Clients are not authorized because of the quota algorithm. - - Shared secret are not used. - - The overlay link protocol is TLS. - - There will be a list of kind and configuration signers. - - The urn:ietf:params:xml:ns:p2p:config-chord, urn:ietf:params:xml:ns:p2p:quota and urn:ietf:params:xml:ns:p2p:vipr extensions are mandatory. - - The Kind VIPR-REGISTRATION will be authorized. What we do not know yet: - - Do we need to authorize the CERTIFICATE-BY-NODE and CERTIFICATE-BY-USER Kinds? - - Will TURN server deployed in the overlay? - - Will ICE overlay link protocols be used? The important question for this topic is the support of ICE in the RELOAD overlay: Pros: With ICE support the RELOAD nodes, the PVP client and the PVP server can be installed behind a NAT/Firewall without having to put them on the DMZ or to open pinholes (the bootstrap servers will still need to be installed in the DMZ or on the Internet). TURN servers are required for ICE support, so they would also be available for anonymising the connections. Cons: ICE is complex to implement and debug. If we decide to exclude ICE, then the TURN servers are no longer available by default, and the idea of using them for anonymising the connections is moot. An additional consideration is that the RELOAD transports are currently limited to UDP and TCP, neither of them being really well suited to carry RELOAD or PVP messages. If we decide to exclude ICE support, I will then propose to use (D)TLS over SCTP instead (and write the I-D for this). So the initial question is: Do we need ICE or not? B.2. Traffic statistics leakage One of the proposed solution is to make random PVP calls to increase the noise. Unfortunately the this would increase the load on the PVP servers without really preventing a motivated party to collect statistical information. B.3. Obtaining the PVP credentials in an office environment This attack uses the facts that PVP credentials are shared inside an organization (enterprise) and that people assume that nothing bad can happen inside this organization. This is the same fallacy that make people think that they are protected by their firewall. One proposed solution is to not share the credentials between users inside an organization by assigning a different VServiceID to each user. This also makes the case for ICE support, as assigning a VServiceID to each user is equivalent to running a VIPR server in each device. B.4. Registering multiple PVP servers to validate based on time tolerance The idea is to register enough PVP servers to increase the probability of guessing the right start/stop time for a call. If the maximum duration of the calls is D and the rounding is R then registering (D/R * (D/R - 1) / 2) PVP servers permits to validate 100% of the calls made inside this duration. Not sharing PVP credentials inside an organization also makes this attack less interesting. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPGD9ZAAoJECnERZXWan7ETuAQANLjcFYlyY00nQYUfuvqrbJE jijDJiBT1KssEULnl5ZLSMrTsHMhtEIo3vulEgrdVod5W/9H5cG3cu9hfSIRvzV/ guKFvY0ICChYNcrwYTpCRjsFJUuvFt2Eb3vxx07DXpoeDwVGeTeRdwDdUS2GPHA+ xafxPm4gZyZEWgc7G2shG1Gq2IQgcLvik1o+tHpVfNPWQRNO4CagYdQBfsATs+EC C+d963teu8hW6feq9ZTAQs0z0s2voqUxFIHbXFCkI71BJO4wqhGjHq5Uuy59MdeG qlt8LOTrbhNN/BeVivco8U04jwUcC+t7g8kjsstHdgyBhIkrdQ4zjRBFOEPY2rJk yagAp6H2igPtV1ojUUOjqqg6TNQ/qMYWkORI8+3oHqNVddl+BoYGX6oKlVwZrHAg QKrmUGTWhPsQvtykBBYdhSHQ7fJMWqwQhvj+0WtEBzFurZmqSJi2i1WLXICFPUao rH/gKWWx3fvlTa+DnXK4p0Hj342mqmaCtvocP7jdpTN20YkqbRQGGP5+hTmgLewL Tw41nHgpgRPcHYh4uToUqJezMw/vnbwKONbCqvcoWJl8KdCNps/i4Kmg3iURsVKK 2Gcbswy1RzO7iZzutEfJGfDQswBUybPzgau9GDbYSZirBjFVxhB4ff9PBUPnxmxY ao9lTIiDsF8nEIoP05xE =gzKh -----END PGP SIGNATURE----- From eburger@standardstrack.com Fri Jan 20 04:44:35 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C0F21F85C0 for ; Fri, 20 Jan 2012 04:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.689 X-Spam-Level: X-Spam-Status: No, score=-101.689 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yzA2YQ-dnAl for ; Fri, 20 Jan 2012 04:44:34 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id C5FB321F85A3 for ; Fri, 20 Jan 2012 04:44:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:From:Content-Type:Subject:Date:Message-Id:To:Mime-Version:Content-Transfer-Encoding:X-Pgp-Agent:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=rP8ljaRDgSA2s6Ok4/sKyTVc9AZJESqfIdWpzmUwdhqOLViPnmBB6yjMUDlgCGCX01DGN+e1mD9Wyue18HYjqryypVsuUO16nk9gz/Fvs4gMXj/Y8DUg3qAyj31FpFcA; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:56938 helo=[192.168.15.184]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RoDpY-0004Re-AY for vipr@ietf.org; Fri, 20 Jan 2012 04:44:33 -0800 From: Eric Burger Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-8-863916252" Date: Fri, 20 Jan 2012 07:44:27 -0500 Message-Id: To: vipr@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [VIPR] Review of VIPR Overview X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 12:44:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-8-863916252 Content-Type: multipart/signed; boundary=Apple-Mail-7-863916248; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-7-863916248 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I volunteered to review draft-jennings-vipr-overview-02, "Verification = Involving PSTN Reachability: Requirements and Architecture Overview," = during the VIPR meeting at IETF 82. My focus is on the readiness of the = document for adoption as a work group item. I did not focus on whether = the document is ready for publication. As an aside, it is NOT ready for = publication. It is my belief the document is ready for adoption as a work group item. = The document is of a sufficient maturity, explains the problem, and is = mostly self-consistent. There are a number of items left for work group = discussion, but they are not substantial open issues, which would = indicate the document would not be ready for work group adoption. What follows are my comments on the document. Consider them as a = potential starting point for work group discussion. GENERAL =3D=3D=3D=3D=3D=3D=3D This document reads like a patent application and product advertisement = all rolled up into one. There is no value in trying to convince the = reader that VIPR is novel, fundamentally different that what was out = there, clever, or neat (all language taken from the draft). Such = language is distracting for an implementor. More to the point, we want = implementors focusing on implementation, not thinking about how to show = that one feature or another is not novel. The most egregious examples = of this language are Sections 5.3.1 in the second paragraph and 2.2 = discussing how email is useless. I would not want an implementor to = think, "Well, I just received this via email, so if the assertion is = email is useless, this protocol must be useless." FORWARD (or no) REFERENCES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= There are a number of forward references or references to items that a = PSTN telecom engineer might be familiar with, but an Internet engineer = might not be familiar with. For example, REQ-2 refers to E.164 numbers. = This is the first we hear of E.164 numbers. I would offer that = mentioning that when we say Phone Number, we mean an E.164 number. A = good place for that would be in Section 2.1. Include a reference to = E.164 there, too. REQ-12: what is call handover? This word appears only once, here. I know = what that means in the PLMN, but I do not know what it means in the SIP = world. Call Agent: for a while, I thought I was reading an H.323 document, not = a SIP document. I can get why one does not want to call the thing that = knows VIPR a SIP User Agent, because it does more than a SIP User Agent. = If one wants to use the term "Call Agent," one must define it = somewhere, preferably at the beginning of the document. However, given = the confusion with H.323 Call Agents, I would offer one either selects a = different term, or perhaps use "VIPR-enabled User Agent." Ticket: Section 5.3.3 starts talking about generating tickets, but never = defines what a ticket is. The reader has to read the whole document to = figure that one out. Section 5.3.4 talks about cached routes and 'next call agent in the = path.' However, the document never discusses chains of call agents, = multiple routes (except in an aside in the previous paragraph to the = reference to the path), or what a path is. In fact, this is the sole = appearance of the word 'path' in the document. OTHER =3D=3D=3D=3D=3D REQ-4: Users do not make the federation; they make calls. Is not the = requirement that without doing anything different users can now do = inter-domain IP calls? REQ-11: This describes a solution, not a requirement. I would offer = language such as "The solution should be self-learning and adapt to VIPR = call failures." NITS =3D=3D=3D=3D Page 11, 2nd list entry: s/SIP endpoints, or with non-IP/SIP endpoints = and with non-IP/ Page 11, 7th list entry: Never, Ever? One Never is good enough. This = whole section needs to be made relevant to implementors or be removed. = See the comment above about patent and marketing language in = specification documents. Page 21, 3rd from last paragraph in Section 5.3.4, floating period after = the string "Section 5.3.3 ." Page 24, Acknowledgements: let me in on the joke: I could imagine Theo = being a thief of numbers. Maybe in the fifth Ring [sic]. If he really = is, I would suggest saying "5th thief [sic]". Otherwise, I would suggest = saying "5th theft", if that is what the document means. --Apple-Mail-7-863916248 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ 9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX 56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0 FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0 okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwMTIwMTI0NDI3WjAjBgkqhkiG9w0BCQQxFgQU UG+QJICip5ElAVNAzmcWcqnRaJAwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw DQYJKoZIhvcNAQEBBQAEggEAESt91W3nPB6PTZfyB25ISQHjKqJVeIyH+HFbBujm6x/gr5CXv2h3 7OcDg6aoKAwq8UXiZoFU/WRRhZKxYAALMsVQ3d9VbIyT706o/B9aYfJ0yjKQdvphSfwhL2OW2RWp BX/z7JxmFlFAqqdSvVm3d5cy+JE2L24ePS5afgCRXb5mup6hfmAO/CdkjeLVacaSoS+IkvSCaS2z YmHngifSY0zsd+l5t/QFpSHJGyG0U2ln5u25KW5bB0YwVWMNWRZEHWSasECIyytwYt9WCjZ5qqGa uBldrDsOIM0Z9RrjTJKX4QZHAFuvdaHCE3K0ykXL/e9NN6OKJAUkM7Mmix6MQQAAAAAAAA== --Apple-Mail-7-863916248-- --Apple-Mail-8-863916252 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJPGWGrAAoJEDY/T2tCIPW3QeMP/ilm2BqaeK7gWdCXOPru79a5 p68iOyvn74G+XaB/4ncq4rGHgnSGnp1HBRkfFLke/MiyqVl/oPDDzzXuk366AgAa ukttJn+hlSqq81Ojd67y4omifeRaUGQBbpQoMVEPJzrNleYk9kRUdrPJ0HlR9phD nrJFstAB/ATl0WM47Vfu0zOTERkPYvRUPU+KseR0Odg4ugJkQihQFdvDFMmLXRhd ICFxjcm3ozDbXHqRA6JiTyaOgPkjop9lFsisYT56Ynq+ztl0+DA8Y8SWeXK3ETd9 IlTjJRebT/Zvl9t7JR3f8cchPWLBsKQg7YkLI+OknOTNh7ftce2cMByTpM5jQcSR IXIq/ssD25r86rpve1BQ60q8LO+WAR2hUeJo7LT7Vner2Pks3Pg5CRU1acfdAhEl 7oZkQiAXxCZf+0jllFbjGfOOzVUMxaH5XUtLCvwfKHy+jLEDgo25D8DmB9cfZy3u 37r99gFdHFWkc8R8E6G8udNqE0P1WXDK19Rhyk6CsP7wulqQT0HUGjMyUWWaWw1p /0qS+Cpo1zunLKUExO/noByBAU8ISNRYlJB+zgvu9FEkW52LGuDC2WoG2q6+pcAW MWBjMhQb1DS5I3bmHpSGEkn4XQPPoK/2Z7SW1bqFdnu86UW3zEQEz4D/9IgQdiAD 3D2AwN7/Ag5e6JlOX2U8 =eA9N -----END PGP SIGNATURE----- --Apple-Mail-8-863916252-- From petithug@acm.org Mon Jan 23 09:02:00 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0361421F846C for ; Mon, 23 Jan 2012 09:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.341 X-Spam-Level: X-Spam-Status: No, score=-102.341 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQugBLUJAQcZ for ; Mon, 23 Jan 2012 09:01:59 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id AC13021F846E for ; Mon, 23 Jan 2012 09:01:58 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 3F3A020142 for ; Mon, 23 Jan 2012 16:47:50 +0000 (UTC) Message-ID: <4F1D9283.4010208@acm.org> Date: Mon, 23 Jan 2012 09:01:55 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Minutes for 2012/01/20 conference call X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 17:02:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 VIPR Design Team conference call on Friday January 20h, from 9:05am to 9:55am PST. o Attendees: Hakim Mehmood Marc Petit-Huguenin Michael Procter Dean Willis o Regrets Mary Barnes Daryl Malas Muthu Arul Mozhi Perumal Jon Peterson John Ward o Agenda - - ICE support in VIPR - - Traffic statistics leakage - - Obtaining the PVP credentials in an office environment - - Registering multiple PVP servers to validate based on time tolerance o Action items - - Continue discussion on privacy issue. - - Discuss about anonymizing the Node-ID in the RELOAD record. - - Add ICE as mandatory for the RELOAD overlay. - - Document the statistic issue in the specs. o Minutes Marc: The discussion in this meeting is about the privacy concerns as listed in Michael Procter's draft. The first one was the Caller-ID, and the agreement was to hash the Caller-ID in method A and publish a new method "C" that invert the selector and the secret. The next concern was source IP identification, and one obvious solution to hide it is to use a relay or a series of relays. One of the simplest solution to do this is to use the TURN servers that should be available in the RELOAD overlay. But TURN servers are only mandatory if the RELOAD overlay uses ICE. So the question shifts to "Do we want to support ICE or not?". We can still mandate TURN servers if the overlay does not require ICE, but there is probably other ways in this case to hide the source. There is an assumption in the specs that the VIPR servers are installed either on the Internet or in the DMZ of a firewall, which implied a non-ice solution. But what is the granularity that we want for the VIPR server? For example as a proof of concept, I am development a prototype of what I call a VIPR Fax, where the VIPR server is embedded inside a fax machine and connect directly on the RELOAD overlay on its own, without requiring external servers. Hakim: Why does this problem applies only to source? Anybody can do a Fetch and find the destination. Why is it more important for the caller than for the callee? Marc: This is a valid but different attack and we should talk about it. I will add this concern to the agenda of the next meeting. Hakim: In the enterprise space, the feedback is that all the security things are good to do but should not be mandatory. Michael: I am not sure how compatible that is with the view that there should be one VIPR overlay. I do not know how we can make many things optional and still have a working overlay. Hakim: It's just the feedback I have from my customers. Marc: My concern is that the lack of security will prevent people to join the VIPR network. Hakim: The architecture should be a compromise between security and manageability. Michael: Going back to something Marc said. If Alice wants to call Bob, but Bob thinks that VIPR does not have the proper security and decide to not participate in VIPR, when Alice call Bob, the fact that she calls still leaks. Bob cannot stop the privacy leak even by just not participating. Without even reducing the security, there is already privacy issues, even if you do not participate. Hakim: I was more talking about source IP disclosure. Michael: What I said applies to that too. Hakim: But how does that compromise my security in this use case? Michael: It all goes back to asymmetric expectations. Alice in this case could have her fully itemized phone bill posted on the Internet. Hakim: But I was talking about a particular use case. Alice probably does not care, but Bob cares and he can anonymize. So as long Bob has the security he wants it's fine. Michael: It is not. Marc: What about putting a flag inside RELOAD asking for privacy? This has the advantage that each registration can choose the level and privacy and will not put as much pressure on the overlay. Michael: It is essentially a bid-down attack. The problem is that you have to be on VIPR to protect your privacy. This is a fundamental problem and expecting everyone to opt-in to protect their privacy is a bit of a challenge. Marc: Let's put on the agenda for next week. We can still talk about the requiring ICE in the overlay. Michael: I like the the VIPR fax use case. I think that it will keep us honest in other areas, because it does not mean that we automatically assume that only companies over 200 employees will be in VIPR. And because of this we'll need ICE. Marc: The only concern with ICE is the complexity. But it's not like RELOAD is simple without ICE. RELOAD is complex, and is even more complex with ICE. Anyway the main case for RELOAD was SIP, and you need ICE for SIP, so any standard RELOAD server will probably also support ICE. Marc: Let's move to statistics leakage. Even if we manage to fully anonymize the PVP transactions, the simple fact that PVP transactions are made discloses information. Michael: As an example we have a taxi company as customer, and simply by looking at the Internet traffic pattern, we can predict the weather in the city in which this company operates. Even adding noise would not help and I think that this attack is real. Marc: This is true for a lot of other things in the Internet. This is something that we need to document, even if we cannot fix it. Michael: And here also the problem exists either people participate or not in the VIPR overlay. Marc: Moving to the office pranks attacks. These attacks exists from the facts that in some environments, you have access to more information, for example inside an enterprise. These attacks can be carried by a virus inside an enterprise. First attack was to obtain the PVP validation. One of the way to mitigate this is to do validation per user, instead of per enterprise. Interestingly it parallel the VIPR fax use case, where each device also has its own VServiceID. Marc: The last attack is similar but was using the rounding. Note that this attack and the previous one come from the low security of methods A and B. If we mandate a validation based on e.g. fingerprinting, then we no longer have these issues, but these methods are the minimum common denominator. Michael: If ICE is not adopted because of its complexity, then we will have a problem adopting fingerprinting, which is even more complex. Marc: Yes, and this also creates a problem for SIP intermediaries who do not have access to the media. Hakim: Two mains themes with our customers has been: Why does it take so long to validate, and what rounding should I use to have my validations succeeding. Marc: We can solve a lot of problems by simply forgetting about these methods, but we are restricting the use of this technology, But these methods looks so bad, between reliability, privacy and time to succeed, that it is perhaps not worth the effort. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPHZJ/AAoJECnERZXWan7EbKsP/RjkAh6cf7AFngJ7a22OfOxK Q2KilGCjpIcfL8Z6MHf8Qp9JVUg7zTwZXy6UEZabUWWjEs6l3IqPCXL1mF+YFjCX Wpv0bofkZzW+95x2ZmTVd47W1rVT5H/zcZoU6c8RASd8Xhorout1VXZDDW4NxfEi vTdSU58DmOBJTCFcrFJYBeGWiK6RHLI9Ufxp7QMZu/oWfIDepN2FPBfQNKgbEiWR XTamwFuXt1m9gzW0ACePVElA29/fSeoL6WjjLZ4A5f1ahfVPbCuMdso5bxQ8RW6y cYIWFacLNAMvr1+vaOKp03cPF2EBkc8ZZvljB1kF5DrTIedaNxaIx8uRVv3qb7vy 3bAfy95o7H80HmRn0YWCIDxn2YgFTm3fJgRMk7EKP+qIP5BDpXT2XQ26i+/UxVY2 xW9dIYXgJQ1OyjaxM/y6QVLboBjNNYvGtm1w+BhCEHsSs0oEzpjkQeQjF6Zxb1fe 26m8eBLYn82VHkxQwJK5rVl+rLOqNSwZikLCng6TleohnGKEzEuL7lIv0/CQKB+g pZZxzrjEmAwwxu3qR5p3ZScOoS+qbA4e6mJ1QqLZ1Os4U2n2hqVDmxnUfs+HfoN3 iBT34BDkL99qwKXAptwXMOuwGKSuMrWk6uafYQANfjqr6TDTnF5GifNaipbB+wtx Y47/BGUEO1YYPYUZoxPk =13ni -----END PGP SIGNATURE----- From petithug@acm.org Tue Jan 24 12:53:28 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C330421F84AA for ; Tue, 24 Jan 2012 12:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3ezT51rhjgR for ; Tue, 24 Jan 2012 12:53:27 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 7985221F84A5 for ; Tue, 24 Jan 2012 12:53:27 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 30947201CF for ; Tue, 24 Jan 2012 20:39:13 +0000 (UTC) Message-ID: <4F1F1A42.1030201@acm.org> Date: Tue, 24 Jan 2012 12:53:22 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 20:53:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Michael Procter explained on the last VIPR design team weekly conference call a privacy attack that I think is devastating. The end result is simple to explain: VIPR turns the Internet into a "trap and trace device"[1], allowing anybody to record the phone numbers called by any entities using VIPR, and this for a relatively low cost. Let's say that VIPR is well deployed in US enterprises and that a spying group is willing to spend the money to know about the phone calls made by these enterprises. This spying group just have to add enough VIPR servers to the RELOAD overlay to register all the phone numbers in the USA. Because all registrations are considered equally untrusted, they will all be verified by establishing a TCP connection between the VIPR server of the source of the call and the VIPR server that stored the registration for a particular phone number. There is multiple pieces of information that are leaked but it is easy for example to find the enterprise that is originating the TCP connection by looking at the source address and to enter it in whois. As Michael pointed out, you have to be on VIPR to protect your privacy, i.e destination numbers that are *not* using VIPR are especially at risk. If the destination number is using VIPR, the TCP connection used to verify the first call from any enterprise has a lower probability to be directed to the spying group, because the real owner of the number may be tried first and prevent other registrations to be tried if successful. And as soon the real owner sends a SIP route and ticket back, the spying group will no longer receive any information about the calls between this enterprise and this destination number, excepted for the periodic renewal of the ticket. Note that the information leaked go deeper than just the verification connection. Here's the various places where privacy information leakage happens with this attack: - - If the spying group uses a different VServiceId for each registered phone number, the called number is always leaked. - - The called number is also leaked for methods A and B. - - For method "A", the Caller-ID is leaked (the bcrypt hash is hard to crack, but it is not impossible). - - For method "B", a random time in the middle of the call is leaked. - - For method "C", the rounded start and stop time of the call are leaked. - - The source IP address of the TCP connection for the PVP transaction is always leaked. - - The addr_port in the AppAttachReq RELOAD message that was used to establish the TCP connection is leaked. - - The certificate of the signer of the AppAttachReq RELOAD message is leaked. Even if the certificate does not contain information about the sender (subject, subjectAltName), it always contains the Node-ID, which can always be resolved to an IP address by using an Attach request. - - The Node-ID is leaked a second time in the via_list of the AppAttachReq message, unless an intermediary RELOAD peer replaced it with a compressed ID. There is probably ways to fix all of these leakages, and I found solutions for most of them, but they make RELOAD and VIPR much, much more complex, to the point that I am starting to think that RELOAD itself is not up to the task. Using TURN to anonymize, as I proposed, does not work because of the multiple places where data is leaked and fixing RELOAD itself, which will require among other things adding something like onion routing, will probably take years[2]. At a minimum, we will need to add a strong requirement about required anonymization in -overview, but it is clear to me that the standardization of VIPR will take a much longer time than expected. [1] http://en.wikipedia.org/wiki/Trap_and_trace_device [2] http://www.ietf.org/mail-archive/web/p2psip/current/msg06166.html - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPHxo6AAoJECnERZXWan7EV0kQALf+0G+bdOj4t3GiNSk1rjKC 7Zbnz4cqiJrmmJl3PjISQy8t+yXEngEO2vmM9ewkb9i4tZV0fV+UNv4Wpxfs2XF1 p/VRZ8gKAGiNfSgY2aGXDtErEaV33Rkuh+iQUVd+FsYTc2lSUDPnRFXD9dfO4GuK FIJKnf3Wm9yK37zN8X+kS9ynrEzTXDKD1V1kfW8JgEne6KkL7wwhH/NWAXKbT3F+ o0RsWbM2Kft9aCmzRtBSgzNRiVb1G6asD8LaETXImEPhP0ScySnul7sqeXg4un5o ipVwjiAuKy6sPsOJoXD26fePzMbymrtKL6R3Lv/YM9W9ae3cQo3JrjShEwYhVETY c0leYotFBSDELu3jv2sqfF1ij9I+XXD9gUT8eOd/XV/xBKvvEr06xQ9tc7E72e1C hEpINusiMYNW1nWvL7WvJNbQU4KaojyF6I2uGLQss8UKBYvYBU4+oIkg6F0bF3GA c5yxdEVOg1Tkn88yiUI4O3pOS1yuscsUBlduOKQsNvKZQWd6Y1eikODU44Ea2hRr JlsQz5Azh7PY07a6dD7VmdS36wA0N+JbPpL6pvgf0r5tfxoWAcfoyZ2gtgEsFf6Y CLaySla7kUaVVzjhe9tsccG3FmdpnDS8wQjJ/47FI/hnCUfv02FOAHWzALRNZgfF nTxixgP8OeOKecgd8ll8 =LV2v -----END PGP SIGNATURE----- From kpfleming@digium.com Tue Jan 24 14:20:20 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3237911E8085 for ; Tue, 24 Jan 2012 14:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.507 X-Spam-Level: X-Spam-Status: No, score=-106.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1UfjdbtzLr9 for ; Tue, 24 Jan 2012 14:20:19 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id EC54A11E8079 for ; Tue, 24 Jan 2012 14:20:18 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Rpoiw-0003c9-Lz for vipr@ietf.org; Tue, 24 Jan 2012 16:20:18 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id A8606D8004 for ; Tue, 24 Jan 2012 16:20:18 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZl0W6n-Bb5b for ; Tue, 24 Jan 2012 16:20:18 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 3040AD8002 for ; Tue, 24 Jan 2012 16:20:18 -0600 (CST) Message-ID: <4F1F2EA1.5070209@digium.com> Date: Tue, 24 Jan 2012 16:20:17 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: vipr@ietf.org References: <4F1F1A42.1030201@acm.org> In-Reply-To: <4F1F1A42.1030201@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 22:20:20 -0000 On 01/24/2012 02:53 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Michael Procter explained on the last VIPR design team weekly conference call > a privacy attack that I think is devastating. The end result is simple to > explain: VIPR turns the Internet into a "trap and trace device"[1], allowing > anybody to record the phone numbers called by any entities using VIPR, and > this for a relatively low cost. > > Let's say that VIPR is well deployed in US enterprises and that a spying group > is willing to spend the money to know about the phone calls made by these > enterprises. This spying group just have to add enough VIPR servers to the > RELOAD overlay to register all the phone numbers in the USA. Because all > registrations are considered equally untrusted, they will all be verified by > establishing a TCP connection between the VIPR server of the source of the > call and the VIPR server that stored the registration for a particular phone > number. There is multiple pieces of information that are leaked but it is > easy for example to find the enterprise that is originating the TCP connection > by looking at the source address and to enter it in whois. > > As Michael pointed out, you have to be on VIPR to protect your privacy, i.e > destination numbers that are *not* using VIPR are especially at risk. If the > destination number is using VIPR, the TCP connection used to verify the first > call from any enterprise has a lower probability to be directed to the spying > group, because the real owner of the number may be tried first and prevent > other registrations to be tried if successful. And as soon the real owner > sends a SIP route and ticket back, the spying group will no longer receive any > information about the calls between this enterprise and this destination > number, excepted for the periodic renewal of the ticket. > > Note that the information leaked go deeper than just the verification > connection. Here's the various places where privacy information leakage > happens with this attack: > > - - If the spying group uses a different VServiceId for each registered phone > number, the called number is always leaked. > - - The called number is also leaked for methods A and B. > - - For method "A", the Caller-ID is leaked (the bcrypt hash is hard to crack, > but it is not impossible). > - - For method "B", a random time in the middle of the call is leaked. > - - For method "C", the rounded start and stop time of the call are leaked. > - - The source IP address of the TCP connection for the PVP transaction is > always leaked. > - - The addr_port in the AppAttachReq RELOAD message that was used to establish > the TCP connection is leaked. > - - The certificate of the signer of the AppAttachReq RELOAD message is leaked. > Even if the certificate does not contain information about the sender > (subject, subjectAltName), it always contains the Node-ID, which can always be > resolved to an IP address by using an Attach request. > - - The Node-ID is leaked a second time in the via_list of the AppAttachReq > message, unless an intermediary RELOAD peer replaced it with a compressed ID. > > There is probably ways to fix all of these leakages, and I found solutions for > most of them, but they make RELOAD and VIPR much, much more complex, to the > point that I am starting to think that RELOAD itself is not up to the task. > Using TURN to anonymize, as I proposed, does not work because of the multiple > places where data is leaked and fixing RELOAD itself, which will require among > other things adding something like onion routing, will probably take years[2]. > > At a minimum, we will need to add a strong requirement about required > anonymization in -overview, but it is clear to me that the standardization of > VIPR will take a much longer time than expected. A very similar point was raised during the last in-person VIPR meeting that I attended (two IETFs ago, I think). I commented that we had personal experience with this problem in the Asterisk world, years ago when we had a public DUNDi cloud for routing E.164-numbered traffic. It is one of the primary reasons that many of us (I was not with Digium at the time) stopped using that cloud. I'm certain that as you say, these problems are not intractable, but providing solutions for them may very well make VIPR (and similar mechanisms) so complex to implement and deploy that nobody will choose to do so. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From petithug@acm.org Wed Jan 25 09:54:44 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5506021F8587 for ; Wed, 25 Jan 2012 09:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.389 X-Spam-Level: X-Spam-Status: No, score=-100.389 tagged_above=-999 required=5 tests=[AWL=-1.757, BAYES_00=-2.599, FRT_FUCK1=2.534, FRT_FUCK2=3.434, GB_I_INVITATION=-2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyUmoe73lbaa for ; Wed, 25 Jan 2012 09:54:43 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 317A121F8585 for ; Wed, 25 Jan 2012 09:54:43 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 3EE8C20198; Wed, 25 Jan 2012 17:40:26 +0000 (UTC) Message-ID: <4F2041DF.4090304@acm.org> Date: Wed, 25 Jan 2012 09:54:39 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "Kevin P. Fleming" References: <4F1F1A42.1030201@acm.org> <4F1F2EA1.5070209@digium.com> In-Reply-To: <4F1F2EA1.5070209@digium.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: vipr@ietf.org Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 17:54:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/24/2012 02:20 PM, Kevin P. Fleming wrote: > On 01/24/2012 02:53 PM, Marc Petit-Huguenin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> Michael Procter explained on the last VIPR design team weekly conference >> call a privacy attack that I think is devastating. The end result is >> simple to explain: VIPR turns the Internet into a "trap and trace >> device"[1], allowing anybody to record the phone numbers called by any >> entities using VIPR, and this for a relatively low cost. >> >> Let's say that VIPR is well deployed in US enterprises and that a spying >> group is willing to spend the money to know about the phone calls made by >> these enterprises. This spying group just have to add enough VIPR >> servers to the RELOAD overlay to register all the phone numbers in the >> USA. Because all registrations are considered equally untrusted, they >> will all be verified by establishing a TCP connection between the VIPR >> server of the source of the call and the VIPR server that stored the >> registration for a particular phone number. There is multiple pieces of >> information that are leaked but it is easy for example to find the >> enterprise that is originating the TCP connection by looking at the >> source address and to enter it in whois. >> >> As Michael pointed out, you have to be on VIPR to protect your privacy, >> i.e destination numbers that are *not* using VIPR are especially at risk. >> If the destination number is using VIPR, the TCP connection used to >> verify the first call from any enterprise has a lower probability to be >> directed to the spying group, because the real owner of the number may be >> tried first and prevent other registrations to be tried if successful. >> And as soon the real owner sends a SIP route and ticket back, the spying >> group will no longer receive any information about the calls between this >> enterprise and this destination number, excepted for the periodic renewal >> of the ticket. >> >> Note that the information leaked go deeper than just the verification >> connection. Here's the various places where privacy information leakage >> happens with this attack: >> >> - - If the spying group uses a different VServiceId for each registered >> phone number, the called number is always leaked. - - The called number >> is also leaked for methods A and B. - - For method "A", the Caller-ID is >> leaked (the bcrypt hash is hard to crack, but it is not impossible). - - >> For method "B", a random time in the middle of the call is leaked. - - >> For method "C", the rounded start and stop time of the call are leaked. - >> - The source IP address of the TCP connection for the PVP transaction is >> always leaked. - - The addr_port in the AppAttachReq RELOAD message that >> was used to establish the TCP connection is leaked. - - The certificate >> of the signer of the AppAttachReq RELOAD message is leaked. Even if the >> certificate does not contain information about the sender (subject, >> subjectAltName), it always contains the Node-ID, which can always be >> resolved to an IP address by using an Attach request. - - The Node-ID is >> leaked a second time in the via_list of the AppAttachReq message, unless >> an intermediary RELOAD peer replaced it with a compressed ID. >> >> There is probably ways to fix all of these leakages, and I found >> solutions for most of them, but they make RELOAD and VIPR much, much more >> complex, to the point that I am starting to think that RELOAD itself is >> not up to the task. Using TURN to anonymize, as I proposed, does not work >> because of the multiple places where data is leaked and fixing RELOAD >> itself, which will require among other things adding something like onion >> routing, will probably take years[2]. >> >> At a minimum, we will need to add a strong requirement about required >> anonymization in -overview, but it is clear to me that the >> standardization of VIPR will take a much longer time than expected. > > A very similar point was raised during the last in-person VIPR meeting that > I attended (two IETFs ago, I think). I commented that we had personal > experience with this problem in the Asterisk world, years ago when we had a > public DUNDi cloud for routing E.164-numbered traffic. It is one of the > primary reasons that many of us (I was not with Digium at the time) stopped > using that cloud. > > I'm certain that as you say, these problems are not intractable, but > providing solutions for them may very well make VIPR (and similar > mechanisms) so complex to implement and deploy that nobody will choose to > do so. > Perhaps, but my current concern is not complexity. VIPR is highly dependent on RELOAD, and half of the leakages come from RELOAD itself. We have a good design team in VIPR and we - slowly but steadily - find consensus on a lot of of the issues that are pure VIPR. But on the RELOAD side, no amount of energy spent seems to help accelerate things. I even considered forking the RELOAD spec to have at least a decent subset that VIPR can use and adapt to its needs, but it's probably not legal, and anyway prevent reusing standard implementations of RELOAD for VIPR. So our options as I see them: - - Stop the work on VIPR until RELOAD reaches a point it is usable. - - Forget RELOAD and replace it with another mechanism. - - Close VIPR. We will probably spend the whole of our conference call next Friday on this subject (everybody is welcome to join, just send an email to the chairs and I, and I will send back an invitation). Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPIEHdAAoJECnERZXWan7EJhAP/AiDXuH63mMvgES+qd/Jgl5Y Z94tyL05aYvsuFT8QjOVPI1aSyQ8Ngv3HvGrMLZhWEEPuv7eWGUmu9WBpZtuWJ5z a3gRZTfxeqH1qCS95+fBfbK77FjyQFBi9oaca1v/RugF7Vs2Xo/0Lb3HfD/vNGiL OO0H0sOBqtUKXPq0eJqjrhbmt0q1yLoYe3IZJR7jbx1YUuMDlop46ADOxUOGhGCM DlK0zZ67t4CyE+eqvLV5PRoMnziHzZHFoO+U/XROmVPf93sOKYhSq13Jvn6MLfq0 ZNnD8AD+1sSO3FsjV135wpF8Kpm8E5PCh4jZGHmDBlhmXEa0LuKc8KXVzgLy3B+Y 1iKzYrhMLqd2tGBOVelyoHFSiPv8gf4K7AHJT7lw/H14MA/a4ZxgJHLk0eZqN+63 IKx/M5X5VMqW6H1HdlSozIjzHVcYEa4uMn7EFNyzsnUOv2OdcfgNgr/kMQoFCwLO 2IVxn0f0rt5x/5x7PRE5pGIx2ALqa2l1xKaJxUCHU6w5c38/KWphLNsePfMmpkVM EPtad/aKRz0IblIFlsvPMmJMDKLZjwGfJkb9y1PrxDyMduGTKomZH+yq/fmaXUxO f3VckfrzRHf3mhqNU2DdGk2aBrnPKbCCdCEiZf5UgypqONWftS55s3PR3xDuPUGG rlyrRaBzidTkhT1JyieV =xJmH -----END PGP SIGNATURE----- From prvs=0372a90b52=KBergsbaken@UNIVISION.NET Wed Jan 25 20:07:45 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4203221F85F6 for ; Wed, 25 Jan 2012 20:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.661 X-Spam-Level: ** X-Spam-Status: No, score=2.661 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_FUCK1=2.534, FRT_FUCK2=3.434, GB_I_INVITATION=-2, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4r9nK7Ch5071 for ; Wed, 25 Jan 2012 20:07:42 -0800 (PST) Received: from nmail.univision.net (nmail.univision.net [216.156.154.24]) by ietfa.amsl.com (Postfix) with ESMTP id B0FDD21F85EE for ; Wed, 25 Jan 2012 20:07:42 -0800 (PST) From: Kurt Bergsbaken CC: "'vipr@ietf.org'" Date: Wed, 25 Jan 2012 23:07:38 -0500 Thread-Topic: [VIPR] VIPR privacy issue Thread-Index: AczbkWOoS+Z8I9JqQI2clOK68kFwuQATqcdh Message-ID: <379B85522FA3D542813DF7D02EC8DF99576ED41A9D@mia-exmbx02> In-Reply-To: <4F2041DF.4090304@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: 355ae39f-542b-4f28-a0b5-1f4463b74c90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: none Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 04:07:45 -0000 I. would appreciate an invite to this design call, if possible. Thanks= . Kurt Bergsbaken | Architect -SIP Voice Services | Univision Communications = Inc. | 8550 NW 33rd Street, Miami, FL 33122 Direct: (305) 463-5745 | Fax: (786) 515-9229 | kbergsbaken@univision.net | = www.univision.com ----- Original Message ----- From: Marc Petit-Huguenin [mailto:petithug@acm.org] Sent: Wednesday, January 25, 2012 12:54 PM To: Kevin P. Fleming Cc: vipr@ietf.org Subject: Re: [VIPR] VIPR privacy issue -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/24/2012 02:20 PM, Kevin P. Fleming wrote: > On 01/24/2012 02:53 PM, Marc Petit-Huguenin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> Michael Procter explained on the last VIPR design team weekly conference >> call a privacy attack that I think is devastating. The end result is >> simple to explain: VIPR turns the Internet into a "trap and trace >> device"[1], allowing anybody to record the phone numbers called by any >> entities using VIPR, and this for a relatively low cost. >> >> Let's say that VIPR is well deployed in US enterprises and that a spying >> group is willing to spend the money to know about the phone calls made b= y >> these enterprises. This spying group just have to add enough VIPR >> servers to the RELOAD overlay to register all the phone numbers in the >> USA. Because all registrations are considered equally untrusted, they >> will all be verified by establishing a TCP connection between the VIPR >> server of the source of the call and the VIPR server that stored the >> registration for a particular phone number. There is multiple pieces of >> information that are leaked but it is easy for example to find the >> enterprise that is originating the TCP connection by looking at the >> source address and to enter it in whois. >> >> As Michael pointed out, you have to be on VIPR to protect your privacy, >> i.e destination numbers that are *not* using VIPR are especially at risk= . >> If the destination number is using VIPR, the TCP connection used to >> verify the first call from any enterprise has a lower probability to be >> directed to the spying group, because the real owner of the number may b= e >> tried first and prevent other registrations to be tried if successful. >> And as soon the real owner sends a SIP route and ticket back, the spying >> group will no longer receive any information about the calls between thi= s >> enterprise and this destination number, excepted for the periodic renewa= l >> of the ticket. >> >> Note that the information leaked go deeper than just the verification >> connection. Here's the various places where privacy information leakage >> happens with this attack: >> >> - - If the spying group uses a different VServiceId for each registered >> phone number, the called number is always leaked. - - The called number >> is also leaked for methods A and B. - - For method "A", the Caller-ID is >> leaked (the bcrypt hash is hard to crack, but it is not impossible). - - >> For method "B", a random time in the middle of the call is leaked. - - >> For method "C", the rounded start and stop time of the call are leaked. = - >> - The source IP address of the TCP connection for the PVP transaction is >> always leaked. - - The addr_port in the AppAttachReq RELOAD message that >> was used to establish the TCP connection is leaked. - - The certificate >> of the signer of the AppAttachReq RELOAD message is leaked. Even if the >> certificate does not contain information about the sender (subject, >> subjectAltName), it always contains the Node-ID, which can always be >> resolved to an IP address by using an Attach request. - - The Node-ID is >> leaked a second time in the via_list of the AppAttachReq message, unless >> an intermediary RELOAD peer replaced it with a compressed ID. >> >> There is probably ways to fix all of these leakages, and I found >> solutions for most of them, but they make RELOAD and VIPR much, much mor= e >> complex, to the point that I am starting to think that RELOAD itself is >> not up to the task. Using TURN to anonymize, as I proposed, does not wor= k >> because of the multiple places where data is leaked and fixing RELOAD >> itself, which will require among other things adding something like onio= n >> routing, will probably take years[2]. >> >> At a minimum, we will need to add a strong requirement about required >> anonymization in -overview, but it is clear to me that the >> standardization of VIPR will take a much longer time than expected. > > A very similar point was raised during the last in-person VIPR meeting th= at > I attended (two IETFs ago, I think). I commented that we had personal > experience with this problem in the Asterisk world, years ago when we had= a > public DUNDi cloud for routing E.164-numbered traffic. It is one of the > primary reasons that many of us (I was not with Digium at the time) stopp= ed > using that cloud. > > I'm certain that as you say, these problems are not intractable, but > providing solutions for them may very well make VIPR (and similar > mechanisms) so complex to implement and deploy that nobody will choose to > do so. > Perhaps, but my current concern is not complexity. VIPR is highly dependen= t on RELOAD, and half of the leakages come from RELOAD itself. We have a goo= d design team in VIPR and we - slowly but steadily - find consensus on a lot = of of the issues that are pure VIPR. But on the RELOAD side, no amount of ene= rgy spent seems to help accelerate things. I even considered forking the RELOA= D spec to have at least a decent subset that VIPR can use and adapt to its needs, but it's probably not legal, and anyway prevent reusing standard implementations of RELOAD for VIPR. So our options as I see them: - - Stop the work on VIPR until RELOAD reaches a point it is usable. - - Forget RELOAD and replace it with another mechanism. - - Close VIPR. We will probably spend the whole of our conference call next Friday on this subject (everybody is welcome to join, just send an email to the chairs and= I, and I will send back an invitation). Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPIEHdAAoJECnERZXWan7EJhAP/AiDXuH63mMvgES+qd/Jgl5Y Z94tyL05aYvsuFT8QjOVPI1aSyQ8Ngv3HvGrMLZhWEEPuv7eWGUmu9WBpZtuWJ5z a3gRZTfxeqH1qCS95+fBfbK77FjyQFBi9oaca1v/RugF7Vs2Xo/0Lb3HfD/vNGiL OO0H0sOBqtUKXPq0eJqjrhbmt0q1yLoYe3IZJR7jbx1YUuMDlop46ADOxUOGhGCM DlK0zZ67t4CyE+eqvLV5PRoMnziHzZHFoO+U/XROmVPf93sOKYhSq13Jvn6MLfq0 ZNnD8AD+1sSO3FsjV135wpF8Kpm8E5PCh4jZGHmDBlhmXEa0LuKc8KXVzgLy3B+Y 1iKzYrhMLqd2tGBOVelyoHFSiPv8gf4K7AHJT7lw/H14MA/a4ZxgJHLk0eZqN+63 IKx/M5X5VMqW6H1HdlSozIjzHVcYEa4uMn7EFNyzsnUOv2OdcfgNgr/kMQoFCwLO 2IVxn0f0rt5x/5x7PRE5pGIx2ALqa2l1xKaJxUCHU6w5c38/KWphLNsePfMmpkVM EPtad/aKRz0IblIFlsvPMmJMDKLZjwGfJkb9y1PrxDyMduGTKomZH+yq/fmaXUxO f3VckfrzRHf3mhqNU2DdGk2aBrnPKbCCdCEiZf5UgypqONWftS55s3PR3xDuPUGG rlyrRaBzidTkhT1JyieV =3DxJmH -----END PGP SIGNATURE----- _______________________________________________ VIPR mailing list VIPR@ietf.org https://www.ietf.org/mailman/listinfo/vipr The information contained in this e-mail and any attached documents may be privileged, confidential and protected from disclosure. If you are not the intended recipient you may not read, copy, distribute or use this information. If you have received this communication in error, please notify the sender immediately by replying to this message and then delete it from your system. From petithug@acm.org Thu Jan 26 07:04:04 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816DD21F852E for ; Thu, 26 Jan 2012 07:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.757 X-Spam-Level: X-Spam-Status: No, score=-100.757 tagged_above=-999 required=5 tests=[AWL=-1.157, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_SUMOF=5, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roEWHpoBHTTV for ; Thu, 26 Jan 2012 07:04:03 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 7893D21F84B6 for ; Thu, 26 Jan 2012 07:04:03 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id C65B5202D2 for ; Thu, 26 Jan 2012 14:49:43 +0000 (UTC) Message-ID: <4F216B60.1030205@acm.org> Date: Thu, 26 Jan 2012 07:04:00 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Agenda & Handout for 2012/01/26 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 15:04:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 A. Agenda - - Privacy issue Note that the sum of the time allocated to each topic may exceeds the time allocated to the whole call. The topics that cannot make it to the discussion will be postponed to the next conference call if they are not subsequently decided in the mailing-list. Because the conference bridge as a limited capacity, an individual invitation to the conference will be sent shortly after this email to each member of the design team. Please send me an email if you are not on this list and want to receive an invitation. Note that the design team conference call is not a way to short-circuit the normal process, but a way to accelerate it by increasing face to face time. All decisions made must be confirmed on the mailing-list. This conference call is subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). B. Handout (reading time: 5 min) Michael Procter explained on the last VIPR design team weekly conference call a privacy attack that is a great source of concern. The end result is simple to explain: VIPR turns the Internet into a "trap and trace device", allowing anybody to record the phone numbers called by any entities using VIPR, and this for a relatively low cost. Let's say that VIPR is well deployed in US enterprises and that a spying group is willing to spend the money to know about the phone calls made by these enterprises. This spying group just have to add enough VIPR servers to the RELOAD overlay to register all the phone numbers in the USA. Because all registrations are considered equally untrusted, they will all be verified by establishing a TCP connection between the VIPR server of the source of the call and the VIPR server that stored the registration for a particular phone number. There is multiple pieces of information that are leaked but it is easy to find the enterprise that is originating the TCP connection by looking at the source address and to enter it in whois. As Michael pointed out, you have to be on VIPR to protect your privacy, i.e destination numbers that are *not* using VIPR are especially at risk. If the destination number is using VIPR, the TCP connection used to verify the first call from any enterprise has a lower probability to be directed to the spying group, because the real owner of the number may be tried first and prevent other registrations to be tried if successful. And as soon the real owner sends a SIP route and ticket back, the spying group will no longer receive any information about the calls between this enterprise and this destination number, excepted for the periodic renewal of the ticket. Note that the information leaked go deeper than just the verification connection. Here's the various places where privacy information leakage happens with this attack: - - If the spying group uses a different VServiceId for each registered phone number, the called number is always leaked. - - The called number is also leaked for methods A and B. - - For method "A", the Caller-ID is leaked (the bcrypt hash is hard to crack, but it is not impossible). - - For method "B", a random time in the middle of the call is leaked. - - For method "C", the rounded start and stop time of the call are leaked. - - The source IP address of the TCP connection for the PVP transaction is always leaked. - - The addr_port in the AppAttachReq RELOAD message that was used to establish the TCP connection is leaked. - - The certificate of the signer of the AppAttachReq RELOAD message is leaked. Even if the certificate does not contain information about the sender (subject, subjectAltName), it always contains the Node-ID, which can always be resolved to an IP address by using an Attach request. - - The Node-ID is leaked a second time in the via_list of the AppAttachReq message, unless an intermediary RELOAD peer replaced it with an opaque ID. There is ways to fix all of these leakages, but they make RELOAD and VIPR much, much more complex. Using TURN to anonymize, as I proposed, does not work because of the multiple places where data is leaked and fixing RELOAD itself will require among other things adding something like onion routing and a way to use anonymous end to end authentication. The added complexity of having to anonymize the PVP connection can be reduced by running PVP directly on top of the anonymized RELOAD messages, but that require to define SRP-DTLS and then the various RELOAD messages to do this, and so on. But complexity is not the only concern. We made slow and steady progress in finding consensus on issues that are pure VIPR, but on the RELOAD side no amount of energy spent seems to help accelerate things. Forking the RELOAD spec to have at least a decent subset that VIPR can use and adapt to its needs is probably not legal, and anyway would prevent reusing standard implementations of RELOAD for the purpose of running VIPR. So our options as I see them are: - - Stop the work on VIPR until RELOAD reaches a point it is usable. - - Forget RELOAD and replace it with another mechanism. - - Close VIPR. At a minimum, we will need to add a strong requirement about required anonymization in -overview, but it is clear to me that the standardization of VIPR will take a much longer time than expected. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPIWtbAAoJECnERZXWan7EEqIP/iokdkMLw/eDa7UUwLbspgxA mOYo+pWJSKq5R6bsvuRnOSbtaQfReJfsCLzEg1n8D+8gV6/VWNfH8Mq5jTvxq2JJ /sa2isWm0IPr8rjfQAGvIJnyjpdVt50UOxJARPh/WVd6r4yvIpF3E/TqAn8lxsLU 1FIuS/1ncz2pLfPXMHwjJ+s8FNK1NUukAWJp89pfgnkGbt/hIDJTeVagSzn3gadH SrZzS9ftlKgKQvLLj/nsM95pajCmt/q2eN2CW1Hj2Ddy676jVsxuFAnLTID3oWMX cJ/zAiHWvJ5ZC3rlj303XKAVCuHJ9xB0pR+M9b9Zm8oRYfD/xWj2cFmnFsm9jSbV 6IGL7F/iVIVSxkBYyKZSMRDtHWWrF53GGgogNGYfolSFHti1IHRxxpaflDBoJmK5 zBDLPxSEbPWpoBjGl8UtrH204atfzi/PxGGhmun8ySKu9TVp7TWGNbLkwEH26edq bWHVF6WvX+lMTfX1PUuAEcvvZ+GJzMPzSXWKnnFEGLeu+zbRAv1Pkd9DlawvnEnT pWiyUsft8J0U1nfLV4jMVI1I2qLPRPdpjp8NmBG+Gspx3cZHnZaNHN6lobCeCpwo 8qLJm/WhX7SPezRiCWq+akN8VmD08SQdBwgp0Mh6fn56gi5/ZXIN5MPFxja8R6dJ ZdHESv/bzJsC00dSuGeg =Xd+4 -----END PGP SIGNATURE----- From petithug@acm.org Thu Jan 26 07:15:14 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E48421F85DF for ; Thu, 26 Jan 2012 07:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.714 X-Spam-Level: X-Spam-Status: No, score=-100.714 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_SUMOF=5, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FxfZlEJPUSc for ; Thu, 26 Jan 2012 07:15:13 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0AF21F8593 for ; Thu, 26 Jan 2012 07:15:13 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 4F828202D2 for ; Thu, 26 Jan 2012 15:00:54 +0000 (UTC) Message-ID: <4F216DF8.9000302@acm.org> Date: Thu, 26 Jan 2012 07:15:04 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Agenda & Handout for 2012/01/27 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 15:15:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 A. Agenda - - Privacy issue Note that the sum of the time allocated to each topic may exceeds the time allocated to the whole call. The topics that cannot make it to the discussion will be postponed to the next conference call if they are not subsequently decided in the mailing-list. Because the conference bridge as a limited capacity, an individual invitation to the conference will be sent shortly after this email to each member of the design team. Please send me an email if you are not on this list and want to receive an invitation. Note that the design team conference call is not a way to short-circuit the normal process, but a way to accelerate it by increasing face to face time. All decisions made must be confirmed on the mailing-list. This conference call is subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). B. Handout (reading time: 5 min) Michael Procter explained on the last VIPR design team weekly conference call a privacy attack that is a great source of concern. The end result is simple to explain: VIPR turns the Internet into a "trap and trace device", allowing anybody to record the phone numbers called by any entities using VIPR, and this for a relatively low cost. Let's say that VIPR is well deployed in US enterprises and that a spying group is willing to spend the money to know about the phone calls made by these enterprises. This spying group just have to add enough VIPR servers to the RELOAD overlay to register all the phone numbers in the USA. Because all registrations are considered equally untrusted, they will all be verified by establishing a TCP connection between the VIPR server of the source of the call and the VIPR server that stored the registration for a particular phone number. There is multiple pieces of information that are leaked but it is easy to find the enterprise that is originating the TCP connection by looking at the source address and to enter it in whois. As Michael pointed out, you have to be on VIPR to protect your privacy, i.e destination numbers that are *not* using VIPR are especially at risk. If the destination number is using VIPR, the TCP connection used to verify the first call from any enterprise has a lower probability to be directed to the spying group, because the real owner of the number may be tried first and prevent other registrations to be tried if successful. And as soon the real owner sends a SIP route and ticket back, the spying group will no longer receive any information about the calls between this enterprise and this destination number, excepted for the periodic renewal of the ticket. Note that the information leaked go deeper than just the verification connection. Here's the various places where privacy information leakage happens with this attack: - - If the spying group uses a different VServiceId for each registered phone number, the called number is always leaked. - - The called number is also leaked for methods A and B. - - For method "A", the Caller-ID is leaked (the bcrypt hash is hard to crack, but it is not impossible). - - For method "B", a random time in the middle of the call is leaked. - - For method "C", the rounded start and stop time of the call are leaked. - - The source IP address of the TCP connection for the PVP transaction is always leaked. - - The addr_port in the AppAttachReq RELOAD message that was used to establish the TCP connection is leaked. - - The certificate of the signer of the AppAttachReq RELOAD message is leaked. Even if the certificate does not contain information about the sender (subject, subjectAltName), it always contains the Node-ID, which can always be resolved to an IP address by using an Attach request. - - The Node-ID is leaked a second time in the via_list of the AppAttachReq message, unless an intermediary RELOAD peer replaced it with an opaque ID. There is ways to fix all of these leakages, but they make RELOAD and VIPR much, much more complex. Using TURN to anonymize, as I proposed, does not work because of the multiple places where data is leaked and fixing RELOAD itself will require among other things adding something like onion routing and a way to use anonymous end to end authentication. The added complexity of having to anonymize the PVP connection can be reduced by running PVP directly on top of the anonymized RELOAD messages, but that require to define SRP-DTLS and then the various RELOAD messages to do this, and so on. But complexity is not the only concern. We made slow and steady progress in finding consensus on issues that are pure VIPR, but on the RELOAD side no amount of energy spent seems to help accelerate things. Forking the RELOAD spec to have at least a decent subset that VIPR can use and adapt to its needs is probably not legal, and anyway would prevent reusing standard implementations of RELOAD for the purpose of running VIPR. So our options as I see them are: - - Stop the work on VIPR until RELOAD reaches a point it is usable. - - Forget RELOAD and replace it with another mechanism. - - Close VIPR. At a minimum, we will need to add a strong requirement about required anonymization in -overview, but it is clear to me that the standardization of VIPR will take a much longer time than expected. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPIW32AAoJECnERZXWan7EYRsP/itjvW9KrpCDzEGlkmucaKZa JXWlkyWXVRoARN9AS1S5yitepu68k5+CCa8F17h87tKZLeZdm5+SxxXRQ3wtu0a8 rgO6vI5fsFovTcUJ665Q1O2Mz2viM3Q5d8ltMtJ02P48CAy9AfuBrNjM03T+JQco DTCDVr0OVnxuAr/zo/VE43od2a2TXLgvI8DfDQTnPtYz5yUQ9qMy/30TNg4Sj37g j3fcptworD85lLcWgE3CUjRMTUNvfgQmH1FWPd7yGC8SngeNQmgUOGoteJ3dnmjh BwdnmuD1FF0cj5AqKCeGYo0G2MtFHXgdVGHzRiWgxBQMCVW6E2ElWs2Z312WGc8F pcxyB/n0/U9iJfSmBPdNpNog2d1dYpr9PK2yGuVw8PnEjcDJ1PV+CPfyuXlKDg/U nG+xOqV0lM561vsqYSwol9mSTqro6dWAbQmR//K6ICwmro8pIqVeGYcYUIKapumU 6NMCnnEvMI3rSAUE51Op/NSEu3J5HAXc/+Du6G4JOtLtzpufP9OhhSgkBFqrdqHT C3Unpg2rJD3csmZmM4rH5xz4D5Jy/W0VCTrLOyEnDdXfbDrfg4CsZpxD3HHk7h8p rabTfs3e9DymJkJn9flwXrVZKkIGB1G1B+2KcEOpRVLYhGF3mFBbcEmSQfyaS0KO 1lDVjEkuKOMhtc9mpyQr =toLk -----END PGP SIGNATURE----- From rbarnes@bbn.com Thu Jan 26 08:01:34 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7EC21F860F for ; Thu, 26 Jan 2012 08:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.115 X-Spam-Level: X-Spam-Status: No, score=-106.115 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPk8j-Jprpsu for ; Thu, 26 Jan 2012 08:01:33 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 29A3D21F85A7 for ; Thu, 26 Jan 2012 08:01:33 -0800 (PST) Received: from ros-dhcp192-1-51-95.bbn.com ([192.1.51.95]:59470) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RqRlS-000EwI-GP; Thu, 26 Jan 2012 11:01:30 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4F1F1A42.1030201@acm.org> Date: Thu, 26 Jan 2012 11:01:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> References: <4F1F1A42.1030201@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: "vipr@ietf.org" Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 16:01:34 -0000 Let's not get hysterical here. These issues are inherent to any system = for resolving identifiers. My local DNS resolver has a very good idea = of things like what websites I'm visiting (A google.com) and what = services I'm using (SRV _xmpp-server._tcp.jabber.org). =20 Analogous mitigations apply, e.g.: =20 * For masking sources of requests, use indirection. In the DNS = context, authoritative servers don't see my IP address because I go = through a local resolver. In the VIPR context, you could have an = outsourced RELOAD agent acquire tickets on behalf of clients who trust = it to handle call information. * For masking destinations of requests, use multiple requests. In the = DNS context, request names/RRtypes other than the one you're looking = for. In the VIPR context, look for numbers you didn't dial, or look for = numbers when you haven't dialled anyone. =20 Note that in both cases, the mitigations are about how you use the = protocol, not the protocol itself. So while it might be worthwhile to = write up a privacy considerations document, it doesn't seem like we need = to change the protocol documents to deal with these threats. --Richard On Jan 24, 2012, at 3:53 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Michael Procter explained on the last VIPR design team weekly = conference call > a privacy attack that I think is devastating. The end result is = simple to > explain: VIPR turns the Internet into a "trap and trace device"[1], = allowing > anybody to record the phone numbers called by any entities using VIPR, = and > this for a relatively low cost. >=20 > Let's say that VIPR is well deployed in US enterprises and that a = spying group > is willing to spend the money to know about the phone calls made by = these > enterprises. This spying group just have to add enough VIPR servers = to the > RELOAD overlay to register all the phone numbers in the USA. Because = all > registrations are considered equally untrusted, they will all be = verified by > establishing a TCP connection between the VIPR server of the source of = the > call and the VIPR server that stored the registration for a particular = phone > number. There is multiple pieces of information that are leaked but = it is > easy for example to find the enterprise that is originating the TCP = connection > by looking at the source address and to enter it in whois. >=20 > As Michael pointed out, you have to be on VIPR to protect your = privacy, i.e > destination numbers that are *not* using VIPR are especially at risk. = If the > destination number is using VIPR, the TCP connection used to verify = the first > call from any enterprise has a lower probability to be directed to the = spying > group, because the real owner of the number may be tried first and = prevent > other registrations to be tried if successful. And as soon the real = owner > sends a SIP route and ticket back, the spying group will no longer = receive any > information about the calls between this enterprise and this = destination > number, excepted for the periodic renewal of the ticket. >=20 > Note that the information leaked go deeper than just the verification > connection. Here's the various places where privacy information = leakage > happens with this attack: >=20 > - - If the spying group uses a different VServiceId for each = registered phone > number, the called number is always leaked. > - - The called number is also leaked for methods A and B. > - - For method "A", the Caller-ID is leaked (the bcrypt hash is hard = to crack, > but it is not impossible). > - - For method "B", a random time in the middle of the call is leaked. > - - For method "C", the rounded start and stop time of the call are = leaked. > - - The source IP address of the TCP connection for the PVP = transaction is > always leaked. > - - The addr_port in the AppAttachReq RELOAD message that was used to = establish > the TCP connection is leaked. > - - The certificate of the signer of the AppAttachReq RELOAD message = is leaked. > Even if the certificate does not contain information about the sender > (subject, subjectAltName), it always contains the Node-ID, which can = always be > resolved to an IP address by using an Attach request. > - - The Node-ID is leaked a second time in the via_list of the = AppAttachReq > message, unless an intermediary RELOAD peer replaced it with a = compressed ID. >=20 > There is probably ways to fix all of these leakages, and I found = solutions for > most of them, but they make RELOAD and VIPR much, much more complex, = to the > point that I am starting to think that RELOAD itself is not up to the = task. > Using TURN to anonymize, as I proposed, does not work because of the = multiple > places where data is leaked and fixing RELOAD itself, which will = require among > other things adding something like onion routing, will probably take = years[2]. >=20 > At a minimum, we will need to add a strong requirement about required > anonymization in -overview, but it is clear to me that the = standardization of > VIPR will take a much longer time than expected. >=20 >=20 > [1] http://en.wikipedia.org/wiki/Trap_and_trace_device > [2] http://www.ietf.org/mail-archive/web/p2psip/current/msg06166.html >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iQIcBAEBCAAGBQJPHxo6AAoJECnERZXWan7EV0kQALf+0G+bdOj4t3GiNSk1rjKC > 7Zbnz4cqiJrmmJl3PjISQy8t+yXEngEO2vmM9ewkb9i4tZV0fV+UNv4Wpxfs2XF1 > p/VRZ8gKAGiNfSgY2aGXDtErEaV33Rkuh+iQUVd+FsYTc2lSUDPnRFXD9dfO4GuK > FIJKnf3Wm9yK37zN8X+kS9ynrEzTXDKD1V1kfW8JgEne6KkL7wwhH/NWAXKbT3F+ > o0RsWbM2Kft9aCmzRtBSgzNRiVb1G6asD8LaETXImEPhP0ScySnul7sqeXg4un5o > ipVwjiAuKy6sPsOJoXD26fePzMbymrtKL6R3Lv/YM9W9ae3cQo3JrjShEwYhVETY > c0leYotFBSDELu3jv2sqfF1ij9I+XXD9gUT8eOd/XV/xBKvvEr06xQ9tc7E72e1C > hEpINusiMYNW1nWvL7WvJNbQU4KaojyF6I2uGLQss8UKBYvYBU4+oIkg6F0bF3GA > c5yxdEVOg1Tkn88yiUI4O3pOS1yuscsUBlduOKQsNvKZQWd6Y1eikODU44Ea2hRr > JlsQz5Azh7PY07a6dD7VmdS36wA0N+JbPpL6pvgf0r5tfxoWAcfoyZ2gtgEsFf6Y > CLaySla7kUaVVzjhe9tsccG3FmdpnDS8wQjJ/47FI/hnCUfv02FOAHWzALRNZgfF > nTxixgP8OeOKecgd8ll8 > =3DLV2v > -----END PGP SIGNATURE----- > _______________________________________________ > VIPR mailing list > VIPR@ietf.org > https://www.ietf.org/mailman/listinfo/vipr From petithug@acm.org Thu Jan 26 08:18:22 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64A521F8690 for ; Thu, 26 Jan 2012 08:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfU-bEuc55iy for ; Thu, 26 Jan 2012 08:18:21 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 7350B21F868C for ; Thu, 26 Jan 2012 08:18:21 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id CC52B202D2; Thu, 26 Jan 2012 16:04:01 +0000 (UTC) Message-ID: <4F217CC9.4080802@acm.org> Date: Thu, 26 Jan 2012 08:18:17 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> In-Reply-To: <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 16:18:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/26/2012 08:01 AM, Richard L. Barnes wrote: > Let's not get hysterical here. These issues are inherent to any system > for resolving identifiers. My local DNS resolver has a very good idea of > things like what websites I'm visiting (A google.com) and what services I'm > using (SRV _xmpp-server._tcp.jabber.org). Yes, but this is not the problem here. AFAIK, it is not possible for anybody to add its own DNS server as nameserver of google.com and receive all the requests sent to this domain and collect the source IP addresses. *That* would be the DNS equivalent of the privacy leak of VIPR. > > Analogous mitigations apply, e.g.: > > * For masking sources of requests, use indirection. In the DNS context, > authoritative servers don't see my IP address because I go through a local > resolver. In the VIPR context, you could have an outsourced RELOAD agent > acquire tickets on behalf of clients who trust it to handle call > information. > > * For masking destinations of requests, use multiple requests. In the DNS > context, request names/RRtypes other than the one you're looking for. In > the VIPR context, look for numbers you didn't dial, or look for numbers > when you haven't dialled anyone. > > Note that in both cases, the mitigations are about how you use the > protocol, not the protocol itself. So while it might be worthwhile to > write up a privacy considerations document, it doesn't seem like we need to > change the protocol documents to deal with these threats. The concern is not how to fix the problem, but that half of the problem comes from a protocol (RELOAD) that is not under our control, and so will take years to bring to a point where we can fix this problem. > > --Richard > > > On Jan 24, 2012, at 3:53 PM, Marc Petit-Huguenin wrote: > > Michael Procter explained on the last VIPR design team weekly conference > call a privacy attack that I think is devastating. The end result is > simple to explain: VIPR turns the Internet into a "trap and trace > device"[1], allowing anybody to record the phone numbers called by any > entities using VIPR, and this for a relatively low cost. > > Let's say that VIPR is well deployed in US enterprises and that a spying > group is willing to spend the money to know about the phone calls made by > these enterprises. This spying group just have to add enough VIPR servers > to the RELOAD overlay to register all the phone numbers in the USA. > Because all registrations are considered equally untrusted, they will all > be verified by establishing a TCP connection between the VIPR server of the > source of the call and the VIPR server that stored the registration for a > particular phone number. There is multiple pieces of information that are > leaked but it is easy for example to find the enterprise that is > originating the TCP connection by looking at the source address and to > enter it in whois. > > As Michael pointed out, you have to be on VIPR to protect your privacy, i.e > destination numbers that are *not* using VIPR are especially at risk. If > the destination number is using VIPR, the TCP connection used to verify > the first call from any enterprise has a lower probability to be directed > to the spying group, because the real owner of the number may be tried > first and prevent other registrations to be tried if successful. And as > soon the real owner sends a SIP route and ticket back, the spying group > will no longer receive any information about the calls between this > enterprise and this destination number, excepted for the periodic renewal > of the ticket. > > Note that the information leaked go deeper than just the verification > connection. Here's the various places where privacy information leakage > happens with this attack: > > - If the spying group uses a different VServiceId for each registered phone > number, the called number is always leaked. - The called number is also > leaked for methods A and B. - For method "A", the Caller-ID is leaked (the > bcrypt hash is hard to crack, but it is not impossible). - For method "B", > a random time in the middle of the call is leaked. - For method "C", the > rounded start and stop time of the call are leaked. - The source IP > address of the TCP connection for the PVP transaction is always leaked. - > The addr_port in the AppAttachReq RELOAD message that was used to establish > the TCP connection is leaked. - The certificate of the signer of the > AppAttachReq RELOAD message is leaked. Even if the certificate does not > contain information about the sender (subject, subjectAltName), it always > contains the Node-ID, which can always be resolved to an IP address by > using an Attach request. - The Node-ID is leaked a second time in the > via_list of the AppAttachReq message, unless an intermediary RELOAD peer > replaced it with a compressed ID. > > There is probably ways to fix all of these leakages, and I found solutions > for most of them, but they make RELOAD and VIPR much, much more complex, > to the point that I am starting to think that RELOAD itself is not up to > the task. Using TURN to anonymize, as I proposed, does not work because of > the multiple places where data is leaked and fixing RELOAD itself, which > will require among other things adding something like onion routing, will > probably take years[2]. > > At a minimum, we will need to add a strong requirement about required > anonymization in -overview, but it is clear to me that the standardization > of VIPR will take a much longer time than expected. > > > [1] http://en.wikipedia.org/wiki/Trap_and_trace_device [2] > http://www.ietf.org/mail-archive/web/p2psip/current/msg06166.html > >> _______________________________________________ VIPR mailing list >> VIPR@ietf.org https://www.ietf.org/mailman/listinfo/vipr > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPIXzHAAoJECnERZXWan7EiA0QAOKtZJVXEwoGO9Jb0ZO7xVoO 1jbFj5DsMU2ECPO6kgApZYE90LMAlLdqOV7E5ke+ovLy5GUuLSQwfOiMOCnbTJWP 9nGbHgv0n1ro5FpBLvHKhyBGBFTYcnxFz5fdDVEjMBnJxHIzMfE7GU53G5195SP5 mx0SstXRD5Ha3ckp/9sMpSrIhZ2OYOghH/XGvjrjqgDOIuB7ws4WqR9UewDrgTzI PGDFpliRY1URnFln/a+0jQwOPqm9ggLqQASnJuLdVA4IsuYsQYfxe7IdXFjj+6fZ ylEkekJNOqSYMgs0nprwUk94y7zCrzdBZOTRVSPWX872Wv5SKbA6hRA1lc8J0VFK VxY7xsIgm60W31u2deLvsBBpamvARC+6Y6wf9L+jcyvzoAr1klfqoh3Al0DxJkEa HFJmQbf8r28cWinXx/OhWr6ZdXTqAKcgv+9/M1AROacnH/cwd4Tqg08sI219D02d 1rRkj857OkEQN7iZcVWZI9B87s3K0zow72TCuXS/KXO5F0GZq8XuzVhGNzCvwPnB PghyKlbTzj2f3Xvpgq+T7lOh3gK93qd225zB0wqIeDR62f2ZXpODFdm+POMBoFME AYtHFiXH8Qim/dR5YJSGS9WJZgjljJX67z0K3i0vDqS/FxwCuPZCWOosZ/FgmpZk uZR/vHy1V1J/49djBaKc =jNuY -----END PGP SIGNATURE----- From rbarnes@bbn.com Thu Jan 26 08:40:21 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0161721F86C7 for ; Thu, 26 Jan 2012 08:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDoK7gVBDxWV for ; Thu, 26 Jan 2012 08:40:20 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D435121F86C6 for ; Thu, 26 Jan 2012 08:40:19 -0800 (PST) Received: from ros-dhcp192-1-51-95.bbn.com ([192.1.51.95]:59693) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RqSN1-000FSj-5f; Thu, 26 Jan 2012 11:40:19 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4F217CC9.4080802@acm.org> Date: Thu, 26 Jan 2012 11:40:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: "vipr@ietf.org" Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 16:40:21 -0000 > On 01/26/2012 08:01 AM, Richard L. Barnes wrote: >> Let's not get hysterical here. These issues are inherent to any = system >> for resolving identifiers. My local DNS resolver has a very good = idea of >> things like what websites I'm visiting (A google.com) and what = services I'm >> using (SRV _xmpp-server._tcp.jabber.org). >=20 > Yes, but this is not the problem here. AFAIK, it is not possible for = anybody > to add its own DNS server as nameserver of google.com and receive all = the > requests sent to this domain and collect the source IP addresses. = *That* > would be the DNS equivalent of the privacy leak of VIPR. True. Although in principle anyone could announce the anycast prefixes = used by the root nodes (in the absence of SIDR deployment), which would = get you lots of interesting traffic. =20 At the very least, however, your queries get forwarded to the DNS root = and intermediate name servers, which has been a problem before: = Like I said, the mitigation here is the same as any situation where you = want to hide your IP address: Send packets from a different network. --Richard >>=20 >> Analogous mitigations apply, e.g.: >>=20 >> * For masking sources of requests, use indirection. In the DNS = context,=20 >> authoritative servers don't see my IP address because I go through a = local=20 >> resolver. In the VIPR context, you could have an outsourced RELOAD = agent=20 >> acquire tickets on behalf of clients who trust it to handle call=20 >> information. >>=20 >> * For masking destinations of requests, use multiple requests. In = the DNS=20 >> context, request names/RRtypes other than the one you're looking for. = In >> the VIPR context, look for numbers you didn't dial, or look for = numbers >> when you haven't dialled anyone. >>=20 >> Note that in both cases, the mitigations are about how you use the >> protocol, not the protocol itself. So while it might be worthwhile = to >> write up a privacy considerations document, it doesn't seem like we = need to >> change the protocol documents to deal with these threats. >=20 > The concern is not how to fix the problem, but that half of the = problem comes > from a protocol (RELOAD) that is not under our control, and so will = take years > to bring to a point where we can fix this problem. >=20 >>=20 >> --Richard >>=20 >>=20 >> On Jan 24, 2012, at 3:53 PM, Marc Petit-Huguenin wrote: >>=20 >> Michael Procter explained on the last VIPR design team weekly = conference=20 >> call a privacy attack that I think is devastating. The end result is >> simple to explain: VIPR turns the Internet into a "trap and trace >> device"[1], allowing anybody to record the phone numbers called by = any >> entities using VIPR, and this for a relatively low cost. >>=20 >> Let's say that VIPR is well deployed in US enterprises and that a = spying=20 >> group is willing to spend the money to know about the phone calls = made by=20 >> these enterprises. This spying group just have to add enough VIPR = servers >> to the RELOAD overlay to register all the phone numbers in the USA. >> Because all registrations are considered equally untrusted, they will = all >> be verified by establishing a TCP connection between the VIPR server = of the >> source of the call and the VIPR server that stored the registration = for a >> particular phone number. There is multiple pieces of information = that are >> leaked but it is easy for example to find the enterprise that is >> originating the TCP connection by looking at the source address and = to >> enter it in whois. >>=20 >> As Michael pointed out, you have to be on VIPR to protect your = privacy, i.e >> destination numbers that are *not* using VIPR are especially at risk. = If=20 >> the destination number is using VIPR, the TCP connection used to = verify >> the first call from any enterprise has a lower probability to be = directed >> to the spying group, because the real owner of the number may be = tried >> first and prevent other registrations to be tried if successful. And = as >> soon the real owner sends a SIP route and ticket back, the spying = group >> will no longer receive any information about the calls between this >> enterprise and this destination number, excepted for the periodic = renewal >> of the ticket. >>=20 >> Note that the information leaked go deeper than just the verification=20= >> connection. Here's the various places where privacy information = leakage=20 >> happens with this attack: >>=20 >> - If the spying group uses a different VServiceId for each registered = phone >> number, the called number is always leaked. - The called number is = also=20 >> leaked for methods A and B. - For method "A", the Caller-ID is leaked = (the=20 >> bcrypt hash is hard to crack, but it is not impossible). - For method = "B", >> a random time in the middle of the call is leaked. - For method "C", = the=20 >> rounded start and stop time of the call are leaked. - The source IP >> address of the TCP connection for the PVP transaction is always = leaked. - >> The addr_port in the AppAttachReq RELOAD message that was used to = establish >> the TCP connection is leaked. - The certificate of the signer of the >> AppAttachReq RELOAD message is leaked. Even if the certificate does = not >> contain information about the sender (subject, subjectAltName), it = always >> contains the Node-ID, which can always be resolved to an IP address = by >> using an Attach request. - The Node-ID is leaked a second time in the >> via_list of the AppAttachReq message, unless an intermediary RELOAD = peer >> replaced it with a compressed ID. >>=20 >> There is probably ways to fix all of these leakages, and I found = solutions=20 >> for most of them, but they make RELOAD and VIPR much, much more = complex, >> to the point that I am starting to think that RELOAD itself is not up = to >> the task. Using TURN to anonymize, as I proposed, does not work = because of >> the multiple places where data is leaked and fixing RELOAD itself, = which >> will require among other things adding something like onion routing, = will >> probably take years[2]. >>=20 >> At a minimum, we will need to add a strong requirement about required=20= >> anonymization in -overview, but it is clear to me that the = standardization=20 >> of VIPR will take a much longer time than expected. >>=20 >>=20 >> [1] http://en.wikipedia.org/wiki/Trap_and_trace_device [2]=20 >> http://www.ietf.org/mail-archive/web/p2psip/current/msg06166.html >>=20 >>> _______________________________________________ VIPR mailing list=20 >>> VIPR@ietf.org https://www.ietf.org/mailman/listinfo/vipr >>=20 >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iQIcBAEBCAAGBQJPIXzHAAoJECnERZXWan7EiA0QAOKtZJVXEwoGO9Jb0ZO7xVoO > 1jbFj5DsMU2ECPO6kgApZYE90LMAlLdqOV7E5ke+ovLy5GUuLSQwfOiMOCnbTJWP > 9nGbHgv0n1ro5FpBLvHKhyBGBFTYcnxFz5fdDVEjMBnJxHIzMfE7GU53G5195SP5 > mx0SstXRD5Ha3ckp/9sMpSrIhZ2OYOghH/XGvjrjqgDOIuB7ws4WqR9UewDrgTzI > PGDFpliRY1URnFln/a+0jQwOPqm9ggLqQASnJuLdVA4IsuYsQYfxe7IdXFjj+6fZ > ylEkekJNOqSYMgs0nprwUk94y7zCrzdBZOTRVSPWX872Wv5SKbA6hRA1lc8J0VFK > VxY7xsIgm60W31u2deLvsBBpamvARC+6Y6wf9L+jcyvzoAr1klfqoh3Al0DxJkEa > HFJmQbf8r28cWinXx/OhWr6ZdXTqAKcgv+9/M1AROacnH/cwd4Tqg08sI219D02d > 1rRkj857OkEQN7iZcVWZI9B87s3K0zow72TCuXS/KXO5F0GZq8XuzVhGNzCvwPnB > PghyKlbTzj2f3Xvpgq+T7lOh3gK93qd225zB0wqIeDR62f2ZXpODFdm+POMBoFME > AYtHFiXH8Qim/dR5YJSGS9WJZgjljJX67z0K3i0vDqS/FxwCuPZCWOosZ/FgmpZk > uZR/vHy1V1J/49djBaKc > =3DjNuY > -----END PGP SIGNATURE----- From petithug@acm.org Thu Jan 26 08:48:20 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837F221F8617 for ; Thu, 26 Jan 2012 08:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.189 X-Spam-Level: X-Spam-Status: No, score=-102.189 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAEhqlS29GGh for ; Thu, 26 Jan 2012 08:48:19 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 018B021F8616 for ; Thu, 26 Jan 2012 08:48:19 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 7E638202D2; Thu, 26 Jan 2012 16:33:59 +0000 (UTC) Message-ID: <4F2183D0.3070809@acm.org> Date: Thu, 26 Jan 2012 08:48:16 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> In-Reply-To: <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 16:48:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/26/2012 08:40 AM, Richard L. Barnes wrote: >> On 01/26/2012 08:01 AM, Richard L. Barnes wrote: >>> Let's not get hysterical here. These issues are inherent to any >>> system for resolving identifiers. My local DNS resolver has a very >>> good idea of things like what websites I'm visiting (A google.com) and >>> what services I'm using (SRV _xmpp-server._tcp.jabber.org). >> >> Yes, but this is not the problem here. AFAIK, it is not possible for >> anybody to add its own DNS server as nameserver of google.com and receive >> all the requests sent to this domain and collect the source IP addresses. >> *That* would be the DNS equivalent of the privacy leak of VIPR. > > True. Although in principle anyone could announce the anycast prefixes > used by the root nodes (in the absence of SIDR deployment), which would get > you lots of interesting traffic. > > At the very least, however, your queries get forwarded to the DNS root and > intermediate name servers, which has been a problem before: > > > Like I said, the mitigation here is the same as any situation where you > want to hide your IP address: Send packets from a different network. Yes, and (I am not sure you saw the second part of my response below), this would not be a concern if we could fix RELOAD to do exactly that. > > --Richard > > > >>> >>> Analogous mitigations apply, e.g.: >>> >>> * For masking sources of requests, use indirection. In the DNS >>> context, authoritative servers don't see my IP address because I go >>> through a local resolver. In the VIPR context, you could have an >>> outsourced RELOAD agent acquire tickets on behalf of clients who trust >>> it to handle call information. >>> >>> * For masking destinations of requests, use multiple requests. In the >>> DNS context, request names/RRtypes other than the one you're looking >>> for. In the VIPR context, look for numbers you didn't dial, or look >>> for numbers when you haven't dialled anyone. >>> >>> Note that in both cases, the mitigations are about how you use the >>> protocol, not the protocol itself. So while it might be worthwhile to >>> write up a privacy considerations document, it doesn't seem like we >>> need to change the protocol documents to deal with these threats. >> >> The concern is not how to fix the problem, but that half of the problem >> comes from a protocol (RELOAD) that is not under our control, and so will >> take years to bring to a point where we can fix this problem. >> >>> >>> --Richard >>> >>> >>> On Jan 24, 2012, at 3:53 PM, Marc Petit-Huguenin wrote: >>> >>> Michael Procter explained on the last VIPR design team weekly >>> conference call a privacy attack that I think is devastating. The end >>> result is simple to explain: VIPR turns the Internet into a "trap and >>> trace device"[1], allowing anybody to record the phone numbers called >>> by any entities using VIPR, and this for a relatively low cost. >>> >>> Let's say that VIPR is well deployed in US enterprises and that a >>> spying group is willing to spend the money to know about the phone >>> calls made by these enterprises. This spying group just have to add >>> enough VIPR servers to the RELOAD overlay to register all the phone >>> numbers in the USA. Because all registrations are considered equally >>> untrusted, they will all be verified by establishing a TCP connection >>> between the VIPR server of the source of the call and the VIPR server >>> that stored the registration for a particular phone number. There is >>> multiple pieces of information that are leaked but it is easy for >>> example to find the enterprise that is originating the TCP connection >>> by looking at the source address and to enter it in whois. >>> >>> As Michael pointed out, you have to be on VIPR to protect your privacy, >>> i.e destination numbers that are *not* using VIPR are especially at >>> risk. If the destination number is using VIPR, the TCP connection used >>> to verify the first call from any enterprise has a lower probability to >>> be directed to the spying group, because the real owner of the number >>> may be tried first and prevent other registrations to be tried if >>> successful. And as soon the real owner sends a SIP route and ticket >>> back, the spying group will no longer receive any information about the >>> calls between this enterprise and this destination number, excepted for >>> the periodic renewal of the ticket. >>> >>> Note that the information leaked go deeper than just the verification >>> connection. Here's the various places where privacy information >>> leakage happens with this attack: >>> >>> - If the spying group uses a different VServiceId for each registered >>> phone number, the called number is always leaked. - The called number >>> is also leaked for methods A and B. - For method "A", the Caller-ID is >>> leaked (the bcrypt hash is hard to crack, but it is not impossible). - >>> For method "B", a random time in the middle of the call is leaked. - >>> For method "C", the rounded start and stop time of the call are leaked. >>> - The source IP address of the TCP connection for the PVP transaction >>> is always leaked. - The addr_port in the AppAttachReq RELOAD message >>> that was used to establish the TCP connection is leaked. - The >>> certificate of the signer of the AppAttachReq RELOAD message is leaked. >>> Even if the certificate does not contain information about the sender >>> (subject, subjectAltName), it always contains the Node-ID, which can >>> always be resolved to an IP address by using an Attach request. - The >>> Node-ID is leaked a second time in the via_list of the AppAttachReq >>> message, unless an intermediary RELOAD peer replaced it with a >>> compressed ID. >>> >>> There is probably ways to fix all of these leakages, and I found >>> solutions for most of them, but they make RELOAD and VIPR much, much >>> more complex, to the point that I am starting to think that RELOAD >>> itself is not up to the task. Using TURN to anonymize, as I proposed, >>> does not work because of the multiple places where data is leaked and >>> fixing RELOAD itself, which will require among other things adding >>> something like onion routing, will probably take years[2]. >>> >>> At a minimum, we will need to add a strong requirement about required >>> anonymization in -overview, but it is clear to me that the >>> standardization of VIPR will take a much longer time than expected. >>> >>> >>> [1] http://en.wikipedia.org/wiki/Trap_and_trace_device [2] >>> http://www.ietf.org/mail-archive/web/p2psip/current/msg06166.html >>> - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPIYPOAAoJECnERZXWan7Er+QP/iqC1BvcJkFilL5tJaQpXEMp Nc6eWH6cEKUpL4Q6gBRhYk7CD0k3CFmNTGEblhjKhZAsLILicdUIUeAsXN8JFFdD Bxf2D99R2t24qrMwBzmOhRUNoV3JryNDOH0S5qFbCZ564WKPdfLrrPRdYfedTBXo H7sm7THDrSNuNLUDejLtRmpLG4CENjSOJe4RMnUkgMb2ikG3OfpRPp3VexKE9prN HO6sJ0IBWtdGt/p0K8CE4xsG2Kg3CYz4v65A7YefQ/6YKy4nk4rfW6fBEchEqApL xRRsoxvSOzNXDHRZqOZiQbrP1qxupAIU43ladvf7Hx4Y9c22uxkw5818o4EJJ0pZ XD03Aml4gCVzl5Mg/X8/4D9oR9GFieeKjXvKO/Y/5LHSC7l/hCVkz/f+2jiSqvtd BfOz9xfxBqIhU3l0x29euur6nO2k0LMYIaulDgp4Rmd1UAY6JqtFoloCjAJrFGFf 0fYjzoI4Lxa+Qknh7Rt3it2JUKooUO3qjygF6CuQ23aB8x2pRZGbZeUp0pvPbb8O AoxeIAF5Bk9JwOb0WfA//g7oKBwZCh0dTRXhL1YycxIlk63LTpMbOdO8VHxSB8GA hbDmMina7oqPBJV/lgJIuolWt3MyYv6EZTaCNXiAJm02HBY+5328P9Lm15KOwlZT 7MnhkdbhrQYOjijmKJZb =Kp7M -----END PGP SIGNATURE----- From rbarnes@bbn.com Thu Jan 26 08:52:34 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C06221F85BD for ; Thu, 26 Jan 2012 08:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.179 X-Spam-Level: X-Spam-Status: No, score=-106.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sCYfxXQofH9 for ; Thu, 26 Jan 2012 08:52:33 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1A79721F85B7 for ; Thu, 26 Jan 2012 08:52:33 -0800 (PST) Received: from ros-dhcp192-1-51-95.bbn.com ([192.1.51.95]:59793) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RqSYq-000FcH-FM; Thu, 26 Jan 2012 11:52:32 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4F2183D0.3070809@acm.org> Date: Thu, 26 Jan 2012 11:52:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <373FB643-AE7A-473C-A7AB-09F9A9E7093B@bbn.com> References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <4F2183D0.3070809@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: "vipr@ietf.org" Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 16:52:34 -0000 >>>> Let's not get hysterical here. These issues are inherent to any >>>> system for resolving identifiers. My local DNS resolver has a very >>>> good idea of things like what websites I'm visiting (A google.com) = and >>>> what services I'm using (SRV _xmpp-server._tcp.jabber.org). >>>=20 >>> Yes, but this is not the problem here. AFAIK, it is not possible = for >>> anybody to add its own DNS server as nameserver of google.com and = receive >>> all the requests sent to this domain and collect the source IP = addresses. >>> *That* would be the DNS equivalent of the privacy leak of VIPR. >>=20 >> True. Although in principle anyone could announce the anycast = prefixes >> used by the root nodes (in the absence of SIDR deployment), which = would get >> you lots of interesting traffic. >>=20 >> At the very least, however, your queries get forwarded to the DNS = root and >> intermediate name servers, which has been a problem before:=20 >> = >>=20 >> Like I said, the mitigation here is the same as any situation where = you >> want to hide your IP address: Send packets from a different network. >=20 > Yes, and (I am not sure you saw the second part of my response below), = this > would not be a concern if we could fix RELOAD to do exactly that. Doesn't really seem like a RELOAD issue. Rather, something for = higher/lower layers. Pay someone to do RELOAD on your behalf, or use a = VPN to somewhere else. Agree with a group of friends that you'll all = make the same queries at the same times, so that your individual = patterns are indistinguishable. OPSEC, not COMSEC. --Richard >=20 >>=20 >> --Richard >>=20 >>=20 >>=20 >>>>=20 >>>> Analogous mitigations apply, e.g.: >>>>=20 >>>> * For masking sources of requests, use indirection. In the DNS >>>> context, authoritative servers don't see my IP address because I go >>>> through a local resolver. In the VIPR context, you could have an >>>> outsourced RELOAD agent acquire tickets on behalf of clients who = trust >>>> it to handle call information. >>>>=20 >>>> * For masking destinations of requests, use multiple requests. In = the >>>> DNS context, request names/RRtypes other than the one you're = looking >>>> for. In the VIPR context, look for numbers you didn't dial, or = look >>>> for numbers when you haven't dialled anyone. >>>>=20 >>>> Note that in both cases, the mitigations are about how you use the=20= >>>> protocol, not the protocol itself. So while it might be worthwhile = to=20 >>>> write up a privacy considerations document, it doesn't seem like we >>>> need to change the protocol documents to deal with these threats. >>>=20 >>> The concern is not how to fix the problem, but that half of the = problem >>> comes from a protocol (RELOAD) that is not under our control, and so = will >>> take years to bring to a point where we can fix this problem. >>>=20 >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>>> On Jan 24, 2012, at 3:53 PM, Marc Petit-Huguenin wrote: >>>>=20 >>>> Michael Procter explained on the last VIPR design team weekly >>>> conference call a privacy attack that I think is devastating. The = end >>>> result is simple to explain: VIPR turns the Internet into a "trap = and >>>> trace device"[1], allowing anybody to record the phone numbers = called >>>> by any entities using VIPR, and this for a relatively low cost. >>>>=20 >>>> Let's say that VIPR is well deployed in US enterprises and that a >>>> spying group is willing to spend the money to know about the phone >>>> calls made by these enterprises. This spying group just have to = add >>>> enough VIPR servers to the RELOAD overlay to register all the phone >>>> numbers in the USA. Because all registrations are considered = equally >>>> untrusted, they will all be verified by establishing a TCP = connection >>>> between the VIPR server of the source of the call and the VIPR = server >>>> that stored the registration for a particular phone number. There = is >>>> multiple pieces of information that are leaked but it is easy for >>>> example to find the enterprise that is originating the TCP = connection >>>> by looking at the source address and to enter it in whois. >>>>=20 >>>> As Michael pointed out, you have to be on VIPR to protect your = privacy, >>>> i.e destination numbers that are *not* using VIPR are especially at >>>> risk. If the destination number is using VIPR, the TCP connection = used >>>> to verify the first call from any enterprise has a lower = probability to >>>> be directed to the spying group, because the real owner of the = number >>>> may be tried first and prevent other registrations to be tried if >>>> successful. And as soon the real owner sends a SIP route and = ticket >>>> back, the spying group will no longer receive any information about = the >>>> calls between this enterprise and this destination number, excepted = for >>>> the periodic renewal of the ticket. >>>>=20 >>>> Note that the information leaked go deeper than just the = verification=20 >>>> connection. Here's the various places where privacy information >>>> leakage happens with this attack: >>>>=20 >>>> - If the spying group uses a different VServiceId for each = registered >>>> phone number, the called number is always leaked. - The called = number >>>> is also leaked for methods A and B. - For method "A", the Caller-ID = is >>>> leaked (the bcrypt hash is hard to crack, but it is not = impossible). - >>>> For method "B", a random time in the middle of the call is leaked. = - >>>> For method "C", the rounded start and stop time of the call are = leaked. >>>> - The source IP address of the TCP connection for the PVP = transaction >>>> is always leaked. - The addr_port in the AppAttachReq RELOAD = message >>>> that was used to establish the TCP connection is leaked. - The >>>> certificate of the signer of the AppAttachReq RELOAD message is = leaked. >>>> Even if the certificate does not contain information about the = sender >>>> (subject, subjectAltName), it always contains the Node-ID, which = can >>>> always be resolved to an IP address by using an Attach request. - = The >>>> Node-ID is leaked a second time in the via_list of the AppAttachReq >>>> message, unless an intermediary RELOAD peer replaced it with a >>>> compressed ID. >>>>=20 >>>> There is probably ways to fix all of these leakages, and I found >>>> solutions for most of them, but they make RELOAD and VIPR much, = much >>>> more complex, to the point that I am starting to think that RELOAD >>>> itself is not up to the task. Using TURN to anonymize, as I = proposed, >>>> does not work because of the multiple places where data is leaked = and >>>> fixing RELOAD itself, which will require among other things adding >>>> something like onion routing, will probably take years[2]. >>>>=20 >>>> At a minimum, we will need to add a strong requirement about = required=20 >>>> anonymization in -overview, but it is clear to me that the >>>> standardization of VIPR will take a much longer time than expected. >>>>=20 >>>>=20 >>>> [1] http://en.wikipedia.org/wiki/Trap_and_trace_device [2]=20 >>>> http://www.ietf.org/mail-archive/web/p2psip/current/msg06166.html >>>>=20 >=20 >=20 >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iQIcBAEBCAAGBQJPIYPOAAoJECnERZXWan7Er+QP/iqC1BvcJkFilL5tJaQpXEMp > Nc6eWH6cEKUpL4Q6gBRhYk7CD0k3CFmNTGEblhjKhZAsLILicdUIUeAsXN8JFFdD > Bxf2D99R2t24qrMwBzmOhRUNoV3JryNDOH0S5qFbCZ564WKPdfLrrPRdYfedTBXo > H7sm7THDrSNuNLUDejLtRmpLG4CENjSOJe4RMnUkgMb2ikG3OfpRPp3VexKE9prN > HO6sJ0IBWtdGt/p0K8CE4xsG2Kg3CYz4v65A7YefQ/6YKy4nk4rfW6fBEchEqApL > xRRsoxvSOzNXDHRZqOZiQbrP1qxupAIU43ladvf7Hx4Y9c22uxkw5818o4EJJ0pZ > XD03Aml4gCVzl5Mg/X8/4D9oR9GFieeKjXvKO/Y/5LHSC7l/hCVkz/f+2jiSqvtd > BfOz9xfxBqIhU3l0x29euur6nO2k0LMYIaulDgp4Rmd1UAY6JqtFoloCjAJrFGFf > 0fYjzoI4Lxa+Qknh7Rt3it2JUKooUO3qjygF6CuQ23aB8x2pRZGbZeUp0pvPbb8O > AoxeIAF5Bk9JwOb0WfA//g7oKBwZCh0dTRXhL1YycxIlk63LTpMbOdO8VHxSB8GA > hbDmMina7oqPBJV/lgJIuolWt3MyYv6EZTaCNXiAJm02HBY+5328P9Lm15KOwlZT > 7MnhkdbhrQYOjijmKJZb > =3DKp7M > -----END PGP SIGNATURE----- From petithug@acm.org Thu Jan 26 10:53:25 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEBD21F860F for ; Thu, 26 Jan 2012 10:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.202 X-Spam-Level: X-Spam-Status: No, score=-102.202 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Him1cabJlD2L for ; Thu, 26 Jan 2012 10:53:24 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE5921F85C0 for ; Thu, 26 Jan 2012 10:53:24 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 46F722040F; Thu, 26 Jan 2012 18:39:04 +0000 (UTC) Message-ID: <4F21A121.10403@acm.org> Date: Thu, 26 Jan 2012 10:53:21 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <4F2183D0.3070809@acm.org> <373FB643-AE7A-473C-A7AB-09F9A9E7093B@bbn.com> In-Reply-To: <373FB643-AE7A-473C-A7AB-09F9A9E7093B@bbn.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 18:53:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/26/2012 08:52 AM, Richard L. Barnes wrote: >>>>> Let's not get hysterical here. These issues are inherent to any >>>>> system for resolving identifiers. My local DNS resolver has a very >>>>> good idea of things like what websites I'm visiting (A >>>>> google.com) and what services I'm using (SRV >>>>> _xmpp-server._tcp.jabber.org). >>>> >>>> Yes, but this is not the problem here. AFAIK, it is not possible >>>> for anybody to add its own DNS server as nameserver of google.com >>>> and receive all the requests sent to this domain and collect the >>>> source IP addresses. *That* would be the DNS equivalent of the >>>> privacy leak of VIPR. >>> >>> True. Although in principle anyone could announce the anycast prefixes >>> used by the root nodes (in the absence of SIDR deployment), which >>> would get you lots of interesting traffic. >>> >>> At the very least, however, your queries get forwarded to the DNS root >>> and intermediate name servers, which has been a problem before: >>> >>> >>> >>> >>> Like I said, the mitigation here is the same as any situation where you >>> want to hide your IP address: Send packets from a different network. >> >> Yes, and (I am not sure you saw the second part of my response below), >> this would not be a concern if we could fix RELOAD to do exactly that. > > Doesn't really seem like a RELOAD issue. Rather, something for > higher/lower layers. Pay someone to do RELOAD on your behalf, or use a VPN > to somewhere else. Agree with a group of friends that you'll all make the > same queries at the same times, so that your individual patterns are > indistinguishable. OPSEC, not COMSEC. > Yes, and my original proposal was to use the TURN servers that are already present in the RELOAD overlay to hide the source of the PVP connections. But after last Friday's call I worked on establishing an exhaustive list of the places where data is leaked. Some information are leaked by the SRP-TLS protocol, but we already worked on that in the WG and are making progress. No concern here. The source IP address of the PVP connection can be hidden by TURN or any of the other solutions you proposed. Here also, no concern. Then I started to dig deeper in RELOAD itself, which is used to pass the information to establish the TCP connection used for the SRP-TLS exchange. If we use TURN or a similar mechanism, then the source IP is also hidden. But the message used for this (an AppAttachReq RELOAD message) also leaks data. The RELOAD messages are authenticated end-to-end, so it is really easy to extract the certificate of the sender, then the Node-ID of the sender and use an Attach (a transaction that is part of the basic set of transactions required for RELOAD) to find the IP address of the sender. The same data is leaked a second time in the via_list. So that's two additional layers that require some work to be made anonymous. And this is where I have concerns. I (and others) have seen our RELOAD extension proposals delayed for the last two years in P2PSIP, so even there is no doubt that we can fix the privacy issues, the problem is more in the time required to fix them. Cullen's email in P2PSIP was unambiguous in saying that doing this will push VIPR to 2015/2020. Let's see a concrete example. I want to know all the calls made by VIPR users to all the phone numbers (VIPR or not) in the USA. For each of these numbers, I register my VIPR server with a different VService-ID: Rogue RELOAD | Store(+14085550001=rogue-Node-ID) | |----------------------------------->| | | Someone with a VIPR enabled phone make a call to *any* of the US phone numbers. In this case, because +1408-555-0001 is not VIPR enabled, the caller cannot already have a SIP route, so the RELOAD distributed database is queried: Rogue RELOAD VIPR Phone | | Fetch(+14085550001)=Node-ID | | |<-------------------------------| | | The next step is for the VIPR phone to execute an AppAttach transaction: Rogue RELOAD VIPR Phone | | | | | AppAttach(phone-IP)=rogue-IP | |<--------------------------------------------------------------------| | | | The AppAttach request contains the IP address of the PVP client - that's the first leak. The AppAttach request is signed by the certificate of VIPR phone. That's the second leak. The AppAttach request also contains the Node-ID of the VIPR phone in the via_list, so RELOAD can route back the response. That the third leak. Then the VIPR phone starts a TCP connection to the PVP server, using the IP address returned in the AppAttach response: Rogue RELOAD VIPR Phone | | | | | TCP establishment | |<--------------------------------------------------------------------| | | | That's the fourth leak. Next step is to establish the SRP-TLS session: Rogue RELOAD VIPR Phone | | | | Client Hello | | |-------------------------------------------------------------------->| | ServerHello/ServerKeyExchange/ServerHelloDone | |<--------------------------------------------------------------------| | Alert | | |-------------------------------------------------------------------->| We know that the 3 PVP methods leaks some data but first as the rogue VIPR server used different VServiceID for each registered phone number, and as the VServiceId is sent in clear in the SRP-TLS exchange, the rogue server knows the called number. Then for method A the hash of the Caller-ID is also sent in clear. For method B a random time chosen in the middle of the call is sent in clear. For method C the start/end time of the call are sent in clear. Again, we can fix all of these. The problem is that we cannot fix the RELOAD issues in a timely manner. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPIaEfAAoJECnERZXWan7EHjYQALwGDeCdRFLOzinFviR8WTfw z86vZFWhL2+Bzxnc50cFZY8uav9CBgN9xpLBRIklXvlhwyWxwossUAASE/b7BCQr SaspiMW3oijv3jjPdPyqUuFNMYJFxf+mS+MOwwd+TnUUVLMQZBi7vI9lsbOegWLm 30jaY1NfBscgqzJPDY3hgbp56R31cGTYl7scE4WndudNA0wr7QeratzvQa3rm9OI XzGXJGaFtuXEG9KTC/cDJiXM23CtDCq9rFmA+6P5FkaVIsG/YDQi4gPYIiUT7vvv YXdHhVaOa7GZVUbOYjoi73J898iRtzyBoZtEvE50CbHs91PYw7PuXaqF0KYF6zfU 82pXh+Wvlw+O5l+X/6EfWj3cjTMY5bBueP2VBtIsmz+iqEKY63PCNGWUaOiyOCbv 5lRjFVLlqjxvL/jJoCOf7Hrvw67NpOcx/ZZyXfF883enb+E2z1f+qvK26VKkOLG4 2gSThVi+SypDyw5MId0tNGp4DXVD4x9oepc5kqYooiNAjFkY4Q3HBAqCHmcbgYvn qa/lUEelPryQ3ojbhgXfww8H8axHsmh0o0np/8JlpDQmQJ5CBBavMY00gZdgyF1z syesITpMgkpIhj5qQjsMd6gSRGu8RLPClg1fK/BPDLHwBUF2tMkJmCvAHwQK9etv 1eYCUlXRb9AUBhshZMrY =XNF7 -----END PGP SIGNATURE----- From dean.willis@softarmor.com Thu Jan 26 13:28:35 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6221C21F86C1 for ; Thu, 26 Jan 2012 13:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0tEUZmNCfZB for ; Thu, 26 Jan 2012 13:28:35 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB36621F8633 for ; Thu, 26 Jan 2012 13:28:34 -0800 (PST) Received: by yenm3 with SMTP id m3so544220yen.31 for ; Thu, 26 Jan 2012 13:28:34 -0800 (PST) Received: by 10.236.173.37 with SMTP id u25mr6215813yhl.26.1327613314441; Thu, 26 Jan 2012 13:28:34 -0800 (PST) Received: from [192.168.2.104] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id n72sm8947223yhh.21.2012.01.26.13.28.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jan 2012 13:28:33 -0800 (PST) References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> In-Reply-To: <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <92E46A75-E370-4A52-BF04-F2D811D3C0C0@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Date: Thu, 26 Jan 2012 15:28:31 -0600 To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) Cc: "vipr@ietf.org" Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 21:28:35 -0000 On Jan 26, 2012, at 10:40 AM, Richard L. Barnes wrote: >=20 >=20 > Like I said, the mitigation here is the same as any situation where = you want to hide your IP address: Send packets from a different network. So we should run a great big VPN in order to run RELOAD in order to run = ViPR? Great! Now all we need is a peer-to-peer VPN capable of obscuring the IP = addresses being used. I'm trying to imagine just how badly the universe would break if one = tried to run RELOAD over TOR. I don't think I have that good an = imagination, because scenes from the movie "2012" pale by comparison, = and I'm sure the real situation would be far worse than what I imagine. But this does all come back to why I haven't been able to convince = myself of the real-world utility of ViPR. We're layering vast complexity = onto what is basically a distributed trust-anchor problem, where the = easiest thing to do in the real-world is to have a centralized anchor = (which might itself refer to the PSTN basis anchor). How about an alt-root DDNS/ENUM server that itself uses PSTN = reachability to verify registrations submitted via DDNS? -- Dean= From petithug@acm.org Thu Jan 26 13:38:57 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A2121F872F for ; Thu, 26 Jan 2012 13:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.215 X-Spam-Level: X-Spam-Status: No, score=-102.215 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Gppm8qoPKUM for ; Thu, 26 Jan 2012 13:38:56 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 79BA521F8633 for ; Thu, 26 Jan 2012 13:38:56 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 19CB72040F; Thu, 26 Jan 2012 21:24:34 +0000 (UTC) Message-ID: <4F21C7EC.2000201@acm.org> Date: Thu, 26 Jan 2012 13:38:52 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: Dean Willis References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <92E46A75-E370-4A52-BF04-F2D811D3C0C0@softarmor.com> In-Reply-To: <92E46A75-E370-4A52-BF04-F2D811D3C0C0@softarmor.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 21:38:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/26/2012 01:28 PM, Dean Willis wrote: > > On Jan 26, 2012, at 10:40 AM, Richard L. Barnes wrote: >> >> >> Like I said, the mitigation here is the same as any situation where you >> want to hide your IP address: Send packets from a different network. > > > So we should run a great big VPN in order to run RELOAD in order to run > ViPR? > > Great! Now all we need is a peer-to-peer VPN capable of obscuring the IP > addresses being used. > > I'm trying to imagine just how badly the universe would break if one tried > to run RELOAD over TOR. I don't think I have that good an imagination, > because scenes from the movie "2012" pale by comparison, and I'm sure the > real situation would be far worse than what I imagine. > > But this does all come back to why I haven't been able to convince myself > of the real-world utility of ViPR. We're layering vast complexity onto what > is basically a distributed trust-anchor problem, where the easiest thing > to do in the real-world is to have a centralized anchor (which might itself > refer to the PSTN basis anchor). > > How about an alt-root DDNS/ENUM server that itself uses PSTN reachability > to verify registrations submitted via DDNS? That may be worth investigating, but the first thing that the WG should answer, IMHO, is do we want to 1) give up, 2) delay for RELOAD, or 3) replace RELOAD? - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPIcfqAAoJECnERZXWan7E6sQP/2jBmenEmlsQ+Pe5V1F/qn7e kSQjw6EuUGKjz5oONhsbEw2N4kAHwtivQlfriJoT4NxeYspWWvg+13Btb4+OlTFU QNAU9rY0Zd+AZJvFBII70TGjKl5aRZ5G7LRmgfsyp88OAODs9FtHRVzTtQVSTbEV ZYWtzYXRWcYosH+9sML7vFn8gf5njDsR0pTEV1Xt+DVdVbec+MV35zHmX8gOtR84 +s/LalXe8rPUdmDV7qAHHZir9gCj2FmSuJlb2KGr3IfEj+mD1FeRTfsN8bhtE0zZ cfg8yAYjLgvNy7O7ZXFN8GIQx40StJqRXCxuzrJ0CHHDlS3NJ8vv8IVM8mlMIt0d UaHnC4DcU3yQGFNGe+f3cG1KrtAIsDTUJyyppsra4Q41dP4eporG8uWZDbIJwDMI Jg7nwSJD6RJ8qL6zgWl1gNyfRXOKG3s3Wt8Oy/l00Q837N8+KxGRA7WeEu0PMjkR 8d1C/i4dPymKVA5FsdPatG+/dHee8FzbYKriGOmCXsGhx5+rcW3m3tVE+lpzqBZ9 0dysmnJmjNJUcsHIp+o+CWKd5FcSewxfNMHy762lmJME7srDVzENd8rWi5luHVWn k1KviQe82XaV6PhKb6/K3rSSotNAPKwkSiIvSsuaOeDv1Wmzi472Mp/BX0M2/s9p 5hv+PEtbfXzcNBh+zW3r =OqpG -----END PGP SIGNATURE----- From rbarnes@bbn.com Thu Jan 26 13:47:39 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604DD21F85FC for ; Thu, 26 Jan 2012 13:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.198 X-Spam-Level: X-Spam-Status: No, score=-106.198 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3FPqXvTq4W9 for ; Thu, 26 Jan 2012 13:47:38 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id A051121F85D5 for ; Thu, 26 Jan 2012 13:47:38 -0800 (PST) Received: from ros-dhcp192-1-51-95.bbn.com ([192.1.51.95]:63286) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RqXAO-0003Dh-V3; Thu, 26 Jan 2012 16:47:37 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4F21C7EC.2000201@acm.org> Date: Thu, 26 Jan 2012 16:47:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <57AD64CF-7F67-44A0-AE79-4AE9848E4746@bbn.com> References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <92E46A75-E370-4A52-BF04-F2D811D3C0C0@softarmor.com> <4F21C7EC.2000201@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: "vipr@ietf.org" , Dean Willis Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 21:47:39 -0000 Or (4), don't worry, be happy? :) Seriously, the question is whether the group feels that these privacy = risks merit changing the work that this group is doing, or whether the = benefit of ViPR is enough that exposing one's IP address is a tolerable = risk. IMO, it seems like there are enough operational mitigations to these = risks that no fundamental changes to ViPR are needed. But I maybe I'm = misunderstanding; it's been a while since I've thoroughly read through = the documents. --Richard On Jan 26, 2012, at 4:38 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > On 01/26/2012 01:28 PM, Dean Willis wrote: >>=20 >> On Jan 26, 2012, at 10:40 AM, Richard L. Barnes wrote: >>>=20 >>>=20 >>> Like I said, the mitigation here is the same as any situation where = you >>> want to hide your IP address: Send packets from a different network. >>=20 >>=20 >> So we should run a great big VPN in order to run RELOAD in order to = run >> ViPR? >>=20 >> Great! Now all we need is a peer-to-peer VPN capable of obscuring the = IP >> addresses being used. >>=20 >> I'm trying to imagine just how badly the universe would break if one = tried >> to run RELOAD over TOR. I don't think I have that good an = imagination, >> because scenes from the movie "2012" pale by comparison, and I'm sure = the >> real situation would be far worse than what I imagine. >>=20 >> But this does all come back to why I haven't been able to convince = myself >> of the real-world utility of ViPR. We're layering vast complexity = onto what >> is basically a distributed trust-anchor problem, where the easiest = thing >> to do in the real-world is to have a centralized anchor (which might = itself >> refer to the PSTN basis anchor). >>=20 >> How about an alt-root DDNS/ENUM server that itself uses PSTN = reachability >> to verify registrations submitted via DDNS? >=20 > That may be worth investigating, but the first thing that the WG = should > answer, IMHO, is do we want to 1) give up, 2) delay for RELOAD, or 3) = replace > RELOAD? >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iQIcBAEBCAAGBQJPIcfqAAoJECnERZXWan7E6sQP/2jBmenEmlsQ+Pe5V1F/qn7e > kSQjw6EuUGKjz5oONhsbEw2N4kAHwtivQlfriJoT4NxeYspWWvg+13Btb4+OlTFU > QNAU9rY0Zd+AZJvFBII70TGjKl5aRZ5G7LRmgfsyp88OAODs9FtHRVzTtQVSTbEV > ZYWtzYXRWcYosH+9sML7vFn8gf5njDsR0pTEV1Xt+DVdVbec+MV35zHmX8gOtR84 > +s/LalXe8rPUdmDV7qAHHZir9gCj2FmSuJlb2KGr3IfEj+mD1FeRTfsN8bhtE0zZ > cfg8yAYjLgvNy7O7ZXFN8GIQx40StJqRXCxuzrJ0CHHDlS3NJ8vv8IVM8mlMIt0d > UaHnC4DcU3yQGFNGe+f3cG1KrtAIsDTUJyyppsra4Q41dP4eporG8uWZDbIJwDMI > Jg7nwSJD6RJ8qL6zgWl1gNyfRXOKG3s3Wt8Oy/l00Q837N8+KxGRA7WeEu0PMjkR > 8d1C/i4dPymKVA5FsdPatG+/dHee8FzbYKriGOmCXsGhx5+rcW3m3tVE+lpzqBZ9 > 0dysmnJmjNJUcsHIp+o+CWKd5FcSewxfNMHy762lmJME7srDVzENd8rWi5luHVWn > k1KviQe82XaV6PhKb6/K3rSSotNAPKwkSiIvSsuaOeDv1Wmzi472Mp/BX0M2/s9p > 5hv+PEtbfXzcNBh+zW3r > =3DOqpG > -----END PGP SIGNATURE----- From mary.ietf.barnes@gmail.com Thu Jan 26 13:49:26 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2235921F8794 for ; Thu, 26 Jan 2012 13:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.71 X-Spam-Level: X-Spam-Status: No, score=-103.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hCUmhxrbK64 for ; Thu, 26 Jan 2012 13:49:25 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4709821F8792 for ; Thu, 26 Jan 2012 13:49:25 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so842679vcb.31 for ; Thu, 26 Jan 2012 13:49:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZEENhQ4ffjRj3q9Zh5uScDhyzofdcLoW9rssUgD7g48=; b=JVGjJh0V2FzZV12nMWjb7uo/vKJAtLwEyznN0tF16Xitqr6wruyUehllBTzZ65AYRW R0j/SIlx68JrArTIICpEKsy71alynjpxQucibF+bhXOoLfBkmvjyhlaZcv+wrSBNzfiK da4L3dsdbBLmwJ5xPjKuLtMayQb4yPU3s5K84= MIME-Version: 1.0 Received: by 10.220.148.138 with SMTP id p10mr2143782vcv.28.1327614562921; Thu, 26 Jan 2012 13:49:22 -0800 (PST) Received: by 10.52.108.196 with HTTP; Thu, 26 Jan 2012 13:49:22 -0800 (PST) In-Reply-To: <4F21C7EC.2000201@acm.org> References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <92E46A75-E370-4A52-BF04-F2D811D3C0C0@softarmor.com> <4F21C7EC.2000201@acm.org> Date: Thu, 26 Jan 2012 15:49:22 -0600 Message-ID: From: Mary Barnes To: Marc Petit-Huguenin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "vipr@ietf.org" , Dean Willis Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 21:49:26 -0000 Unfortunately, options 2 and 3 introduce delays that decrease the relevance/utility of VIPR , which in my view has significant near term (i.e., now) value, but in the long term is likely to be far less useful. Mary. On Thu, Jan 26, 2012 at 3:38 PM, Marc Petit-Huguenin wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 01/26/2012 01:28 PM, Dean Willis wrote: >> >> On Jan 26, 2012, at 10:40 AM, Richard L. Barnes wrote: >>> >>> >>> Like I said, the mitigation here is the same as any situation where you >>> want to hide your IP address: Send packets from a different network. >> >> >> So we should run a great big VPN in order to run RELOAD in order to run >> ViPR? >> >> Great! Now all we need is a peer-to-peer VPN capable of obscuring the IP >> addresses being used. >> >> I'm trying to imagine just how badly the universe would break if one tri= ed >> to run RELOAD over TOR. I don't think I have that good an imagination, >> because scenes from the movie "2012" pale by comparison, and I'm sure th= e >> real situation would be far worse than what I imagine. >> >> But this does all come back to why I haven't been able to convince mysel= f >> of the real-world utility of ViPR. We're layering vast complexity onto w= hat >> is basically a distributed =A0trust-anchor problem, where the easiest th= ing >> to do in the real-world is to have a centralized anchor (which might its= elf >> refer to the PSTN basis anchor). >> >> How about an alt-root DDNS/ENUM server that itself uses PSTN reachabilit= y >> to verify registrations submitted via DDNS? > > That may be worth investigating, but the first thing that the WG should > answer, IMHO, is do we want to 1) give up, 2) delay for RELOAD, or 3) rep= lace > RELOAD? > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQIcBAEBCAAGBQJPIcfqAAoJECnERZXWan7E6sQP/2jBmenEmlsQ+Pe5V1F/qn7e > kSQjw6EuUGKjz5oONhsbEw2N4kAHwtivQlfriJoT4NxeYspWWvg+13Btb4+OlTFU > QNAU9rY0Zd+AZJvFBII70TGjKl5aRZ5G7LRmgfsyp88OAODs9FtHRVzTtQVSTbEV > ZYWtzYXRWcYosH+9sML7vFn8gf5njDsR0pTEV1Xt+DVdVbec+MV35zHmX8gOtR84 > +s/LalXe8rPUdmDV7qAHHZir9gCj2FmSuJlb2KGr3IfEj+mD1FeRTfsN8bhtE0zZ > cfg8yAYjLgvNy7O7ZXFN8GIQx40StJqRXCxuzrJ0CHHDlS3NJ8vv8IVM8mlMIt0d > UaHnC4DcU3yQGFNGe+f3cG1KrtAIsDTUJyyppsra4Q41dP4eporG8uWZDbIJwDMI > Jg7nwSJD6RJ8qL6zgWl1gNyfRXOKG3s3Wt8Oy/l00Q837N8+KxGRA7WeEu0PMjkR > 8d1C/i4dPymKVA5FsdPatG+/dHee8FzbYKriGOmCXsGhx5+rcW3m3tVE+lpzqBZ9 > 0dysmnJmjNJUcsHIp+o+CWKd5FcSewxfNMHy762lmJME7srDVzENd8rWi5luHVWn > k1KviQe82XaV6PhKb6/K3rSSotNAPKwkSiIvSsuaOeDv1Wmzi472Mp/BX0M2/s9p > 5hv+PEtbfXzcNBh+zW3r > =3DOqpG > -----END PGP SIGNATURE----- > _______________________________________________ > VIPR mailing list > VIPR@ietf.org > https://www.ietf.org/mailman/listinfo/vipr From prvs=0372a90b52=KBergsbaken@UNIVISION.NET Thu Jan 26 14:34:26 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBDF21F8624 for ; Thu, 26 Jan 2012 14:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.031 X-Spam-Level: X-Spam-Status: No, score=0.031 tagged_above=-999 required=5 tests=[AWL=2.630, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jSlLybmdg9S for ; Thu, 26 Jan 2012 14:34:25 -0800 (PST) Received: from nmail.univision.net (nmail.univision.net [216.156.154.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC6921F8613 for ; Thu, 26 Jan 2012 14:34:25 -0800 (PST) From: Kurt Bergsbaken To: "'mary.ietf.barnes@gmail.com'" , "'petithug@acm.org'" Date: Thu, 26 Jan 2012 17:34:21 -0500 Thread-Topic: [VIPR] VIPR privacy issue Thread-Index: AczcdGEY4UqHrCCMSDyDowwpp9nwgQABkTAQ Message-ID: <379B85522FA3D542813DF7D02EC8DF99576ED41A9F@mia-exmbx02> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: 355ae39f-542b-4f28-a0b5-1f4463b74c90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: none Cc: "'vipr@ietf.org'" , "'dean.willis@softarmor.com'" Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 22:34:26 -0000 Are there viable candidates to displace RELOAD that could be shovel-ready w= ithin the acceptable event horizon? Kurt Bergsbaken | Architect -SIP Voice Services | Univision Communications = Inc. | 8550 NW 33rd Street, Miami, FL 33122 Direct: (305) 463-5745 | Fax: (786) 515-9229 | kbergsbaken@univision.net | = www.univision.com ----- Original Message ----- From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: Thursday, January 26, 2012 04:49 PM To: Marc Petit-Huguenin Cc: vipr@ietf.org ; Dean Willis Subject: Re: [VIPR] VIPR privacy issue Unfortunately, options 2 and 3 introduce delays that decrease the relevance/utility of VIPR , which in my view has significant near term (i.e., now) value, but in the long term is likely to be far less useful. Mary. On Thu, Jan 26, 2012 at 3:38 PM, Marc Petit-Huguenin wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 01/26/2012 01:28 PM, Dean Willis wrote: >> >> On Jan 26, 2012, at 10:40 AM, Richard L. Barnes wrote: >>> >>> >>> Like I said, the mitigation here is the same as any situation where you >>> want to hide your IP address: Send packets from a different network. >> >> >> So we should run a great big VPN in order to run RELOAD in order to run >> ViPR? >> >> Great! Now all we need is a peer-to-peer VPN capable of obscuring the IP >> addresses being used. >> >> I'm trying to imagine just how badly the universe would break if one tri= ed >> to run RELOAD over TOR. I don't think I have that good an imagination, >> because scenes from the movie "2012" pale by comparison, and I'm sure th= e >> real situation would be far worse than what I imagine. >> >> But this does all come back to why I haven't been able to convince mysel= f >> of the real-world utility of ViPR. We're layering vast complexity onto w= hat >> is basically a distributed trust-anchor problem, where the easiest thin= g >> to do in the real-world is to have a centralized anchor (which might its= elf >> refer to the PSTN basis anchor). >> >> How about an alt-root DDNS/ENUM server that itself uses PSTN reachabilit= y >> to verify registrations submitted via DDNS? > > That may be worth investigating, but the first thing that the WG should > answer, IMHO, is do we want to 1) give up, 2) delay for RELOAD, or 3) rep= lace > RELOAD? > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQIcBAEBCAAGBQJPIcfqAAoJECnERZXWan7E6sQP/2jBmenEmlsQ+Pe5V1F/qn7e > kSQjw6EuUGKjz5oONhsbEw2N4kAHwtivQlfriJoT4NxeYspWWvg+13Btb4+OlTFU > QNAU9rY0Zd+AZJvFBII70TGjKl5aRZ5G7LRmgfsyp88OAODs9FtHRVzTtQVSTbEV > ZYWtzYXRWcYosH+9sML7vFn8gf5njDsR0pTEV1Xt+DVdVbec+MV35zHmX8gOtR84 > +s/LalXe8rPUdmDV7qAHHZir9gCj2FmSuJlb2KGr3IfEj+mD1FeRTfsN8bhtE0zZ > cfg8yAYjLgvNy7O7ZXFN8GIQx40StJqRXCxuzrJ0CHHDlS3NJ8vv8IVM8mlMIt0d > UaHnC4DcU3yQGFNGe+f3cG1KrtAIsDTUJyyppsra4Q41dP4eporG8uWZDbIJwDMI > Jg7nwSJD6RJ8qL6zgWl1gNyfRXOKG3s3Wt8Oy/l00Q837N8+KxGRA7WeEu0PMjkR > 8d1C/i4dPymKVA5FsdPatG+/dHee8FzbYKriGOmCXsGhx5+rcW3m3tVE+lpzqBZ9 > 0dysmnJmjNJUcsHIp+o+CWKd5FcSewxfNMHy762lmJME7srDVzENd8rWi5luHVWn > k1KviQe82XaV6PhKb6/K3rSSotNAPKwkSiIvSsuaOeDv1Wmzi472Mp/BX0M2/s9p > 5hv+PEtbfXzcNBh+zW3r > =3DOqpG > -----END PGP SIGNATURE----- > _______________________________________________ > VIPR mailing list > VIPR@ietf.org > https://www.ietf.org/mailman/listinfo/vipr _______________________________________________ VIPR mailing list VIPR@ietf.org https://www.ietf.org/mailman/listinfo/vipr The information contained in this e-mail and any attached documents may be privileged, confidential and protected from disclosure. If you are not the intended recipient you may not read, copy, distribute or use this information. If you have received this communication in error, please notify the sender immediately by replying to this message and then delete it from your system. From fluffy@fluffy.im Thu Jan 26 16:28:02 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7720421F85AF for ; Thu, 26 Jan 2012 16:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brgQREGwT57t for ; Thu, 26 Jan 2012 16:28:01 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE7F21F8555 for ; Thu, 26 Jan 2012 16:28:01 -0800 (PST) Received: by iagf6 with SMTP id f6so1720217iag.31 for ; Thu, 26 Jan 2012 16:28:00 -0800 (PST) Received: by 10.42.152.65 with SMTP id h1mr3450885icw.50.1327624080910; Thu, 26 Jan 2012 16:28:00 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id x18sm5824417ibi.2.2012.01.26.16.27.59 (version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 16:28:00 -0800 (PST) Sender: Cullen Jennings Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4F1F1A42.1030201@acm.org> Date: Thu, 26 Jan 2012 17:27:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <26235819-9BF3-453F-81F5-F5351F648D4C@iii.ca> References: <4F1F1A42.1030201@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: "vipr@ietf.org" Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 00:28:02 -0000 Few comments about this ... As pointed out before, if someone is willing to buy enough certificates, = all P2P systems I am aware of become insecure in some way. The = mitigation to this is to price certificates appropriate and also to be = able to detect that someone is doing this and be able to black list them = off the DHT. I will note that GoDaddy has many constraints on issues the = certificates people are currently using and one of theses is a minimum = price. I will also note the more nodes are on a reload ring, the more = expensive it becomes to compromise it. And that is is possible to figure = out which certificates are being used by nodes which are publishing your = number when they should not be.=20 For some of the attacks on ViPR, the best defense is to make sure your = PSTN numbers are registered. I view this as feature of the design. I'm = sure opinions vary on this.=20 I don't think there is anything stopping you from forking the RELOAD = draft. But my limited energy will be on the WG draft not some fork of it = - I think I fail to see how forking RELOAD will help. The idea that = replacing VIPR with some yet to be determined protocol will help speed = things up, ah, - lets just say I find that very unlikely. If someone = would like to clarify what it is they need RELOAD to do that it does not = do, I'd be happy to scratch my head about ways to achieve that. If one = of the problems is the attacker can learn the IP of the PVP which = reveals the owner, how about running you PVP on Amazon EC2 or whatever = you like.=20 On Jan 24, 2012, at 1:53 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Michael Procter explained on the last VIPR design team weekly = conference call > a privacy attack that I think is devastating. The end result is = simple to > explain: VIPR turns the Internet into a "trap and trace device"[1], = allowing > anybody to record the phone numbers called by any entities using VIPR, = and > this for a relatively low cost. >=20 > Let's say that VIPR is well deployed in US enterprises and that a = spying group > is willing to spend the money to know about the phone calls made by = these > enterprises. This spying group just have to add enough VIPR servers = to the > RELOAD overlay to register all the phone numbers in the USA. Because = all > registrations are considered equally untrusted, they will all be = verified by > establishing a TCP connection between the VIPR server of the source of = the > call and the VIPR server that stored the registration for a particular = phone > number. There is multiple pieces of information that are leaked but = it is > easy for example to find the enterprise that is originating the TCP = connection > by looking at the source address and to enter it in whois. >=20 > As Michael pointed out, you have to be on VIPR to protect your = privacy, i.e > destination numbers that are *not* using VIPR are especially at risk. = If the > destination number is using VIPR, the TCP connection used to verify = the first > call from any enterprise has a lower probability to be directed to the = spying > group, because the real owner of the number may be tried first and = prevent > other registrations to be tried if successful. And as soon the real = owner > sends a SIP route and ticket back, the spying group will no longer = receive any > information about the calls between this enterprise and this = destination > number, excepted for the periodic renewal of the ticket. >=20 > Note that the information leaked go deeper than just the verification > connection. Here's the various places where privacy information = leakage > happens with this attack: >=20 > - - If the spying group uses a different VServiceId for each = registered phone > number, the called number is always leaked. > - - The called number is also leaked for methods A and B. > - - For method "A", the Caller-ID is leaked (the bcrypt hash is hard = to crack, > but it is not impossible). > - - For method "B", a random time in the middle of the call is leaked. > - - For method "C", the rounded start and stop time of the call are = leaked. > - - The source IP address of the TCP connection for the PVP = transaction is > always leaked. > - - The addr_port in the AppAttachReq RELOAD message that was used to = establish > the TCP connection is leaked. > - - The certificate of the signer of the AppAttachReq RELOAD message = is leaked. > Even if the certificate does not contain information about the sender > (subject, subjectAltName), it always contains the Node-ID, which can = always be > resolved to an IP address by using an Attach request. > - - The Node-ID is leaked a second time in the via_list of the = AppAttachReq > message, unless an intermediary RELOAD peer replaced it with a = compressed ID. >=20 > There is probably ways to fix all of these leakages, and I found = solutions for > most of them, but they make RELOAD and VIPR much, much more complex, = to the > point that I am starting to think that RELOAD itself is not up to the = task. > Using TURN to anonymize, as I proposed, does not work because of the = multiple > places where data is leaked and fixing RELOAD itself, which will = require among > other things adding something like onion routing, will probably take = years[2]. >=20 > At a minimum, we will need to add a strong requirement about required > anonymization in -overview, but it is clear to me that the = standardization of > VIPR will take a much longer time than expected. >=20 >=20 > [1] http://en.wikipedia.org/wiki/Trap_and_trace_device > [2] http://www.ietf.org/mail-archive/web/p2psip/current/msg06166.html >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iQIcBAEBCAAGBQJPHxo6AAoJECnERZXWan7EV0kQALf+0G+bdOj4t3GiNSk1rjKC > 7Zbnz4cqiJrmmJl3PjISQy8t+yXEngEO2vmM9ewkb9i4tZV0fV+UNv4Wpxfs2XF1 > p/VRZ8gKAGiNfSgY2aGXDtErEaV33Rkuh+iQUVd+FsYTc2lSUDPnRFXD9dfO4GuK > FIJKnf3Wm9yK37zN8X+kS9ynrEzTXDKD1V1kfW8JgEne6KkL7wwhH/NWAXKbT3F+ > o0RsWbM2Kft9aCmzRtBSgzNRiVb1G6asD8LaETXImEPhP0ScySnul7sqeXg4un5o > ipVwjiAuKy6sPsOJoXD26fePzMbymrtKL6R3Lv/YM9W9ae3cQo3JrjShEwYhVETY > c0leYotFBSDELu3jv2sqfF1ij9I+XXD9gUT8eOd/XV/xBKvvEr06xQ9tc7E72e1C > hEpINusiMYNW1nWvL7WvJNbQU4KaojyF6I2uGLQss8UKBYvYBU4+oIkg6F0bF3GA > c5yxdEVOg1Tkn88yiUI4O3pOS1yuscsUBlduOKQsNvKZQWd6Y1eikODU44Ea2hRr > JlsQz5Azh7PY07a6dD7VmdS36wA0N+JbPpL6pvgf0r5tfxoWAcfoyZ2gtgEsFf6Y > CLaySla7kUaVVzjhe9tsccG3FmdpnDS8wQjJ/47FI/hnCUfv02FOAHWzALRNZgfF > nTxixgP8OeOKecgd8ll8 > =3DLV2v > -----END PGP SIGNATURE----- > _______________________________________________ > VIPR mailing list > VIPR@ietf.org > https://www.ietf.org/mailman/listinfo/vipr From fluffy@fluffy.im Thu Jan 26 16:28:03 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039EF21F8555 for ; Thu, 26 Jan 2012 16:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-f4H-z8t3zv for ; Thu, 26 Jan 2012 16:28:02 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7996021F85B6 for ; Thu, 26 Jan 2012 16:28:02 -0800 (PST) Received: by mail-iy0-f172.google.com with SMTP id f6so1720217iag.31 for ; Thu, 26 Jan 2012 16:28:02 -0800 (PST) Received: by 10.43.48.132 with SMTP id uw4mr3491255icb.17.1327624082060; Thu, 26 Jan 2012 16:28:02 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id x18sm5824417ibi.2.2012.01.26.16.28.01 (version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 16:28:01 -0800 (PST) Sender: Cullen Jennings Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4F21A121.10403@acm.org> Date: Thu, 26 Jan 2012 17:28:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5466D9E6-3859-41A7-9A54-D23DC6D775C6@iii.ca> References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <4F2183D0.3070809@acm.org> <373FB643-AE7A-473C-A7AB-09F9A9E7093B@bbn.com> <4F21A121.10403@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: "vipr@ietf.org" Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 00:28:03 -0000 On Jan 26, 2012, at 11:53 AM, Marc Petit-Huguenin wrote: > Cullen's email in > P2PSIP was unambiguous in saying that doing this will push VIPR to = 2015/2020. That is not at all what I said. The 2020 was a date where I think we = might be possible to have a location privacy solution. As folks may = recall from the BOFs when P2PSIP was formed, Cisco had expressed that = one of these cases it was interested in was when the communications were = not at all anonymous but the location needed to be. The example used as = Vice President of the US during an emergency may be moved to a location = that is kept very secret but they need to communicate security and with = authentication to a large number of people. Todays internet protocols = don't offer much in the form of location privacy - with the possible = exception of TOR. Some person with General in their title even showed up = at Vancouver and Prague IETFs. When P2PSIP got chartered, location = privacy got drooped out because it was viewed as it would just be too = much to solve. I think I argued for doing location privacy at the time = but I was wrong - it clearly would have been too much to do in the first = version.=20 However, I still hope that we might have a standards based location = privacy system by 2020 but others think it is better to do this type of = thing just a a proprietary system so who knows.=20 From fluffy@fluffy.im Thu Jan 26 16:28:04 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AB721F86B2 for ; Thu, 26 Jan 2012 16:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr46Xc5e9leO for ; Thu, 26 Jan 2012 16:28:03 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BDD5D21F85AF for ; Thu, 26 Jan 2012 16:28:03 -0800 (PST) Received: by mail-iy0-f172.google.com with SMTP id f6so1720217iag.31 for ; Thu, 26 Jan 2012 16:28:03 -0800 (PST) Received: by 10.50.87.132 with SMTP id ay4mr4454732igb.2.1327624083560; Thu, 26 Jan 2012 16:28:03 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id x18sm5824417ibi.2.2012.01.26.16.28.02 (version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 16:28:03 -0800 (PST) Sender: Cullen Jennings Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4F21C7EC.2000201@acm.org> Date: Thu, 26 Jan 2012 17:28:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0A6AADFB-57D3-4057-A4E5-98CB6FC2F2D1@iii.ca> References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <92E46A75-E370-4A52-BF04-F2D811D3C0C0@softarmor.com> <4F21C7EC.2000201@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: "vipr@ietf.org" , Dean Willis Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 00:28:04 -0000 On Jan 26, 2012, at 2:38 PM, Marc Petit-Huguenin wrote: > 2) delay for RELOAD, forgive my rolling around on the floor laughing... no matter how slow = RELOAD is, I'll bet Eric Burger some fist full of untraceable cash it = will be done well before VIPR From petithug@acm.org Thu Jan 26 17:16:32 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBE221F871C for ; Thu, 26 Jan 2012 17:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.122 X-Spam-Level: X-Spam-Status: No, score=-102.122 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_RMML_Stock1=0.21, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcVSFJjPZQ8N for ; Thu, 26 Jan 2012 17:16:31 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id C31A921F8699 for ; Thu, 26 Jan 2012 17:16:31 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 21B772040F; Fri, 27 Jan 2012 01:02:09 +0000 (UTC) Message-ID: <4F21FAEA.8070306@acm.org> Date: Thu, 26 Jan 2012 17:16:26 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: Cullen Jennings References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <92E46A75-E370-4A52-BF04-F2D811D3C0C0@softarmor.com> <4F21C7EC.2000201@acm.org> <0A6AADFB-57D3-4057-A4E5-98CB6FC2F2D1@iii.ca> In-Reply-To: <0A6AADFB-57D3-4057-A4E5-98CB6FC2F2D1@iii.ca> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" , Dean Willis Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 01:16:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/26/2012 04:28 PM, Cullen Jennings wrote: > > On Jan 26, 2012, at 2:38 PM, Marc Petit-Huguenin wrote: > >> 2) delay for RELOAD, > > forgive my rolling around on the floor laughing... no matter how slow > RELOAD is, I'll bet Eric Burger some fist full of untraceable cash it will > be done well before VIPR > > Well, it's up to the WG to decide what they want to do with this problem. I really would have liked to have these drafts in good shape before passing the torch to someone else in two months, but it seems that it will not happen. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPIfrpAAoJECnERZXWan7EEE8QANxI57J7TBu50WwKQ51yvuXE xxdakmIHqlzneI5nEG2eCqUj0lnT0Pfvx3H4L6ASNI7hmj8wWVK43dwjLum3XZdz SCC6id71Np/AtkJHdcGPIbVHqA5e8UDU3NIxMzUbrXE8bNdiEhc6+sMDX9h+1RIg yLVEzEGLpGDrdcpWk6KRl+xqgW/7i4BS8QpVYymqdbegF+UFlXgucePy5UC9M09O iLX8UP2gX5rsEl6zBtqKsPgxyQXj9CvK727FipgcoitOZ3HHe86UyPFRQgEuvX9v X/8vHI15/BqGz1ZUaQ9D89gvy10HmeubJz1/1k9/mTVtDkOadS7CEUQfOVU/bHKo zlwbL+d+cM37XUm4pquCM63lqyjk587WSFvcIpuByscytgTq1gklycvdoUkTL0tC M2xvFbNR3oK9XOG1WlGf7Z1RGtGULAvskDP/5yueDZIlSXeUJZREQLjO2974zpW0 5+YQmv7M0nShCxTjntogQrSU3KMnt/7ZaPqT9wA44pB8lL2g0I5SlfKmcQ5NtYxu qqxUG2Gz6BLMVOkFEUwLNg56tM/7GhmB5saMINhjxt3gOn9+Si4iKgevEwDBv0uj +Az5tPnti8WKP55Dkq6R8d/bdJp0ePtuRVhgz1OHe5m+88obFJL51P4ImPClj7EC zqFyR9DCsvGLA99JOgtC =4XUw -----END PGP SIGNATURE----- From fluffy@fluffy.im Thu Jan 26 17:35:09 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B561011E8079 for ; Thu, 26 Jan 2012 17:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=-1.095, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMoMNyw8Btin for ; Thu, 26 Jan 2012 17:35:08 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF27B11E8072 for ; Thu, 26 Jan 2012 17:35:08 -0800 (PST) Received: by pbdu7 with SMTP id u7so844106pbd.31 for ; Thu, 26 Jan 2012 17:35:08 -0800 (PST) Received: by 10.68.73.196 with SMTP id n4mr10153702pbv.33.1327628108642; Thu, 26 Jan 2012 17:35:08 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id a5sm15727520pbh.15.2012.01.26.17.35.07 (version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 17:35:07 -0800 (PST) Sender: Cullen Jennings Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 26 Jan 2012 18:35:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric Burger X-Mailer: Apple Mail (2.1084) Cc: vipr@ietf.org Subject: Re: [VIPR] Review of VIPR Overview X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 01:35:09 -0000 Eric, thanks for the review. On Jan 20, 2012, at 5:44 AM, Eric Burger wrote: > I volunteered to review draft-jennings-vipr-overview-02, "Verification = Involving PSTN Reachability: Requirements and Architecture Overview," = during the VIPR meeting at IETF 82. My focus is on the readiness of the = document for adoption as a work group item. I did not focus on whether = the document is ready for publication. As an aside, it is NOT ready for = publication. >=20 > It is my belief the document is ready for adoption as a work group = item. The document is of a sufficient maturity, explains the problem, = and is mostly self-consistent. There are a number of items left for = work group discussion, but they are not substantial open issues, which = would indicate the document would not be ready for work group adoption. >=20 > What follows are my comments on the document. Consider them as a = potential starting point for work group discussion. >=20 >=20 > GENERAL > =3D=3D=3D=3D=3D=3D=3D > This document reads like a patent application and product = advertisement all rolled up into one. There is no value in trying to = convince the reader that VIPR is novel, fundamentally different that = what was out there, clever, or neat (all language taken from the draft). = Such language is distracting for an implementor. More to the point, we = want implementors focusing on implementation, not thinking about how to = show that one feature or another is not novel. mostly agree - always hard to decide how much the document should go = into what problems this solves and where it is useful. That's not useful = info for implementer but it is useful for someone considering deploying. = But of course I agree with about gratuitous advertising can go. I've = order a t shirt with "patent application and product advertisement all = rolled up into one" > The most egregious examples of this language are Sections 5.3.1 in = the second paragraph ' Looks like deleting "neat", "clever" , "incredible " , and "enormous" = would fix this paragraph.=20 > and 2.2 discussing how email is useless. I would not want an = implementor to think, "Well, I just received this via email, so if the = assertion is email is useless, this protocol must be useless." How would you suggest a rephrase of email is useless.... (send over = email please) >=20 >=20 > FORWARD (or no) REFERENCES > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > There are a number of forward references or references to items that a = PSTN telecom engineer might be familiar with, but an Internet engineer = might not be familiar with. For example, REQ-2 refers to E.164 numbers. = This is the first we hear of E.164 numbers. I would offer that = mentioning that when we say Phone Number, we mean an E.164 number. A = good place for that would be in Section 2.1. Include a reference to = E.164 there, too. +1=20 >=20 > REQ-12: what is call handover? This word appears only once, here. I = know what that means in the PLMN, but I do not know what it means in the = SIP world. I suspect we could just delete this and no one would care.=20 > Call Agent: for a while, I thought I was reading an H.323 document, = not a SIP document. I can get why one does not want to call the thing = that knows VIPR a SIP User Agent, because it does more than a SIP User = Agent. If one wants to use the term "Call Agent," one must define it = somewhere, preferably at the beginning of the document. However, given = the confusion with H.323 Call Agents, I would offer one either selects a = different term, or perhaps use "VIPR-enabled User Agent." Call Agent used to be PBX but then it got replaced .... > Ticket: Section 5.3.3 starts talking about generating tickets, but = never defines what a ticket is. The reader has to read the whole = document to figure that one out. >=20 > Section 5.3.4 talks about cached routes and 'next call agent in the = path.' However, the document never discusses chains of call agents, = multiple routes (except in an aside in the previous paragraph to the = reference to the path), or what a path is. In fact, this is the sole = appearance of the word 'path' in the document. >=20 >=20 > OTHER > =3D=3D=3D=3D=3D > REQ-4: Users do not make the federation; they make calls. Is not the = requirement that without doing anything different users can now do = inter-domain IP calls? Perhaps change=20 OLD in inter-domain IP federation NEW in inter-domain calls using IP >=20 > REQ-11: This describes a solution, not a requirement. I would offer = language such as "The solution should be self-learning and adapt to VIPR = call failures." This needs to be rewritten. What it is trying to get at is a requirement = that if the new IP based calls are not working, the systems fall back to = doing inter domain calling in whatever way they did before=20 >=20 >=20 > NITS > =3D=3D=3D=3D > Page 11, 2nd list entry: s/SIP endpoints, or with non-IP/SIP endpoints = and with non-IP/ +1 >=20 > Page 11, 7th list entry: Never, Ever? One Never is good enough. This = whole section needs to be made relevant to implementors or be removed. = See the comment above about patent and marketing language in = specification documents. +1 > Page 21, 3rd from last paragraph in Section 5.3.4, floating period = after the string "Section 5.3.3 ." +1 >=20 > Page 24, Acknowledgements: let me in on the joke: I could imagine Theo = being a thief of numbers. Maybe in the fifth Ring [sic]. If he really = is, I would suggest saying "5th thief [sic]". Otherwise, I would suggest = saying "5th theft", if that is what the document means. >=20 > _______________________________________________ > VIPR mailing list > VIPR@ietf.org > https://www.ietf.org/mailman/listinfo/vipr From fluffy@fluffy.im Thu Jan 26 17:38:00 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3E221F85B6 for ; Thu, 26 Jan 2012 17:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf8f3L4JmZbV for ; Thu, 26 Jan 2012 17:38:00 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E65921F8597 for ; Thu, 26 Jan 2012 17:38:00 -0800 (PST) Received: by pbdu7 with SMTP id u7so845626pbd.31 for ; Thu, 26 Jan 2012 17:38:00 -0800 (PST) Received: by 10.68.135.1 with SMTP id po1mr10378310pbb.16.1327628280304; Thu, 26 Jan 2012 17:38:00 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id n8sm15782792pbq.7.2012.01.26.17.37.59 (version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 17:37:59 -0800 (PST) Sender: Cullen Jennings Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4F21FAEA.8070306@acm.org> Date: Thu, 26 Jan 2012 18:37:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <92E46A75-E370-4A52-BF04-F2D811D3C0C0@softarmor.com> <4F21C7EC.2000201@acm.org> <0A6AADFB-57D3-4057-A4E5-98CB6FC2F2D1@iii.ca> <4F21FAEA.8070306@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: vipr@ietf.org Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 01:38:01 -0000 On Jan 26, 2012, at 6:16 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > On 01/26/2012 04:28 PM, Cullen Jennings wrote: >>=20 >> On Jan 26, 2012, at 2:38 PM, Marc Petit-Huguenin wrote: >>=20 >>> 2) delay for RELOAD, >>=20 >> forgive my rolling around on the floor laughing... no matter how slow >> RELOAD is, I'll bet Eric Burger some fist full of untraceable cash it = will >> be done well before VIPR >>=20 >>=20 >=20 > Well, it's up to the WG to decide what they want to do with this = problem. agree > I > really would have liked to have these drafts in good shape before = passing the > torch to someone else in two months, but it seems that it will not = happen. >=20 I'd love to see VIPR all in good shape by Paris. If I had to guess, I = would give RELOAD a 35% chance of being IESG approved by Paris.=20 From rbarnes@bbn.com Fri Jan 27 07:08:46 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7499121F85E3 for ; Fri, 27 Jan 2012 07:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.278 X-Spam-Level: X-Spam-Status: No, score=-106.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5E2tEbkrTyX for ; Fri, 27 Jan 2012 07:08:46 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id EFACB21F85E1 for ; Fri, 27 Jan 2012 07:08:45 -0800 (PST) Received: from ros-dhcp192-1-51-95.bbn.com ([192.1.51.95]:64536) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RqnPr-000BNm-KQ; Fri, 27 Jan 2012 10:08:39 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <5466D9E6-3859-41A7-9A54-D23DC6D775C6@iii.ca> Date: Fri, 27 Jan 2012 10:08:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <4F2183D0.3070809@acm.org> <373FB643-AE7A-473C-A7AB-09F9A9E7093B@bbn.com> <4F21A121.10403@acm.org> <5466D9E6-3859-41A7-9A54-D23DC6D775C6@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: "vipr@ietf.org" Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 15:08:46 -0000 Could we please distinguish between "location privacy" and "IP address = privacy"? They are related, but distinct concepts. On Jan 26, 2012, at 7:28 PM, Cullen Jennings wrote: >=20 > On Jan 26, 2012, at 11:53 AM, Marc Petit-Huguenin wrote: >=20 >> Cullen's email in >> P2PSIP was unambiguous in saying that doing this will push VIPR to = 2015/2020. >=20 > That is not at all what I said. The 2020 was a date where I think we = might be possible to have a location privacy solution. As folks may = recall from the BOFs when P2PSIP was formed, Cisco had expressed that = one of these cases it was interested in was when the communications were = not at all anonymous but the location needed to be. The example used as = Vice President of the US during an emergency may be moved to a location = that is kept very secret but they need to communicate security and with = authentication to a large number of people. Todays internet protocols = don't offer much in the form of location privacy - with the possible = exception of TOR. Some person with General in their title even showed up = at Vancouver and Prague IETFs. When P2PSIP got chartered, location = privacy got drooped out because it was viewed as it would just be too = much to solve. I think I argued for doing location privacy at the time = but I was wrong - it clearly would have been too much to do in the first = version.=20 >=20 > However, I still hope that we might have a standards based location = privacy system by 2020 but others think it is better to do this type of = thing just a a proprietary system so who knows.=20 >=20 >=20 >=20 From petithug@acm.org Fri Jan 27 07:19:32 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418F721F8601 for ; Fri, 27 Jan 2012 07:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.235 X-Spam-Level: X-Spam-Status: No, score=-102.235 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+TD1XPe8V0O for ; Fri, 27 Jan 2012 07:19:31 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6E021F85E0 for ; Fri, 27 Jan 2012 07:19:31 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 1CBB320143; Fri, 27 Jan 2012 15:05:05 +0000 (UTC) Message-ID: <4F22C07D.2090809@acm.org> Date: Fri, 27 Jan 2012 07:19:25 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <4F2183D0.3070809@acm.org> <373FB643-AE7A-473C-A7AB-09F9A9E7093B@bbn.com> <4F21A121.10403@acm.org> <5466D9E6-3859-41A7-9A54-D23DC6D775C6@iii.ca> In-Reply-To: X-Enigmail-Version: 1.3.4 X-Enigmail-Draft-Status: 513 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" , Cullen Jennings Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 15:19:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/27/2012 07:08 AM, Richard L. Barnes wrote: > > > Could we please distinguish between "location privacy" and "IP address > privacy"? They are related, but distinct concepts. Yeah, my mistake. I thought that Cullen was responding to my concern about IP address privacy in his email to p2psip. This said, I think that adding one hop to hide the IP address is not enough, and I believe that onion routing is the way to go to solve the IP address privacy - which may or may not also solve the location privacy problem. The interesting part is that business goals are, in this particular case, aligned with privacy advocates. In any case, even if Cullen was talking about something different, I do not think that the dates he provided are wrong. > > > > On Jan 26, 2012, at 7:28 PM, Cullen Jennings wrote: > >> >> On Jan 26, 2012, at 11:53 AM, Marc Petit-Huguenin wrote: >> >>> Cullen's email in P2PSIP was unambiguous in saying that doing this >>> will push VIPR to 2015/2020. >> >> That is not at all what I said. The 2020 was a date where I think we >> might be possible to have a location privacy solution. As folks may >> recall from the BOFs when P2PSIP was formed, Cisco had expressed that one >> of these cases it was interested in was when the communications were not >> at all anonymous but the location needed to be. The example used as Vice >> President of the US during an emergency may be moved to a location that >> is kept very secret but they need to communicate security and with >> authentication to a large number of people. Todays internet protocols >> don't offer much in the form of location privacy - with the possible >> exception of TOR. Some person with General in their title even showed up >> at Vancouver and Prague IETFs. When P2PSIP got chartered, location >> privacy got drooped out because it was viewed as it would just be too >> much to solve. I think I argued for doing location privacy at the time >> but I was wrong - it clearly would have been too much to do in the first >> version. >> >> However, I still hope that we might have a standards based location >> privacy system by 2020 but others think it is better to do this type of >> thing just a a proprietary system so who knows. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPIsB7AAoJECnERZXWan7EnAAQAMR/u2bdaWVmZ9yJMgbwkaR0 a90eVoqftISpEKNlK6vHPGsGmPo3R28Gaysbk2y+ssxVIVV5rlC6mdKq7XUjPrqa akumo5S/hGRZ0ZINvG/HSYkCOQP1yyBJqlXFDa+ZTy2hsxJc9eKcrUxCGYVTzok2 yZjrM0ZknfAE4cEd3Xra2LUOQqLx4KQ7TFvtR/+Kn+tldi0bSe7b3CLDKZNAR17X bOLDil+YtJE+PQmPtF7OMkj7InoVXaH0nCJLpxagAskBaNYyW4UPKc3MjSOMw2OM WSlz1FK3OeTv4vrcjz/lsseYk4FBIPGXVdy+AxYBrjfxsuKUfayTEK4DM8Z9SD2f fvSO4cwiWbxfuBvN6KSgmv1cDYEHTLDT4I5rlu4sAAqpPNQc8NM9TGlDdvLMYACq 9XLb7VUdUggXL/MwENIEno6VzT1fh2k6blxuIeS2Asb6CYLbBzlB9xwNRyphjZHM pPZzs3U/eDMflwerX8I3y88oNleIKJHWsJbyO5lJZLr3adwFVCggZ5uOvsi60NK7 xoR+H9yNRBx5TFr72f1OeGYNjOriIHk6hJ55TtvP0sJiNtnoRFsMJOzZsMgWGPdO D8rWy1t4NVi7RkP+c/wmsWQw/gPxeTawFaZIa0tkex7hI0rJ8QDcENZqX06iMYcn LRSBEHfBzoHJnhdp1qgc =YLG2 -----END PGP SIGNATURE----- From kpfleming@digium.com Fri Jan 27 07:39:23 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1D121F850D for ; Fri, 27 Jan 2012 07:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myxvLalgqWq8 for ; Fri, 27 Jan 2012 07:39:22 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 397A221F850F for ; Fri, 27 Jan 2012 07:39:22 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RqntZ-0008OV-GD for vipr@ietf.org; Fri, 27 Jan 2012 09:39:21 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 77A64D8004 for ; Fri, 27 Jan 2012 09:39:21 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzUxrl1BYIGl for ; Fri, 27 Jan 2012 09:39:20 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id E5FE5D8002 for ; Fri, 27 Jan 2012 09:39:20 -0600 (CST) Message-ID: <4F22C528.6080706@digium.com> Date: Fri, 27 Jan 2012 09:39:20 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: vipr@ietf.org References: <4F1F1A42.1030201@acm.org> <26235819-9BF3-453F-81F5-F5351F648D4C@iii.ca> In-Reply-To: <26235819-9BF3-453F-81F5-F5351F648D4C@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [VIPR] VIPR privacy issue X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 15:39:23 -0000 On 01/26/2012 06:27 PM, Cullen Jennings wrote: > For some of the attacks on ViPR, the best defense is to make sure your PSTN numbers are registered. I view this as feature of the design. I'm sure opinions vary on this. Wearing a 'businessperson' hat, I just don't see how this is an acceptable situation. This would be similar to saying that if you don't choose to advertise in the Yellow Pages, other companies can do it in a way that lets them know who your customers are. Granted, there might not be much of a direct cost to participate in a public ViPR cloud, but there are certainly significant potential indirect costs for companies who don't have the equipment/software in place to participate from day one. In addition, wearing my 'paranoia' hat, who is to say that there won't be multiple (possibly many) ViPR clouds being used to route E.164 numbers? For each one that exists, anyone who wishes to best defend their numbers must participate. I suppose one way to look at this is that it will potentially spawn a whole new industry of 'ViPR protection service' companies :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From mary.ietf.barnes@gmail.com Fri Jan 27 13:16:42 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CDE21F86D0 for ; Fri, 27 Jan 2012 13:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=-1.255, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qoiQuKXm73J for ; Fri, 27 Jan 2012 13:16:40 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 07BC121F86D6 for ; Fri, 27 Jan 2012 13:16:39 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so1673068vbb.31 for ; Fri, 27 Jan 2012 13:16:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DiNfbfYOvgJnojoBLTIY/Fp6FdEXKZPSdjmnhEpyjw0=; b=OY+gsVpeabZENS1yuVyQDF1rWxvJCiZ0nChAtvfp3sy13AqB9QR81phM9kzdPDcyuQ qGvoZJFZNtJbHXQ6BGjrzGy5uTZd2J46ZRskfja+umtjL3nD4IN5nZIw+9E+iC/sWUUG S1t6eSwuC5NIWibkz1pf8WtdLPgyzzuUdhGfY= MIME-Version: 1.0 Received: by 10.52.67.35 with SMTP id k3mr3756890vdt.38.1327698999483; Fri, 27 Jan 2012 13:16:39 -0800 (PST) Received: by 10.52.108.196 with HTTP; Fri, 27 Jan 2012 13:16:39 -0800 (PST) In-Reply-To: References: Date: Fri, 27 Jan 2012 15:16:39 -0600 Message-ID: From: Mary Barnes To: Eric Burger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vipr@ietf.org, Cullen Jennings Subject: Re: [VIPR] Review of VIPR Overview X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 21:16:42 -0000 Eric, Thanks also for the review. Just a few additional comments below [MB]. Mary. On Thu, Jan 26, 2012 at 7:35 PM, Cullen Jennings wrote: > > Eric, thanks for the review. > > On Jan 20, 2012, at 5:44 AM, Eric Burger wrote: > >> I volunteered to review draft-jennings-vipr-overview-02, "Verification I= nvolving PSTN Reachability: Requirements and Architecture Overview," during= the VIPR meeting at IETF 82. =A0My focus is on the readiness of the docume= nt for adoption as a work group item. =A0I did not focus on whether the doc= ument is ready for publication. =A0As an aside, it is NOT ready for publica= tion. >> >> It is my belief the document is ready for adoption as a work group item.= =A0The document is of a sufficient maturity, explains the problem, and is = mostly self-consistent. =A0There are a number of items left for work group = discussion, but they are not substantial open issues, which would indicate = the document would not be ready for work group adoption. >> >> What follows are my comments on the document. =A0Consider them as a pote= ntial starting point for work group discussion. >> >> >> GENERAL >> =3D=3D=3D=3D=3D=3D=3D >> This document reads like a patent application and product advertisement = all rolled up into one. =A0There is no value in trying to convince the read= er that VIPR is novel, fundamentally different that what was out there, cle= ver, or neat (all language taken from the draft). =A0Such language is distr= acting for an implementor. =A0More to the point, we want implementors focus= ing on implementation, not thinking about how to show that one feature or a= nother is not novel. > > mostly agree - always hard to decide how much the document should go into= what problems this solves and where it is useful. That's not useful info f= or implementer but it is useful for someone considering deploying. But of c= ourse I agree with about gratuitous advertising can go. I've order a t shir= t with "patent application and product advertisement all rolled up into one= " > >> =A0The most egregious examples of this language are Sections 5.3.1 in th= e second paragraph > ' > Looks like deleting "neat", "clever" , "incredible " , and "enormous" wou= ld fix this paragraph. [MB] I actually did try to tone down the language, but I can se that another pass would be helpful - I did at least remove all instances of "nirvana". > >> and 2.2 discussing how email is useless. =A0I would not want an implemen= tor to think, "Well, I just received this via email, so if the assertion is= email is useless, this protocol must be useless." > > How would you suggest a rephrase of email is useless.... (send over email= please) [MB] How about something like the following? However, the email system has now become plagued with spam. This has resulted in administrators spending a significant amount of time maintaining spam filters. This does not always benefit the end users as in some cases valid emails are dropped without the user being notified. [/MB] >> >> >> FORWARD (or no) REFERENCES >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >> There are a number of forward references or references to items that a P= STN telecom engineer might be familiar with, but an Internet engineer might= not be familiar with. =A0For example, REQ-2 refers to E.164 numbers. =A0Th= is is the first we hear of E.164 numbers. =A0I would offer that mentioning = that when we say Phone Number, we mean an E.164 number. =A0A good place for= that would be in Section 2.1. =A0Include a reference to E.164 there, too. > +1 > >> >> REQ-12: what is call handover? This word appears only once, here. I know= what that means in the PLMN, but I do not know what it means in the SIP wo= rld. > > I suspect we could just delete this and no one would care. [MB] There have been several documents related to handover of SIP calls, including these two: http://www.cs.columbia.edu/~hgs/papers/Schu0007_Application.pdf http://www1.cs.columbia.edu/~andreaf/documents/other/pdad/ashutosh-dutta.pd= f There were drafts associated with those papers at one time and I thought one had been published, but can't find it right off. The first two papers use the term handoff in the body of the documents. Here's a GSM focused paper that uses handover: http://www.cttc.cat/resources/doc/071029-voip-umts-icc07-uploaded-cttc-3356= 6.pdf The terms are synonymous - handover is used in the GSM specs and handoff in the CDMA specs. That all said, I don't see that this applies directly to VIPR, so I think it can be dropped. [/MB] > >> Call Agent: for a while, I thought I was reading an H.323 document, not = a SIP document. I can get why one does not want to call the thing that know= s VIPR a SIP User Agent, because it does more than a SIP User Agent. =A0If = one wants to use the term "Call Agent," one must define it somewhere, prefe= rably at the beginning of the document. =A0However, given the confusion wit= h H.323 Call Agents, I would offer one either selects a different term, or = perhaps use "VIPR-enabled User Agent." > > Call Agent used to be PBX but then it got replaced .... [MB] From what I could find, there is a certain vendor that uses the term "call agent" to refer to SIP User Agents.I don't know that calling it a VIPR-enabled User Agent is quite correct as the UA does not necessarily have to be VIPR-enabled to use VIPR. The call agent is a more generic term - it could be the UA that is VIPR-enabled or another entity. I think the problem is an inconsistency. When Call agent is first used in the 2nd paragraph in 5.3, it is referring to a User Agent, however, in section 5.3, it is used to refer to an entity that can be handling multiple phones/UAs - to me this implies something like a state-ful SIP Proxy : The call agent is connected to one or more phones in the domain, and is responsible for routing calls, handling features, and processing call state. The call agent is stateful, and is aware of when calls start and stop. Elsewhere, it also states that the this entity in the first context (Alice and Bob) can be any sort of endpoint - not just SIP, so you are correct that we shouldn't call it a SIP UA. Why don't we just use the term "User Agent" when we are referring to the entity that Alice and Bob use to make calls and leave Call Agent as is elsewhere. My understanding is that a Node-ID gets you to a Call Agent which then can access the mapping to the specific UA. We can define Call Agent to be the entity in a domain that handles the mappings, etc. I think the problem really is that we split the overview document into two parts - an overview (this doc) and then a framework document. the -01 version of the overview document clearly defines Call agent: 6.2. Call Agent The call agent is a box within the domain which performs call processing on behalf of one or more phones within the domain. ViPR can work with a wide variety of call agents, as long as they meet some specific criteria: o The call agent must be know of the start time, stop time, caller ID, and called numbers of calls placed from phones towards the PSTN. o The call agent must be capable of making routing decisions for outbound calls from phones that would otherwise go to the PSTN, directing them towards the PSTN or towards other domains (based on ViPR routing rules). So, I think we might need to revisit how we've split the material or include some more forward references. [/MB] > >> Ticket: Section 5.3.3 starts talking about generating tickets, but never= defines what a ticket is. =A0The reader has to read the whole document to = figure that one out. [MB] I think the problem is that when the ticket concept is first introduced in 5.3.3, it's stated as a "form of shared secret" and it's not clear that it means the ticket. We can make it clear there and add a definition to the terminology section. [/MB] >> >> Section 5.3.4 talks about cached routes and 'next call agent in the path= .' =A0However, the document never discusses chains of call agents, multiple= routes (except in an aside in the previous paragraph to the reference to t= he path), or what a path is. In fact, this is the sole appearance of the wo= rd 'path' in the document. [MB] There is a note that we need to figure out whether or not we need to or feel we should allow multiple routes. If so, we probably need to add a section somewhere - maybe not here but in framework document about this functionality. We kindof have a chicken/egg situation because we're trying to give a run through of the functionality in this doc, but you really have to read the framework to understand some of this. I'm not quite sure of the way around - maybe simplify some of the text in this section and include a reference to the framework document. [/MB] >> >> >> OTHER >> =3D=3D=3D=3D=3D >> REQ-4: Users do not make the federation; they make calls. Is not the req= uirement that without doing anything different users can now do inter-domai= n IP calls? > Perhaps change > > OLD > in inter-domain IP federation > > NEW > in inter-domain calls using IP > >> >> REQ-11: This describes a solution, not a requirement. I would offer lang= uage such as "The solution should be self-learning and adapt to VIPR call f= ailures." > This needs to be rewritten. What it is trying to get at is a requirement = that if the new IP based calls are not working, the systems fall back to do= ing inter domain calling in whatever way they did before > >> >> >> NITS >> =3D=3D=3D=3D >> Page 11, 2nd list entry: s/SIP endpoints, or with non-IP/SIP endpoints a= nd with non-IP/ > +1 > >> >> Page 11, 7th list entry: Never, Ever? One Never is good enough. This who= le section needs to be made relevant to implementors or be removed. =A0See = the comment above about patent and marketing language in specification docu= ments. > +1 > >> Page 21, 3rd from last paragraph in Section 5.3.4, floating period after= the string "Section 5.3.3 ." > +1 > >> >> Page 24, Acknowledgements: let me in on the joke: I could imagine Theo b= eing a thief of numbers. =A0Maybe in the fifth Ring [sic]. =A0If he really = is, I would suggest saying "5th thief [sic]". Otherwise, I would suggest sa= ying "5th theft", if that is what the document means. [MB] The problem is that the security section only addresses 4 threats, so I have no idea what that comment means either. [/MB] >> >> _______________________________________________ >> VIPR mailing list >> VIPR@ietf.org >> https://www.ietf.org/mailman/listinfo/vipr > > _______________________________________________ > VIPR mailing list > VIPR@ietf.org > https://www.ietf.org/mailman/listinfo/vipr From fluffy@fluffy.im Sat Jan 28 09:23:22 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE3321F8508 for ; Sat, 28 Jan 2012 09:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yO5qvIBfBto for ; Sat, 28 Jan 2012 09:23:21 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBFA21F845C for ; Sat, 28 Jan 2012 09:23:10 -0800 (PST) Received: by dado14 with SMTP id o14so2725652dad.31 for ; Sat, 28 Jan 2012 09:23:10 -0800 (PST) Received: by 10.68.209.39 with SMTP id mj7mr24692517pbc.25.1327771390535; Sat, 28 Jan 2012 09:23:10 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id li19sm30461053pbb.17.2012.01.28.09.23.08 (version=SSLv3 cipher=OTHER); Sat, 28 Jan 2012 09:23:09 -0800 (PST) Sender: Cullen Jennings Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Sat, 28 Jan 2012 10:23:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2C186333-87E9-42B6-8A49-AF74EB2C9222@iii.ca> References: To: Mary Barnes X-Mailer: Apple Mail (2.1084) Cc: vipr@ietf.org Subject: Re: [VIPR] Review of VIPR Overview X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 17:23:22 -0000 On Jan 27, 2012, at 2:16 PM, Mary Barnes wrote: >>>=20 >>> Page 24, Acknowledgements: let me in on the joke: I could imagine = Theo being a thief of numbers. Maybe in the fifth Ring [sic]. If he = really is, I would suggest saying "5th thief [sic]". Otherwise, I would = suggest saying "5th theft", if that is what the document means. > [MB] The problem is that the security section only addresses 4 > threats, so I have no idea what that comment means either. [/MB] The attack that Theo pointed out was the one described in last para of = 6.2 which reads=20 An attacker could make a call so they know the call details of the call they made and use this to forge a validation for that call. They could then try to convince other users, which would have to be in the same domain as the attacker, to trust this validation. This is mitigated by not sharing validations inside of domains where the users that can originate call from that domain are not trusted by the domain. It's a good attack and Theo should get credit for pointing this out.=20 From petithug@acm.org Mon Jan 30 08:52:48 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1D411E8071 for ; Mon, 30 Jan 2012 08:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.246 X-Spam-Level: X-Spam-Status: No, score=-102.246 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qB4ak4X4a+Q8 for ; Mon, 30 Jan 2012 08:52:46 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 7817C21F855A for ; Mon, 30 Jan 2012 08:52:38 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 1EAC820142 for ; Mon, 30 Jan 2012 16:38:02 +0000 (UTC) Message-ID: <4F26CAD2.1030402@acm.org> Date: Mon, 30 Jan 2012 08:52:34 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Minutes release delayed X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 16:52:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Yesterday I lost the finished version of the minutes so I have to re-transcript the last 35 minutes, but I have first to regenerate the audio file, which takes 2 or 3 more hours. I hope to be able to send them around noon. Sorry for that. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPJsrRAAoJECnERZXWan7Ev0IQAN7p4Rxwha9DAmMOilDtsNkO qHfTgWz/DmG/Ca/Uo/GTgP1LgIkipPWcZ7ASWBXKs/Pn8tJ/oxEuX4ZHHr5WpUFc +4f0Eko87b59GW9R2y/HuiSls6GTX1C+g8kEzdkznbpidX7kcbJXnWcanHc/3XiV N6h7/v252moda6GWSLVhb2sKkrZCS041JleKrLQqG+9bvcve6ZetNaV3Md6q05w+ JI2qyT6GrLTt75lt+LBHjKccJCPSbV2vzi0d9DCzJKEkD26rcEjPVu4wZf0eVZ5z Cl+9jkqRM/5v2keMm/1mMrubM/daLN/D6CcGgbfzGwhixyy34j0C4UWJ2qZK9w5p 694ugwrdDnlFgDm9I7YYocCbnxSg/8Dx+BArn89EoQQOhlxAQoWGTKfgF2ohPaUz mYRzveMljhmC4MUsZLBgn//f9W1troH5Hi6Gta0Rv4I6AlEL5hwd5De7jlJZP7V8 +PcE8WjIrCiVRTdcC/ewiRRiBR2xOMhEYgSqBSk/n98LcHPnWkUI4gFNEuPZQ/Uk 5ehD+IXouapl1aJUTMd3bsiB4vBNrQSNFH6cLcqKHvTfbOkuXIDQS8YQP20TXjL7 dOwdJDBLkPbIK19WHQNTYF39Jp2HEr95F/6aKvAUP1OZZ/nVKQj2xW6+/MT1+MeB xeicel84WhU9APUhPm/b =W1bR -----END PGP SIGNATURE----- From petithug@acm.org Mon Jan 30 15:50:09 2012 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A57411E80EA for ; Mon, 30 Jan 2012 15:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.266 X-Spam-Level: X-Spam-Status: No, score=-102.266 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJuq84yWMbdo for ; Mon, 30 Jan 2012 15:50:07 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 6462C11E80F4 for ; Mon, 30 Jan 2012 15:50:07 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 0F0C420142 for ; Mon, 30 Jan 2012 23:35:30 +0000 (UTC) Message-ID: <4F272CAC.5030905@acm.org> Date: Mon, 30 Jan 2012 15:50:04 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Minutes for 2012/01/27 conference call X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 23:50:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 VIPR Design Team conference call on Friday January 27h, from 9:05am to 9:55am PST. o Attendees: Mary Barnes Kurt Bergsbaken Daryl Malas Hakim Mehmood Jon Peterson Marc Petit-Huguenin Michael Procter John Ward Dean Willis o Regrets Muthu Arul Mozhi Perumal o Agenda - - Privacy issue o Action items - - We continue working on VIPR. - - Michael to update his document, please send text. o Minutes Marc: I propose to talk about the privacy problem is 3 steps. First we need to agree that this is really a problem. Option 4, proposed by Richard Barnes, was to not do anything about this. If we agree that this is problem, then the second question is do we agree that this requires modification in RELOAD. Then the 3rd step would be to decide what to do, knowing that doing anything in RELOAD will take a long time. Daryl: If this problem has not shown itself in p2psip, I am curious to know if this problem is unique to VIPR, and then to decide if we want to do any modification to RELOAD. Marc: My original plan was to work on VIPR until December, I extended for 3 months, but after the meeting in Paris I will no longer be able to put as much work on VIPR. So let's be sure that we have some kind of decision at the end of this meeting, so I know if I am going to Paris or not. Marc: So is this privacy issue really a problem? Dean: This is a real problem. You have a 50% chance of being in the first attempt of verifying the connection, and for every registration you increase your odds. Michael: It's right if you stop after the first success. Jon: The reason for doing that relates to things that are still controversial, like SIP intermediaries. From my perspective, it's an interesting problem, but I do not think that it is a showstopper in the sense that I do not think that VIPR is worthless if it has this liability. I would be comfortable with documenting the problem, and measures that mitigates it. And I would also be comfortable with saying is there a way to really do an anonymous DHT, but it's almost a research project. But I certainly do not think that it render useless and that we should go home. Hakim: I agree with everything you said. Marc: Should we put a requirement in the -overview document saying that we must fix this privacy problem, and is it just something that we should work on in the future? Jon: There is specific threat models that we can discuss. There is a difference between someone who register for one number and someone who register for all numbers. For example this is an argument to not go through all registrations. But there is no fix for this, as there is no fix for SIP security issues. Daryl: I agree with that. There is a lot of architectures that VIPR works very well within. Dean: There is potential mitigation that we can build going forward. For example adding a web of trust. Alice calls Bob and successfully validates, then Alice put something in the overlay saying this, then Charlie, who has an existing relationship with Alice might then be more inclined to trust the validation of Bob. This is things that we can address going forward. We can also came with suggestions for RELOAD, and have the RELOAD design change over time, but they will not change RELOAD in this round. But that does not prevent a first version of the protocol to be released. Daryl: I like that approach. To go back to what Jon said, in the early days of SIP, there was concerns around security issues, workarounds were documented, but still people do not implement them - people still are not doing SIP over TLS. Michael: There is plenty of things we can do to attack the problem, but if we continue with the idea that there will be only one VIPR network, globally, that make it a lot harder for us to solve these problems. If we define things that should work with a group of participants, then I think that we can make something that has all the properties for that group of users. But if we focus on one overlay for the whole planet, then these problems will really bite. Jon: I am sure that the designers of VIPR would be reluctant to give up the property that there something that everyone can join and that it is public. I would prefer that we keep that property. Daryl: Are you suggesting to have multiple VIPR networks, and have some sort of inter-domain communication? Jon: Michael is suggesting that it is the public nature of VIPR that is creating all these problems. If you imagine a closed trusted community of enterprises, that would be one way to prevent rogue party to entering and putting bogus registrations. Cullen alluded to a common CA, so if everybody follow a trust anchor, we can trace who everybody who is participating is. Daryl: So it's a federation that's being established. Jon: That does not change RELOAD. Changing RELOAD will not happen in any reasonable time. Daryl: I totally agree. And I agree with the federation that you described. Jon: Michael, do you think that the only way to combating this is to split the overlay, or do you think there is alternatives? Michael: For some of the attacks we can probably work out mitigation while maintaining a single DHT. But I do not think that we can capture all the problems, and I fear that we will end up with one DHT that cause this huge problem. A lot of these problems seems to go away if you deploy in small groups, so maybe one approach is to finish off a version of VIPR that is suitable for groups that prominently trust each other. Jon: Does the current specification mandates a single overlay? Marc: The specification assumes only one DHT. Dean: Even with one VIPR cloud, one could imagine adding information in the overlay to track the relationship between CAs. Marc: This is not a small modification of VIPR. Jon: A lot of the mitigation solutions would be looking at the registrations deciding why one is preferred over the others. Hakim: You could have one more step where the Fetch comes from your trusted domain, so you do not start PVP. Jon: It's like a whitelist, The original design was really to have an introductory system, to be a way to use the PSTN as a bootstrap. We can argue to a point where it's no longer doing what it's supposed to do. Hakim: It's part of the mitigation. At the end the goal is for everybody to use VIPR with confidence, and not undermine privacy and security, but those measures should be recommended, not mandated. Marc: If we can anonymize the PVP connection and the RELOAD transactions, then we can solve this problem without adding more verifications. Hakim: Agreed. Jon: I am not even sure where to start with that. That's almost a research problem. Marc: Yes and the problem is that RELOAD is not the best place to do that currently. Jon: I agree that anonymyzing RELOAD would be great, but that would require a new working group, a different charter, and would complete in 5/7 years. If we want to continue, our job is to figure how to mitigate with the current system. Hakim: Was your comment about anonymizing the IP address? Jon: Yes, because from the source IP address you can find the enterprise. Hakim: If we use TURN and method B, it would hide the source IP address and the Caller-ID. Jon: The problem with TURN is that you do not necessarily trust the people you are asking. You need several hops, to have a reasonable assurance that the nodes you are using are not bad actors. And I suspect that would be a very different model for RELOAD. Michael: You still leak the fact that someone has requested the record for that phone number. Jon: That's why it's important to articulate the whole set of threats. But if your could solve the problem of hiding analytics, the bittorrent community would be so thrilled. Michael: But the point is that with bittorrent, who have the choice to not participate, but with VIPR, you do not. Jon: When I was first reading about this problem, I though about fixing it the other way: is there anyway we can get as many registrations done as possible. There is the interesting property that says that as soon the validation is done, you are no longer vulnerable, until you need a revalidation. But the result for an attacker will be very unpredictable. Michael: I agree. John: We are talking for the point of view of an attacker, but there is all kind of usages for intermediaries. For example I can query the DHT and determine the network topology of my competitors. Jon: The network topology under VIPR is pretty flat. John: We will not get away from the point where there will not be intermediaries. Jon: It's another approach to privacy. Dean : Yes, if there is 3 aggregators in the world, there is not much information leak. Jon: We need to document thoroughly that the threat is first. One is where someone is curious about a particular phone number. Another is to collect information on any number. For each of these threats we need to understand what they can accomplish, do we have any way to detecting it, and finally what change to the design we can make to mitigate that. Daryl: Would this potentially cause a situation where these become just proprietary VIPR. I do not want to say at the end to go to one vendor. Dean: How would we block aggregator choice of delivery? Daryl: The goal is to encourage various vendors to participate, not to create these proprietary aggregations that never talk to each other. Jon: We can add compromising RELOAD to the list of threats. Dean: Do we have something like the voice hammer attack? Marc: There is a quota mechanism in RELOAD, so the more registrations you put on the network, the more hardware you need to contribute. Jon: Yes, these are active attacks. But we should separate the from the passive attacks. The privacy attacks are discoverable, because you can look after the fact. Dean: You can also do self verification of validation, i.e. audit your phone number and if there is strange registrations, make inquiries. Jon: Yes, each time there is a failed validation you can record it, and we can flag the source. Marc: Yes and remember that in RELOAD there is a blacklist mechanism, so the people responsible for the overlay configuration document can prevent specific nodes to join. But note that it is not because a registration fails that the guy at the other side is a bad guy. There is a lot of reasons why a registration can fail and still be a legitimate node. We do not want to go overboard, and create a new attack that prevent the right owner to participate. Jon: Yes, but if every node reports that there is a problem with a particular entity, then there is a consensus that there is a problem. Marc: OK, we have a consensus that we should continue to work on this, and we agree to document the use cases. Michael: Please send text. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPJyymAAoJECnERZXWan7EbaEQAIa+zCMXY3LW+t2SyX5iwXqG DVSIbYWpVFM06Z+yWj+Z7pOaWal2GrfIsqHyhHTj2r2HCakW7Q/fA5LRqg+58K/c nJwJEuioyLyh25OWbQ1xd0bdcxySIKyXD4EXYLHbOAxwEG3OfT1kieva9+ja0RNt qMQZnNOjRr70gomhDPjLUejTiVc1zeUSNyDLNG3WbhfYjAvoM2/YEVfyej5f93/N lzfncI0u+mQ3QrqEFWysUumUe5DPR0OoJoMHFEPWJzXfWpWl3INmAxAq+p96FlvX MBpPqqF6XbHni3q3tY0s/0rwEI/ouY9jSUJ0rJ+1limJI3eUNzjl8uKDF4qrHYaH yiu7VVTPhJ7faeeJ1JRcnS9tp4mvwI3+lPWWglFkdXgAmMSbGvQTaPkq5Pdyo7Rr sE17t5ZDuXFj8bgA4AQbgthTy5EugBMAYMJ4YfYoUcRoeLl6Q3RXeSR+9QnYBEsg XVH5o5OP92zR+vP0C+xqmCnLDfEnj2eB7fIlsWIE0QbIPX11LMltsV/1wkCwfIY9 4oYVSvbSswbMlhPNRDKmCnzouwDVeV+NfdVn84ybBEQz1Sg/0KgPF1WnWEV1TA/n 3hUmJZCigM23QedwhuX+ooNy5Le5UNX8d09WcMV92xBlIx6kBG0jhlJdoYAcqB9y 4xM8EEX903UWEexiCNia =/1U3 -----END PGP SIGNATURE-----