October 2002 - Test - lists.nanog.org

Re: Sugestions for a colocation equipment check-list
by JC Dill 26 Oct '02

26 Oct '02

On 07:11 PM 10/23/02, Mike (meuon) Harrison wrote: > >On Wed, 23 Oct 2002, Dan Lockwood wrote: > >> Does anyone have a list of criteria that is collected when a customer >> brings equipment into a colocation facility? Things may include make >> and model, number of power supplies, serial number, etc. Any comments >> on this type of operation are greatly appreciated. > >On the paranoid side: On the practical side: A single line on a form, with fields for: Make and model of item Description of item or its use Serial number Inventory/ID tag (maybe) Example: Cisco 2501 Router SN# 123123123123 ID# 1234 At the top or bottom of the form are fields for the date, the company that owns the equipment (name, address, phone numbers etc.), the name and signature of person bringing it in (or removing it) and a place and for the Colo security person's signature who verifies the data against the equipment (sometimes). This has been the standard procedure for all colos that I've installed equipment in to or taken equipment out of, including: Above.net (several locations) PAIX (several locations) Exodus (several locations) Equinix (several locations) NTT in Tokyo I've never been asked to open a case. I've never been asked to list internal parts (power supplies, ram, hard drives, etc.) or external pieces (cables etc.). I *have* had them paw thru my laptop bag looking for "suspicious items". I have always had a wireless card with me (with my laptop) and never had anyone give it a second look. Many colos require that you unbox your equipment before bringing it into the colo, and box it after removing it out of the colo (and of course they don't have provide any facility for you to do this on the outside of the security wall). They *really* need better systems for handling boxing and IDing of equipment. jc

1 0

More federal management of key components of the Internet needed
by Sean Donelan 26 Oct '02

26 Oct '02

Its starting already. I don't mean to diss any of the root server operators, they all do a great job. But in the past it seemed the federal agency sysadmins had the most difficult job getting the budget approval for upgrades, and seemed to always be behind the performance curve. I don't understand how giving the US federal government management control of key components of the Internet will make it more secure. What steps could the US federal government take which non-governmental organizations aren't or couldn't do? Putting a root name server on a military base isn't really going to protect it from DDOS attacks. Should root servers be located in the "middle" of backbones, instead of stub networks? Or do networks naturally "grow" towards root servers? http://www.idg.net/ic_958962_1793_1-1681.html "More federal management of key components of the Internet infrastructure is needed, Julian and Brady agreed. That could include tax incentives or direct federal funding for private companies and public organizations managing key DNS servers to secure their systems, all of which are currently operated as a free service by companies, government entities and non-profit organizations. "This showcases a specific vulnerability that requires the government to get involved," Julian said. "If you run a DNS server what is your monetary incentive to secure it? There is none. This is the number one area of focus that the government should have."

14 14

Re: How to secure the Internet in three easy steps
by Michael Lamoureux 25 Oct '02

25 Oct '02

"batz" == batz <batsy(a)vapour.net> writes: batz> Assuming you are referring to "securing" as the balance of the batz> holy triuvirate of Confidentiality, Integrity and Availability, batz> there are other options than the modest proposals you made. batz> The ISP doesn't have to manage the firewall, but like I said batz> earlier, if they provided a configurable filter in the form of a batz> web interface to altering access-lists applied to the customers batz> connection, this would solve most problems. Just to make sure I understand what you are suggesting, you are saying that the solution to most of the Internet's security problems is for ISPs to set up webservers with applications running on them that allow customers to alter the ACLs on the ISP's routers for the interfaces that have that customer's connections? I must be misreading that somehow. ;-) IMHO, Michael

1 0

Re: How to secure the Internet in three easy steps
by Paul Vixie 25 Oct '02

25 Oct '02

> > > 1. Require all providers install and manage firewalls on all subscriber > > > connections enforcing source address validation. > > > > i can see how the end to end principle applies in cases 2 and 3, but not 1. > > I didn't make any of these up. They've all been proposed by serious, > well-meaning people. i recommend caution with your choice of words. apparently not everyone treats "well meaning" as the compliement that it is. > If you have 2 and 3, why do you need to waste global addresses on 1. i don't believe that 2 or 3 will ever happen, for simple market reasons -- it is harder to make money if you do 2 or 3. however, 1 only costs a small bit of ops expense, and has no market impact at all, so it's practical in simple economic terms. > Its a mis-understanding of what source address validation is. Some folks > think it should work like ANI, where the telephone company writes the > "correct" number on the call at the switch. ouch. i guess you're right. perhaps a copy of BCP38 should come with every router sold?

5 4

Re: DNS issues various
by Randy Bush 25 Oct '02

25 Oct '02

> Future attacks will be stronger and more organized. So how do we protect > the root servers from future attack? protecting the servers is not the *critical* point. protecting the service is. don't obsessed up on silly boxes. of course, box/link protection is *one* aspect of protecting the service. randy

18 25

RE: Ameritech/SBC DSL?
by Ethan Blodgett 25 Oct '02

25 Oct '02

NOC(a)SWBell.net is your best bet. -----Original Message----- From: Spencer.Wood(a)dot.state.oh.us [mailto:Spencer.Wood@dot.state.oh.us] Sent: Friday, October 25, 2002 7:24 AM To: nanog(a)merit.edu Subject: OT: Ameritech/SBC DSL? I was wondering, does anyone have a good contact at Ameritech/SBC on the DSL side of the house???? We lost quite a few of our DSL VPN sites earlier this week, and it appears that Ameritech changed there PPPoE authentication method??? Spencer ************************************************************ Spencer Wood, Network Manager Ohio Department Of Transportation 1320 Arthur E. Adams Drive Columbus, Ohio 43221 E-Mail: Spencer.Wood(a)dot.state.oh.us <mailto:Spencer.Wood@dot.state.oh.us> Phone: 614.644.5422/Fax: 614.887.4021/Pager: 866.591.9954 *************************************************************

1 0

anycast dns servers
by Randy Bush 25 Oct '02

25 Oct '02

i am a bit confused here. seems to be that the major differences between smb's scheme, for which you personally attacked me, and yours are o yours has centralized control, you, instead of isp control. this is known not to have good layer nine properties, see marinara del roi. o we get to pay you for that privilige, though at 'cost', mighty kind of you, but we're silly enough to also think we know how to run services. though it might be fun to talk about how to automate testing for the relevant parts of rfc 2870. i.e. they are not technically much different. as smb said, the hard problems are at layer nine. but, first focusing on the technology, let's talk about the hard part of the problem first, the gtld servers, hard because of the size of the data and the frequency of change. so a large isp lets the registries (verisign et alia) put a honkin' hidden primary server near _big_ backbone links. other large (i.e. can handle moving that kind of data) isps set up ipsec or tsig secondary cluster off of it. of course, the isps' secondary clusters use a well-known anycast address for serving queries. the isps which have secondaries might not accept announcements of the anycast prefix from eachother, or they might, point to disucss. i could elaborate further, but it might be more fun to let others have a say too. especially how this can safely support all the non-oc48++ isps. randy

1 0

Re: DNS issues various
by Michael.Dillon＠radianz.com 25 Oct '02

25 Oct '02

> you might remember or look up smb's presentation on 'pushback' at > some nanog or another (those anonymous hotel rooms kinda blur, > especially before first coffee). that's not perfect, but it > scales. and it's an engineering approach to a technology problem, > always a good sign. I find citeseer to be a useful tool for finding this sort of technical information. Go to http://citeseer.nj.nec.com/cs and type in "pushback" then click the search button. Voila! You do have to be careful about what you do with the information you find there. Since these are mostly papers produced by academics the quality can be variable, i.e. a masters course project versus a paper produced by someone who is a leader in their field. If people like what they see in the papers discussing "pushback" then why not push this issue back into the lap of Cisco and Juniper?

1 0

OT: Ameritech/SBC DSL?
by Spencer.Wood＠dot.state.oh.us 25 Oct '02

25 Oct '02

I was wondering, does anyone have a good contact at Ameritech/SBC on the DSL side of the house???? We lost quite a few of our DSL VPN sites earlier this week, and it appears that Ameritech changed there PPPoE authentication method??? Spencer ************************************************************ Spencer Wood, Network Manager Ohio Department Of Transportation 1320 Arthur E. Adams Drive Columbus, Ohio 43221 E-Mail: Spencer.Wood(a)dot.state.oh.us Phone: 614.644.5422/Fax: 614.887.4021/Pager: 866.591.9954 *************************************************************

1 0

The Cidr Report
by cidr-report＠potaroo.net 25 Oct '02

25 Oct '02

This report has been generated at Fri Oct 25 21:44:47 2002 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 18-10-02 114704 82884 19-10-02 115116 82872 20-10-02 114956 82781 21-10-02 114861 82208 22-10-02 115010 82457 23-10-02 115086 82530 24-10-02 115044 82513 25-10-02 114752 82519 AS Summary 13926 Number of ASes in routing system 5448 Number of ASes announcing only one prefix 1750 Largest number of prefixes announced by an AS AS701 : ALTERNET-AS UUNET Technologies, Inc. 73146368 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 25Oct02 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 115124 82508 32616 28.3% All ASes AS3908 1062 559 503 47.4% SUPERNETASBLK SuperNet, Inc. AS701 1750 1260 490 28.0% ALTERNET-AS UUNET Technologies, Inc. AS7843 759 337 422 55.6% ADELPHIA-AS Adelphia Corp. AS2828 472 102 370 78.4% XO-AS15 XO Communications AS7018 1361 1003 358 26.3% ATT-INTERNET4 AT&T WorldNet Services AS7132 415 70 345 83.1% SBIS-AS Southwestern Bell Internet Services AS6198 419 80 339 80.9% BATI-MIA BellSouth Network Solutions, Inc AS4323 519 181 338 65.1% TW-COMM Time Warner Communications, Inc. AS1221 1196 874 322 26.9% ASN-TELSTRA Telstra Pty Ltd AS18566 326 4 322 98.8% COVAD Covad Communications AS7046 587 299 288 49.1% UUNET-CUSTOMER UUNET Technologies, Inc. AS852 737 458 279 37.9% ASN852 Telus Advanced Communications AS6347 350 75 275 78.6% DIAMOND SAVVIS Communications Corporation AS4355 385 125 260 67.5% ERMS-EARTHLNK EARTHLINK, INC AS705 442 203 239 54.1% ASN-ALTERNET UUNET Technologies, Inc. AS4151 292 55 237 81.2% USDA-1 USDA AS209 572 338 234 40.9% ASN-QWEST Qwest AS1239 885 663 222 25.1% SPRINTLINK Sprint AS1 651 434 217 33.3% GNTY-1 Genuity AS4814 232 15 217 93.5% CHINANET-BEIJING-AP China Telecom (Group)Beijing Telecom CompanyBeijing China AS17557 314 118 196 62.4% PKTELECOM-AS-AP APNIC ASN block AS22927 215 20 195 90.7% AR-TEAR2-LACNIC TELEFONICA DE ARGENTINA AS690 517 324 193 37.3% MERIT-AS-27 Merit Network Inc. AS6140 258 65 193 74.8% IMPSAT-USA ImpSat USA, Inc. AS6595 249 56 193 77.5% DODDSEUR DoD Education Activity Network Assistance Center AS17676 224 34 190 84.8% GIGAINFRA APNIC ASN block AS4134 296 113 183 61.8% ERX-CHINALINK Data Communications Bureau AS2048 265 88 177 66.8% LANET-1 State of Louisiana AS174 290 133 157 54.1% PSINET PSINet Inc. AS2548 401 244 157 39.2% ICIX-MD-AS Business Internet, Inc. Total 16441 8330 8111 49.3% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)lists.apnic.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0