>One questions about the scope of this work ... are people only trying >to make it work for email style address or is the scope to also try >for E.164 style addresses?
I can't help remembering how hard it was for network designers to give up SNA addressing (at that time used for 80%-90% of the data networks) for IP addresses. Is anyone really thinking there are new, future applications and services that may use E.164? If so, it would be interesting to know what they may be. An example would help. Sure, there is the huge installed base of E.164, but so was SNA. This is not a valid reason to reject Derive. In this light, the limitations of Derive are very acceptable IMO. Henry On 11/13/08 12:54 AM, "Cullen Jennings" <[EMAIL PROTECTED]> wrote: One questions about the scope of this work ... are people only trying to make it work for email style address or is the scope to also try for E.164 style addresses? I think it is important to be clear about this when looking at any Forward Routing Verification or Return Routing Verification type scheme. I also think in any identity scheme, it's important to be clear what the trust relationship is between all the sip elements. On Nov 12, 2008, at 17:10 , Adam Roach wrote: > I've spent quite a bit of time over the past few days pondering the > approach laid out in the DERIVE draft. I think the approach of using > some form of "dial-back" to confirm identity has some merit (with a > few very strong caveats). I think the idea of leveraging already- > defined behavior is a good idea and somewhat clever; however, I > suspect that the exact mechanism defined in the current draft is not > yet well enough deployed for us to accept the limitations that it > imposes. > > > The Need For User-Visible Caveats > ================================= > > As we've seen with the XMPP system, dial-back approaches can be used > with a fair amount of success to prevent certain types of identity > spoofing (see XEP-0220). Caveats associated with this approach in > general include reliance on security of the DNS and IP routing > systems. We have seen real-world attacks on bot h in the past [1] > [2], so we need to make sure that user expectations for any dial- > back system are set appropriately. > > > SIP and Return Routability of AORs > ================================== > > However, when the flexibility of SIP routing is thrown into the mix, > the ability to reliably route back to the calling user's specific > device using that user's AOR becomes a much larger issue. > > For example, a caller at a call center my well advertise a calling > identity that reflects the contact point for that call center as > their "From" identity. However, calls made to that identity will > either reach an IVR or be dispatched to a random call center device > that has no knowledge of the calling party's dialog. Other normal > subscribed services, such as time-of-day routing, can have similar > results. Further, interaction with find-me-follow-me services -- or, > really, any service with serial forking -- can potentially result in > dramatic post-dial-delays that make execution of such a call-back > service infeasible. > > All of which is to say: any dial-back attempt using an AOR may > legitimately reach a device (or several devices) without reaching > the calling party's actual device. I would therefore assert that any > dial-back based strictly on AOR can at best confirm the veracity of > the "To" header field (with the DNS and routing caveats I mention > above). It cannot, under any circumstances, *refute* a claim. > > > Dialog-Package Re-Use > ===================== > > The actual use of the dialog event package in the DERIVE draft is > clever. The idea of being able to deploy a system based on what is > already in the field is very attractive, as it allows us to put the > solution into play immediately. However, based on results at SIPits, > it is supported by somewhere less than 50% of current UA > implementations (the estimate I got was "probably about one out of > three"). > > That's actually not a bad percentage, especially considering that > the incidence of dialog package implementation should only go up -- > it has immense value in a number of useful services. However, the > behavior that the dialog event package needs to exhibit to support > DERIVE is not sufficiently well defined in RFC 4325. We've had a > number of SIP experts weigh in on the SIP mailing list with widely > differing opinions about how UAs *should* operate. And if *we* can't > figure it out, I can guarantee that implementors have done... let's > use the work "innovative"... things in this space. > > In other words, I fear that whatever gains we achieve by re-using > the dialog event package are largely negated by the fact that we're > using the very aspects of it that have been most poorly specified. > > > Potential Alternate Approaches > ============================== > > If we don't re-use the dialog event package as-is, then we need to > either find some other widely-deployed, well-defined UA behavior > that we can leverage, or we need to define new behavior on both the > caller and callee equipment. I can't immediately think of a solution > that falls into the former category -- perhaps someone else can come > up with something clever. That leaves defining some new mechanism to > address a call-back mechanism. Jiri has suggest defining a new > method for call-back validation, and I think this is a reasonable > approach. > > Regardless of the approach taken, I would suggest that we should > leverage the use of public GRUUs to assist with routing to the > proper device. Devices that validate the identity of an incoming > request can render the public GRUU (with the ;gr parameter stripped) > as the calling party identity after they use it to reach the exact > calling device. With GRUUs thrown into the mix, we get around the > issue of potentially being unable to reach the calling party devices > -- this allows us to return actual negative hits in addition to > positive hits. > > In fact, if the calling party is using a GRUU, we might be able to > achieve some interesting results by taking the GRUU out of the > Contact header-field of the INVITE and sending back an innocuous in- > dialog request of some kind (UPDATE? OPTIONS? Dare I say INFO?) > *without* any route headers to see whether we get a 481 response... > > > Conclusion > ========== > > In short, I support work towards dial-back "better than nothing" > style security. And, while I commend the authors of DERIVE for their > ingenuity, I fear that the dialog event package is a poor enough fit > that we should explore other alternatives before going too far down > this path. > > /a > > > [1] > http://arstechnica.com/news.ars/post/20080225-insecure-routing-redirects-youtube-to-pakistan.html > [2] > http://arstechnica.com/news.ars/post/20071212-dns-poisoning-used-to-redirect-unwitting-surfers.html > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
