Hadriel Kaplan wrote:
-----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)
Yes. (Under the assumption that sender domain is using it, otherwise you
are ending up with "dunno" too.)
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
+ 3pcc, +call-forwarding (could be sub-cases of some of the points above)
(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
Yes, that's I think a very good summary.
-jiri
(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
