Security control in DSL access network

Tue Mar 28 10:57:35 UTC 2006

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 at peter-dambier.de
mail: peter at echnaton.serveftp.com
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/