nanog mailing list archives
Re: Cable Modem [really responsible engineering]
From: "Wojtek Zlobicki" <wojtekz () idirect com>
Date: Tue, 26 Jun 2001 21:43:15 -0400
----- 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 ?
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.
Current thread:
- Re: Cable Modem [really responsible engineering] Fletcher E Kittredge (Jun 25)
- <Possible follow-ups>
- Re: Cable Modem [really responsible engineering] Fletcher E Kittredge (Jun 25)
- Re: Cable Modem [really responsible engineering] Fletcher E Kittredge (Jun 26)
- Re: Cable Modem [really responsible engineering] Greg A. Woods (Jun 26)
- Re: Cable Modem [really responsible engineering] Fletcher E Kittredge (Jun 26)
- Looking for x.org Kurt Kayser (Jun 26)
- Re: Looking for x.org Neil J. McRae (Jun 27)
- Re: Cable Modem [really responsible engineering] Miquel van Smoorenburg (Jun 26)
- Re: Cable Modem [really responsible engineering] Chris Adams (Jun 26)
- Re: Cable Modem [really responsible engineering] Wojtek Zlobicki (Jun 26)
- Message not available
- Re: Cable Modem [really responsible engineering] Wojtek Zlobicki (Jun 27)
- Message not available
- Re: Cable Modem [really responsible engineering] Wojtek Zlobicki (Jun 27)
- Looking for x.org Kurt Kayser (Jun 26)
- Message not available
- Re: Cable Modem [really responsible engineering] Wojtek Zlobicki (Jun 26)
- Re: Cable Modem [really responsible engineering] Charles Sprickman (Jun 26)
- Re: Cable Modem [really responsible engineering] Miquel van Smoorenburg (Jun 27)
- Re: Cable Modem [really responsible engineering] Fletcher E Kittredge (Jun 28)
- Re: Cable Modem [really responsible engineering] Greg A. Woods (Jun 28)
- Re: Cable Modem [really responsible engineering] Fletcher E Kittredge (Jun 28)
- Re: Cable Modem [really responsible engineering] Greg A. Woods (Jun 28)