At the end of the day it's just a form of return-routability test, subject to the same middle-box trust issues we already know and love. Not that there's anything wrong with that, just that I don't think they're claiming it does anything more than that.
With regards to your specific scenario, you said with 4474 if sp.net did NOT interfere with the From-uri then you can verify where the call really came from. (example.com) But if sp.net did not interfere with the From-uri, then Derive will also route to example.com. 4474 does not and cannot prevent sp.net from changing the From-uri to sp.net - it can only prevent sp.net from changing it to example.com, or foobar.com. If sp.net changed it to foobar.com, Derive could catch that in some cases, but obviously if the Derive message just happened to go through sp.net then sp.net can successfully lie and make the Derive check succeed. Whereas 4474 would catch the lie no matter what. BTW, I think it still is subject to the Baiting attack. I make a Bank call me, and I then re-use its call-id+tag in an INVITE I send to you. Since it's the same call-id and tag, Bank will say "yes I'm making that call". But I assume the purpose for Derive is not to try to prevent all kinds of middle-man/middle-box attacks, but rather prevent spray-spamming and some basic identity fraud scenarios in a better-than-nothing approach. No? -hadriel > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Elwell, John > Sent: Wednesday, November 19, 2008 11:15 AM > To: IETF SIP List > Subject: [Sip] Another possible limitation of DERIVE > > Suppose, for the sake of argument, we go with Hadriel's draft and > OPTIONS, e.g., global call ID in INVITE request, sent back in OPTIONS > request with global call ID to URI obtained from receive From. > > Now suppose the initial From URI is sip:[EMAIL PROTECTED];user=phone > and this gets modified by callee's service provider to > sip:[EMAIL PROTECTED];user=phone. Callee UA sends OPTIONS request to the > latter URI. B2BUA in sp.net acts as UAS for the OPTIONS request and > returns 200 OK, on basis that it recognises the global call ID. What > does this give me? Basically that the call arrived via my service > provider, which I know anyway if it arrives over a TLS connection for > which I have authenticated the service provider. The problem is, I don't > know that sp.net has terminated the OPTIONS request. Even if the service > provider has not acted in this way and the OPTIONS request has gone all > the way back to the caller UA (or at least to its domain proxy/B2BUA), I > have no evidence that this is so. > > Now contrast this with RFC 4474. With RFC 4474, sp.net can change the > URI as above and re-sign (insert a new Identity header field). At least > my UA can see that the only guarantee I have is that the call arrived > via sp.net. On the other hand, if sp.net has not intervened in this way > I can see where the call has really come from (subject to B2BUAs not > breaking the signature). In other words, RFC 4474 tells me who is > asserting that it sent the INVITE request, whereas DERIVE just tells me > that someone is asserting that it sent the INVITE request. > > John > > _______________________________________________ > 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
