[geeks] FBI vs. bandwidth thieves

[Greg A. Woods]

[ On Thursday, June 27, 2002 at 20:24:10 (-0400), Joshua D Boyd wrote: ]
> Subject: Re: [geeks] FBI vs. bandwidth thieves
>
> On Thu, Jun 27, 2002 at 06:21:10PM -0400, Greg A. Woods wrote:
> 
> > The issue though isn't with limiting bandwidth per se, but rather with
> > locking down the modems so your customers (or the rest of the Internet)
> > can't screw with them.
> 
> So, with that DOCSIS system, you can't control your customers speed
> into you.

Yes, you can control the bandwidth allocation the modem makes -- you
just have to make sure the customer (and anyone/everyone else in the
world) can't ever control their own modems.  That's not nearly so hard
as it sounds because the modem _must_ TFTP its configuration file from
wherever the CMTS tells it to.  Unless you can spoof packets on the RF
side you're never going to "own" your modem! :-)  With DOCSIS-2.0 you
supposedly won't even be able to spoof RF packets unless you can also
break the encryption used on the RF side of things (even 1.1 may afford
enough protection against RF signal spoofing/sniffing, and do so in a
deployable fashion).

Indeed the operator can fairly easily arrange things so that even if
some non-customer plugs his own store-bought modem into your plant the
only thing he can do is browse your provisioning web pages and sign up
for service.  (My clients currently don't do that (every modem MAC must
be known to the DHCP server) -- they only support modems that they
lease, just to keep compatabiliity issues at bay, and yes there are lots
and lots of the latter even with standards conforming modems!)

>  You still can speed there speed going back out again.

"You can still control their speed..."  :-)

Yes, but that's "REALLY HARD" to do effectively -- or rather REALLY
expensive to do correctly.  Many "core" routers now include facilities
to control throughput per-flow, and some of them can handle upwards of
millions of flows at a time or so, but it gets complicated and if you're
trying to use flow-based rate limiting for other purposes (eg. giving
your customers a better pull with KaZa et al than outsiders can get from
them, which is literally necessary when you have asymmetric bandwidth
allocations as required by the available bandwidth on the return
segments of your cable plant), it really quickly gets in the way too.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods at acm.org>;  <g.a.woods at ieee.org>;  <woods at robohack.ca>
Planix, Inc. <woods at planix.com>; VE3TCP; Secrets of the Weird <woods at weird.com>