Re: draft-kuthan-sip-derive

Hi Adam,

thank you very much  -- that's been most helpful indeed and I agree
with pretty much all the points. I would highlight the scope and
the actual verification mechanisms.

I think that the scope, better-than-nothing, which just works with
the same infrastructure, as for INVITE delivery, and makes on
particular trust assumptions, begins to be agreeable.

I agree too the actual verification mechanism, is difficult to agree
upon. For now,I would resort to listing how such can differ from each
other:
- it it E2E (i.e., without any support in the network)
   -- that's obviously the objective
- does it work with existing UA implementations, at least with
   some? That's desirable, not sure if really feasible.
- if it leans on some existing SIP extensions, are these specified
   in a way that the scenario can unambiguously lean upon? (unfortunately
   not the case with dialog package)
- does it work for requests that don't establish dialogs (preferably
   yes)
- can it deal with forking?

So far I have heard further suggestions for using some combination of
OPTIONS, dialog authorization, or even a new method -- but we haven't
really yet tested those hard.

Also the applicability is a key  aspect -- reverse routability
agreeably being the most important one (apart from latency, security
assumptions such as uncompromised DNS). I think the general
approach is to explain that positive assertions are useful, negative
don't give much, and document examples of when it fails, possibly
accompanied by remedy suggestions:
- unregistered UAC, UAC with call forwarding, anonymous UAC: don't do it :)
   (possibly offer to retry)
- B2BUA: if you break it you fix it
- tel URI .... perhaps resolving to IP if possible?
- shared URI ....
- UAC's proxy forwarding SUBSCRIBEs somewhere else...
- 3pcc...

-jiri

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