Re: Cable Modem [really responsible engineering]
This discussion has moved to NANOG ( nanog@merit.edu ). Please remember to trim your headers not to cross post to dhcp-server. In fact, given the quality of your comments, why don't you just respond to me privately and not waste people's time?
I think we are in violent agreement. I don't like the IP->MAC->Customer mapping, it is forgeable, but it is the only one I know we have available. I agree with you that it is not the only possible mapping. If you can point me to a better existing mechanism, I would be greatful.
Saying something is "forgeable" is assuming that it was supposed to be authentic in the first place. MAC addresses and IP addresses weren't designed for that.
I never said they were. However, given the design parameters, they provide useful information which should not be discarded.
If a database was kept of client MACs, and this information was required before access to service was made available, you then have a network of known devices and have made a long step towards towards assigning responsibility.
And every user would have to know the mac address of every piece of equipment and divulge this to the ISP before they could have service? And when they wanted to add a new computer, hook up a friend's laptop? Buy a new NIC card? Come on. If my ISP did that to me, they'd be gone faster than lemonaid on a hot day.
Exactly. You need to supply the MAC address to bring a computer on line. Why is the more onerous that supplying a username/password? Other ISPs restrict the number of systems you can connect, the uses of those systems (no servers, etc.), block certain ports, etc. That displeases me as it reduces the value of the network and breaks end-to-end.
are not tied to hardware type or specific device: IP address is much more useful for that, in my opinion, especially if additional information about physical connections (such as port and switch numbers) is available.
I tend to agree because: The mac addresses of the computers in my house may change quite a bit, but my external IP addresses will remain the same (and have to, since only those IPs are being routed to me).
Do you have any actual experience with designing or operating such a public access network? If so, please explain how to get the "port and switch number" for a user's PC on a cable network as I was unaware of this functionality.
Please remember we are talking about large IP over Ethernet *public* networks (cable, Etherloop DSL, wireless) which are used by a completely heterogeneous population. The operator must support the connection of arbitrary devices. Many of the customers have very little knowledge of their configuration or networking. The network operator must support arbitrary devices and clueless customers.
And such clueless users may have no idea what their MAC address is. They also might have equipment that doesn't list it's MAC address readily.
...and the moon might be made of green cheese. We haven't had a problem explaining to users how to get their MAC addresses.
3) ARIN has sent the strong message that they expect IP over E public network providers to use dynamic IP allocation in order to conserve IPv4 addresses.
And the intelligent public has sent an equally strong message that dynamic IPs are not acceptible. Most people I know with DSL or similar service make sure to use static IPs that are usable for server purposes. Wether static or dynamic IPs are used, the same _number_ of IPs is required, we aren't talking about dial-up here where most of the users will be offline most of the time.
I disagree with all of the above. Since it nothing more than your opinion and anecdotal evidence, mere contradiction suffices.
accurately tracked, or that customers be accurately charged for their bandwidth usage. In gathering these statistics, a MAC
I am a bit confused here. Most providers don't charge for bandwidth usage, they charge for bandwidth availability. My ISP doesn't need to track the traffic from my MAC address to charge me $Xx.XX for xx mbps.
One needs this information in aggregate in order to model to accurately set prices. Otherwise, your company will go out of business when you charge less for the service than the service cost to provision, or you charge too much to compete with more accurate models. Say, what happened to all those DSL providers that were here just a minute ago? [ we have been in business for over seven years, and are profitable...]
Finally, I would not want to declare under oath that a MAC address absolutely and uniquely identified a client host: it's just too easy to spoof.
Again, why even say "spoof", that makes it sound like it's _supposed_ to be "authentic" or something. I don't thin I am "spoofing" by changing my MAC address. It wasn't supposed to identify me, and nobody ever said it was. In fact I have changed the MAC addresses of all of my sparcstations (which are easily programmable in software!) to be sequential.
That was pretty stupid, wasn't it? Ethernet MACs must be unique to be to work. Have you ever thought about what would happen if more than one person on the same network as you chose the same Ethernet MACs? Further, if you reprogram your MACs, and then you would not get access until you registered them. So your traffic still could be tracked.
Total and absolute agreement. There is no question that it is easy for a technical sophisticated customer to spoof a MAC address. This fact should always be kept in mind when analysing any information. Your forgot: 3.) An existing MAC address that isn't currently in use is "spoofed". One only has to watch the network for a while and get a list of MACs visible on their net. (this is especially easy typical on cablemodem networks). Wait until one disappears for a while (computer turned off?). Assume that MAC address. You could even discover a pattern that a certain MAC address is only used from X:XX to X:XX on typical days. (some users only turn on their PCs during certain times).
yawn. I didn't forget; you can't read. See the first part of my statement. Here it is again: "Total and absolute agreement. There is no question that it is easy for a technical sophisticated customer to spoof a MAC address. This fact should always be kept in mind when analysing any information."
-- noah silva
Noah, go away and don't come back until you have some real experience and something interesting to say. At least correspond with me privately. . o O (Now, where did I put that kill file?)
Hi, anybody knows where www.x.org (X/Open) or AS1849 is right now?? I can't seem to find it on any Looking-Glass or Route-Server.. It looks like it simply dropped of the map... :-( Kurt -- Kurt Kayser Consulting * +49 175 2978081 (mobile) * +49 9129 289315 (ISDN) Heinrich-Müller-Str. 1c * 90530 Röthenbach b.St.W. * Germany http://www.n-ix.de * eMail: kurt_kayser@gmx.de
I think AS1849 was migrated into AS702 a few months ago. Neil.
Hi,
anybody knows where www.x.org (X/Open) or AS1849 is right now??
I can't seem to find it on any Looking-Glass or Route-Server.. It looks like it simply dropped of the map... :-(
Kurt -- Kurt Kayser Consulting * +49 175 2978081 (mobile) * +49 9129 289315 (ISDN) Heinrich-M_ller-Str. 1c * 90530 R_thenbach b.St.W. * Germany http://www.n-ix.de * eMail: kurt_kayser@gmx.de
In article <200106261522.f5QFMGt13957@smtp.gwi.net>, Fletcher E Kittredge <fkittred@gwi.net> wrote:
I tend to agree because: The mac addresses of the computers in my house may change quite a bit, but my external IP addresses will remain the same (and have to, since only those IPs are being routed to me).
Do you have any actual experience with designing or operating such a public access network? If so, please explain how to get the "port and switch number" for a user's PC on a cable network as I was unaware of this functionality.
I have a bit of experience in designing and operating such a network. We are an ADSL provider, and we use RC1483 bridging. The modem at the customer has an ether over ATM over ADSL connection to the DSLAM and then that connection is forwarded to a central BRAS - a Redback in our case. 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 ;)] The ATM-based COM21 modems operate in much the same way (ethernet over ATM over cable using a BRAS to terminate the connection) so if you're designing a new network it's very well possible to get the "port and switch number". I'm not sure about the DOCSIS system, if the modems have a unique identifier that cannot be changed by the enduser and the headend somehow puts this info in a DHCP option when it acts as a DHCP relay you can probably do something similar. This is pure speculation though.
We haven't had a problem explaining to users how to get their MAC addresses.
Well, we have, and what's more if you're doing your accounting purely based on the mac addresses in the DHCP logs how do you ever know for sure who was using a certain IP address on a certain time? That's important, did customer A send out spam or was it his neighbor spoofing A's MAC address when A was asleep ?
3) ARIN has sent the strong message that they expect IP over E public network providers to use dynamic IP allocation in order to conserve IPv4 addresses.
And the intelligent public has sent an equally strong message that dynamic IPs are not acceptible. Most people I know with DSL or similar service make sure to use static IPs that are usable for server purposes. Wether static or dynamic IPs are used, the same _number_ of IPs is required, we aren't talking about dial-up here where most of the users will be offline most of the time.
I disagree with all of the above. Since it nothing more than your opinion and anecdotal evidence, mere contradiction suffices.
It's true though. With a cable or DSL network you must assume the worst, that is all users online at the same time. It will happen. And then your dynamic pool needs to be just as big as the number of subscribers. Mike.
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. 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. 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.
----- 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.
On Tue, 26 Jun 2001, Chris Adams wrote:
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.
Assuming the BRAS is somewhat similar to other boxes that perform these functions for dialup users you should be able to take care of this very easily with a decent radius server (ie: Radiator). Assume the key here is the pvc the user comes in on. BRAS hits the radius server when it gets a DHCP request, radius looks up said pvc and hands a reply back with the IP and a filter for that user that only lets the assigned IP back out. How would the user be able to use another address? While I have not toyed with a Redback or other similar purpose-built hardware like this, I have to assume they at least beat our USR gear, which does all of the above. It even has a DHCP server for dialup (don't ask). There's a reason people are building these specialized boxes... Charles
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.
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.
In article <20010626202013.A23709@HiWAAY.net>, Chris Adams <cmadams@hiwaay.net> wrote:
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?
The BRAS equipment we use, redback SMSes, can filter out IP addresses with invalid source addresses. Like cisco's ip verify unicast reverse-path
Also, how do you prevent the user from trying to forge someone else's IP address or even MAC address in outgoing packets?
Like I said, the SMSes we use filter IP, and it doesn't use real bridging even within the same subnet, it does proxy arp. So if a customer arps for another IP in the same subnet, the SMS will answer the ARP request itself, it will not be bridged. Unfortunately I have not been able to play with Cisco's 6400 series yet to see if they offer the same functionality - not that we're not happy with our current equipment but I'd like to know a bit more about how other equipment behaves. However from the docs I get the impression that Cisco calls this IRB.
Without protecting against forged packets, I don't see how to provide accountability when someone attacks.
Very true. The BRAS must be able to protect from IP spoofing and it must do proxy arp instead of real bridging. Mike.
participants (7)
-
Charles Sprickman
-
Chris Adams
-
Fletcher E Kittredge
-
Kurt Kayser
-
miquels@cistron-office.nl
-
neil@DOMINO.ORG
-
Wojtek Zlobicki