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