Re: Cable Modem [really more about PPPoE]
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 :) 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
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
At 05:17 PM 6/25/2001 -0400, 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 :)
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. :)
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 -- \\\|||/// \ Chris Parker: Manager, Development Engineering \ ~ ~ / \ cparker@starnetusa.net \ cparker@megapop.net | @ @ | \ www.starnetusa.net \ www.megapop.net oOo---(_)---oOo--\------------------------------------------------------ \ Without C we would have 'obol', 'basi', and 'pasal'
On Mon, 25 Jun 2001 17:09:24 -0500 Chris Parker wrote:
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. ;-) 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
On Tue, 26 Jun 2001, William Allen Simpson wrote:
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. ;-)
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.
William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
On Tue, 26 Jun 2001 10:28:16 -0400 (EDT) Chris White wrote:
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.?
Hello Chris; You provide frustrating few details and a statement "DHCP alone is not a viable option in this model." Could you restate more concretely what is your design problem which can only be solved by ATM/MPLS/PPPoE? I hesitate to answer for fear that there is some constraint I don't know about.
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.
What follows is not directed at you personally, but you happened to say the wrong thing at the wrong time :) Apologies in advance. <rant> I don't believe any of this "ATM is the way to do" COS/QOS crap. I have had it in my face for 10 years (my graduate work in the early 90's was performance of IP over ATM. This just in: it sucks.) IPoATM has never worked; prove to me it will work, then we can talk. Same goes for MPLS, with knobs on. Fat pipes; big buffers; simple protocols; get out of the way. </rant> We avoided doing DSL (much) until Etherloop and Ethernet was available because ATM sucks so much. I don't have much sympathy for people who decided otherwise. They knew, or should have known, the problems with the ATM pvc approach. If IPoATM worked; Ethernet would have been dead long ago.
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 am sincerely sorry you are stuck using broken hardware. As a person who has thrived by deliberately passing up "the latest thing" until the proper hardware was available to implement good designs, I urge you to question your assumptions about whether using broken hardware is a good idea.
I do not intend to argue one technology over another, just to point out that there are reasons PPPoE exists and is in use.....
Reasons don't equate to good reasons :)
A good network design also needs to consider the business model of the company it supports.
I couldn't agree more! But the converse of that is true; the business model of a network company should reflect good network design. I believe the only workable model for networking companies is to have network engineers involved at the highest levels. That is, they have to have veto power over decisions. I don't understand how people think they can thrive in an industry in which they do not have at the senior level deep knowledge of the product. My undergraduate degree was in English; my graduate degrees are in CS. I worked for nine years at BBN before starting this company. Our COO was an a EE and a practicing network/compuer engineer for years before he got his law degree. Our CFO was a CPA, but has been in the commercial Internet business since its inception (ANS/AOL/UUnet). Technical experience works for us, while I note success does not seem to be widespread in the industry. regards, fletcher
On Tue, 26 Jun 2001, Fletcher E Kittredge wrote:
On Tue, 26 Jun 2001 10:28:16 -0400 (EDT) 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? Policy routing, GRE, MPLS, force your ISP customer to interconnect at every location, etc.?
Hello Chris;
You provide frustrating few details and a statement "DHCP alone is not a viable option in this model." Could you restate more concretely what is your design problem which can only be solved by ATM/MPLS/PPPoE? I hesitate to answer for fear that there is some constraint I don't know about.
The constraint is that outbound packets need to go to the right ISP. That is, the packets need to go through the carrier network according to the business relationship, not according to the destination IP address. Some method of identifying the ISP associated with each outbound packet is necessary. Policy routing, tunnels and PVC's are a few methods. VLAN tagging works, too. -Steve
On Tue, 26 Jun 2001 09:21:11 -0700 (PDT) Steve Schaefer wrote:
The constraint is that outbound packets need to go to the right ISP. That is, the packets need to go through the carrier network according to the business relationship, not according to the destination IP address.
Some method of identifying the ISP associated with each outbound packet is necessary. Policy routing, tunnels and PVC's are a few methods. VLAN tagging works, too.
What details of which technology? Cable? Etherloop? Wireless? What is this DOCSIS thing I keep hearing about? regards, fletcher
On Tue, 26 Jun 2001, Steve Schaefer wrote:
On Tue, 26 Jun 2001, Fletcher E Kittredge wrote:
You provide frustrating few details and a statement "DHCP alone is not a viable option in this model." Could you restate more concretely what is your design problem which can only be solved by ATM/MPLS/PPPoE? I hesitate to answer for fear that there is some constraint I don't know about.
The constraint is that outbound packets need to go to the right ISP. That is, the packets need to go through the carrier network according to the business relationship, not according to the destination IP address.
Some method of identifying the ISP associated with each outbound packet is necessary. Policy routing, tunnels and PVC's are a few methods.
Ditto
VLAN tagging works, too.
Ouch:)
-Steve
On Tue, 26 Jun 2001, Steve Schaefer wrote:
On Tue, 26 Jun 2001, Fletcher E Kittredge wrote:
You provide frustrating few details and a statement "DHCP alone is not a viable option in this model." Could you restate more concretely what is your design problem which can only be solved by ATM/MPLS/PPPoE? I hesitate to answer for fear that there is some constraint I don't know about.
The constraint is that outbound packets need to go to the right ISP. That is, the packets need to go through the carrier network according to the business relationship, not according to the destination IP address.
Some method of identifying the ISP associated with each outbound packet is necessary. Policy routing, tunnels and PVC's are a few methods.
Still vague, and you have the bad habit of specifying implementation mechanisms when asked for requirements. Users who specify implementation methods to engineers end up with bad designs :) With sincere respect, I point out you are asking a question to which you do not know the optimal answer and then supplying your best answer so far as if it is the only answer. You might learn more if you sincerely asked the question and listened... Quick review: ------------- Using an object for a purpose for which it was not designed is almost always a bad idea. Yes, improvisation is a life-saver. But if you get back to home base safely, pop the cowling, have the mechanics remove the duct tape and repair the damage the right way. Same for protocols. Using them for a purpose for which they were not designed almost always results in an inferior design. IP stands for Internet protocol. It was designed to tie disparate physical networks together into one seamless virtual network. The IP suite does not specify any qualities of the physical network. It does specify the end-to-end nature of the virtual Internetwork. It does things like end-to-end security (IPsec.) The Ethernet protocol was designed to adjudicate and route packets internal to one homogeneous, physical network. It handles media access, security, reliablity and routing in that one physical network. It appears to me that your problem here is at the physical network level. You only have one physical network. Your Ethernet hardware should handle the routing to the proper ISP. If it were me, I would also expect my Ethernet hardware to be able to filter, load-balance and meter based on MAC address so that I could gaurantee no ISP could see another's traffic and accurately charge the ISP for bandwidth. I think I hear you saying you must use hardware that does not use Ethernet. In which case, you have steered the conversation away from the original IPoE public network arena. You also have my condolences. I strongly recommend you spend some quality time with the DOCSIS spec... Personally, I think DSL and wireless modems would benefit from using DOCSIS. I have not thought hard about this issue and am interested in other opinions... regards, fletcher
The Ethernet protocol was designed to adjudicate and route packets internal to one homogeneous, physical network. It handles media access, security, reliablity and routing in that one physical network.
What does Ethernet have to do with routing ?
It appears to me that your problem here is at the physical network level. You only have one physical network. Your Ethernet hardware should handle the routing to the proper ISP. If it were me, I would also expect my Ethernet hardware to be able to filter, load-balance and meter based on MAC address so that I could gaurantee no ISP could see another's traffic and accurately charge the ISP for bandwidth.
The problem you dont really have one physical network. We are trying to extend Ethernet into a logical network. The physical link to the customer is the same, but the customer is terminated logically. The reason that I like PPPoATM is that the end device requires littel intelligence , it knows one PVC, and all changes (linking them to the ISP of choice, propogate easily downstream).RFC 1483 (Ethernet over ATM, used in DSL and plausibly in cable ) is a great idea for business but not suitable for home users. Hardware that you speak of becomes just too expensive.
I think I hear you saying you must use hardware that does not use Ethernet. In which case, you have steered the conversation away from the original IPoE public network arena. You also have my condolences.
I strongly recommend you spend some quality time with the DOCSIS spec... Personally, I think DSL and wireless modems would benefit from using DOCSIS. I have not thought hard about this issue and am interested in other opinions...
It appears as if someone has thought of this before Someone is apparently doing this already (I don't know the name of the company), taking regular cable modems and using wireless for intramodem communication (why re-invent the wheel) instead of copper.
regards, fletcher
On Tue, 26 Jun 2001 14:27:29 -0400 "Wojtek Zlobicki" wrote:
The Ethernet protocol was designed to adjudicate and route packets internal to one homogeneous, physical network. It handles media access, security, reliablity and routing in that one physical network.
What does Ethernet have to do with routing ?
Routing in its original sense. You stick an Ethernet frame in here, it traverses a number wires connected by boxes which make decisions as to which wire it should go out on. It then pops out on the other edge of the network. Magic! A network of Ethernet switches looks a heck of a lot like routers. They are certainly smarter than the IP routers of circa 1983.
The problem you dont really have one physical network. We are trying to extend Ethernet into a logical network.
Who is "we" in this statement?
The reason that I like PPPoATM is that the end device requires littel intelligence , it knows one PVC, and all changes (linking them to the ISP of choice, propogate easily downstream)
Little intelligence to implement ATM? Never heard that claim before. Contrast the cost of an Ethernet chip with an ATM chipset.
.RFC 1483 (Ethernet over ATM, used in DSL and plausibly in cable ) is a great idea for business but not suitable for home users. Hardware that you speak of becomes just too expensive.
Define "great idea". Compare and contrast with all the failed DSL providers which used ATM. Use one DSL/ATM provider who is making money as an example. No excuses please. How do you reconcile the cost of the hardware being too expensive with the statement above that ATM requires little intelligence?
It appears as if someone has thought of this before Someone is apparently doing this already (I don't know the name of the company), taking regular cable modems and using wireless for intramodem communication (why re-invent the wheel) instead of copper.
That would be a good idea. regards, fletcher
----- Original Message ----- From: "Fletcher E Kittredge" <fkittred@gwi.net> To: "Wojtek Zlobicki" <wojtekz@idirect.com> Cc: <nanog@merit.edu> Sent: Tuesday, June 26, 2001 2:52 PM Subject: Re: Cable Modem [really good network design]
On Tue, 26 Jun 2001 14:27:29 -0400 "Wojtek Zlobicki" wrote:
The Ethernet protocol was designed to adjudicate and route packets internal to one homogeneous, physical network. It handles media access, security, reliablity and routing in that one physical network.
What does Ethernet have to do with routing ?
Routing in its original sense. You stick an Ethernet frame in here, it traverses a number wires connected by boxes which make decisions as to which wire it should go out on. It then pops out on the other edge of the network. Magic!
A network of Ethernet switches looks a heck of a lot like routers. They are certainly smarter than the IP routers of circa 1983.
The problem you dont really have one physical network. We are trying to extend Ethernet into a logical network.
Who is "we" in this statement?
Those using PPPoATM/E
The reason that I like PPPoATM is that the end device requires littel intelligence , it knows one PVC, and all changes (linking them to the ISP of choice, propogate easily downstream)
Little intelligence to implement ATM? Never heard that claim before.
Much easier to place a $300 CPE (Cisco 678 which speaks ATM). Than a 1605 (chosen for the fact that its about the cheapest Dual Ethernet Router from Cisco). How do you propose that we bring Ethernet to the customer ? The now defunct CLEC that I worked for, used 678 and 1483 so that the 1605 did the routing (as far as our netowork was concerened, we were bridging/switching these customers, the fact that they ran IP was their business).
Contrast the cost of an Ethernet chip with an ATM chipset.
ATM to the desktop never took off, whats wrong with Ethernet over ATM ? With devices such as IADS, it allows for easy differentiation of traffic. Now you can cary voice and data over the same physical link without worry. ATM is expensive in the core but inexpensive at the customer prem ($300 for a ATM DSL modem is relativel cheap, especially since it is a router , if you want it to be).
.RFC 1483 (Ethernet over ATM, used in DSL and plausibly in cable ) is a great idea for business but not suitable for home users. Hardware that you speak of becomes just too expensive.
Define "great idea". Compare and contrast with all the failed DSL providers which used ATM. Use one DSL/ATM provider who is making money as an example. No excuses please.
Market GLUT and not technology failed here. I was able to completely reprovision a customer in about two minutes in a PPPoATM network we ran. PPPoATM allows for a easily managable resale strategy, if your sales staff and wholesalers can't sell the service, thats not the fault of the technology.
How do you reconcile the cost of the hardware being too expensive with the statement above that ATM requires little intelligence?
It appears as if someone has thought of this before Someone is
doing this already (I don't know the name of the company), taking regular cable modems and using wireless for intramodem communication (why re-invent
apparently the
wheel) instead of copper.
That would be a good idea.
regards, fletcher
On Tue, Jun 26, 2001 at 03:01:41PM -0400, Wojtek Zlobicki wrote:
ATM to the desktop never took off, whats wrong with Ethernet over ATM ? With devices such as IADS, it allows for easy differentiation of traffic. Now you can cary voice and data over the same physical link without worry. [..]
Ever tried it without that? I have done quite a bit of less than scientific testing of VoIP over a QoS-less infrastructures. Small VoIP packets seem to have little trouble squeezing thru and it works actually pretty well. That's without ATM QoS crap on a broadband connection. -- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only.""
----- Original Message ----- From: "Christian Kuhtz" <ck@arch.bellsouth.net> To: "Wojtek Zlobicki" <wojtekz@idirect.com> Cc: <nanog@merit.edu> Sent: Tuesday, June 26, 2001 3:24 PM Subject: Re: Cable Modem [really good network design]
On Tue, Jun 26, 2001 at 03:01:41PM -0400, Wojtek Zlobicki wrote:
ATM to the desktop never took off, whats wrong with Ethernet over ATM ? With devices such as IADS, it allows for easy differentiation of traffic. Now you can cary voice and data over the same physical link without worry. [..]
Ever tried it without that? I have done quite a bit of less than scientific testing of VoIP over a QoS-less infrastructures. Small VoIP packets seem to have little trouble squeezing thru and it works actually pretty well. That's without ATM QoS crap on a broadband connection.
I have to concede here. We were able to run the VOIP traffic using UBR, out network not being saturated, this may have helped, on a busy network, a lot of problems could have arrisen. What is nice, is that QOS is easy to enable in ATM. There are many reasons that ATM has not taken off, from a CLEC perspective, I believe it to be the superior technology. I would much rather have a 10 Mbps Ethernet feed from a company like Cogent but those links do not compare in pricing with DSL.
-- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA,
U.S.
"I speak for myself only.""
[ On Tuesday, June 26, 2001 at 13:05:40 (-0400), Fletcher E Kittredge wrote: ]
Subject: Re: Cable Modem [really good network design]
I strongly recommend you spend some quality time with the DOCSIS spec... Personally, I think DSL and wireless modems would benefit from using DOCSIS. I have not thought hard about this issue and am interested in other opinions...
You do learn fast! ;-) However you'd better watch out. DOCSIS-1.0 is an implementer's worst nightmare. At best it provides a low-level physical layer spec. and the rest of it is pretty much useless in prodcution. 2.0 solves some of the problems, but introduces more. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <woods@robohack.ca> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
On Tue, 26 Jun 2001 14:37:34 -0400 (EDT) Greg A. Woods wrote:
I strongly recommend you spend some quality time with the DOCSIS spec... Personally, I think DSL and wireless modems would benefit from using DOCSIS. I have not thought hard about this issue and am interested in other opinions...
You do learn fast! ;-)
I haven't yet learned not to make weak jokes on mailing lists...
However you'd better watch out. DOCSIS-1.0 is an implementer's worst nightmare. At best it provides a low-level physical layer spec. and the rest of it is pretty much useless in prodcution. 2.0 solves some of the problems, but introduces more.
My experience has been that DOCIS-1.0 is unusable, 1.1 works well. I have no experience with 2.0. But then, I don't get out much... [sorry! weak joke!] regards, fletcher
On Tue, 26 Jun 2001, Chris White wrote:
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.
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
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
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
Fletcher E Kittredge wrote:
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.
There is no such thing as a "well designed IPoE environment", that's a contradiction in terms. But there is ALWAYS a Network Access Server! Unless, you are postulating something without network access, in which case why are you pontificating on NANOG? RADIUS was designed for authentication. (It's in the name.) Cable needs authentication, too, as all its users are "Remote".
... 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.
We are in agreement on the latter. Which is why there are separate protocols, instead of 1. However, you seem to have some misconceptions. DHCP is a "Host" protocol. RADIUS is a "Server" protocol. (It's in the names.) Hosts never talk RADIUS. The host to NAS authentication protocols vary. For serial point-to- point links, PPP is the natural mechanism. For multipoint broadcast media, we developed IPsec tunnels. There are other efforts, such as 802.1x. It could fill the niche, but has complicated problems, and has not seen much deployment. And unlike IPsec, it is not well integrated with privacy.
... 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...)
Works here.... OK, only tens of thousands, but if you are postulating hundreds of thousands on a single cable, you will be rather seriously oversubscribed. (I have seen Kerberos used across realms throughout North America, with potentially hundreds of thousands of simultaneous users. I have seen Kerberos used as a backend for RADIUS users. The pioneering code was done at Merit, which should not surprise anyone :-) -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
participants (9)
-
Chris Parker -
Chris White -
Christian Kuhtz -
Fletcher E Kittredge -
Jim Shankland -
Steve Schaefer -
William Allen Simpson -
Wojtek Zlobicki -
woods＠weird.com