|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Cable Modem [really more about PPPoE]
At 05:17 PM 6/25/2001 -0400, Fletcher E Kittredge wrote: On Mon, 25 Jun 2001 11:16:29 -0500 Chris Parker wrote: > PPPoE. Auth via radius. Same management infrastructure as used for > dialup ( in terms of radius accounting from PPPoE aggregation boxes ). 1) Auth via radius is not an advantage for the customer; only for the engineer whom has a legacy radius infrastructure to support. A key engineering skill is to be able to evolve such infrastructures economically and reliably to more modern infrastructures. Therefore, this is not much of an advantage as you should know how to replace it :) But why replace it if you don't have to? Is it not more economical to reuse parts of your existing infrastructure than to chuck it all out the window? Removing radius-auth from PPPoE for a second, I would hazzard that with the use of the defined radius VSA format, the number of client configuration values is not limited in practical applications. You failed to include your [1] reference, so I'm not sure what you are refuting here. I would suggest that relying on username/password auth via CHAP is less susceptible to spoofing than a MAC address. I'm definitely open for other means of authenticating yourself on the network. > You have start/stop logs with timestamps. You know who had what IP and > when. 3) Inflicting a connection oriented access model on customers is unfair; the network should be always on. Only the legacy design of the PSTN requires a connection oriented model. Therefore, start/stop displease me. Checkpoint accounting updates are also possible, if you wish. 4) DHCP also logs leases which tell you who had what IP and when. You were the one that previously said: I don't like the IP->MAC->Customer mapping, it is forgeable, but it is the only one I know we have available. I was merely suggesting an alternative: IP->username->Customer. Username is not hardware dependant, either. > Also, most PPPoE aggregation boxes record the client MAC address in > the 'Calling-Station-Id' radius field, so that solves your MAC problem > as well. 5) That is a good, but I don't like the cost. I already have a working model. Hey, so do I. Mine uses radius. :) > Before anyone bemoans the dearth of PPPoE clients, check again. Nearly > every major consumer OS ( Windows,MacOS,Linux,*bsd ) has PPPoE support. > Or failing that, you can pick up a nice little netgear or linksys > pppoe router that does nat for ~$75. 6) I don't care about the dearth of PPPoE clients, if it exists, it will resolve itself. I do care about their bugginess, as this will be with us always. All code is buggy. Avoid adding more code (complexity) unless truely necessary. Certainly. However, at some point one must implement new code or nothing changes. 7) NAT breaks end-to-end. NAT is evil. NAT is a sign of weakness. NAT only exists because we have failed in providing a secure network with virtually infinite addresses. NAT is a sign of shame for every self-respecting Internet Engineer. Well, that was only proposed as an option for the <1% of users who didn't already have PPPoE capabilities. NAT is, IMHO, a tool, and like backhoes, can be used without breaking things. So, suffice to say, you've rejected radius as an option, and I've embraced it. Let us agree to disagree. We're now drifting off-topic from NANOG, follow-ups should probably go private. -Chris -- \\\|||/// \ Chris Parker: Manager, Development Engineering \ ~ ~ / \ [email protected] \ [email protected] | @ @ | \ www.starnetusa.net \ www.megapop.net oOo---(_)---oOo--\------------------------------------------------------ \ Without C we would have 'obol', 'basi', and 'pasal'
|