Cable Modem [really more about PPPoE]

Mailman List Mirror (Read Only)
1

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 :slight_smile:

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

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.

4) DHCP also logs leases which tell you who had what IP and when.

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.

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.

   Remember what Cato said: "NAT must be destroyed". If I only knew
how... a plan, I need a plan...

regards,
fletcher

2

You write:

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.

NAT is good. I don't necessarily *want* end-to-end. I don't want to
give the world IP-level access to the thermostat in my refrigerator,
nor do I want to burden my refrigerator with encryption/authentication
software. Within my house, I'm happy to be able to read and change
the refrigerator's thermostat with an unauthenticated UDP datagram.
This is not an unusual situation. Does GE (say) need or want every
desktop PC and laser printer in the corporation to be globally
addressable? (Yes, I know they have 3.0.0.0/24; how many of those
addresses are pingable -- or will respond in any way to a packet
from outside GE?)

The usual response to this argument is to point out (correctly) that
NAT is neither necessary nor sufficient for such an arrangement.
True, but it's a natural way of expressing it. Think of NAT as the
address space analogue of DNS domains: refrigerator.shankland.org is
not the same as refrigerator.gwi.net. My world (a fairly
security-conscious one) is naturally organized into multiple address
spaces, with well-specified and well-controlled access paths between them.
I could implement this world on a global, flat address space; but why
would I want to? The fact that using NAT also leads to massive
conservation of the dwindling IPv4 address space is a nice bonus :-).

Jim Shankland

3

> 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 :slight_smile:

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?

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.

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.

   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.

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

> 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

4

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:

> 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 :slight_smile:

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.