Vonage complains about VoIP-blocking
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
http://advancedippipeline.com/60400413
The FCC is investigating -- it's not even clear if it's illegal to do that.
How is this any different then blocking port 25 or managing the bandwidth certain applications use. Adi
Consider the possibility that a VoIP customer uses ISP xyz that decides to start filtering ports/protocols for VoIP, and that customer needs to make a 911 call from their VoIP phone? Adi Linden wrote:
http://advancedippipeline.com/60400413
The FCC is investigating -- it's not even clear if it's illegal to do that.
How is this any different then blocking port 25 or managing the bandwidth certain applications use.
Adi
On Tue, 15 Feb 2005, Adi Linden wrote:
http://advancedippipeline.com/60400413
The FCC is investigating -- it's not even clear if it's illegal to do that.
How is this any different then blocking port 25 or managing the bandwidth certain applications use.
could be there are some 911 access issues... perhaps that's important to someone.
I can see where it may come to a LEC being able to block a competitor's port only if they offer a comparable service. It will be an interesting ride to be sure. -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Christopher L. Morrow Sent: Tuesday, February 15, 2005 9:58 AM To: Adi Linden Cc: nanog@nanog.org Subject: Re: Vonage complains about VoIP-blocking On Tue, 15 Feb 2005, Adi Linden wrote:
http://advancedippipeline.com/60400413
The FCC is investigating -- it's not even clear if it's illegal to do that.
How is this any different then blocking port 25 or managing the bandwidth certain applications use.
could be there are some 911 access issues... perhaps that's important to someone.
At 10:07 AM -0800 2/15/05, Jim Devane wrote:
I can see where it may come to a LEC being able to block a competitor's port only if they offer a comparable service. It will be an interesting ride to be sure.
Imagine Verizon blocking AOL dialup numbers [since verizon also provides internet access]... Not exactly the same thing... -mKaegler -- Michael "Porkchop" Kaegler, Network Analyst, 845 575 3061 Marist College, 3399 North Road, Poughkeepsie, NY 12601 Last week a cop stopped me in my car. He asked me if I had a police record. I said, no, but I have the new DEVO album.
Michael Kaegler wrote:
At 10:07 AM -0800 2/15/05, Jim Devane wrote:
I can see where it may come to a LEC being able to block a competitor's port only if they offer a comparable service. It will be an interesting ride to be sure.
Imagine Verizon blocking AOL dialup numbers [since verizon also provides internet access]... Not exactly the same thing... -mKaegler
Some of us remember the days when central offices would run out of PRI capacity, but the LEC owned ISP's would still be able to get new phone banks installed out of those CO's... But the "we're your friends - no really we are!" lunches that the LEC's sponsored back then more than made up for these minor inconveniences... -W
I can see where it may come to a LEC being able to block a competitor's port only if they offer a comparable service. It will be an interesting ride to be sure.
What if a LEC added QoS to increase priority of their own VoIP product and reduced QoS on their competitors? Packets are still getting through but the voice quality sucks. Are the VoIP providers paying to have premium service on the LEC network? -Matt
Christopher L. Morrow wrote:
On Tue, 15 Feb 2005, Adi Linden wrote:
http://advancedippipeline.com/60400413
The FCC is investigating -- it's not even clear if it's illegal to do that.
How is this any different then blocking port 25 or managing the bandwidth certain applications use.
could be there are some 911 access issues... perhaps that's important to someone.
The last I checked, Vonage didn't have selective router access (that's fancy talk for REAL 911 access) - at least in my market. When you dial 911 from your Vonage phone, your call is sent to the 7-digit inbound number for the default PSAP. For response time, reliability, overall safety, you were better off dialing 911 from your cellphone. We have a VoIP provider living in our datacenter. It took quite some doing to get their PS-ALI set up with their PSTN carrier. Problem: Unless the ALI record is updated to reflect "voip phone customer address", when one of their customers dialed 911, the selective router sent the call to the closest PSAP for our datacenter and the dispatcher got the address of our datacenter. VoIP is nifty. I'm a huge fan but.... Buyer beware when it comes to 911 access. Dialing 911 and hearing "911 what is your emergency" isn't always a good enough test. You need to verify that the ALI information is correct, blah blah blah. John
On Tue, Feb 15, 2005 at 11:53:59AM -0600, Adi Linden wrote:
How is this any different then blocking port 25 or managing the bandwidth certain applications use.
If the article is correct, and the ISP involved is also a LEC, then it would be pretty clearly anticompetitive, and the LECs have some legal obligations to provide access to their customers. I don't think any such restriction would also apply to a normal ISP, but that could change. We'll see. --msa
On Tue, Feb 15, 2005 at 10:22:56AM -0800, Majdi Abbas wrote:
On Tue, Feb 15, 2005 at 11:53:59AM -0600, Adi Linden wrote:
How is this any different then blocking port 25 or managing the bandwidth certain applications use.
If the article is correct, and the ISP involved is also a LEC, then it would be pretty clearly anticompetitive, and the LECs have some legal obligations to provide access to their customers.
I don't think any such restriction would also apply to a normal ISP, but that could change. We'll see.
Internet stuff is unregulated still in the US last i knew. Perhaps this will be the idiotic move by a SP that causes someone to step in and impose some. At minimum, i'd like to see some sort of Universal-Service offering surrounding high speed internet access (eg: 512k dsl) in the US market. This way Ma and Pa Kettle can get their Microsoft patches at a reasonable speed. Either way, this is a provider asking to be smacked down. I wouldn't mind it if they were named so we could shame them into perserving the end-to-end nature of the internet. btw, port 25 blocks are primarily for anti-spam purposes because people can't keep their machines from getting infected. I'm all for them unless you're purchasing some more-dedicated-type service. The days of dialing up with your mail server and updating dns are over. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Anyone know which rural LECs might be involved? I find it interesting that it isnt an MSO or RBOC doing the blocking - perhaps the greater lawyer:engineer ratio at those organizations prevents it? The other interesting aspect is that there seems to be a bit of a persecution complex on the part of some VoIP providers. Of course, even paranoids have enemies, as they say :) -- Daniel Golding Network and Telecommunications Strategies Burton Group On 2/15/05 1:22 PM, "Majdi Abbas" <majdi@puck.nether.net> wrote:
On Tue, Feb 15, 2005 at 11:53:59AM -0600, Adi Linden wrote:
How is this any different then blocking port 25 or managing the bandwidth certain applications use.
If the article is correct, and the ISP involved is also a LEC, then it would be pretty clearly anticompetitive, and the LECs have some legal obligations to provide access to their customers.
I don't think any such restriction would also apply to a normal ISP, but that could change. We'll see.
--msa
On Tue, Feb 15, 2005 at 11:53:59AM -0600, Adi Linden wrote:
How is this any different then blocking port 25 or managing the bandwidth certain applications use.
Something else to consider. We block TFTP at our border for security reasons and we've found that this prevents Vonage from working. Would this mean that LEC's can't block TFTP? Eric :)
On Tue, Feb 15, 2005 at 01:45:05PM -0500, Eric Gauthier wrote:
On Tue, Feb 15, 2005 at 11:53:59AM -0600, Adi Linden wrote:
How is this any different then blocking port 25 or managing the bandwidth certain applications use.
Something else to consider. We block TFTP at our border for security reasons and we've found that this prevents Vonage from working. Would this mean that LEC's can't block TFTP?
This is a significant issue. Vonage is complaining about what are purportedly deliberate actions to block their service, while at the same time trying to sweep under the rug that *they have chosen to provide their service using insecure protocols that some carriers might quite reasonably choose to filter*. If their -- centrally-provided: everything is forced through their SIP proxy anyway, resulting in a voice network architecture that really looks like a giant corporate VoIP PBX -- service were actually properly resistant to tampering and random-adversary eavesdropping, it would *also* have the property that it were opaque to intermediate networks: providers blocking SSL or ESP to Vonage's proxies would _clearly_ have no motivation to do so save interference with Vonage service. It is my general impression of Vonage that they are very, very savvy about gaming what they percieve as the regulatory trend at the Federal level in an attempt to cut technical corners and thus grow their service faster than they could if they consistently did things "right". The history of their many, many wiggles on 911 access shows this pretty obviously, I think, and here I believe we have another case: they want to try to get regulatory agencies or the courts to force intermediate networks to let their packets through (by claiming all such filtering _must_ be deliberate) rather than actually doing what, on technical grounds, they ought to do anyway, and provide real security to their customers. It is understandable, and probably a viable economic and political strategy, but that doesn't really make it right. It behooves those of us who understand the actual underlying technical issues (e.g. telco routing and human factors issues with Vonage's so-called 911 service; man-in-the-middle and eavesdropping issues with Vonage's totally unsecured TFTP boot and SIP services from each ATA) to do our best to point them out, so that, if possible, coercive regulatory decisions are not made on the basis of smoke and mirrors. Thor
On Tue, Feb 15, 2005 at 11:53:59AM -0600, Adi Linden wrote:
How is this any different then blocking port 25 or managing the bandwidth certain applications use.
Something else to consider. We block TFTP at our border for security reasons and we've found that this prevents Vonage from working. Would this mean that LEC's can't block TFTP?
Exactly my point. If my network management practises impact service my customers use it is an issue between me and my customers. If I loose customers over it, I'd better be prepared to deal with the fallout. I do not think someone offering a service somewhere in the world has the right to demand that I make this service available to my customers. Adi
Why block TFTP at your borders? To keep people from loading new versions of IOS on your routers? ;) Not trying to be flippant, but what's the basis for this? - Dan On 2/15/05 1:45 PM, "Eric Gauthier" <eric@roxanne.org> wrote:
On Tue, Feb 15, 2005 at 11:53:59AM -0600, Adi Linden wrote:
How is this any different then blocking port 25 or managing the bandwidth certain applications use.
Something else to consider. We block TFTP at our border for security reasons and we've found that this prevents Vonage from working. Would this mean that LEC's can't block TFTP?
Eric :)
Hi, Dan. ] Why block TFTP at your borders? To keep people from loading new versions of ] IOS on your routers? ;) Funny you should mention that. :) We have seen miscreants do exactly that. They will upgrade or downgrade routers to support a feature set of their choosing. A lot of malware uses TFTP to update itself as well. Please note that I am NOT advocating the blocking of TFTP. Thanks, Rob. -- Rob Thomas http://www.cymru.com Shaving with Occam's razor since 1999.
I've gotten a couple emails on this. To summarize: 1) some malware uses tftp. However much malware now uses other ports, such as 80 2) There are numerous buffer overflow bugs with tftp. This would seem to be better resolved with rACLs or ACLs towards loopback/interface blocks. (and, of course, turning tftp off and using scp or sftp) It would be interesting to find out what percentage of Internet accessible routers are remotely upgradable via TFTP presently. Sadly, this would be non-zero... - Dan On 2/15/05 4:28 PM, "Rob Thomas" <robt@cymru.com> wrote:
Hi, Dan.
] Why block TFTP at your borders? To keep people from loading new versions of ] IOS on your routers? ;)
Funny you should mention that. :) We have seen miscreants do exactly that. They will upgrade or downgrade routers to support a feature set of their choosing.
A lot of malware uses TFTP to update itself as well.
Please note that I am NOT advocating the blocking of TFTP.
Thanks, Rob.
On Tue, 15 Feb 2005, Rob Thomas wrote:
Hi, Dan.
] Why block TFTP at your borders? To keep people from loading new versions of ] IOS on your routers? ;)
Funny you should mention that. :) We have seen miscreants do exactly that. They will upgrade or downgrade routers to support a feature set of their choosing.
A lot of malware uses TFTP to update itself as well.
Didn't nachi setup a tftpd on infected systems and then use tftp to load itself onto systems it spread to? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Tue, 15 Feb 2005 16:18:01 -0500 Daniel Golding <dgolding@burtongroup.com> wrote:
Why block TFTP at your borders? To keep people from loading new versions of IOS on your routers? ;)
Fear.
Not trying to be flippant, but what's the basis for this?
In addition to what others have said. The T in TFTP and the use of UDP is a clue as to why you'd want to use TFTP. It's relatively light weight and relatively simple to implemented in a small platform with limited resources. It is not required to run TCP after all. It could be possible to build a relatively trustworthy TFTP process without having to expose the device to TCP-based processes that typically get used for SSH or HTTPS, Since the TCP-based methods tend to contain more code and thus more complex, vulnerabilities may be more likely. I'll also point that implementations will use port 69 in a single packet, the one from the client initially the write or read. That means if you really must filter, you might be able to get away with filtering the destination port in a particular direction that is most dangerous for you. John
Why block TFTP at your borders? To keep people from loading new versions of IOS on your routers? ;)
Not trying to be flippant, but what's the basis for this?
This is a really good question :) In our particular case, it was not to protect the network as others suggested. We do ACL our equipment, keep updated code, use private IPs were necessary, etc. We're a University network, but we're not completely insane ;) Of course we don't let random hosts TFTP to our gear... A while ago (18 months maybe?) our security team argued that filtering TFTP connections between subnets on our campus would slow down the spread of computer worms/viruses as many were using TFTP as part of their propogation vector. The decision was made that the trade off between the end-to-end principle (we didn't have a good counter at the time citing a particular application that was used and would break) and helping contain virus outbreaks was worth filtering, so the filter was put into place. No one has complained yet, so the filter has stayed in place. Eric :)
http://advancedippipeline.com/60400413
The FCC is investigating -- it's not even clear if it's illegal to do that.
For what it's worth, my ISP is owned by my rural ILEC, and I just cancelled my Vonage service because it had become unusable. However, the problem was not TFTP, it was rotten inbound voice quality, combined with a complete inability to contact anyone at Vonage by e-mail or phone to do anything about it. My link is a T1, and it has plenty of spare inbound capacity. Traceroutes suggest that Vonage is suffering from packet loss problems at gateways between their NSP and mine, or perhaps the packet loss within my NSP (Sprint) was too much for it. I switched to Lingo which works fine. Its box uses NTP to set the time, then http to configure. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.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
participants (19)
-
Adi Linden -
Andy Johnson -
Christopher L. Morrow -
Daniel Golding -
Eric Gauthier -
Jared Mauch -
Jim Devane -
John Fraizer -
John Kristoff -
John Levine -
John Todd -
Jon Lewis -
Majdi Abbas -
Matthew Crocker -
Michael Kaegler -
Rob Thomas -
Steven M. Bellovin -
Thor Lancelot Simon -
William R. Charnock