From petithug@acm.org Mon May 2 10:22:51 2011 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 BD2B0E06B1 for ; Mon, 2 May 2011 10:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.365 X-Spam-Level: X-Spam-Status: No, score=-101.365 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-GezFHUC8Fy for ; Mon, 2 May 2011 10:22:51 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by ietfa.amsl.com (Postfix) with ESMTP id 756DFE073E for ; Mon, 2 May 2011 10:22:47 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id C8442DBE400C; Mon, 2 May 2011 17:22:46 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 78A2FDBE400A for ; Mon, 2 May 2011 17:22:45 +0000 (UTC) Message-ID: <4DBEE864.1040002@acm.org> Date: Mon, 02 May 2011 10:22:44 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110402 Iceowl/1.0b2 Icedove/3.1.9 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Review of draft-jennings-vipr-overview-00 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, 02 May 2011 17:22:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (I am co-editor of this draft, but as I am proposing some radical changes, I thought it was better done in a formal review) I think that this draft tries to be more than just than just a "Requirements, Problem statement, and architecture overview" informational document. More precisely I think that section 7, 8 and 9 should be moved to a separate document (with Standard Track status) that would be named something like "Verification Involving PSTN Reachability (ViPR): Base protocol". I am also worried that the VAP document (draft-jennings-vipr-vap-00) is conflating two differents things: 1) the detail of the ViPR server behavior and 2) the VAP protocol itself. Because it is possible to design an interopeable ViPR system without VAP (from the outside point of view), I think that the ViPR behavior part of the VAP draft should be merged with the document I described above, and keep only the VAP protocol in the VAP document. If this proposal is accepted, I am willing to prepare such draft (with the same set of authors). Now for the review of draft-jennings-vipr-overview-00: - - The Intended Status in page 1 should be changed to "Informational". - - Section 6.1, second paragraph "The Internet firewall will require two pinholes, one for the P2P protocol, and one for the validation protocol" Unless the idea was to use a dialect of RELOAD non-compliant with draft-ietf-p2psip-base, a pinhole for the P2P protocol (RELOAD) is needed only if the node in the ViPR server is a bootstrap peer. If a ViPR server decides to not be a bootstrap node, then it will establish the initial connection with a bootstrap peer then can use ICE transports to connect to attach to other nodes. Same thing for the validation protocol. An AppAttach will be used to connect to the peer declared in the ring, and ICE will take care of opening a pinhole in the firewall. Which brings a new question Who will manage the bootstrap, configuration and enrollment servers for ViPR? Nits - ---- - - first page, first line: s/vipr/VIPR/ - - Section 4, Req-10: s/This mechanism/These mechanisms/ - - Section 6, first paragraph s/call agent can/call agent to/ - - Section 6.1, 4th bullet s/restore/re-store/ - - Section 6.4 s/enrollment are/enrollment is/ - -- 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) iEYEARECAAYFAk2+6GIACgkQ9RoMZyVa61eGiwCeOxMjMZZDGLB0u+gZMDOE7zuO e8wAn2Dqx9F5RAexFC6sLJKY2pma8Eed =Ntsp -----END PGP SIGNATURE----- From D.Malas@CableLabs.com Wed May 4 09:23:40 2011 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 77565E07C9 for ; Wed, 4 May 2011 09:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.462 X-Spam-Level: X-Spam-Status: No, score=-100.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-HBVpTr6cl5 for ; Wed, 4 May 2011 09:23:39 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id C78C2E07B1 for ; Wed, 4 May 2011 09:23:39 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id p44GNYs5000577 for ; Wed, 4 May 2011 10:23:38 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 4 May 2011 10:23:34 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 4 May 2011 10:23:38 -0600 From: Daryl Malas To: "vipr@ietf.org" Date: Wed, 4 May 2011 10:23:35 -0600 Thread-Topic: [VIPR] Overview: QoS/Troubleshooting - Concerns Thread-Index: AcwKd59CsVo81wV0SLigLyUOR3U3SA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9E6D9A715E2Admalascablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: [VIPR] Overview: QoS/Troubleshooting - Concerns 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, 04 May 2011 16:23:40 -0000 --_000_C9E6D9A715E2Admalascablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have some concerns about the QoS & Troubleshooting sections of the overvi= ew draft. While it may be true that there are a large number of existing V= oIP deployments that run over the internet, the type of traffic and user pr= ofile is undetermined. For example, while I may have a desire to make a Go= ogle voice phone call to a family member, that same desire is not there for= a conference call with a potential client with a $1M contract on the line.= It could be though! The statement, "Though the lack of QoS is a concern,= it has not proven a barrier to deployment," is highly subjective in its cu= rrent form. I would prefer this document to suggest existing defined metho= ds for tracking QoS and troubleshooting potential problems, so an enterpris= e could potentially adjust layers 1 =96 4 connectivity/routes to alleviate = these potential problems. Here are some suggested RFCs to reference in sec= tion 2.3/2.4: Media related troubleshooting and QoS monitoring: RFC 3550 (RTCP) RFC 3611 (RTCP-XR) Signaling related troubleshooting and QoS monitoring: RFC 6076 (Basic Telephony SIP End-to-End Performance Metrics) Instead of the above quoted sentence, I would suggest a sentence more along= the lines of, "The lack of QoS is a concern; however, some methods for mon= itoring the signaling and media have been defined to assist in monitoring a= nd troubleshooting VoIP deployments that run over the internet." =85and, th= en proceed to briefly reference the above RFCs (or others if applicable). Regards, Daryl --_000_C9E6D9A715E2Admalascablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I have some concerns about the = QoS & Troubleshooting sections of the overview draft.  While it ma= y be true that there are a large number of existing VoIP deployments that r= un over the internet, the type of traffic and user profile is undetermined.=  For example, while I may have a desire to make a Google voice phone = call to a family member, that same desire is not there for a conference cal= l with a potential client with a $1M contract on the line.  It could b= e though!  The statement, "Though the lack of QoS is a concern, i= t has not proven a barrier to deployment," is highly subjective in its= current form.  I would prefer this document to suggest existing defin= ed methods for tracking QoS and troubleshooting potential problems, so an e= nterprise could potentially adjust layers 1 =96 4 connectivity/routes to al= leviate these potential problems.  Here are some suggested RFCs to ref= erence in section 2.3/2.4:

Media related troublesh= ooting and QoS monitoring:
RFC 3550 (RTCP)
RFC 3611 (RT= CP-XR)

Signaling related troubleshooting and QoS m= onitoring:
RFC 6076 (Basic Telephony SIP End-to-End Performance M= etrics)

Instead of the above quoted sentence, I wo= uld suggest a sentence more along the lines of, "The lack of QoS is a = concern; however, some methods for monitoring the signaling and media have = been defined to assist in monitoring and troubleshooting VoIP deployments t= hat run over the internet." =85and, then proceed to briefly reference = the above RFCs (or others if applicable).

Regards,=

Daryl
--_000_C9E6D9A715E2Admalascablelabscom_-- From michael@voip.co.uk Fri May 13 01:37:45 2011 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 273B6E06FA for ; Fri, 13 May 2011 01:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHFBmQWgxi9x for ; Fri, 13 May 2011 01:37:44 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with SMTP id 68950E06C2 for ; Fri, 13 May 2011 01:37:40 -0700 (PDT) Received: from mail-iw0-f181.google.com ([209.85.214.181]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTczt040Copvm/r0nBOrBZbBwUfVUSx8v@postini.com; Fri, 13 May 2011 01:37:44 PDT Received: by mail-iw0-f181.google.com with SMTP id 38so2574394iwn.12 for ; Fri, 13 May 2011 01:37:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.4.202 with SMTP id 10mr1384749ict.449.1305275859501; Fri, 13 May 2011 01:37:39 -0700 (PDT) Received: by 10.42.151.68 with HTTP; Fri, 13 May 2011 01:37:39 -0700 (PDT) Date: Fri, 13 May 2011 09:37:39 +0100 Message-ID: From: Michael Procter To: vipr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [VIPR] Review of draft-jennings-vipr-overview-01 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, 13 May 2011 08:37:45 -0000 General Three occurrences of the header field 'X-Cisco-ViPR-Ticket'. Hopefully this will be renamed at some stage? Section 2.1 para 2: "email-style SIP URI" replace with "email-style SIP URIs" Section 8.2 The TLS-SRP uses the caller ID and called number as a "username" This seems to open up an interesting information leak, since the username is sent in the clear. Let's assume EvilCorp registers its node-id against the hash of the sales number of its competitor, VictimCorp. Then, whenever a ViPR-enabled caller tries to call VictimCorp to buy something, a few hours later their ViPR server will attempt to establish a connection to EvilCorp. Even assuming that EvilCorp can't complete the handshake because it has no idea of the call details, EvilCorp still ends up with a list of CLIs for people who called their competitor's sales line. I'm not a salesperson, but I believe that supplying a list of 'hot leads' like this would make EvilCorp's sales team quite happy. Section 9.2: 3rd attack "the TTL for cached routes is set to match the duration that carriers typically hold numbers." I understand the reason for this, but I think it might lead to a poor user experience. If someone becomes accustomed to having a videocall / wideband audio with a regular recipient, and then finds that one day it falls back to PSTN, I doubt that "ViPR cached route TTL expiry" will be the first thing that springs to mind. If you have a moderate number of ViPR-connected regular destinations, and a cache time of 3-6 months, then you will find that this happens quite often, which will lead to a perception of unreliability for the technology. Once a fallback call is made, it will take up to 12 hours (from my reading of the PVP draft) to refresh the SIP route, which essentially means it won't be 'fixed' on the same day. It might help if there were a faster way to revalidate routes that have expired recently, or a way to qualify a route for continued use whilst still protecting against this attack. Section 9.2: 5th attack I think you may be understating the risk here. An environment that uses phones supporting the dialog event package, for example, will allow mischievous colleagues to mount this attack. Even someone sitting in the next cubical to the caller, wielding a stop watch, probably stands a good chance of mounting this attack. Rather than recommending that ViPR is not deployed in enterprises with moderately clueful staff, is there something that can be done to tighten up the defences to this attack? Best regards, Michael