Re: Vonage complains about VoIP-blocking

[John Todd <jtodd () loligo com>]

At 11:07 AM -0500 on 2/15/05, Steven M. Bellovin wrote:
> http://advancedippipeline.com/60400413
>
> The FCC is investigating -- it's not even clear if it's illegal to do
> that.
>
>                 --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb


This has been an interesting thread; lots of divergence.  I'll 
condense replies at the risk of losing some context threads.

It's unclear from the linked articles if this is a "blocking the 
provisioning system (TFTP)" or "blocking the VoIP signalling (SIP)" 
question.  There is speculation about both in this thread here on the 
list.


1) Several ISPs have been seen to be blocking SIP in my experiences, 
but it's been rare.  None of them have been "big" providers in North 
America, and in these rare instances customers quickly let their 
dollars do the talking - they have moved to alternate providers who 
do not block SIP.  Typically the response is outrage, and any ISP 
doing this type of selective interference should paint a big red 
target on their foreheads, to be shot at by customers, competitors, 
and regulators.
  Outside of North America, of course, the rules are significantly 
different, and the target often appears on the customer's forehead 
(see: Panama, China, perhaps India.)

  By saying that the FCC has jurisdiction over what packets can be 
carried, IP networks are treading dangerously close to the "common 
carrier" status.  Note to the Internet community: Careful what you 
wish for; you might get it.  Now, if the FTC should get involved, 
that is a different issue if the argument is phrased differently.

  Anyone want to venture a guess as to how Canada might deal with 
something like this situation?  Their very confusing rulings leave me 
scratching my head, so I'm unclear on what this would imply for their 
legal viewpoint.


2) "If they modulate the shields, modulate the phasers."   I'll trot 
out that worn out old Star Trek analogy here, since it's accurate. 
If devices in use support RFC 2782 (SRV) and are even halfway 
intelligent, then make systems run on ports other than 5060 as a 
failover.  Or to be more targeted, look for DNS requests from 
netblocks inside of $foolish_provider and the DNS resolver should 
then hand back SRV records for ports other than 5060.  (Hi, Patrick! 
Sounds like a speciality DNS product for Akamai targeted at the ITSP 
market.)  Then the proxy/registrar would be configured to answer on 
those ports.  This of course only works until $foolish_provider 
starts to meddle with RTP flows and degrades performance on the edge 
network, or intercepts/forbids DNS requests... but then one can 
cancel because of an SLA, and it is more clear that the "fault" lies 
with the IP network provider than with the remote SIP endpoint.


3) SIP as an "insecure protocol": well, that's all in the eye of the 
beholder.  SMTP is just as insecure as SIP, if not more so.  Now, if 
the argument is that "SMTP is blocked at the edge of most 
well-managed networks" that is correct, but that is because SMTP is 
an outgoing threat, while SIP is currently not such a threat (at 
least, I've yet to hear of an attack using port 5060, and even if 
there was, it's unclear that this would be any different than an HTTP 
or ssh or any other type of attack.)  Using the security argument for 
blocking SIP is hollow.  With the addition of TLS (this implies TCP) 
this becomes even more obviously inaccurate.

    Anyone know if SIP was being blocked by the nameless carrier on 
both TCP _and_ UDP?  (if it was SIP at all that was being blocked, 
which is still unclear from current data)


4) Configuration protocols: Most current SIP end devices use at least 
TFTP, but many use http and https.  There are still a handful of 
crippled devices (<cough>CISCO7900's<cough>) which still only use 
TFTP for device configuration.  Most vendors have figured out that 
this is inadequate, because SIP devices are now appearing on the 
"open Internet" instead of on closed intranets where threat was 
minimized (though this is no excuse for using unencrypted and 
unverified configurations via TFTP.)  The smart vendors are 
signing/encrypting their configuration files, with self-signed certs 
or simply shared secrets.  Some devices come "off the shelf" with a 
pre-installed key.  Not many vendors do this, but most of you reading 
this message have some contact with VoIP hardware vendors: beat them 
into submission if they don't support encrypted configs via https or 
http or _something_ other than tftp, and use encryption to protect 
customer username/passwords.  We'll all be better off if it's not 
possible (or at least much more difficult) for capacity vendors to 
politically argue for or technically block service or provisioning, 
but only the device manufacturers and softphone vendors can make 
service delivery and configuration more robust.

JT