Cable Modem [really more about PPPoE]

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

You know, I started down that path once.

Good luck trying to get Microsoft and Apple to support radius VSA for
configuring clients. Can you imagine what Microsoft would do?

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

Sorry about that missing footnote.

[1] Radius is auth mechanism independent. There are probably more
than a dozen currently supported by one implemenation or another.
However, for large, public access networks, the only one I know of in
use is username/password.

Username/password is weak authorization. If you don't agree, please
see "Secrets and Lies : Digital Security in a Networked World" by
Bruce Schneir, [John Wiley & Sons, August 2000 ; ISBN: 0471253111 ].
It is an accessable discussion of the issues by an expert.

Let me start out by saying I am not a proponent of client software
and personally avoid using it if possible. In some cases it is a
consideration though.

Consider the following.

You have a large (Regional/National) cable/wireless/DSL deployment and
resell the last mile to ISP customers.

There are two potential business models for this network. (according to
your marketing department)

One would be to partner with your ISP customers where
they resell your services targeting the residential market. DHCP will work
fine in this configuration where you provide the internet transit and
maintain
control over the customer.

The other would be to Wholesale the last mile connection to the ISP
customer. In this scenario you need to hand off the end user traffic to
your ISP customers.
DHCP alone is not a viable option in this model. How do you get the end
user traffic to the ISP and back in a pure IP environment? Policy routing,
GRE, MPLS, force your ISP customer to interconnect at every location,
etc.?

At this point ATM and PPPoE become considerations each with its own
advantages. If the service offering is business class ATM may be preferred
(required by your customer) for COS/QOS. From a configuration management
standpoint PPPoE has advantages especially in a residential environment as
you do not need to reconfigure the PVC when the end user changes
providors.

In a wireless environment this becomes even more of a consideration as
most of the current hardware is limited in ATM or L3 functionality...

Most network designs/business models are more complex than this but I did
not feel like typing that much:)

I do not intend to argue one technology over another, just to point out
that there are reasons PPPoE exists and is in use.....

A good network design also needs to consider the business model of the
company it supports.

Chris White wrote:

DHCP alone is not a viable option in this model. How do you get the end
user traffic to the ISP and back in a pure IP environment?

Very easily. The ISP has a NAS at the headend (or even in every
block). The cablemodem is a router that talks to the NAS, just as in
any other environment. The NAS performs DHCP, just as in any other
environment. The carrier provides commodity service, just as in any
other environment. :wink:

For access control, you need IPsec. But you need IPsec for security
and privacy anyway on a broadcast medium. This is really no different
than wireless.

(Hint, we discussed this stuff in the IP/cable working group many years
ago.... And I specified Mobile-IP to handle moving seamlessly between
cellular and broadband networks back in '92-93. Should stop rehashing
very old arguments.)

In a wireless environment this becomes even more of a consideration as
most of the current hardware is limited in ATM or L3 functionality...

I shudder to think of trying to deploy ATM over wireless.

I don't know why you would deploy at L3, it seems rather far away --
but if you perhaps mean IP, then I don't expect wireless that isn't
IP capable, going back to Tetherless Access Limited, and before that to
amateur radio. Nobody would use it otherwise!

William Allen Simpson
    Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

Aha! Now we come to the business problem that PPPoE solves for the
carrier. I gained a keen appreciation of the difficulty of scaling
per-user provisioning when I worked for a DSL CLEC.

That makes an enormous amount of sense. When the end user changes ISP's,
there is no change to the carrier network.

What doesn't make sense is that SBC made a business choice at the same
time that requires them to get involved. Since SBC is forcing the ISP to
bill for the line, SBC has all kinds of administrative changes to make.
Whatever scripts they have to auto-configure the authentication mechanism
could reasonably handle the PVC provisioning instead.

-Steve

Chris White wrote:
>
> DHCP alone is not a viable option in this model. How do you get the end
> user traffic to the ISP and back in a pure IP environment?

Very easily. The ISP has a NAS at the headend (or even in every
block). The cablemodem is a router that talks to the NAS, just as in
any other environment. The NAS performs DHCP, just as in any other
environment. The carrier provides commodity service, just as in any
other environment. :wink:

The cable modem may be a router. A large number of DSL modems are not.
Most (if not all) 802.11b wireless endpoints are not (these are very
common in large scale deployments at the moment - long term viability is
another issue)

For access control, you need IPsec. But you need IPsec for security
and privacy anyway on a broadcast medium. This is really no different
than wireless.

Agreed, but this is an additional client software on most end user systems
unless you have an IPsec capable router and it adds a substantial cost at
the termination point if you were to use IPsec tunnels to hand off the
customers to another provider.

(Hint, we discussed this stuff in the IP/cable working group many years
ago.... And I specified Mobile-IP to handle moving seamlessly between
cellular and broadband networks back in '92-93. Should stop rehashing
very old arguments.)

I looked into Mobile-IP for a wireless deployment...requires a client and
is not well supported at this time. Someday maybe...

> In a wireless environment this becomes even more of a consideration as
> most of the current hardware is limited in ATM or L3 functionality...
>
I shudder to think of trying to deploy ATM over wireless.

I don't know why you would deploy at L3, it seems rather far away --
but if you perhaps mean IP, then I don't expect wireless that isn't
IP capable, going back to Tetherless Access Limited, and before that to
amateur radio. Nobody would use it otherwise!

I was talking about the functionality of the client stations. Most are no
more than bridges at this time.