Security control in DSL access network
Hi, Is there any books or papers on carrier level DSL access network and LAN access network? Specifically, it should analysis the futures of DSL network and security problems in DSL networks. Joe __________________________________ Meet your soulmate! Yahoo! Asia presents Meetic - where millions of singles gather http://asia.yahoo.com/meetic
On Sun, 26 Mar 2006, Joe Shen wrote:
Is there any books or papers on carrier level DSL access network and LAN access network? Specifically, it should analysis the futures of DSL network and security problems in DSL networks.
You probably want to start with the DSL Forum <http://www.dslforum.org/> After you get through their technical reports you should be very confused. A problem you will discover is often the DSL folks don't think they have any security problems. That all the security issues are with IP and the ISP.
I could add that many of the implementations are done using "professional services" of whoever the manufacturer of the DSLAM is and it is a very simple and weak configuration. They make sure it works and thats it. No attention is given to security or performance in any form. Now, I should also mention that the reason for this is that the providers usually only pay for this basic configuration and think or assume they can do the rest. The problem is that a DSLAM configuration can become so huge once the service start rolling that it is hard for any one to go back a fix the configurations because of the impact it may have to the clients. It is not impossible to fix, it will just have an impact to all the clients arriving to the same DSLAM and this can be counted in tens of thousands of clients. So the solution is to do it right from the beginning. -W Sean Donelan wrote:
On Sun, 26 Mar 2006, Joe Shen wrote:
Is there any books or papers on carrier level DSL access network and LAN access network? Specifically, it should analysis the futures of DSL network and security problems in DSL networks.
You probably want to start with the DSL Forum <http://www.dslforum.org/> After you get through their technical reports you should be very confused.
A problem you will discover is often the DSL folks don't think they have any security problems. That all the security issues are with IP and the ISP.
-- William Caban-Babilonia Senior Network & System Consultant Mobil: 787 378-7602
Maybe you're just baiting trolls, and granted, I haven't had my coffee yet. But let's try to be perfectly straight up here. At the very least, you're making a big assumption here, and that is that there are no EMS in charge of managing configurations and no provisioning system to trigger and not triggering EMS configuration management. In effect, service provisioning doesn't exist in what you describe. While OSS in carrier settings often -- put politely -- leave a lot to be desired, that is -- politely put -- a bit absurd. That would seem to be a very flawed at scale when you're talking 10's of thousands of DSLAMs, not to mention that it is really not matching reality in a carrier setting (rather than small time provider or other type of hack). There may have been periods in the past where that was true, but it is certainly not state of the art during any period of the recent past. This type of provisioning actually has been around as flow through provisioning for a while, and the flow specifically touches the port a customer would be provisioned on. The day this functionality arrived seems to generally have coincided within a relatively short period around offering variable DSL sync speeds, and it would simply be a business necessity for offering such service variants. Quite frankly, in such a world, anything more than a field crew making the device available to NMS is total overkill and a waste of time, multiplied by 10K's of DSLAMs, for a few actually provisioned customers. Btw, if you don't mind, please point out to me a large scale deployment that actually has 10's of thousands of live customers on a single DSLAM or which DSLAM you propose this is even physically possible, as well as anticipated engineered bit rates for such a deployment. Best regards, Christian On Mar 27, 2006, at 8:21 AM, William Caban wrote:
I could add that many of the implementations are done using "professional services" of whoever the manufacturer of the DSLAM is and it is a very simple and weak configuration. They make sure it works and thats it. No attention is given to security or performance in any form. Now, I should also mention that the reason for this is that the providers usually only pay for this basic configuration and think or assume they can do the rest. The problem is that a DSLAM configuration can become so huge once the service start rolling that it is hard for any one to go back a fix the configurations because of the impact it may have to the clients. It is not impossible to fix, it will just have an impact to all the clients arriving to the same DSLAM and this can be counted in tens of thousands of clients. So the solution is to do it right from the beginning.
-W
Sean Donelan wrote:
On Sun, 26 Mar 2006, Joe Shen wrote:
Is there any books or papers on carrier level DSL access network and LAN access network? Specifically, it should analysis the futures of DSL network and security problems in DSL networks.
You probably want to start with the DSL Forum <http:// www.dslforum.org/> After you get through their technical reports you should be very confused.
A problem you will discover is often the DSL folks don't think they have any security problems. That all the security issues are with IP and the ISP.
-- William Caban-Babilonia Senior Network & System Consultant Mobil: 787 378-7602
Christian Kuhtz wrote: > At the very least, you're making a big assumption here, and that is > that there are no EMS in charge of managing configurations and no > provisioning system to trigger and not triggering EMS configuration > management. In effect, service provisioning doesn't exist in what > you describe. Being able to provision over point-and-clicks does not get away with the rest of the configuration. I know you can do (depending on the EMS) a certain types of security configurations. Personally, I haven't seen an EMS capable of do a very good hardening of the configurations of DSLAMs and CMTS's. > Btw, if you don't mind, please point out to me a large scale > deployment that actually has 10's of thousands of live customers on a > single DSLAM or which DSLAM you propose this is even physically > possible, as well as anticipated engineered bit rates for such a > deployment. 1) Point out? I know but I can't. This is a public list and I would get fired if I discuss in public anything from a client with name. But believe me when I say _it does_ exist. 2) Well with a over subscription you can do it on the Junipers E Series (and I've seen it). It is on the technical docs of the ESeries but you can also see it in this URL: (http://www.thinkjuniper.net/isp/information.asp?page=239) 3) It is not a configuration I will ever recommend; but sometimes due to budget restrictions of what a provider set to spend for the servicing of a location, the provisioning division just "make it work" doing this. -W
On Mar 27, 2006, at 7:35 PM, William Caban wrote: > > Christian Kuhtz wrote: >> At the very least, you're making a big assumption here, and that >> is that there are no EMS in charge of managing configurations and >> no provisioning system to trigger and not triggering EMS >> configuration management. In effect, service provisioning >> doesn't exist in what you describe. > Being able to provision over point-and-clicks does not get away > with the rest of the configuration. I know you can do (depending > on the EMS) a certain types of security configurations. Personally, > I haven't seen an EMS capable of do a very good hardening of the > configurations of DSLAMs and CMTS's. In a carrier environment with flow through(!) provisioning, humans generally don't touch EMS. They can't, you can't hire that many monkeys and still be in business. Instead, a service provisioning system (or OSS) gets all warm and friendly with the EMS on its northbound interface. Sometimes, OSS skip the EMS altogether because it sucks so bad and can't handle the volume. And it's only as smart (or stupid) as the professional (or moron) who designed it. So, if there's a flaw in provisioning, it can be traced back to a human. And DSL is not provisioned by hand at scale, that's just an absurd concept. That was only true for carriers when DSL was first introduced almost a decade ago now. >> Btw, if you don't mind, please point out to me a large scale >> deployment that actually has 10's of thousands of live customers >> on a single DSLAM or which DSLAM you propose this is even >> physically possible, as well as anticipated engineered bit rates >> for such a deployment. > 1) Point out? I know but I can't. This is a public list and I would > get fired if I discuss in public anything from a client with name. > But believe me when I say _it does_ exist. Carriers can do some pretty dumb things, but in my experience they don't do what you describe. > 2) Well with a over subscription you can do it on the Junipers E > Series (and I've seen it). > It is on the technical docs of the ESeries but you can also see it > in this URL: (http://www.thinkjuniper.net/isp/information.asp? > page=239) An E-Series is not a DSLAM, it's a BRAS. Totally different function. A BRAS terminates subscriber sessions, a DSLAM terminates xDSL lines. Some DSLAMs act as mini BRAS these days. But an E- Series is not a DSLAM. Is this where your confusion is? You really mean to be talking about BRAS? > 3) It is not a configuration I will ever recommend; but sometimes > due to budget restrictions of what a provider set to spend for the > servicing of a location, the provisioning division just "make it > work" doing this. Not in a carrier setting. Thanks, Christian
An E-Series is not a DSLAM, it's a BRAS. Totally different function. A BRAS terminates subscriber sessions, a DSLAM terminates xDSL lines. Some DSLAMs act as mini BRAS these days. But an E-Series is not a DSLAM.
Is this where your confusion is? You really mean to be talking about BRAS? Ooops! Yeah! I don't know what I was thinking when I mixed the two. I've been talking about the BRAS. The DSLAMs that I've worked with, Stingers and Paradyne, none support tens of thousands. Definitively not. Sorry about the mix up.
So for the previous emails: 's/DSLAM/BRAS/g' -W
Hi, I am connected to this monster. I guesstimate it serves some 80,000 customers: Access-Concentrator: DARX41-erx AC-Ethernet-Address: 00:04:0e:6d:8a:42 link capacity kBit/s 8512 1048 ATM-Datarate kBit/s 1184 160 usable-Datarate kBit/s 1073 145 interleaved Latenz ms 16 16 Frame Coding Rate kBit/s 32 32 FEC Coding Rate kBit/s 128 32 Trellis Coding Rate kBit/s 360 60 1 gw1.selm-media.de (192.168.55.1) 3.226 ms 3.539 ms 3.529 ms 2 DARX41-erx (217.0.116.49) 45.533 ms 48.356 ms 49.283 ms 3 p54A7E732.dip.t-dialin.net (84.167.231.50)(N!) 101.063 ms (N!) 106.199 ms (N!) 111.359 ms 1 krzach.peter-dambier.de (192.168.48.2) 0.735 ms 1.176 ms 1.285 ms 2 DARX41-erx (217.0.116.49) 55.232 ms 62.911 ms 79.945 ms 3 p54A7BED2.dip0.t-ipconnect.de (84.167.190.210)(N!) 116.538 ms (N!) 124.900 ms (N!) 133.240 ms The two sites are some 50 kilometers separate and are served by different ISPs (t-online.de, 1und1.de). The ip-address range is always 84.167.xxx.xxx but it depends on the ISP. The DARX41-erx (217.0.116.49) belongs to dtag.de Deutsche Telekom AG. Some 8 of these boxes, Juniper erx, serve practily most of germany. I cannot tell you wether this is a DSLAM or a BRX but I guess it is both in a single one box. Cheers Peter and Karin Christian Kuhtz wrote:
Maybe you're just baiting trolls, and granted, I haven't had my coffee yet. But let's try to be perfectly straight up here. At the very least, you're making a big assumption here, and that is that there are no EMS in charge of managing configurations and no provisioning system to trigger and not triggering EMS configuration management. In effect, service provisioning doesn't exist in what you describe.
While OSS in carrier settings often -- put politely -- leave a lot to be desired, that is -- politely put -- a bit absurd. That would seem to be a very flawed at scale when you're talking 10's of thousands of DSLAMs, not to mention that it is really not matching reality in a carrier setting (rather than small time provider or other type of hack). There may have been periods in the past where that was true, but it is certainly not state of the art during any period of the recent past. This type of provisioning actually has been around as flow through provisioning for a while, and the flow specifically touches the port a customer would be provisioned on. The day this functionality arrived seems to generally have coincided within a relatively short period around offering variable DSL sync speeds, and it would simply be a business necessity for offering such service variants. Quite frankly, in such a world, anything more than a field crew making the device available to NMS is total overkill and a waste of time, multiplied by 10K's of DSLAMs, for a few actually provisioned customers.
Btw, if you don't mind, please point out to me a large scale deployment that actually has 10's of thousands of live customers on a single DSLAM or which DSLAM you propose this is even physically possible, as well as anticipated engineered bit rates for such a deployment.
Best regards, Christian
On Mar 27, 2006, at 8:21 AM, William Caban wrote:
I could add that many of the implementations are done using "professional services" of whoever the manufacturer of the DSLAM is and it is a very simple and weak configuration. They make sure it works and thats it. No attention is given to security or performance in any form. Now, I should also mention that the reason for this is that the providers usually only pay for this basic configuration and think or assume they can do the rest. The problem is that a DSLAM configuration can become so huge once the service start rolling that it is hard for any one to go back a fix the configurations because of the impact it may have to the clients. It is not impossible to fix, it will just have an impact to all the clients arriving to the same DSLAM and this can be counted in tens of thousands of clients. So the solution is to do it right from the beginning.
-W
Sean Donelan wrote:
On Sun, 26 Mar 2006, Joe Shen wrote:
Is there any books or papers on carrier level DSL access network and LAN access network? Specifically, it should analysis the futures of DSL network and security problems in DSL networks.
You probably want to start with the DSL Forum <http:// www.dslforum.org/> After you get through their technical reports you should be very confused.
A problem you will discover is often the DSL folks don't think they have any security problems. That all the security issues are with IP and the ISP.
-- William Caban-Babilonia Senior Network & System Consultant Mobil: 787 378-7602
-- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.serveftp.com http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/
On Tue, 28 Mar 2006, Peter Dambier wrote:
I cannot tell you wether this is a DSLAM or a BRX but I guess it is both in a single one box.
Not unless Germany is a very, very small country. The Holy See and Monaco might be small enough to serve the entire country from a DSLAM. DSL is distance sensitive. If your country is bigger than about 5 km, you have lots of DSLAMs. You are confusing a BRAS (Broadband Remote Access Server) with a DSLAM (DSL access multiplexer). The DSL access network does not show up in an IP traceroute. As I suggested before, please read the technical reports available from the DSL forum <http://www.dslforum.org/>. A misleading diagram, but for the purpose of reference, a typical user connection: ROUTER---ip---BRAS---atm---DSLAM---dsl---B-NT---ethernet---COMPUTER In reality, these are protocol stacks such as IP over PPP over ATM over DSL, but it makes the ASCII artwork very confusing. Understanding the security issues involved with just one of components in the diagram is a challenge. Finding people who understand the security issues involved with ALL of the components in the diagram is a huge challenge. Usually you rely on people responsible for each of the components are doing a good job at keeping their part of the picture secure and working.
On Tue, 28 Mar 2006, Sean Donelan wrote:
ROUTER---ip---BRAS---atm---DSLAM---dsl---B-NT---ethernet---COMPUTER
In reality, these are protocol stacks such as IP over PPP over ATM over DSL, but it makes the ASCII artwork very confusing.
Let me counter with: ROUTER - ip/ethernet - DSLAM - ip/ethernet/atm/dsl - CPE - ip/ethernet - COMPUTER In some cases a modern dslam will do routing as well. ATM was close to death before DSL came along, please don't CPR it anymore. Let it R.I.P. -- Mikael Abrahamsson email: swmike@swm.pp.se
participants (6)
-
Christian Kuhtz -
Joe Shen -
Mikael Abrahamsson -
Peter Dambier -
Sean Donelan -
William Caban