Media-One Express, IP Masquerading

[richb at pioneer.ci.net (Rich Braun)]

Michael O'Donnell wrote:
> ...  Examples of
> well-defined transgressions include being caught attempting to
> compromise security, or running a DHCP server.

I have a friend whose access was shut off by M1X because of a security
problem.  He had a system (I forget which O/S, I think it was actually
a Microsoft box) which ran a piece of software with a security hole in it.
A hacker used it to hide source addresses and wreak havoc in such a way
that M1X tech support got dragged into it.  My friend hadn't logged the
activity, so he got blamed for the hackery and had no way to prove it
wasn't him.  Finally after a couple of days he persuaded M1X to turn his
service back on.

>  That latter offense
> is death, even if it was only an accident, since m1x relies upon
> DHCP to dole out IP addrs; m1X has enough trouble keeping DNS
> and IP mapping working without some yo-yo gumming up the works.

I see the point.  To be safe, then, one should set up DHCP on a second
Ethernet port.  I don't see how this can cause problems once it's debugged.
This leads to an obvious suggestion:  use the templates posted in this
discussion forum and/or the web pages cited, and do all your debugging
with your M1X connection disconnected.

If my DHCP server is leaking back into my ISP, then they don't know about
it, and I haven't seen any logging activity.  Methinks the firmware on the
cable boxes for the M1X service should be modified to block DHCP packets
coming back to the ISP from a subscriber.  Shame on M1X for blaming the
customer for something they should take care of themselves.

>  And of course Linux is too wild and wooly to
> even consider supporting.  Such restrictions also reduce the amount
> of OS familiarity required of their installers.  The installers who
> activated my service knew what I had in mind, but they're obliged
> to go by the book, and had to insist on one of the sanctioned OS's.

That's fine, and indeed most every ISP has this policy:  use Mac or Windoze,
you can call tech support; use Linux, you're on your own.  That's why
discussion forums like this exist--to provide help outside the commercial
services.

> Other definitions of "minding your manners" are less well defined,
> like "using too much bandwidth" 

... This is another of those too-expensive-to-meter sorts of problems.  ISPs
have been trying to figure out a way to charge heavy users more, but thus
far all attempts to set a price-per-packet fee at the retail level have
failed.  Wholesale bandwidth is routinely priced in a per-packet equivalent
fashion.  But it's not really metered--a point-to-point circuit is built
with X megabytes of capacity, which is sold at $Y per month until the
circuit gets clogged at which point the speed and price get bumped upward.
Co-loc service providers haven't even figured out how to meter traffic
on shared segments at their data centers.

> And there's always the [inevitable?] risk that m1x will be victims
> of their own success: more customers == less available bandwidth...

Not likely to happen.  The reason is the bottleneck at remote sites.  If
you buy a T3 or two and divvy it up among your cable subscribers, your
costs are pretty much flat-rated, and subscribers can't use up your
backbone connection until the rest of the Internet's capacity catches up.
I've been out of the backbone biz for six months now, but as of the summer
of '97 you simply couldn't buy more than about 90 megabits of capacity
no matter who you were.  And you couldn't use it up--most remote sites your
subscribes connect to don't have anything faster than a T1, so no matter
how many customers you piled on, the remote sites got bogged down as fast
as the customers could sign on.  The equation probably still looks similar
today--I don't think OC3 or OC12 services are common yet, the backbone
hardware has hit something of a plateau in performance; I think folks are
looking for technology breakthrough products in LAN hardware (gigabit
LANs for co-loc servers and NAPs) and WAN switching.

> I believe the "preferred" unofficial configuration simply employs
> a gateway machine (one computer with two Enet adapters)  That way
> the modem can never see any card but the "official" one and is thus
> prevented from recognizing any other (wrong) adapters.

That's the safe way to go, but the real issue is that the cable-modem
firmware simply has to be made more sophisticated.  If these companies
want to succeed, they've got to build adequate protection against conflicts
between subscribers.  Were I on the engineering team at a cable modem
company, I'd be looking to protect against any commonly-predictable
network abuse which an NT, Linux, Mac, Win95, or Solaris box could dish out.

Even if the problems were solely limited to misconfigured Linux boxes,
I would think the intersection between the community of Linux users and
the likely early-subscriber base of cable Internet users willing to
shell out $40+ per month would be large indeed.  Have the marketeers
been clued in to this?

-rich