Re: Cable Modem [really responsible engineering]

["Wojtek Zlobicki" <wojtekz () idirect com>]

----- Original Message -----
From: "Daniel Senie" <dts () senie com>
To: "Wojtek Zlobicki" <wojtekz () idirect com>
Sent: Tuesday, June 26, 2001 9:51 PM
Subject: Re: Cable Modem [really responsible engineering]


> At 09:43 PM 6/26/01, Wojtek Zlobicki wrote:
>
>
> > ----- Original Message -----
> > From: "Chris Adams" <cmadams () hiwaay net>
> > To: <nanog () merit edu>
> > Sent: Tuesday, June 26, 2001 9:20 PM
> > Subject: Re: Cable Modem [really responsible engineering]
> >
> >
> > > Once upon a time, Miquel van Smoorenburg <miquels () cistron-office nl>
said:
> > > > When the BRAS requests config info when the circuit goes up (using
> > > > radius) or when it acts as a DHCP relay, it includes the VPI/VCI
> > > > of the ATM channel in the request. That means that you can assign
> > > > IP addresses based on the physical connection rather than the MAC
> > > > address, and this is what we do [well, will do soon anyway ;)]
> > >
> > > Okay, but how do you keep the end user from putting a different IP in
> > > their computer?  We use PPPoA for our "residential" DSL, but someone
> > > that works here lives outside our service area (small local telcos are
> > > all over this area), and just got DSL from his local telco/ISP, which
> > > uses 1483 bridging.  He has multiple computers, so he just picked
> > > another address, pinged it to see it wasn't in use at the moment, used
> > > it, and it worked just fine.
> >
> > Access lists are one way to go :)  You dont get out unless we say so :)
> >
> > > Also, how do you prevent the user from trying to forge someone else's
> > > IP address or even MAC address in outgoing packets?  Without
protecting
> > > against forged packets, I don't see how to provide accountability when
> > > someone attacks.
> >
> > How would anyone find out anothers MAC.  As long as you seperate each
> > customer into their own bridge group, there is no way for them to find
> > anothers MAC.  As for forging IP's not much you can do about that.  MAC
> > address access list.. do they exists ?
>
> Broadcast packets... DHCP DISCOVERs if nothing else.
>
>          tcpdump -i eth0
>
> on a Linux box attached to my cable modem finds all kinds of broadcast
> packets from neighbors' computers (mostly Windows-related packets) as well
> as ARP requests. It's possible this is just a poorly configured system,
but
> I'm not sure how bridge groups are going to isolate you from one another
> AND block broadcasts, and still allow users to play interactive games
> against one another (i.e. you still have to let them send packets around
> the neighborhood).

There is not much you can do about broadcast packets.  This is not a grave
security
risk as most of this traffic is benine.  It is unicast traffic that I would
not want you to see (can you see any of that?).  With carefull subnetting,
you could prevent these from being seen.  Is it plausible (I don't know the
cable modem hardware well enough to comment here) to assign IP/32 to virtual
interfaces ?  Since a subnet in this case is only ony IP, there is no
broadcast.  How could one filter out MAC layer or IP layer broadcasts ?

BTW , if you really want to kill a few weeks of your time, get a copy of
TCPTRACE and XLOT.  TCPTRACE allows you to take a tcpdump dump file
(tcpdump -w dump_file_name ) and plot it.  You can track RTT, windows size,
throughput.  XPLOT is used to display the plots created by TCPTRACE.

> > > DHCP or RADIUS (how did I know you used RADIUS :-) ) is fine for
> > > assigning things, but how do you _enforce_ those assignments?  I know
> > > how with PPPoA, but not with a bridged network (the same thing applies
> > > with cable modems).
> > >
> > > --
> > > Chris Adams <cmadams () hiwaay net>
> > > Systems and Network Administrator - HiWAAY Internet Services
> > > I don't speak for anybody but myself - that's enough trouble.
>
> -----------------------------------------------------------------
> Daniel Senie                                        dts () senie com
> Amaranth Networks Inc.                    http://www.amaranth.com