============================================================================================== Verification Involving PSTN Reachability (ViPR) IETF#81 VIPR Meeting Minutes Friday, July 29, 2011, 1300-1400 (Afternoon Session I - 202) ============================================================================================== The VIPR WG met once at IETF#81. The meeting was chaired by Jon Peterson and Daryl Malas. Minutes reported by Eric Burger. Introduction Jon Peterson reviewed the noteworthy statement and agenda. In addition, Cullen indicated that he is no longer able to dedicate the right level of effort to the Overview draft, so he requested a new editor. Mary Barnes agreed to take over as editor. There were no concerns from the working group with this decision. Presentation - ViPR Overview Draft Speaker: Cullen Jennings Draft: draft-jennings-vipr-overview-01 Materials: http://www.ietf.org/proceedings/81/slides/vipr-2.pptx Action Item - Ekr, Kevin Fleming and John Ward volunteered to review the draft. Action Item - Chairs to setup an interim meeting on this topic around mid-October. One issue is with regards to removing "Cisco" from the draft. Cullen says, "We don't need a draft with Cisco in it" with respect to removing X-Cisco. These specific references should be removed from all drafts, as applicable. There was a proposal to extract the ViPR Access Protocol from the ViPR overview, since it is believed to not be a required component in order to implement ViPR. There were no comments on whether or not to do this. An issue was discussed with regards to "Evil Tracking," which involves an attacker registering its node-id against the hash of a Victim's number. The attacker learns who is calling the Victim, by getting their IP addresses and certificates, when the caller's systems validate VIPR tokens. Discussion ensued on this issue and provided some potential solutions: - Blacklist server by spoofing server registrations to DoS victim. However, failing validation to take out bad guys has a lot of potential collateral damage. Dale demonstrated how blacklisting does not solve anything. Cullen asked if it is a stupid proposal? Jonathan Lennox responded that one could think of worse, but hard to find it. - Validate in a zero-knowledge way - Victim validates the caller (In other words, turn around the validation handshake.) - Have caller give Victim something that it needs to give back during validation. Another issue involves the "First Call Problem." "It takes 24 hours to get a video call?!?" If you start with a PSTN call, things are "OK," because expectation is poor and then gets better. If you start over IP-capable networks, the expectation is the ability to achieve the best capable service (e.g., wide-band codec and video) immediately. The ViPR exchange will cause a delay in achieving this. Discussion on this issue included the following potential solutions: - Could do some sort of out-of-band signaling (e.g., ISDN USI, but it is blocked in Europe for the most part) - In-band signaling to indicate this is a VIPR-capable endpoint - Why not use SMS? SMS is not just for wireless any more. Neustar pitch for land-line SMS. Why keep audio and video together? One could just validate one or the other. Important problem to solve. Similar to MMUSIC "how to setup a PSTN call" issue. Should look to see if there is synergy. Cullen has been looking at it, but it will not help the validation problem. Key is the message must be out-of-band. Need to think about security issues if we have third party ringing, etc. Presentation - Proportional Quota in RELOAD Speaker: Marc Petit-Huguenin Draft: draft-petithuguenin-p2psip-proportional-quota-01 Materials: http://www.ietf.org/proceedings/81/slides/vipr-0.pdf Action Item - Gonzalo will investigate if this should be worked on in the P2PSIP working group. (Follow-up) After discussion among the chairs, it was decided the ViPR working group would work on both this and the RELOAD drafts, since they are both related to the ViPR work. Marc presented on this RELOAD work in both the P2PSIP and ViPR working groups. P2PSIP WG not interested in taking on RELOAD work. VIPR is the only WG that would be willing to work on it. During discussion, the question was asked whether this work is generic or ViPR specific. The consensus is that it is a generic mechanism. The challenge is that P2PSIP will take a long time to address it. Presentation - Combined Draft Update Review Speaker: Marc Petit-Huguenin Drafts: draft-petithuguenin-vipr-reload-usage-02 draft-petithuguenin-vipr-pvp-01 draft-petithuguenin-vipr-sip-antispam-01 draft-petithuguenin-p2psip-proportional-quota-01 Materials: http://www.ietf.org/proceedings/81/slides/vipr-1.pdf **This presentation provided a combined review of the drafts listed above, and provided a discussion about specific topics related to the drafts. The question was asked if there is a mechanism a service provider can do to remove enterprise entries? Does this have the BGP problem of advertising routes to enterprises that are the wrong endpoint? Marc describes how this mechanism avoids this problem. He will do a drawing to explain it better. It stops the situation of just picking the first response as being Evil. However, it still has the problem of how to pick right response. Topic: Voting Mechanism There was discussion about the current "Voting Mechanism" (e.g., retrieve 3 copies and vote). The question was asked why 3 copies? Is it for resiliency against failure? That seems to be what it is for. There are sequence numbers, so will this really be an issue? Design of RELOAD is to deal with failure, so again, why do we have this issue? We have a bigger problem if RELOAD is not consistent. Topic: Removing VIPR Registrations As part of this discussion, an issue was brought up regarding the fact that ViPR registrations never die, they simply expire. The question was asked if we need an ability to explicitly remove a registration. The proposal is to change the operative so that one MAY remove the registration as an implementation could do that, anyway. Cullen responded that the important thing to say is that if validation fails, you do not have to remove the record; and, if you find a record, it may not be valid. After further discussion their was consensus among the working group that we will say nothing about removing entries in the draft. Topic: Generic Tickets As part of this topic, an issue discussed how to work with the generic ticket mechanism? Should it be a VIPR draft or should it go to DISPATCH. After discussion, the working group felt like this was really ViPR specific, and we agreed to work on this within ViPR. Topic: Enrollment Process At this point, we ran out of time for the working group session, but there were three remaining issues for discussion: - Who should sign the configuration document? - How will the bootstrap servers be managed? - Who will issue the certificates? >end.