Cable Modem [really more about PPPoE]

Tue Jun 26 04:21:46 UTC 2001

Mr PPP (that's me) says, "PPPoE really IS inferior!"

Heck, there are relatively few things that the IETF has refused to 
standardize, and PPPoE is one of them.

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 :)
> 
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.

There is nothing that stops RADIUS from working with 802.1x, for 
example.  Or for working with Kerberos to synthesize session keys 
for IPsec, as another example.

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.

> 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.....

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.

>    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?

> 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.

> 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.

> > 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.

> > 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.
> 
> 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.

As opposed to PPPoE, which solves nothing.
-- 
William Allen Simpson
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32