> -----Original Message----- > From: Jiri Kuthan [mailto:[EMAIL PROTECTED] > Sent: Monday, December 08, 2008 3:36 PM > > Hadriel Kaplan wrote: > > Actually, I would debate that. Derive and other return-routability > checks have the property of: "if I pass then you know I'm good, if I fail > then you know nothing (neither good nor bad)". I would argue such a > property is only useful in voice communications if it passes and provides > a positive/"good" result *frequently*. > > Well, I don't think really this is specific to DERIVE -- most of > communication technologies > are useful only if used frequently. (economists call it networking I > recall). The starting > point is obviously zero, the key challenge is a growth strategy and I > thinkt the key to it > is simplicity.
Sure, but I meant it in the context of even once everyone does it. Let's assume every UA on the planet supports doing this DERIVE check right now. If the check only works a small portion of the time when the call is actually good, then I would argue it won't stop Palin from assuming she's talking to Sarkozy - because a failure is not really a failure and can't be treated as a failure. It's kinda like that annoying "This page contains both secure and nonsecure items" warning you get when you go to www.ietf.org agenda pages. You get it so often you just ignore it, or turn it off altogether. Anyway, Derive can't actually detect forgeries - it can only detect (some) non-forgeries. That's a different property than a 4474-type thing; in a 4474-type thing a verification failure is actually a real failure; the kind of thing to alarm on and log and such. (if we had a working 4474-type thing) And I didn't mean it as a knock on Derive - I meant that it contradicted Dean's claims, but if and only if Derive fails most of the time when the call is in fact legit. I believe the cases where Derive fails even when a call is legit (false negatives), are: 1) Multiple contacts for a single AoR - it's a roll of the dice to get the right one 2) No contact for an AoR (e.g., From-URI is the main business number) 3) Can't reach that AoR domain (e.g., the call was forwarded to you, with no applicable SIP direct return path) 4) Can't reach that AoR domain with a SUBSCRIBE, but could an INVITE 5) B2BUA's in the signaling path, but the return path does not cross the same exact B2BUA's 6) B2BUA's in the signaling path, and they don't all support dialog-event package 7) UAC itself doesn't support the dialog-event package 8) UAC's domain doesn't allow subscriptions to dialog-event from outside its domain 9) E.164 Phone numbers, in general 10) Malicious middleboxes (Some of those above are eventually fixable, BTW) I believe the cases where Derive passes (says "legit") even though the call is actually a forgery (false positives), are: 1) Malicious middleboxes 2) Baiting attacks 3) From-URI encoding hacks 4) DNS spoofing or other attacks on rfc3263 (Which isn't much worse than any other mechanism, fwiw) -hadriel _______________________________________________ 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
