Vonage complains about VoIP-blocking
John Todd
jtodd at loligo.com
Thu Feb 17 01:42:20 UTC 2005
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
More information about the NANOG
mailing list