1996-03-10 - Re: FCC & Internet phones

Header Data

From: tbyfield@panix.com (t byfield)
To: cypherpunks@toad.com
Message Hash: d048e02105572277dad2978de10bccaa0733d008b338380579cd2eea0b64b7e6
Message ID: <v02120d00ad68230251cb@DialupEudora>
Reply To: N/A
UTC Datetime: 1996-03-10 07:22:20 UTC
Raw Date: Sun, 10 Mar 1996 15:22:20 +0800

Raw message

From: tbyfield@panix.com (t byfield)
Date: Sun, 10 Mar 1996 15:22:20 +0800
To: cypherpunks@toad.com
Subject: Re: FCC & Internet phones
Message-ID: <v02120d00ad68230251cb@DialupEudora>
MIME-Version: 1.0
Content-Type: text/plain


At 12:07 AM 3/10/96, Adam Shostack wrote re the Q:

>| >         Q: Is it practically possible to find netphone traffic on a
>| > generic network at any level above the source and target addresses?

>Presumably, the signal has a number of charictaristics.  Some of them
>have a central switchboard, where preople go to set up calls.  Most
>presumably use a mix of a UDP data connection and tcp for control
>functions.  They all consist of high volume, long duration connections
>(or data flows in the case of UDP.)  Many probably use a standardized
>destination port.  They might use the urgent pointer to force data up
>the stack quickly.
>
>        In short, yes the data streams can be easily found, if one can
>tap and grep a T3 in real time.

        That's a big if, given the priority such a tap would likely merit.
        Of the Mac apps I've seen (Maven, Cu-SeeMe Talk, and Netphone), the
last is by far the best. On startup it verifies registration by querying
the company's site, so it'd be easy enough to shut down at, at least for
now; but strangling it at that level would likely kill the company, which
would effectively orphan the code--a real factor, imo. In any case, there's
a crack floating around that circumvents this verification; obviously,
then, it'd also circumvent that method of enforcement.
        As for traffic characteristics, I've never seen one of these apps
work in full-duplex mode--just the allegedly fallback "push to talk" mode
(i.e., hold down the button while you yak, release it to listen), which
really changes the texture of a conversation--so the signal tends to be a
kind of high-volume call/response "negotiation" in slow-mo, with ~10-20
secs of transmission punctuated by null periods of about the same duration.
Ports are no problem, since the disassembly it'd take to rewrite the call
to another port would be minimal (and it'd be easy enough to make hack a
configurable port call to be arranged by mutual consent through plain old
UN*X Talk). The upshot being that signal analysis would be nontrivial--and,
from what I've read, the major telecom players aren't especially worried
that they'll lose business to this, so they'd likely resist getting saddled
with burdensome sniffing duties.
        And there's always PGPfone, which obviously flattens out signal
characteristics... heh heh.
        I think ACTA will make a valiant effort to ban this stuff, and the
FCC might listen--if only to safeguard its purview--but the only
"effective" way to enforce such a ban would be to impose yet another
policing duty on ISPs. Bandwidth aside, they've got better things to worry
about. And it'd be damned hard to work the public into a frenxy over free
long-distance phone calls.
        Basically, I think we got ourselves a winner.

Ted







Thread