[VOIPSEC] (Missed)Trust in Caller ID Act

Henry Sinnreich hsinnrei at adobe.com
Sun Oct 15 18:52:52 CDT 2006


>I grow rather tired of the arguments offered by the SIP community.

So do I for tolerating the emulation of the PSTN/PBX for which SIP was
clearly not designed. At a higher level, the "dumb" Internet with its
e2e principle was not designed for "Intelligent services in the
network". 
Note that I have avoided AIN :-)

See RFC 4485 on SIP Guidelines:

3.1.  SIP's Solution Space
...
   SIP is not meant to be used as a strict Public Switched Telephone
   Network (PSTN) signaling replacement.  It is not a superset of the
   Integrated Services Digital Network (ISDN) User Part (ISUP).
   Although it can support gatewaying of PSTN signaling and can provide
   many features present in the PSTN, the mere existence of a feature or
   capability in the PSTN is not a justification for its inclusion in
   SIP.
...

Henry



-----Original Message-----
From: voipsec-bounces at voipsa.org [mailto:voipsec-bounces at voipsa.org] On
Behalf Of Geoff Devine
Sent: Saturday, October 14, 2006 10:01 AM
To: voipsec at voipsa.org
Subject: Re: [VOIPSEC] (Missed)Trust in Caller ID Act

Jesus Oquendo writes:

> Is this fair? What about overseas companies passing off bogus
> information, what mechanisms exist for checking the validity
> of where the call is coming from? E.g.:
>
> Russian-VoIP-ISP.com is a known VoIP despot who routes calls
> through some point to point in the US. That point to point
> routes it through Level3 down the chain, there is no mechanism
> I know of that can do reverse checking to validate that this
> number is coming from a legitimate source. Is this Level3's
> fault? 

In a word.... Yes.

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.

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".  
 * We watched the VoIP community howl in anguish about emergency
services
   requirements.  
 * We watched the VoIP community howl in anguish about lawful intercept
   requirements.  
* We watched the VoIP community howl in anguish about universal service
  fees.  
* Malicious calls (a.k.a. SPIT) and customer originated trace
  requirements are another big problem in VoIP networks.  

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.  

Geoff

_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org




More information about the Voipsec mailing list