Re: Cable Modem [really more about PPPoE]

[Fletcher E Kittredge <fkittred () gwi net>]

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