[VOIPSEC] (Missed)Trust in Caller ID Act

[J. Oquendo]

Geoff Devine wrote:

> To it's up to Level3 to police their trust federation.  If they have a
> customer who is allowing Russian-VoIP-ISP.com to spoof CallerID, Level3
> must pull the plug on that customer or at least filter CallerID for
> calls from that customer.

And this is expected how. That was my initial argument on the re-subject
of this post. How does anyone expect ANY company to provide such type
of filtering when there is no mechanism nor could there ever be one that
will simplify, even undertake this kind of filtering. Based off of what
do you propose? An IP Address? Sorry these change. Based off of DID's?
Sorry porting kills this notion.

> I grow rather tired of the arguments offered by the SIP community.  The
> telephone network has a known set of requirements.  SIP and SIP-based
> VoIP architectures were created that completely ignored those
> requirements.  The reality of legacy requirements keeps intruding on the
> SIP community and the knee-jerk reaction is to reject these requirements
> out of hand as being "old" and "obsolete".  

Maybe it's because they are old and obsolete. Technology has evolved and
whether the old Praetorian Guards like it or not, the remedy is not a hop
skip and a jump away, in fact they aren't even on the drawing table. Maybe
this discussion will allow those "Guards" to take a quick step back and
assess it entirely in order to move forward as opposed to sitting back
responding "It's not our problem anymore". 

>  * We watched the VoIP community howl in anguish about lawful intercept
>    requirements.  

Define "lawful" when this government has been doing UNLAWFUL taps for
some time now.

> In this thread, we're watching the VoIP community howl in anguish about
> CallerID problems they created and are expected to fix.  Most of the
> legacy telephony requirements are there for very good public policy
> reasons.   In my opinion, it's a very poor engineering job to build
> something without first learning the full requirements.  

My gosh, you've just described every single protocol/product in existence.
What has been done to these products and protocols, they've been modified
to conform in time. Nothing has been perfect at its inception and PSTN
is definitely no exception to the rule.

So the question remains, how does anyone expect to fix this issue when
a fix will break more than it will actually fix. So what can be done?
Reverse-DID-Validation? Based on what? Logic dictates IP addresses change
so does the company who owns the DID.

Scenario1:

2035551212 (Belongs to SomeTelcoCompany as of 10/13/05) it resolves to
let's say Cox's AS26204 (24.248.88.0/22 range).

Level3 applies filters to accept 2035551212:24.248.88.0

Call --> 2035551212:24.1.2.0/24 --> ROUTES --> FILTERED

Level3 decides to filter this call since it is not coming from the
"accepted" range.

All is fine correct? Wrong. Customer ports their number to Comcast's
AS22909 24.0.0.0 range. So now this customer is getting blocked because
someone decided that they were going to do filtering. So how do you
propose filtering... DID's won't work, IP can never work. So what
protocol here is broken, SIP? I don't think so.

It's not about pointing fingers at which group has bigger better
"cojones" its about "what can be done", definitely some insane law
won't solve much in fact it will create a bigger mess.


====================================================
J. Oquendo
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743
sil . infiltrated @ net http://www.infiltrated.net 

The happiness of society is the end of government.
John Adams