Subject: [Rucus] Some comments on today's presentation

From: Otmar Lendl <[email-masked]>
Date: Mon, 10 Mar 2008 22:55:12 +0100

Despite Dan's heroic efforts as the jabber/skype scribe, I declined
to raise questions via him (unless it's a simple question on a slow
session, it's not worth the effort). There were a few notable points
during the presentations which merit a response, though:

Can someone please upload the slides of the CDT presentation?

---

From Henning's presentation:

I think slide 4 (categorization of groups) is way too simplistic.
You *want* to be able to reach your kid if your own phone broke down
(lost, out-of-batteries, some emergency) and you have to borrow one from
a stranger.

The Detection vs. Action slide is good. Way too much focus has been on
the detection part. Much more interesting (IMHO at least from a protocol
design point of view) is the Action part. If my oracle/policy decides
not to let a legitimate call through directly (e.g. no whitelist entry),
then what are the fall-back mechanisms with which the caller can get
through?  Perhaps some sort of fall-back routing via a premium rate
line provider which may charge serious money for the service. (As someone
rightly said: if a caller is prepared to pay 1$/min for talking with me,
I'm inclined to pick up the phone.)

---

On the 5039 presentation, the color-coded lists was good as it 
IMHO basically gave a possible solution in green:

* Use "Centralized Providers" to guarantee reachability
  (Whether it's on SIP or or TDM doesn't matter that much).
* Use "circles of trust" to provide arbitrage possibilities
  to smaller providers (or enterprises) against the big 
  centralized ones
* Use Consent/Whitelist schemes to enable direct IP calling
  for those 90% (or whatever) of calls which stay in close social
  groups.

---

Regarding Jim's slides:

Concerning "legacy": The overall inter-domain call routing architectures
of SMTP and SIP are identical, but the legacy isn't. Isn't that an
invitation to see whether we can't just use that difference to find a
solution to SPIT where there is none to SPAM?

In a nutshell: on the email side, everybody needs to talk to everybody
else: if you mess with that, you break email. 
On the SIP side, we currently have islands of SIP networks, with the
PSTN as connecting network. In real deployments, not everybody is talking
to everybody else.

The email side is battling to keep the bad guys out. They start from "I
accept every connection" and try to find reasons to block a specific
email. The state of the game is different in the VoIP world:  Zero SIP
interconnection is the norm (the PSTN is used), and people can look for
reasons why they should allow connections in.

That reason for letting someone connect to your SIP server doesn't need
to be perfect and fail-safe. It just needs to be in the same range of
SPIT-risk as an SS7 trunk connection.

---

To summarize: focusing on SPIT detection is a fool's game and the path
into an endless spy-vs-spy evolutionary escalation with the adversary.
(as with email and spam-detection).

Don't. Go. There.

What's needed is a more flexible call routing algorithm such that a
false positive (or incomplete whitelists, ...) is not the end of a
call. Once we have flexibility here, then the individual building blocks
don't need to be perfect. And we apply a judo-move on the PSTN and
leverage the settlement and trust relationships built in there.
Let them (or their SIP equivalents) deal with the 2% of calls which we
can't handle with the straight forward "good-call detection" algorithms
out there.

/ol
-- 
-=-  Otmar Lendl  --  [email-masked]  -=-
_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus