On Tue, 26 Jun 2001 00:21:46 -0400 William Allen Simpson wrote:
RADIUS (speaking as one of the original authors) has nothing to do with PPP. It was just a simple mechanism to communicate to a NAS for authentication purposes.
Correct. Let me restate that again. Radius was designed for an different purpose than for authenticating in an IPoE environment. There is no NAS in an well designed IPoE environment. I like radius; radius was a friend of mine. Radius has made me a wealthy man. Thank you. However, radius is showing its age and it is time to move on. By accident, DHCP is a much better protocol for public IP-over-E networks. This does not mean that DHCP doesn't need help. For example, DHCP only does a fraction of what Radius does; DHCP only allocates IPs and "suggests" client parameters. No accounting... No auth... Personally, I think that multiple protocols, one for each task, is a better approach.
There is nothing that stops RADIUS from working with 802.1x, for example.
Given enough monkeys, enough keyboards and enough time, they could rewrite emacs. However, I wouldn't give them the job.
Or for working with Kerberos to synthesize session keys for IPsec, as another example.
I am having problems visualizing how Kerberos' ticket model would work in a public access network with potentially hundreds of thousands of users wandering on and off in millions of short lived sessions per day (check for mail every five minutes...)
RADIUS "accounting" is the problem, not the solution.
And, because later "design by committee" added so many bags on the side to RADIUS, there is another long term replacement effort. It is not DHCP alone. It is Diameter.
Operators should take a long hard look at Diameter, before the standardization process gets so far along that it is too hard to fix. As always, the engineering needs operational experience.
Thank you very much for the pointer! I will check in on Diameter.
2) To balance this one special case advantage, radius auth has a number of flaws: i) it is an older protocol designed for a different model of networking and thus is missing many features of DHCP. In particular, clean mechanisms for setting an arbitrary number of client configuration values.
Since DHCP is older than RADIUS, perhaps it might have occurred to you that we discussed this during the design process.....
Sorry, I was thinking of the newer DHCP standards, some of which are freshly minted. DHCP does go back to bootp, and in some ways has not changed so much from bootp.
I'm sure I can point to meeting minutes circa 1994-95 where it was decided that since DHCP already had configuration values, then DHCP should be used for configuration, and we should not reinvent the wheel.
DHCP works fine over PPP, over Ethernet, over Frame Relay, etc.
This configuration does work well; we use DHCP and Radius to support one-way cable modems connecting to Livingston Portmasters... If you did a historical search, you would find a different discussion on the "radius" mailing list a while back where I champion the use of DHCP with Radius.
ii) public networks, it uses username/password authentication. This is a flawed mechanism for auth. It is insecure[1] and generates a fair amount of support traffic.
Since CHAP (speaking as an author) is older than RADIUS, why would anyone think that RADIUS was limited to username/password?
I don't know why anyone would think that. I didn't mean to imply that username/password is the only auth mechanism. I simply did not want to point this out in main body of my message because it would have distracted from the flow. It was mean to be in footnote [1]. Then I forgot to write footnote [1] :( However, since the topic is large, public access networks, I wonder how practical it is to use SKey, or smart cards, or Kerberos, or whatever instead of username/password.
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.
I doubt that any Internet Engineer would disagree.
Well, the reason we are having this discussion is that there are plenty of non-Internet engineers designing god-awful cable and wireless IPoE networks. They hang out over on the dhcp-server list. You should visit some time. It would make your toes curl.
4) DHCP also logs leases which tell you who had what IP and when.
Agreed, as long as you are using secure DHCP and have an admission control layer.
I should stress that I don't trust the MAC->IP map very far at all. But it is better than nothing... This topic originally started because someone was planning to throw away the IP->MAC->customer information.
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.
MAC as a security endpoint? Dangerous. Evil. Shameful.
I can't help but agree with you. My problem is, in an IPoE environment, which is naturally non-connection oriented, how do you supply a security endpoint without inflicting unnecessary complexity?
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.
As a "self-respecting Internet Engineer", I will agree with everything except that latter. NAT is an engineered solution to an actual problem.
I know that when Paul Francis (one of the most brilliant Internet Engineers I've ever met) spoke at UMich last year, he admitted that he is widely vilified for NAT; but notes it solved an actual need.
Can I paraphrase your argument? "We know that NAT is architecturally bad, but is good because we haven't solved the problem any other way yet." What I was trying to say was: "We know that NAT is architecturally bad, the fact that it is our only current solution for a vital problem only means we have more work to do. We should not rest until NAT is not in use and end-to-end is restored." All of my connections to the Internet are via a NAT, either at home or at work. I build, configure and use them. I still know they are wrong. For that matter, I use Akamai and even hold stock in the company. I still know that Akamai is immoral. The Internet has gone down a deadly path in breaking end-to-end. We have to wean ourselves from this deadly addiction. If one starts breaking end-to-end in these ways, it makes one no better than a stinking ATM or MPLS user. Before I remove the splinter from the eye of other, I should remove the log from my own eye. Thank you for reminding me. Mea Culpa. regards, fletcher