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:

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.

Christopher L. Morrow 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

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

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

Imagine Verizon blocking AOL dialup numbers [since verizon also provides internet access]... Not exactly the same thing...
-mKaegler

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 :slight_smile:

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 :slight_smile:

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

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

Michael Kaegler 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

Samantha Fetter wrote:

Hi, just wanted to let you know that a friend recently got Vonage, and they had to go through a special process to get 911 properly associated with her address so that it would work right. I'm guessing that means they have "REAL 911 access"? I'm not familiar with that all, so pardon my lack of technical terms :

Cheers,
Samantha

If they had to go through a "special" process, then no. That would indicate that Vonage still doesn't have PS/ALI, at least in your friends market.

That "special" process is Vonage determining the "default" PSAP in your area and routing your 911 call to the 7-digit number for that PSAP. With PS/ALI, Vonage wouldn't be doing the routing. They would hand the call off to the 911 Selective Router which would THEN hand the call off to the appropriate PSAP based on a DIG to get your ALI information.

For those of you unfamiliar with how E911 works, and specifically, PS/ALI, take a look at: http://www.xo.com/products/smallgrowing/voice/local/psali/

Or... Simply google for "PS/ALI".

John

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? :wink:

Not trying to be flippant, but what's the basis for this?

- Dan

Hi, Dan.

] Why block TFTP at your borders? To keep people from loading new versions of
] IOS on your routers? :wink:

Funny you should mention that. :slight_smile: 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.

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

Why block TFTP at your borders? To keep people from loading new versions of
IOS on your routers? :wink:

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