[VIPR] Agenda & Handout for 2011/09/28
Marc Petit-Huguenin <petithug@acm.org> Thu, 29 September 2011 15:11 UTC
Return-Path: <petithug@acm.org>
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 3FBCC21F8E1E for <vipr@ietfa.amsl.com>; Thu, 29 Sep 2011 08:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.025
X-Spam-Level:
X-Spam-Status: No, score=-100.025 tagged_above=-999 required=5 tests=[AWL=-2.225, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_SUMOF=5, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 v+SDKwpaAXvC for <vipr@ietfa.amsl.com>; Thu, 29 Sep 2011 08:11:26 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id B3EBE21F8E21 for <vipr@ietf.org>; Thu, 29 Sep 2011 08:11:25 -0700 (PDT)
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 5D5AD2087B; Thu, 29 Sep 2011 15:07:39 +0000 (UTC)
Message-ID: <4E848B45.20708@acm.org>
Date: Thu, 29 Sep 2011 08:14:13 -0700
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>, "Hakim Mehmood (naim)" <naim@cisco.com>, Michael Procter <michael@voip.co.uk>, John Ward <jward@IntelePeer.com>, 'Mary Barnes' <mary.ietf.barnes@gmail.com>, "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>, Daryl Malas <D.Malas@cablelabs.com>, Jon Peterson <jon.peterson@neustar.biz>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Cc: "vipr@ietf.org" <vipr@ietf.org>
Subject: [VIPR] Agenda & Handout for 2011/09/28
X-BeenThere: vipr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Verification Involving PSTN Reachability working group <vipr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vipr>, <mailto:vipr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vipr>
List-Post: <mailto:vipr@ietf.org>
List-Help: <mailto:vipr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vipr>, <mailto:vipr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Sep 2011 15:11:28 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A. Agenda - - Security section of -overview (5 min) - - SIP Intermediaries (10 min) - - Capabilities (10 min) - - RELOAD registration (5 min) - - PVP privacy (10 min) - - PVP method priority and registration (10 min) - - PVP method entropy (10 min) - - Replacement ticket by client certificate (10 min) - - Ticket renewal (10 min) - - Infrastructure overlays (5 min) Note that the sum of the time allocated to each topic 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: 15 min) B.1 VIPR Overview - Security section An updated version of -overview has been submitted but the security section may need some more work. We want to submit -overview as soon as possible, so finishing this spec has the highest priority. Here's the current text: "6. Security Considerations Security is incredibly important for VIPR. This section provides an overview of some of the key threats and how they are handled. 6.1. Attacks on the DHT Attackers could attempt to disrupt service through a variety of attacks on the DHT. Firstly, it must be noted that the DHT is never used at call setup time. It is accessed as a background task, solely to learn NEW numbers and routes that are not already known. If, by some tragedy, an attacker destroyed the P2P network completely, it would not cause a single call to fail. Furthermore, it would not cause calls to revert to the PSTN - calls to routes learned previously would still go over the IP network. The only impact to such a devastating attack, is that a domain could not learn *new* routes to new numbers, until the DHT is restored to service. This service failure is hard for users and administrators to even notice. That said, VIPR prevents many of these attacks. The DHT itself is secured using TLS - its usage is mandatory. Quota mechanisms are put into place that prevent an attacker from storing large amounts of data in the DHT. Other attacks are prevented by mechanisms defined by RELOAD itself, and are not VIPR specific. 6.2. Theft of Phone Numbers The key security threat that VIPR is trying to address is the theft of phone numbers. In particular, a malicious domain could store, into the DHT, phone numbers that it does not own, in an attempt to steal calls targeted to those numbers. This attack is prevented by the core validation mechanism, which performs a proof of knowledge check to verify ownership of numbers. An attacker could try to claim numbers it doesn't own, which are claimed legitimately by other domains in the VIPR network. This attack is prevented as well. Each domain storing information into the DHT can never overwrite information stored by another domain. As a consequence, if two domains claim the same number, two records are stored in the DHT. An originating domain will validate against both, and only one will validate - the real owner. An attacker could actually own a phone number, use it for a while, validate with it, and build up a cache of routes at other domains. Then, it gives back the phone number to the PSTN provider, who allocates it to someone else. However, the attacker still claims ownership of the number, even though they no longer have it. This attack is prevented by expiring the learned routes after a while. Typically, operators do not re-assign a number for a few months, to allow out-of-service messages to be played to people that still have the old number. Thus, the TTL for cached routes is set to match the duration that carriers typically hold numbers. An attacker could advertise a lot of numbers, most of which are correct, some of which are not. VIPR prevents this by requiring each number to be validated individually. 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. 6.3. Spam Another serious concern is that attackers may try to launch SIP spam (also known as SPIT) calls into a domain. As described in Section 5.3.3, VIPR prevents this by requiring that a domain make a PSTN call to a number before it will allow a SIP call to be accepted to that same number. This provides a financial disincentive to spammers. The current relatively high cost of international calling, and the presence of national do-not-call regulations, have prevented spam on the PSTN to a large degree. VIPR applies those same protections to SIP connections. VIPR still lowers the cost of communications, but it does so by amortizing that savings over a large number of calls. The costs of communications remain high for infrequent calls to many numbers, and become low for frequent calls to a smaller set of numbers. Since the former is more interesting to spammers, VIPR gears its cost incentives away from the spammers, and towards domains which collaborate frequently. It is important to note that VIPR does not completely address the spam problem. A large spamming clearing house organization could actually incur the costs of launching the PSTN calls to numbers, and then, in turn, act as a conduit allowing other spammers to launch their calls to those numbers for a fee. The clearinghouse would actually need to transit the signaling traffic (or, divulge the private keys to their domain name), which would incur some cost. As such, while this is not an impossible situation, the barrier is set reasonably high to start with - high enough that it is likely to deter spammers until it becomes a highly attractive target, at which point other mechanisms can be brought to bear. This is, again, an example of the incremental deployability philosophy of VIPR." B.2 SIP intermediaries One of the things that was discussed in the last conference call was about VIPR domains that are not directly connected to the PSTN, but that are using intermediaries (e.g. SIP trunk). The problem is that an intermediary will probably use VIPR for toll bypass, whereas the main use case for VIPR is to be able to use enhanced features (wideband audio, video, text, etc...) between VoIP islands. So I would like to present a proposal to solve this issue, but as this is a little bit unorthodox, I'll present it progressively. This first diagram depicts the routing process as described by the current spec: ,~~~~~~~~~~~~~~~~~~~~~> UAC< `---------------------> In this diagram, the UAC is directly connected to the PSTN, and use the route database to choose if the call is using the PSTN (top arrow) or if the call is using SIP and enhanced features (bottom arrow). We will probably need in the future to define a profile for this SIP connection, but for now let's just define a SIP profile that supports wideband speech and audio, video, text, file exchanges, games, etc... and call it SIPbeyond (in reference to "SIP beyond VoIP" by Sinnreich and al.). In some VIPR domains, the PSTN connection would still be inside the domain, but would be physically separated from the UAC, using a connection between the UAC and the PSTN gateway, which gives us the following diagram: PSTN~~~~~~~~~~~~~~~~~~> / / UAC----------------------> Here the link between "UAC" and "PSTN" uses SIP but with a different profile. This time there is an existing profile SIPconnect, so we'll use it for the remaining of the discussion. The UAC still decides based on the content of the route database and will use SIPbeyond if a route is found, and SIPconnect to the PSTN gateway if no route is found. Now there is nothing that prevents moving the PSTN gateway outside the VIPR domain, and still using the SIPconnect profile. The issue is that the entity managing the PSTN gateway can decide to also be a VIPR domain itself, but because the SIP connection is using the SIPconnect profile, it cannot do more than using VIPR as a toll pass, as the direct SIP route created will never be able to use enhanced features, thus defeating the main goal of VIPR. One solution would be to merge the SIPconnect and SIPbeyond profile when sending the request to the PSTN gateway, but that will complicate things and in the end nobody will implement this. My proposal is to send *both* profiles to the upstream VIPR domain, in a multipart/alternate body, as shown in this diagram: PSTN~~~~~~~~> / / Proxy----------> // // UAC--------------> In this diagram, the UAC uses the route database to choose if the call is direct and using SIPbeyond (bottom arrow) or if the call is sent to an external domain for processing (the double link above the UAC). The SIP request contains two SDPs, one for SIPconnect, one for SIPbeyond. The SIP proxy in the upstream VIPR domain uses its own route database to choose between a direct route (by stripping the SIPconnect SDP from the request and adding the ticket) or using the PSTN (by stripping the SIPbeyond SDP). Note that an external domain that does not support multipart would simply reject the SIP request with a 415, so the UAC can resend the request with only the SIPconnect SDP, knowing now that the external domain is not a VIPR domain. We can now extend the mechanism to multiple levels of VIPR domains, and even use this mechanism inside the VIPR domain closest to the user (so the network elements choosing how to route is separated from the UAC), as shown in this diagram: PSTN~~~~~> / / Proxy-------> // // Proxy----------> // // UAC===>Proxy-------------> Here's an example of a SIP INVITE body that contains the two SDPs: - --boundary Content-Type: application/sdp v=0 o=- 1 1 IN IP4 192.0.2.1 s= c=IN IP4 192.0.2.1 t=0 0 m=audio 8000 RTP/AVP 0 96 97 a=rtpmap:0 PCMU/8000 a=rtpmap:96 G729/8000 a=rtpmap:97 telephone-event/8000 - --boundary Content-Type: application/sdp v=0 o=- 2890844526 2890842807 IN IP6 2001:DB8::1 s= c=IN IP6 2001:DB8::1 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 54312 RTP/SAVP 101 b=RS:0 b=RR:0 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE15GbN a=rtpmap:101 opus/48000 a=fmtp:101 maxcodedaudiobandwidth=16000; maxaveragebitrate=20000;stereo=1; useinbandfec=1; usedtx=0 a=ptime:40 a=maxptime:40 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998 m=video 49170 RTP/SAVPF 98 b=RS:0 b=RR:0 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE15GbN a=rtpmap:98 VP8/90000 a=fmtp:98 version=0 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998 m=text 11000 RTP/SAVP 98 100 b=RS:0 b=RR:0 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE15GbN a=rtpmap:98 t140/1000 a=rtpmap:100 red/1000 a=fmtp:100 98/98/98 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998 - --boundary-- We would need to define a convention in the order of the SDPs so a proxy knows which SDP is SIPconnect, and which SDP is SIPbeyond. Also, as for SIPconnect and SIPbeyond, the INVITE containing the alternative SDPs must use TLS. B.3. Capabilities PhoneA Enterprise ProviderA RELOAD ProviderB PhoneB | | Store | | | | 1 | |---------------------------->| Store | | 2 | | | Store |<------------| | 3 | | |------------->| | | : : : : : : | | | | | INVITE | 4 | | | | SETUP |<========| 5 | | INVITE |<~~~~~~~~~~~~~~~~~~~~~~~~~~~| | 6 | INVITE |<=============| | | | 7 |<==========| | | | | : BYE : : : : : 8 |==========>| BYE | | | | 9 | |=============>| DISC | | | 10 | | |~~~~~~~~~~~~~~~~~~~~~~~~~~~>| BYE | 11 | | | | Fetch |========>| 12 | | | |<------------| | | | | | ValExchange | | 13 | | |<:::::::::::::::::::::::::::| | | | | | ValExchange | | 14 | |<::::::::::::::::::::::::::::::::::::::::::| | : | : : : INVITE : 15 | | | | INVITE |<========| 16 | | INVITE |<===========================| | 17 | INVITE |<============ | | | | 18 |<==========| | | INVITE | | 19 | |<==========================================| | | INVITE | | | | | 20 |x==========| | | | | | | | | | | Bottom line is that in this case two routes are learned, 1 -- Being advertized by the Enterprise 2 -- The route from providerA. Ideally we would like to use the route advertized by Enterprise as it is nearest to the endpoint and the probability of getting all the IP services (voice, video, SMS etc) on this route has much higher likelihood. On the other hand ProviderA's route is a valid route too. The issue is as to how the "learning entity" ProviderB in this use case is capable of making decisions that offer the best capability (video etc) for calls between PhoneB and PhoneA. Option 1:- During the publication of the number the entities publishing the number also publish the capabilities of the endpoint, possibly read from the registrar or learned by other means. So when issuing a ticket based on the publication the the route includes the capabilities also, for example: (& (sip.audio=TRUE) (sip.video=TRUE) (sip.mobility=fixed) (| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS) (sip.methods=ACK) (sip.methods=CANCEL))) Again relies on trust that the publisher (or the issuer of the route and ticket) is not lying about the capabilities. Based on the the capabilities received in the Route the originator of the call can pick a route that is optimal in terms of capabilities. Now the issue is that ProviderA which is SIP capable could provide similar capabilities as it is connected via SIP to the endpoint. Option2: Learn all the routes and recommend use them in some policy based fashion ( round robin etc) and eventually mark the routes based on what capabilities these routes provided the endpoints for future usage -- Work at the SIP layer. B.4. RELOAD registration Let's now move to the interactions between the VIPR domain and the RELOAD overlay. The current specification states that a phone number must be registered 3 times, which with the underlying replication done by the CHORD RELOAD algorithm, means that the mapping between a PVP server and a phone number is stored 9 times. The problem discussed in Quebec City was what to do when the 3 copy retrieved from the overlay are not identical, and the proposal was to use the copy that appears at least twice, so no peer can alone create a denial of service for a specific number. The discussion moved to the reasons for having 3 copies in the first place. The proposal is to drop the requirement for the 3 copies from VIPR, but to add the requirement that the node requesting the phone number MUST also fetch (or stat) the 2 additional replicas and use the value that matches at least one other copy (using a majority vote prevents a rogue peer to block the access to the phone numbers currently stored here). If not all 3 copies are equals, then an incident must be logged. The PVP client must retrieve the 2 replicas in addition to the original registration and use the voting algorithm to choose one and log an incident if all 3 are not equal. B.5. Ticket vs Client certificate In the current specification, the PVP server builds and signs a VIPR ticket, and sends it back to the PVP client, which passes it to the SIP element. The SIP element will insert this ticket in the next SIP method to the remote SIP element, which will check the validity of the ticket and the domain of the TLS client. There is multiple problems with this process: - - The verification of the ticket use HMAC-SHA1, and so the same password has to be provisioned in both the SIP element (to verify the ticket) and the PVP server (to generate the ticket). - - The ticket can be used without TLS, and we all know that implementers think of MUST as SHOULD and SHOULD as MAY. So the proposal would be to replace the ticket by a client certificate, which could work like this: Instead of using a symmetrical key, the local PVP server generates an RSA key pair, with the public key distributed to the SIP element(s). After a successful PVP connection, the remote PVP client sends a PKCS#10 certificate request, containing the domain name and signed with a private key. The local PVP server generates a new certificate, sign it with its private key and send it back to the remote PVP client, which pass it back to the remote SIP element. The remote SIP element will use the certificate received to establish the TLS connection for the SIP transactions to the local SIP element, which will use a standard CA based certificate for its own domain. The local SIP element will be able to verify with the PVP server public key that it issued the certificate, then will validate the standard parts of the certificate (expiration date and so on). There is multiple advantages to this proposal: - - The private key is stored only in the PVP server, or better in a physical token. - - VIPR does not work without TLS for the SIP connection. - - There is plenty of commercial or free TLS and X.509 implementations that have years of experience and testing, which is not the case for the ticket proposal. - - Security agility is provided by TLS. - - No additional SIP Header. - - Because the ticket verification process is folded into the client certificate verification, less processing resources are needed. B.6. PVP Privacy As reported by Michael Procter, there is ways with the current PVP methods to discover valuable information about a competitor. But first let's add some common vocabulary related to PVP: - - The PVP selector is a list of parameters that are sent by the PVP client side to retrieve a set of call records in the PVP server side. The resulting set can be empty, in which case the validation fails, can contain one element, or can contain multiple elements in which case the method description must also defines what call record should be selected (e.g. in the case of method "a", the most recent call record is selected). One important point is that the selector is always passed from the PVP client to the PVP server in clear, and so this is where the privacy leakage happens. - - The PVP parameter is a list of name/value pairs that are passed in clear between the PVP client and PVP server to aid the verification. Examples are the rounding value and the vservice id for methods "a" and "b". - - The PVP secret is the information that each side of the PVP transaction tries to verify. The algorithm used (SRP) uses a zero-knowledge password proof, so neither side can deduce the secret if the verification fails. In the case of methods "a" and "b" the secret is the rounded start and end time for the call, but there is a lot of other possible secrets that can be used in new methods (DTMF, UUIE, fingerprint, SMS hash, etc...). In the privacy issue, the problem is that callee number and caller numbers are disclosed in the PVP selector for method "a" and the callee number is disclosed in the PVP selector for method "b". One proposed solution would be to hash these numbers, but finding the phone numbers would still be trivial for a determined competitor. Passing the hash salt as a PVP parameter and using an adaptive hash method like bcrypt will force the PVP server to rehash all the current terminating call record, but will force a competitor to rehash probably half of the total E.164 space to find the numbers. This is still possible but can provide an adequate privacy protection level. Another possibility would be to invert the selector and the secret. After all the star/stop time of a call is not as sensitive as the caller/callee phone numbers. In this method the PVP selector would be the start/stop time and the secret would be the caller/callee numbers. The problem is that it will be more difficult to design an algorithm to select a unique call record if the returned set contains more than one. One solution could be to add more data in the PVP selector, for example by adding the call initiation time and the direction of the termination. We do not even need to decide - we can define these two algorithms as different methods (in addition to "a" and "b") and let the VIPR domain choose (see PVP registry proposal). B.7. PVP Methods Registry On the PVP subject, The VIPR specification currently defines two methods for the PSTN validation: Method "a", which is used when the Caller-ID is available and method "b", which is used when it is not. The PVP draft also permits to define new validation methods, but it does not explain when and how to use this extended methods. This proposal is in two parts. First we need to establish a IANA registry for the PVP methods, and to assign a priority to each of these methods. Let's say for now that the priority is between -∞ (lowest priority) to +∞ (highest priority) and that priorities should be assigned by steps of 100. With this scale we could assign priority 0 to method "b" and priority 100 to method "a". Then we say in the spec that a VIPR server must try available methods starting from the highest priority to the lowest priority, until one succeeds or all fail. This implements the same algorithm that is currently in -pvp ("a" first, then "b"). Now the problem with this is that the number of methods will increase in the future, but we may not want that the PVP client tries all the methods available each time. So the second part of this proposal is to have each VIPR domain publishing the list of methods supported by each of its phone numbers in the RELOAD distributed database, in the existing VIPR-REGISTRATION resource record. With this information, the PVP client immediately knows what methods to try from the VIPR-REGISTRATION record, and the order to try them from the IANA registry, and can also accumulate statistics on the usage of unsupported methods. The PVP server can use this mechanism to simplify the process. For example if it knows that it will never receive the Caller-ID, it just have to never advertize the "a" method. Another example is with analog FXO ports that cannot be used with either method "a" or "b". In this case the VIPR server can still advertize a new method using DTMF or fingerprint. Note that because the methods supported per phone number are stored in the RELOAD distributed database, the SIP call agent cannot retrieve them to decide what method to use when starting a call, as it would take too much time to retrieve it (same reason the validation is not done in real-time). But it can query them in the background using the history of calls or just before scheduling a re-validation. I would also propose to move the description of the generic PVP algorithm to the - -framework document, to add a section in -framework explaining how to register a new method on a IANA registry and to keep the two existing methods ("a" and "b") into the -pvp draft. B.8. PVP Entropy A second issue related to PVP is the management of entropy (Section 10.1 of the - -pvp draft). The idea is that the fact that one validation succeeds is not always enough for a remote VIPR server to give back routes and ticket for this destination. For example a VIPR domain could decide that at least 3 different calls validated with method "b" are needed to let a SIP call reach the endpoint. This proposal describes a mechanism for PVP to implement this. The idea is that when a PVP validation succeeds, the PVP server will return a ticket but may not return the list of routes if the entropy threshold is not reached. The ticket will contain an opaque value set by the PVP server that contain the level of entropy that this caller has reached. The PVP client stores the ticket but does not notify the call agent as there is no routes available. The next time the PVP client has a successful validation with the same destination, it sends the saved ticket in addition to the domain. The PVP server then evaluates the ticket, increases the entropy value stored and sends back a new ticket. If the threshold has been reached, then the PVP server sends back the routes at the same time, routes that the PVP client can now send with the ticket to the SIP element. When renewing the routes/ticket, the PVP client also sends the existing ticket, so the PVP server can decide to lower the threshold based on the entropy collected the previous time and the date of the ticket. This can be combined with the proposal for method priority. If multiple methods are available for a destination but the first that succeeds does not return the routes then the PVP client can use the next available methods in the list to try to increase the entropy and receive them. A PVP server may even use different thresholds, depending on the domains to validate. This then becomes an extension to the white/black list, where a blacklist is implemented as a default threshold of X and an infinite threshold for the domains blacklisted, and where a whitelist is implemented as a default infinite threshold and a threshold of X for the domains whitelisted. B.9. Ticket renewal Another thing that was discussed in Quebec City was the "First Call Problem", i.e. the problem that it takes up to 48 hours to verify a call and been able to use enhanced media. I think the conclusion of the discussion was that it was not too annoying for the first call, as it did not degrade the user experience. On the other hand, the cryptographic ticket granted after the first has an expiration date and so need to be renewed, and that will degrade the user experience as it would mean that for each destination, the end-user will periodically not be able to use enhanced media for the duration of a call. There was multiple proposals at the microphone to solve this problem, but I would like to detail the one I proposed. The idea is, sometimes before the expiration of the ticket, to make in parallel a PSTN call and a SIP call using the existing SIP route and ticket for the enhanced media (let's say video for the remaining of this discussion). There is already an existing I-D that can be use for this, draft-ietf-mmusic-sdp-cs. The way it could work is that the call agent, after retrieving the SIP route and ticket for a destination, will decide that it is time to re-validate the route, based for example on the frequency of calls to this number and the remaining validity of the ticket. The SIP element then adds an additional m= line to the SDP that contains a PSTN address. The offered SDP then looks something like this: v=0 o=- 2890844526 2890842807 IN IP4 10.47.16.5 s= c=IN IP4 10.47.16.5 t=0 0 m=audio 49170 RTP/AVP 0 m=audio 9 PSTN - c=PSTN - - a=setup:active a=connection:new a=cs-correlation: uuie callerid dtmf m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 The SIP element on the other side verifies the ticket then starts to process the SDP. If it does not support this feature then, as per the rules in RFC 3264, it will reject the second m= line by using port 0 in the answer SDP (In this case the end user will have to have PSTN only calls for the 48 hours after the expiration of the ticket). If the remote SIP element supports this extension then it will send back an offer like this: v=0 o=- 0 1 IN IP4 192.168.2.1 s= c=IN IP4 192.168.2.1 t=0 0 m=audio 8000 RTP/AVP 0 m=audio 9 PSTN - c=PSTN E164 +14085551234 a=setup:passive a=connection:new a=cs-correlation:uuie:2890W284hAT452612908awudfjang908 dtmf:14D*3 m=video 9000 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 The local SIP element checks that the c= line contains the right number, then establishes the audio and video media over IP, as usual, but also starts a PSTN call following the rules in draft-ietf-mmusic-sdp-cs (i.e. sending the correlation value as needed). The remote SIP element will receive the PSTN call, and correlate it with the existing SIP connection. Both parties must send audio on both the IP and the PSTN side, but the receivers can choose to play the audio coming from either the IP or PSTN connection (this is because we may want to use in the future fingerprint methods for the validation). The PSTN call is ended at the same time than the IP connection if the methods used for validation are based on the call duration (other methods may permit to end the call before), so the VCRs are processed as for an initial call. The local party marks the route as been under re-validation, so to not use the renewal method for the next 48 hours. The VIPR server will send a notification before the end of the 48 hours if there is still a PSTN route to this destination. B.10. 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." - -- 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) iEYEARECAAYFAk6EizYACgkQ9RoMZyVa61d51wCeIPIYd/nGpP00AQJjoScurKMq 13cAn3Jj+LutsSgskKWgte17sL5VpjSN =PoT/ -----END PGP SIGNATURE-----
- [VIPR] Agenda & Handout for 2011/09/28 Marc Petit-Huguenin