=================================================================== Verification Involving PSTN Reachability (ViPR) IETF#80 VIPR Meeting Minutes Thursday, March 31, 2011, 1300-1500 (Afternoon Session I - Tyrolka) =================================================================== The VIPR WG met once at IETF#80. The meeting was chaired by Jon Peterson and Daryl Malas. Minutes reported by Dale Worley. ***Action Items: The following people agreed to review draft-jennings-vipr-overview-00 (http://tools.ietf.org/html/draft-jennings-vipr-overview-00): - Mary Barnes - Ken Fischer - Marc Petit-Huguenin - Richard Barnes - Michael Procter Please review and post comments to the mailing list as soon as possible to allow time for discussion prior to the next IETF meeting. Thanks!! 1. Introduction The chairs note that the mailing list now exists. Jon Peterson presented the agenda, deliverables, goals and milestones. The schedule is aggressive, and we are expecting the first deliverables by September, before the Taipei IETF meeting. Roni Even noted that deliverable number 2 (Submit Peer to peer base protocol specification for publication as Proposed Standard) is actually "use of P2PSIP", not "P2PSIP" itself as it is described in the December 2011 goal. This first ViPR meeting was scheduled at the very last minute, so the agenda and objectives for the meeting rather ad-hoc. 2. Overview of current ViPR drafts Cullen Jennings presented the current drafts. Note: There is Cisco IPR on this subject -- See the IPR disclosure for details. [https://datatracker.ietf.org/ipr/1242/, et al.] Expects that there will be incompatible changes made to the scheme before the specification is frozen. Sohel Khan: Proposes a properly authenticated database to hold this info. Jonathan Rosenberg: The point of ViPR is to not require prior business relationships. Richard Barnes: In regard to emergency information, we have a system like this; it's called ECRIT. Jon Peterson: The first discussion point is the number of validation mechanism to support. Jon compared ViPR's validation mechanism to validation mechanisms used in other situations; e.g., Apple Facetime uses SMS. Notes that there has been discussion regarding alternative validation mechanisms. Jonathan Rosenberg: Meta comment on the question of multiple validation mechanisms: The question of scope of applicability -- Where can you and the callee be for it to work? E.g., SMS works well in the mobile environment but not in the enterprise environment, etc. Ultimately, forward routing of calls is the only universal mechanism, so that is what we chose. What is the problem with the current (call routing) validation scheme? The fact that the first call is handled differently is a usability problem, especially in regard to conference rooms, which are called infrequently.  Security is another problem, as the number of entropy bits in a single call's CDR is low. Jon Peterson: Clarification: The "first call" designation also applies to some degree to later refresh calls. John Elwell: Given that first calls aren't likely to be video calls [as ViPR won't route them via SIP], people may call and and then call again, which reduces the entropy available for validation [at the point that the second call is made]. Dale Worley: Pitched modularization to allow multiple mechanisms for both database and validation scheme. Jon Peterson: Notes that multiple validation mechanisms probably have little extra cost, and so should be supported. Jonathan Lennox: Need to make sure that validation mechanisms don't enable abusive usages. Jonathan Rosenberg: Supports previous point by Jonathan Lennox. Another property of validation schemes needs to be considered: Blockability by operators.  Forward routability can't be blocked by service providers. Richard Barnes: Need to consider whether entropy could be aggregated across multiple number accesses or multiple validation mechanisms. Cullen Jennings: Some entropy aggregation is done now, but Cullen's head exploded when he considered aggregating entropy from multiple sources.  Reiterates what Jonathan Rosenberg said, to consider what information could be difficult or expensive to block. Jon Peterson: Next topic: We discussed at lunch the properties we want for the spam tickets. The tickets prove that the caller received the mapping from the ViPR mechanism. Can the tickets be made applicable to, e.g., all PBXs in a large enterprise? Jonathan Rosenberg: To achieve the policy we want, arrange that someone can only call this enterprise via ViPR if the caller has previously made a PSTN call to the enterprise. This economic cost functions as a spam deterrent. Also, anti-spam regulations that apply to the PSTN are effectively incorporated. But if one wants a higher economic barrier, one may require more than one PSTN call before VoIP is enabled. Daryl Malas: (as an individual) I have concern as to what we define as the PSTN. It's possible to make a call that does not go over the PSTN, but still is effective as a first call from the ViPR perspective. This undermines or affects all the desired/expected properties of "PSTN calls" as we are discussing them. Sohel Khan: Are we interested in cost/economic analysis or solely technical solutions? Jon Peterson: I think we can acknowledge economic factors. Ken Fischer: There is a problem with the proposed model if we try to expand it too much. E.g., proposed schemes relate different E.164 numbers to each others in ways that may not be valid and may cause security problems. In practice, only a small subset of possible caller/callee combinations are used. Jonathan Rosenberg: We can publish not just mappings of single numbers but of prefixes. The caller can decide whether or not to accept such prefixes as being valid for groups of numbers. Even if the telco replaces circuit-switching with IP telephony, the E.164 administrative situation remains, and can be exploited by ViPR. Jon Peterson: In some situations you can't make the assumption that even an inter-enterprise call will by default go through the PSTN. Jonathan Rosenberg and Cullen Jennings: Elaborate various situations that affect how E.164 calls will be routed. Daryl Malas: We want to make sure the protocol is able to adapt to situations where some E.164 numbers might be privately route via SIP-trunks, etc. John Elwell: Is consideration being given to contact centers? Particularly if the caller is given callback number which is not the original contact number, the first call to the callback number won't benefit from ViPR. Hadriel Kaplan: In regard to private SIP peering, in such situations, you don't need ViPR. Dale Worley: How one's E.164 is routed is not relevant, as ViPR's purpose is to duplicate the caller's existing E.164 routing. Ken Fischer: Effectively, we can replace "PSTN" with "the service provider that we already trust". Jonathan Rosenberg: Supports Ken Fischer's remark. Jonathan Lennox:  What about non-constant routing -- call forwarding, or where 1-800-MY-PIZZA goes to different destinations from different originating points?  Any destination could steal calls from other destinations. Sohel Khan:  Number changes and domain changes make the mapping change over time. Jon Peterson:  We understand that probe calls have to be repeated at some interval.  The timeframe has not been defined. Cullen Jennings:  The PSTN has rules on reusing numbers, and that time interval is regulatorily defined.  We have not found a carrier that has a reuse time less than 60 days. Jonathan Rosenberg:  Number portability is not a problem, but reallocation is a problem.  But we have that problem in private phone books, and ViPR doesn't have to be better than that. Jon Peterson:  But there are prepaid carriers that recycle numbers from SIMs very quickly. Jonathan Lennox: What if a carrier presents validation rather than the subscriber? Hadriel Kaplan: How number portability is done varies by company. Sohel Khan: Who is the owner of the validater? Jon Peterson: In ViPR, each caller system does its own validation. Ken Fischer: What I like is that this is about the end user, not the carrier. Dean willis: (cough) (hoarsely:) [This is] what's left of Dean Willis... (normal tone:) If I'm a carrier with a million subscribers, I might want to have my own ViPR system and charge people for transit to use it. We need a way to prevent carriers from doing such things. Cullen Jennings: I'll comment on Skype. Clearly you could form a private RELOAD ring inside your company. "We're not designing protocols to circumvent firewall operators." Jon Peterson: We're not entirely adhering to the questions on the agenda, but they're still good questions Sohel Khan: The trust model is still not clear to me. Jon Peterson: The architecture is a great departure from other schemes.  There is a single worldwide DHT by which subscribers advertise themselves.  Nobody owns the DHT, and you do not trust its contents. Cullen Jennings: What is the plan for the anchors of the DHT? Where do you root RELOAD? There are multiple root nodes operated by different companies. There is a need for someone to decide when we need to change hash algorithms, certificate authority's etc. Hadriel Kaplan: This is owned by the same people who own the Internet: Cisco! Jon Peterson: The non-PSTN entity question is an interesting one. There are some popular calling systems that don't use E.164 numbers. What is the use case for that? I don't want to pick on Skype as an example, but it is one.  Say we wanted to apply the anti-spam components to Skype calls. Richard Barnes: Where we started with is the trust in the PSTN and extending it to SIP. Is the point to use another system as the trust origin instead of the PSTN? Dale Worley: Require all mappings that are filed to be "from" URIs [as they are already "to" URIs], and then any URI scheme can be accommodated without architectural change. Sohel Khan: Charter question:  Is the charter on the web page correct? Jon Peterson: Yes Richard Barnes: There is a simple way to generalize. Dale Worley: The charter says "domain responsible for the phone number" when it should be "SIP URI responsible...".  Is that correct? (general agreement) Daryl Malas: Yes, the system needs to be flexible. Jon Peterson: There are a number of modularization issues. Jonathan Rosenberg: The DHT doesn't store mappings, but rather claimed mappings. So one could easily create an unauthenticated DNS database to look up claims, without using a DHT. And there are other methods of storing claims. Jonathan Lennox: Would it be possible to have ViPR use as input a subtree of e164.arpa that was poorly maintained? Daryl Malas: If the intermediate Internet enforces a policy, it may not be that an Internet call will have all the features that a PSTN call would have, instead of having more features. Cullin Jennings: I think we should run a BOF on ways to defeat middleboxes. But middleboxes are not the question we are addressing. The question is how to leverage trust in E.164 to the Internet realm. Jon Peterson: How many people here have read the drafts? (20 or so hands raised) The mailing list is . That is where we will be discussing this going forward. We have an aggressive schedule and may progress some drafts in the Quebec meeting timeframe. Sohel Khan: Maybe we to revise the naming, as "PSTN reachability" may not be appropriate. Daryl Malas: Read the drafts! At Quebec we will inquire if there are comments and see if we can do WGLC. We don't want people to wait until WGLC to read the drafts. Mary Barnes: Notes that the names of the drafts contain -dispatch- and should be updated to -vipr-. Daryl Malas: Volunteers are Mary Barnes, Ken Fischer, Marc Petit-Huguenin, Richard Barnes, and Michael Procter to review the overview document. (sarcastically:) Please give comments by July 15! (as that is just before the Quebec meeting) [EOF]