============================================================================================== Verification Involving PSTN Reachability (ViPR) IETF#82 VIPR Meeting Minutes Thursday, November 17, 2011, 1740-1940 (Afternoon Session III - 101B) ============================================================================================== The VIPR WG met once at IETF#82. The meeting was chaired by Jon Peterson. Minutes reported by Alexander Mayrhofer. Introduction Jon Peterson opens the meeting, shows the Agenda. Encourages people to participate in the design team calls. Agenda is accepted. Presentation - ViPR Overview Draft Speaker: Mary Barnes Draft: draft-jennings-vipr-overview-02 Materials: http://www.ietf.org/proceedings/82/slides/vipr-2.ppt Mary became the new editor, explains slide 1. References to Nirvana were removed. Next Steps: WG review required, security section needs additional work. Marc: supports adoption Cullen: seconds that Jon: We need more reviews before adopting this Eric Burger has volunteered to review the draft. Presentation - ViPR Drafts Speaker: Marc Petit-Huguenin Drafts: draft-petithuguenin-vipr-proportional-quota-00 draft-petithuguenin-vipr-reload-usage-03 draft-petithuguenin-vipr-sip-antispam-03 draft-petithuguenin-dispatch-infrastructure-overlay-0 Materials: http://www.ietf.org/proceedings/82/slides/vipr-0.pdf We made some progress, not as much as expected. Worked on the framework document, but too many issues were discovered. Framework is not ready yet. Design team (8 people) do a conf call each week (Since 9/23/11). It was too late to have the document ready for this meeting. There are still lots of open issues for interested people to work on. Framework is a new doc that was made of the sections that were removed from the -overview document. -framework does not assume a specific architecture. Still too many issues to publish it. PVP (PSTN validation protocol) methods IANA registry will be in the framework document. Because many methods are expected, priority will be associated. Clients would then try them in the specific order. Jon: for each method, a priority will be defined? How to "insert" new methods between .. eg. "3" and "4"? Marc: Want to have the better, faster first. Not yet decided which kind of priority it would be? Some discussion about what the "priority" would be - tradeoff between cost and security? Is the registry the right for the priority? No final conclusion.. "SIP intermediaries": Problem that not every ViPR domain will have direct PSTN connection (SIP trunks), and the service provider can't be stopped to create a ViPR domain for that. Cullen: Agree that you can't prevent them - this is an attack you cannot stop. Jon: Not a threat model - you cannot easily eavesdrop on ISDN, but you can on SIP. Should participation in the DHT be limited to the party who actually provides the "end service"? Alex: Can also go into the "other" direction - enterprise user "stealing" the number of the enterprise? Stay away from "number assignee" considerations. Jon: It's about allowing the features of direct end to end communication Hadriel: So what would we want? Jon: You can participate in ViPR if you support these features. Hadriel: So we are going to create a list of features? Jon: Proximity to endpoint is the proper metric. Hadriel: Not a protocol problem to solve. If the customer does it themselves, let them. If the carrier "steals" the ViPR domain, let the customer move elsewhere. Lawsuits, not protocol. Jon: We're trying to define whether eg. both can participate? What if a call comes in? Hadriel: Parallel fork? discussion concludes, Marc continues the presentation. draft vipr-sip-intermediaries... Hadriel: Keyword "breaks". Jon: Can be more than one. Fork limit / bomb? Hadriel: Can't be more entries for a single AoR...? Also, multiple invalids Marc: Not talking about the invalid ones. Jon: "breaks" in the sense that the current protocol does not know what to do in case of multiple entries. Was discussed extensively in the design team Marc: Initial suggestion was parallel forking. Hadriel: You also get all the SDP offers, and can then choose based on media type... Document contains a description of the 3 problems. "Proportional Quota" One change was applied: Algorithm does not apply anymore to replicas, just to the original record. Checked against the original RELOAD spec, this should hence be fine. There's still some more work to be done. "RELOAD Usage" Will see many PVP methods, so if we have all methods tried for each number, this would bloat. Therefore, the RELOAD should contain the list of PVPs to be tried for the number. Alex: Concern that an insecure PVP would allow an attacker to "take over" numbers? Cullen: Understand the concern, but something probably more of concern is that it's hard to *delete* numbers - flooding issue? Method registration could also allow statistics collection. "Reload usage: no additional copies" Each number is only stored in one set of 1 original, and two replicas, client must fetch 1 original and 2 replicas, and use the value at least found twice. Jon: Question was why had we 3 copies? DHT health and splits? No good reason? Cullen: Reliability, we didn't have experience. Algorithm has been pretty strong, so that has changed. Extra traffic *might* be relevant for mobile only, however, haven't seen it *catch* something that otherwise would have failed. "RELOAD Usage: Multiplier" Probability equation currently contains "3", but there's no explanation. We need to fix this. "PVP: Vocabulary" selector - secret - parameters. Sohel: Clarification what "caller-id" and "callee" means Marc: Phone numbers "PVP: Hashing the Caller-ID for 'a'" Cullen: The question is always the number of rounds Jon: well, always depends on Q whether info is still valuable after one month of offline attack.. Cullen: Always the problem "What's the lower bar"? Discussion around basing number of rounds on "cost for number"... "PVP: Inverting the secret and the selector" Using start/stop time as selector, and callee/Caller-ID as secret. Additionally, could add "prefix" of numbers, or rather "chunks" of the number, look at what amount of entropy we need to keep. Marc: Will duplicate method A as method C, and use the tricks described above. "PVP: Method entropy" Some methods not secure enough - Idea to accumulate entropy across various methods.. 3 Solutions Cullen: Let's make the required level of entropy configurable, so that we can pull the gates up once the bad guys arrive. Allow people to pick the level? Orthogonal issue where to store the information. Marc: Both sides can then choose what the level of entropy they want would be? Sohel: Definition of "call"? Jon: completed call, ViPR evaluates lazily. Eric (via Jabber): End user are clueless, but the default min entropy works well. Jon: Most people agree with configurable? No objections "Ticket as certificates" problem: symmetrical key, lacks agility. Use X.509? Jon: Becoming a CA is complicated, and easy to get wrong. concern. Cullen: crypto agility: not a problem, we can pick the one we believe will meet. Do not offer a "list" of every hash funcs that ever existed. Jon: Yes, agree on an algo, and when we need to change it, write a new standard. Cullen: We use nothing of the X.509 things Marc: Not true, we use the validity. Discussion around the X.509 certificate generation.. Cullen: Asymmetric keys do not necessarily reduce the amount of trust required? Alex: X.509 is complex, why add it to the already complex system? Jon: Not about X.509, but about what level of security required? Richard Barnes volunteers to do a security review on this question. "SIP Antispam: Ticket renewal" Marc describes a proposal to prevent "reduction of service quality" when the ticket is up for renewal? Sohel: When is the table updated? A: between 1 min and 48 hours. Sohel: Concerned that this could be used to scan users? Marc: This is PSTN. "Infrastructure Overlay" VIPR deployment key issue: Get one and only one RELOAD overlay. There's a draft proposed to DISPATCH. Jon: Sent comments already "VIPR Troubleshooting" There's no testing, because the calls are "production calls". Need test tools to debug, eg. pcap files, logs and other debugging info while still respecting privacy and data protection and security. Cullen: Problem to wait 48h hours to demonstrate. We need a "test ring" mode. "ICE Support in RELOAD" RELOAD nodes can only be behind a firewall if ICE is deployed. Jon closes the meeting. >end.