- Test - lists.nanog.org

RE: Problem with routing from AS15694 to some US networks
by Hire, Ejay 09 Aug '01

09 Aug '01

>From the output there, it looks like that is the chap that is aggregating the /20 that encompasses your block. How large is your ip block? -----Original Message----- From: Adam Obszynski [mailto:awo@atm.com.pl] Sent: Thursday, August 09, 2001 11:55 AM To: nanog(a)merit.edu Subject: Problem with routing from AS15694 to some US networks Hello NONAG! I'm speaking from Poland, and would like to ask you about help in finding some kind of contact to ZephyrTele NOC/NMC becouse they absent in irrd and they recorc in arin is very simple. They anounce our network without BGP session established to our AS 15694, here is sample output which i found after some time of problems with US IP regions (the same hapends in direction to AOL.net but cannot find his looking-glass or route server) Next issue: is there any good way to avoid those situations ? Everybody could redistribute static "sh*s" to BGP and spread it around.. here is sample output from my small investigation: telnet ner-routes.bbnplanet.net [..] ner-routes>trace 217.17.34.10 Type escape sequence to abort. Tracing the route to 217.17.34.10 1 e0-1-5.burlma1-ops1.bbnplanet.net (4.2.34.162) 144 msec 8 msec 240 msec 2 s7-0-4.bstnma1-cr7.bbnplanet.net (4.0.3.181) 4 msec 4 msec 4 msec 3 p5-0.bstnma1-ba2.bbnplanet.net (4.24.4.225) 4 msec 4 msec 4 msec 4 p7-0.bstnma1-br2.bbnplanet.net (4.24.7.121) 4 msec 4 msec 4 msec 5 p2-0.bstnma1-br1.bbnplanet.net (4.24.7.113) 0 msec 4 msec 4 msec 6 p9-0.nycmny1-nbr2.bbnplanet.net (4.24.6.50) 12 msec 12 msec 8 msec 7 p15-0.nycmny1-nbr1.bbnplanet.net (4.24.10.209) 12 msec 12 msec 8 msec 8 p1-0.nycmny1-cr9.bbnplanet.net (4.24.8.162) 8 msec 12 msec 12 msec 9 h0.zephyrtel.bbnplanet.net (4.24.188.50) 12 msec 12 msec 12 msec 10 gr1-ny.ip.zephyrtele.com (12.35.239.4) 8 msec 12 msec 12 msec 11 * * * 12 * * * 13 * * * 14 * * * 15 * 12.124.183.37 !A * ner-routes>sh ip bgp reg _15694$ BGP table version is 1340345, local router ID is 4.2.34.165 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * i217.17.32.0/20 4.24.188.50 100 0 16499 7018 1239 1755 8246 15694 i ner-routes>sh ip bg 217.17.32.1 BGP routing table entry for 217.17.32.0/20, version 0 Paths: (1 available, no best path) 16499 7018 1239 1755 8246 15694, (aggregated by 15694 217.17.34.1) 4.24.188.50 (inaccessible) from 4.24.0.48 (4.24.1.60) Origin IGP, localpref 100, valid, internal, atomic-aggregate Community: 1:1000 Originator : 4.24.0.225, Cluster list: 4.24.0.48, 4.24.0.131 -- ATM S.A., ul. Grochowska 21a, 04-186 Warszawa +48-607-608701, +48-22-5156418, http://www.atm.com.pl/

3 2

Re: SP's & network security issues
by Travis Pugh 09 Aug '01

09 Aug '01

----- Original Message ----- From: "Martin hepworth" <martinh(a)solid-state-logic.com> > > I think you need to differentiate between broadband cable/DSl customers > at 'home' and those who run a business over it. There's alot of ranting > on /. about the fact that AT&T Broadband is stopping port 80 into the > cable modem and Verizon also not allowing port 25 in, ie stopping the > end user running web and mail servers over their nice new broadband > connection. > > Certain users want this so they can run these services locally without > paying fees for leased lines, colo's etc. Obviously the ISP's don't > like it (or the telco's) as it means they loose their leased lines that > are nice and profitable. > > Maybe the providers should offer to do this port blocking if the > customer requests it, of at least have the options to remove the port > blocking is I want to run all this stuff locally. > > Now Colo's are a different issue and IHMO the servers there should be > well segmented, but it depends on the contract. Does the colo look after > the O/S and applications or is the customer responsible. In the cases > I've seen in the UK the colo usually does this as an added service. > > just my 2 pence worth Hey Martin. I think what i'm suggesting is a "security by default" stance, even for small businesses or power users on the other end of these connections. It makes the system monstrously more complex, but I'd rather see a situation where the access customer has to "opt in" to any given open port across an upstream link, and has to take some responsibility to secure it. It is a large change from the current thinking -- a.k.a. "we just give you the line, what you do with it is your business", but it is blindingly obvious to me that the current line of thinking has failed miserably. Granted, performance considerations on faster links and any given customer's desire to manage their own security must be taken into account, but those seem to be exceptions to the rule. How many DS3 and above customers and yahoo-style server farms are we really dealing with, and how many small businesses with a competent security admin, as compared to T1/E1 and broadband customers who take the line, plug it in, and hope for the best? -travis > > > > -- > Martin Hepworth > Senior Systems Administrator > Solid State Logic Ltd > +44 (0)1865 842300

1 0

Re: SP's & network security issues
by Travis Pugh 09 Aug '01

09 Aug '01

----- Original Message ----- From: "Christian Kuhtz" <ck(a)arch.bellsouth.net> > > > Hey there, Hi Chris, > > In our case, we have several hundred thousands of DSL customers today, and the > million plus subscriber mark is on the engineering horizon. The problem of > security threats & resulting incidents is going to get considerably worse > before it gets better. And that's for at least two reasons.. the ramp up of > broadband and presumably the declining sophistication of the subscriber > population as a result of the greater market penetration. Lack of security knowledge is also a huge problem in the collocation market. The percentage of security-conscious colo customers is low, and uneducated customers tend to be connected to Fast Ethernet or Gigabit Ethernet feeds. One compromise in a well-connected colo can have the same effect as hundreds of broadband compromises, although it's easier to track down and stop. > > How do you effectively scale the massive support effort need for collaborative > marketing of personal firewalls and the potential for false positives and > negatives? Any ideas on the legal exposure of security services? My former employer ran several different managed firewall services, both for broadband customers and colos, with some success ... all firewalls were either built into CPE or designed as part of a "managed colo" environment where large numbers of colo customers were front-ended by a few firewalls. I don't see the broadband issue fixing itself without some built-in stateful inspection firewall in the CPE itself -- if the customer has to pay for an additional piece of hardware or software, it will instantly reduce penetration. If you can do what you need from a firewalling standpoint on the CPE, it makes life a lot easier. If you can provide a default firewall installation on your choice of CPE, configuration scaling becomes much easier. As we were never taken to court on the legal issues of managing a firewall, the only shot in the dark I would make there is that our standard contract made no warranty for host security at all, and accepted no liability, even though the 'wall was managed. It's impossible to manage network security, but not host security, and make any guarantees. > > Like, in the current case, several providers have resorted to blocking port 80 > to their non-DIA subscriber base. Is this really scalable? Obviously not for > every threat. You can't effectively keep this up with the myriad of threats. > Or can you? <this should get the crowd rolling> I'd think that a good default stance would be to block all incoming TCP connections that aren't part of an established session, for all broadband customers. Most of them would never notice, as email and http still work. However, at the scale you're talking about, I don't see blocking anything on the aggregation device itself ... it'd have to happen in the CPE, since firewall rules are going to have to be customized for clients who do need to run servers on their LAN. > > So, I think it's clear that something needs to be done, but coming up with a > definitive plan of attack is everything but trivial. > > This obviously doesn't just apply to DSL, it applies to Cable and whatever > other broadband networks are out there or will evolve... Instant results could be had, by: - firewalling *all* broadband customers by default, with a strict ruleset that denies incoming connections. Most of these customers don't know that they're running open servers on what they consider desktop machines. NT and Linux are easy to yell at, but anyone seen a default installation of Solaris 8 lately? OS vendors are not going to fix this any time soon, which leaves greater responsibility on the shoulders of whoever connects the machines to the 'net. - requiring a firewall on all collocations, whether administered by you (for money) or by the customer. Exceptions exist, i'm sure, but there aren't that many of them as compared to the vast number of poorly secured installations. - if you're going to go this far, firewall all T1 customers too ... CPE exists that will happily do this. these three should take care of a lot of the "oops i left that port open" security problems, and I'd be interested to know what percentage of major infections could be cured by just putting up a firewall. Of course, it requires a lot more staff to manage, so that cost is going to affect your bottom line. That doesn't, however, address something like code red exploiting a legitimate web server. As I'm already in security nazi mode, how about: - put it in your contract that you will run vulnerability scans against all customer servers, with advance notice if necessary. Run them. - put a required response time in your contract for a customer to fix any vulnerabilities found. Shut them off if they don't patch the holes. (note that if you are firewalling the customer, you don't have to unplug them, just block access to the server until it's fixed) - recognize your limits. try to stop the canned, automated exploits -- after the fact if necessary, but realize that a determined attacker would require much greater effort to stop. That one may be best left to the customer. This is really just a small start, but if you're going to get this serious about security, some amount of education is necessary ... even if it's just so you can say "i told you so." Translate and bounce all CERT, security focus, etc. exploit announcements to your customer base, making it clear what is in danger and what must be done to fix it. Remind customers that they may be shut down if they're compromised. Put links up to patches on your website. Run an abuse department that responds quickly to customers, and to other providers, within limits. 24 x 7 is necessary, responding instantly to black ice freaking out because someone ran nmap past it is not. I've probably ranted enough already, but I don't think that the cost of adequate security has *ever* been addressed at SPs. I may be wrong, but the emphasis just doesn't seem to be there. In order to protect yourself from your customer base, you have to incur significant costs ... how do you compete with someone who doesn't care? How do you blackball those who don't care, so you can compete with them? Is this something that requires general agreement from the SP community, or is it possible for single companies to make an effort without pricing themselves out of the market? I've probably already stepped on enough toes this morning, so i'll drop it ... except to say it's nice to see someone trying to wrap their head around these issues. Cheers. -travis > Cheers, > Chris > > -- > Christian Kuhtz <ck(a)arch.bellsouth.net> -wk, <ck(a)gnu.org> -hm > Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. > "I speak for myself only." >

3 2

Problem with routing from AS15694 to some US networks
by Adam Obszynski 09 Aug '01

09 Aug '01

Hello NONAG! I'm speaking from Poland, and would like to ask you about help in finding some kind of contact to ZephyrTele NOC/NMC becouse they absent in irrd and they recorc in arin is very simple. They anounce our network without BGP session established to our AS 15694, here is sample output which i found after some time of problems with US IP regions (the same hapends in direction to AOL.net but cannot find his looking-glass or route server) Next issue: is there any good way to avoid those situations ? Everybody could redistribute static "sh*s" to BGP and spread it around.. here is sample output from my small investigation: telnet ner-routes.bbnplanet.net [..] ner-routes>trace 217.17.34.10 Type escape sequence to abort. Tracing the route to 217.17.34.10 1 e0-1-5.burlma1-ops1.bbnplanet.net (4.2.34.162) 144 msec 8 msec 240 msec 2 s7-0-4.bstnma1-cr7.bbnplanet.net (4.0.3.181) 4 msec 4 msec 4 msec 3 p5-0.bstnma1-ba2.bbnplanet.net (4.24.4.225) 4 msec 4 msec 4 msec 4 p7-0.bstnma1-br2.bbnplanet.net (4.24.7.121) 4 msec 4 msec 4 msec 5 p2-0.bstnma1-br1.bbnplanet.net (4.24.7.113) 0 msec 4 msec 4 msec 6 p9-0.nycmny1-nbr2.bbnplanet.net (4.24.6.50) 12 msec 12 msec 8 msec 7 p15-0.nycmny1-nbr1.bbnplanet.net (4.24.10.209) 12 msec 12 msec 8 msec 8 p1-0.nycmny1-cr9.bbnplanet.net (4.24.8.162) 8 msec 12 msec 12 msec 9 h0.zephyrtel.bbnplanet.net (4.24.188.50) 12 msec 12 msec 12 msec 10 gr1-ny.ip.zephyrtele.com (12.35.239.4) 8 msec 12 msec 12 msec 11 * * * 12 * * * 13 * * * 14 * * * 15 * 12.124.183.37 !A * ner-routes>sh ip bgp reg _15694$ BGP table version is 1340345, local router ID is 4.2.34.165 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * i217.17.32.0/20 4.24.188.50 100 0 16499 7018 1239 1755 8246 15694 i ner-routes>sh ip bg 217.17.32.1 BGP routing table entry for 217.17.32.0/20, version 0 Paths: (1 available, no best path) 16499 7018 1239 1755 8246 15694, (aggregated by 15694 217.17.34.1) 4.24.188.50 (inaccessible) from 4.24.0.48 (4.24.1.60) Origin IGP, localpref 100, valid, internal, atomic-aggregate Community: 1:1000 Originator : 4.24.0.225, Cluster list: 4.24.0.48, 4.24.0.131 -- ATM S.A., ul. Grochowska 21a, 04-186 Warszawa +48-607-608701, +48-22-5156418, http://www.atm.com.pl/

1 0

RE: Covad, Chapter 11 !
by Roeland Meyer 09 Aug '01

09 Aug '01

Some bond-holders can agree in principle. But, it takes a judge to allow them to go to *their* backers and help *them* pitch the deal. > From: Christopher A. Woodfield [mailto:rekoil@semihuman.com] > Sent: Wednesday, August 08, 2001 11:06 AM > > I think the one exception to the rule in Covad's case is that > Covad seems > to have their reorg plan already in place and with the > blessing of the > majority, if not all, of their bondholders. I have no experience with > bankruptcy law, but given the fact that the debt-retiring > deal has been > made, where is the need to file Chapter 11? To flush out the > bondholders > who haven't agreed to the stock-for-debt deal? > > -C > > On Wed, Aug 08, 2001 at 08:41:07AM -0700, Roeland Meyer wrote: > > > > > From: up(a)3.am [mailto:up@3.am] > > > Sent: Wednesday, August 08, 2001 7:57 AM > > > > > > On Wed, 8 Aug 2001, deeann mikula wrote: > > > > > > > On Wed, 8 Aug 2001, Smith, Rick wrote: > > > > > > > > > Just found this... > > > > > > > > > > http://www.internetweek.com/story/INW20010807S0008 > > > > > > > > i read a similar article y'day, and that was the first > that i had > > > > heard mention of rhythms going down. either i was too busy > > > pulling my > > > > hair out last month or they were really good about > keeping it quiet. > > > > *sigh* > > > > > > > > looks like verizon is gonna be the only xdsl provider > left solvent > > > > when the dust settles. how scary is that, and how predictable? > > > > > > Although this may well ultimately prove true, people do > realize that > > > filing for chapter 11 is not synonymous with going out of > business, > > > right? > > > > Show me one case, in the xDSL CLEC business where this has > held true. Thus > > far, *every* one of them, that has filed CH11, has gone out > of business > > within 30 days, as near as I can tell. The track record is > pretty dismal. > > -- > --------------------------- > Christopher A. Woodfield rekoil(a)semihuman.com > > PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B

1 0

RE: SP's & network security issues (partII)
by Roeland Meyer 09 Aug '01

09 Aug '01

If it gets some of them to put up a firewall then it's not a total loss. > -----Original Message----- > From: Gary E. Miller [mailto:gem@rellim.com] > Sent: Wednesday, August 08, 2001 9:56 PM > To: Christian Kuhtz > Cc: nanog(a)nanog.org > Subject: Re: SP's & network security issues (partII) > > > > Yo Christian! > > Singnet, in Singapore, scanned all their direct connect customers > for BO and some other things 2 years ago. The local newspapers picked > it up front page for days. They were racked over the coals > for "invasion > of privacy". Very bad PR to scan your customers without > prior informed > consent. Even then some will get bent. > > RGDS > GARY > -------------------------------------------------------------- > ------------- > Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 > gem(a)rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 > > On Thu, 9 Aug 2001, Christian Kuhtz wrote: > > > Do you guys scan your customers? If so, what for? OS > scans? Specific > > threats? Infections? How do you handle this in your AUP? > Have you had > > problems with it? What sort of problems have you had and > how did you handle > > them? >

1 0

RE: Covad, Chapter 11 !
by Roeland Meyer 08 Aug '01

08 Aug '01

> From: Steven J. Sobol [mailto:sjsobol@NorthShoreTechnologies.net] > Sent: Wednesday, August 08, 2001 12:44 PM > > On Wed, 8 Aug 2001, Mitch Halmu wrote: > > > Ownership of the C/O and the last mile confers ILECs an > unfair advantage > > in this business > > I'd agree with that, but I think there's more to it than that. Cash > management and order turnaround time play a big role in the > success of a DLEC, too. Cash management wasn't just a problem with the DLECs. Most of the dot-com world had that problem. If WebVan had reduced itself to making at least ONE region profitable (proving the market) and then resrticted themselves to half of their growth rate, they'd still be around. Most of them bit off more than they could chew, were to stupid to realise it, and choked to death when they couldn't feed the burn-rate.

1 0

Covad, Chapter 11 !
by Smith, Rick 08 Aug '01

08 Aug '01

Just found this... http://www.internetweek.com/story/INW20010807S0008

11 15

RE: Covad, Chapter 11 !
by Roeland Meyer 08 Aug '01

08 Aug '01

> From: up(a)3.am [mailto:up@3.am] > Sent: Wednesday, August 08, 2001 7:57 AM > > On Wed, 8 Aug 2001, deeann mikula wrote: > > > On Wed, 8 Aug 2001, Smith, Rick wrote: > > > > > Just found this... > > > > > > http://www.internetweek.com/story/INW20010807S0008 > > > > i read a similar article y'day, and that was the first that i had > > heard mention of rhythms going down. either i was too busy > pulling my > > hair out last month or they were really good about keeping it quiet. > > *sigh* > > > > looks like verizon is gonna be the only xdsl provider left solvent > > when the dust settles. how scary is that, and how predictable? > > Although this may well ultimately prove true, people do realize that > filing for chapter 11 is not synonymous with going out of business, > right? Show me one case, in the xDSL CLEC business where this has held true. Thus far, *every* one of them, that has filed CH11, has gone out of business within 30 days, as near as I can tell. The track record is pretty dismal.

2 1

RE: MPLS VPNs or not?
by Kavi, Prabhu 08 Aug '01

08 Aug '01

> -----Original Message----- > From: Kevin Loch [mailto:kloch@opnsys.com] > Sent: Wednesday, August 08, 2001 1:53 PM > To: nanog(a)merit.edu > Subject: Re: MPLS VPNs or not? > > > > Diddn't PSInet deploy L2 switching massively throughout their network? > What did the market decide about that? Could it be that > UUNet's success > was due to other factors? BTW, I'm not sure that #1 above > was ever true > in a large scale network. > > KL > Like I said, to be succesful, you need to do many things right. And one of them having a sufficiently good sales team and market presence that you run into the problem where you have to scale your network rapidly to meet customer demand. UUNET had that problem (a good problem to have), tried a solution, and it worked for them. PSINet did not have this problem of outrunning L3 routers. #1 (running out of gas on the routers) was most definitely a problem at the time for a few providers. Remember that the most stable and widely deployed router in 1994-1997 could do about 300Kpps across the entire box. We've just come a long way since then. Prabhu

1 0