- NANOG - lists.nanog.org

Re: Operational Issues with 69.0.0.0/8...
by Michael.Dillon＠radianz.com 09 Dec '02

09 Dec '02

> So here's a question for people. For those who filter, what about the > real-time feed that people want from the RIRs is different from this: > lynx -dump http://www.iana.org/assignments/ipv4-address-space | grep "IANA > - Reserved" 1. Missing data. Your solution does not show the parts of 69/8 that ARIN has reserved or unallocated. 2. Referrals. Your solution provides no referral to another source for more detailed data. In another world, if I ask a .org server for www.ipv6.org it will "refer" me to the ipv6.org server who will "refer" me to www.ip6.org. With LDAP we have a directory service that can issue such referrals and have them automatically followed to provide as complete a view as we desire. 3. Not a crude hack. A UNIX shell script scraping data from a text file that was created as a human-readable document is not my idea of a directory service. We needed crude hacks like whois and RADB in the beginning when there were no other tools available and we had networks to build. But now we have lots of tools and technology available. Our companies are probably all spending money today on LDAP directories for internal use. It is becoming a standard IT technology and we should be leveraging it rather than continuing with crude hacks for old times sake. --Michael Dillon

2 2

Re: Operational Issues with 69.0.0.0/8...
by Michael.Dillon＠radianz.com 09 Dec '02

09 Dec '02

> That is a good point, but you are talking about a periodic notification > when new blocks are allocated. Michael is talking about an automated feed > of all unallocated blocks. I'm talking first of all, about a directory listing all the unallocated space that people can query. Secondly, I'm suggesting that this same set of data could be published by ARIN using BGP to make it easier for people to monitor changes. > If we were to invert this and say that ARIN > will provide a list of all blocks that are allocated to it, then that might > be worth doing. I specifically suggested that ARIN provide a list of unallocated blocks because otherwise everyone else has to suck down the entire database of allocated blocks and invert it themselves. If they screw up their inversion algorithm that creates further problems. In an ideal world, IANA would provide a top-level LDAP directory of the entire IPv4 address space with referrals for each large allocation to the RIR LDAP servers just like the DNS delegates a domain to other DNS servers. But it is just as workable for the 4 RIRs to work out some other way of synchronizing the top level of the IPv4 address space and for all 4 of them to publish the entire data set in their local (topologically speaking) servers. > However, I get back to my original question. For people who insist on > filtering unallocated address space, is it too much to ask that they either > subscribe to NANOG, or potentially subscribe to an RIR-specific > announce-only mailing list for such things? Yes. This is the 21st century. Mailing lists are a 19th century technology (memorandums) dressed up with a bit of 20th century technology. We can do better. If we can create routing protocols that dynamically distribute routing topology data, then we can surely come up with an automated way of distributing the IPv4 allocation data. People who are scared of automation can insert the human being inside their own domains of control. But let's use some network protocols for the core distribution of the data. > It seems really silly to me > for the registries to spew a mailing to their entire contact database just > to reach a handful of people who actually do route filtering. Yes, spewing out email to solve a simple database synchronization problem seems counter-productive to me. Even a plain ASCII text file mirrored with rsync polling would be a vast improvement over email. But LDAP is proving to be the direction that the world is moving in for this type of directory service so why not leverage the tools and expertise that are available out there? -- Michael Dillon

2 1

Re: The magic security CD disc Re: HTTP proxies
by Steven M. Bellovin 09 Dec '02

09 Dec '02

In message <Pine.GSO.4.44.0212082230200.11579-100000(a)clifden.donelan.com>, Sean Donelan writes: >On Sun, 8 Dec 2002, Steven M. Bellovin wrote: >> I forget which of the Rainbow Series of books said it -- the Yellow >> Book, I think -- but one of them noted that the same LAN that was >> insecure in an office might be quite secure in a submerged submarine >> with a highly-cleared crew aboard. > >As far as I know, we don't have a big problem with zombie computers on >submarines DOSing the Internet. Well, no... > >It takes a lot of time to talk individual users through fixing their >computers. Especially when they didn't break it. They just plugged >the computer in, and didn't spend 4 hours "hardening" it. Most of the >time we're not talking about very complex server configurations, with >full-time system administrators. The "magic" CD would be for people who >don't know they are sharing their computers with the Internet. When >they find out (or someone else reports it), they don't want to share >their computers with everyone the Internet. They just want it fixed. > Right. The problem (and the point I was making) is that "secure" is context-dependent. In some sense, the easy way to "secure" machines is to pull the network jack. That's a serious DoS attack on yourself. Microsoft et al. could -- and should -- ship with all services off, but of course those services exist because they provide some functionality that some people want. Are those services safe? Well, maybe -- it depends on your environment and your clue. Ssh to a Cisco router is a reasonable thing to do, but not if the login password is trivial. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book)

2 1

Re: The magic security CD disc Re: HTTP proxies
by Steven M. Bellovin 09 Dec '02

09 Dec '02

In message <Pine.GSO.4.44.0212081952200.11337-100000(a)clifden.donelan.com>, Sean Donelan writes: > > >Has anyone come out with a fix everything CD customers could use >to clean up their systems? This isn't an operating system specific >issue. Buggy and misconfigured software is running on Unix, Mac, >Windows, etc. > It can't be done, at least not usefully. It's easy to turn things off; the hard part is knowing what should be left on, given your needs, the threat environment, and other protective measures. I forget which of the Rainbow Series of books said it -- the Yellow Book, I think -- but one of them noted that the same LAN that was insecure in an office might be quite secure in a submerged submarine with a highly-cleared crew aboard. It is possible, though, to write something that would analyze a configuration and present you with a sensible menu of choices. It could know, for example, that one can't disable rpcbind if other RPC-based services are running. But getting that right for even a single release of a single OS is hard enough, let alone many releases of many OSes. And then, of course, you want to add advice to the user. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book)

3 2

Re: HTTP proxies, was Re: Operational Issues with 69.0.0.0/8...
by Michael.Dillon＠radianz.com 09 Dec '02

09 Dec '02

> And don't forget about the biggest of them all, open BIND proxies. After > port 80, port 53 goes through almost as much. A lot of times you don't > need to hack anything, software comes with relay/proxy/recursion enabled. > How do we get software vendors (free, pay, virus) to distribute software > with appropriate defaults? Set up the Net Police. First step, learn from the RBL and other blacklists. Second step, publish a directory. I.e. detect the non-conforming devices and publish their IP addresses in an LDAP server. Third step, use these directories to dynamically configure filters and ACLs and blackhole routes. Fourth step, lean on the vendors to make more things dynamically configurable, i.e. make ACL configuration more like route distribution. That makes the 3rd step easier and will get more of the corporate networking people to police their neighborhoods. Finally, stop raving about how the net police would be bad. They already exist in the form of many disorganized private net police groups like the RBL people, spammer blacklists, NANOG mailing list, CIDR report, CERT, etc. The point is that policing the network itself and the devices that connect to the network is a good thing and should be done in a coordinated fashion. The purpose of publishing stuff using LDAP is because we are not policing people, we are policing machines therefore we need to talk to them in a language they can understand, i.e. a network protocol. And yes, I realize that there are lots of problems with this that need to be solved and slippery slopes that we have to be wary of, but that is not a reason for not trying. --Michael Dillon

1 0

BGP version 5 announcement
by Michael.Dillon＠radianz.com 09 Dec '02

09 Dec '02

> Perhaps e-mails > can be sent to the registered contacts of existing IP space upon initial > allocation, on the first of each month, and then on the last day of the > hold. That's a brilliant idea! We could call this BGP version 5. This is such an amazingly simple idea that I can't understand why anyone would want to run any other data distribution protocol. -- Michael Dillon ;-)

1 0

Amid telecom ruins, a fortune is buried - The Oregonian - Portland, Oregon
by Martin J. Levy 09 Dec '02

09 Dec '02

Not operational, but relevant... This is from today's Oregonian (Portland, Oregon newspaper). The article had good graphs and maps, but they are not online. http://www.oregonlive.com/news/oregonian/index.ssf?/xml/story.ssf/html_stan… There are some interesting guesses on the amount of money spent on fiber and-the-like in Oregon and some quotes from the like of Reed Hundt and Jere Retzer, etc. Martin

1 0

The magic security CD disc Re: HTTP proxies
by Sean Donelan 09 Dec '02

09 Dec '02

Has anyone come out with a fix everything CD customers could use to clean up their systems? This isn't an operating system specific issue. Buggy and misconfigured software is running on Unix, Mac, Windows, etc. There are lots of partial solutions, e.g. anti-virus vendors clean up some things but ignore most misconfigured commercial products; anti-spyware/adware cleans up other things; vulnerability checkers make long lists of problems but don't fix them. Your computer is broadcasting its IP address.

1 0

latest variety of Nigeria scam
by hostmaster 08 Dec '02

08 Dec '02

For those of you interested in the latest variety of the Nigeria -scam... it came straight from 217.78.73.1 SIOTEL NIGERIA LIMITED 217.78.73.5 SIOTEL NIGERIA LIMITED 217.78.73.160 SIOTEL NIGERIA LIMITED And for law enforcement in The Netherlands, this hopefully will lead you to something. best Bert =============================================================== Dear xxxxx , WELTLOTTO-FIRMA WORLDLOTTO 41132, NL-1007 DB AMSTERDAM, THE NETHERLANDS. FROM: THE DESK OF THE DIRECTOR PROMOTIONS, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: WFL/67-C337209635 ATTENTION ENTRANT: AWARD NOTIFICATION; FINAL NOTICE We are pleased to inform you of the announcement today, 13TH November 2002,of winners of the WELTLOTTO-FIRMA WORLDLOTTO/INTERNATIONAL PROGRAMS held on the 8TH OCTOBER, 2002. Your company, attached to ticket number 013-2316-2002-477, with serial number A025-09 drew the lucky numbers 37-13-34-85-56-42, and consequently won in category C. You have therefore been approved for a lump sum pay out of US$1,500,000.00 in cash credited to file REF NO. REF: WFL/67-C337209635. This is from total prize money of US$22,500,000.00 shared among the fifteen international winners in the category C. All participants were selected through a computer ballot system drawn from 30,000 names from Australia, New Zealand, America, Asia, Europe and North America as part our International Promotions Program, which is conducted annually. CONGRATULATIONS! Your fund is now deposited with a Finance and Security House insured in your name. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. We hope with a part of you prize, you will participate in our end of year high stakes US$1.3 billion International lotto. To collect your claim, please contact your claims officer immediately: MAXWELL FRIEDEL, FOREIGN SERVICE MANAGER, EUROSECURITIES NL, FAX : 31 205248020 EMAIL : euro_securities_nl(a)europe.com WEB URL : http:/www.eurosecurities-bv.com For due processing and remittance of your prize money to a designated account of your choice. Remember, you must contact your claims officer not later than DECEMBER 17TH, 2002. After this date, all funds will be returned as Unclaimed. ************ NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference number in every one of your correspondences with your claims officer. Furthermore,should there be any change of your address, do inform your claims officer as soon as possible. ************ ____________________________________________________________________________ _ **NB** QUOTE YOUR REFERENCE NUMBER AS THE SUBJECT OF YOUR MAIL, AND ATTACH THIS ONE WHEN YOU MAIL YOUR CLAIMS AGENT TO EXPEDITE YOUR CLAIM AND AVOID SERIOUS DELAYS. ____________________________________________________________________________ _ Congratulations again from all our staff and thank you for being part of our promotions program. Sincerely, THE DIRECTOR PROMOTIONS, WELT LOTTO FIRMA BV. www.weltlottofirma.s5.com N.B. Any breach of confidentiality on the part of the winners will result in disqualification. Please do not reply this e-mail.

8 7

RE: Operational Issues with 69.0.0.0/8...
by Todd A. Blank 07 Dec '02

07 Dec '02

This will never work - because it all makes way too much sense... -----Original Message----- From: Leo Bicknell [mailto:bicknell@ufp.org] Sent: Friday, December 06, 2002 5:18 PM To: 'Adam Tauvix Debus'; nanog(a)merit.edu Subject: Re: Operational Issues with 69.0.0.0/8... In a message written on Fri, Dec 06, 2002 at 01:44:15PM -0700, Alec H. Peterson wrote: > ARIN announced the fact that it received the 69/8 delegation on August 8th. > ARIN received the delegation on August 6th. ARIN made its first > allocation/assignment (I don't know which it was, but that isn't important) > out of that block on September 19th. [snip] > Do people have any suggestions for ARIN (and other RIRs) on how they can > better dissemenate this information so that people will update their > filters? * One month from filtered to first use is too short. Should be 6 months, with multiple notices. To back this up I can point to a number of places that stopped all global changes from before thanksgiving to after christmas. (Not that I support such things.) * Mailing nanog is nice, but ARIN probably should mail all the ARIN members, or particularly people with ASN's. Far too many people view the nanog mailing list as entertainment, rather than operational necessity. * Space that goes from "reserved" to "in use" should be test routed first. Perhaps more of a job for ISI before they turn it over than ARIN. This allows people to make sure their changes actually worked. * Maintain an RADB object of reserved space, so those with automated tools can easily query it. * Perhaps offer a BGP feed (multi-hop, a-la RBL) of reserved space to ARIN members. If I were in charge it would be: 1) Notify all ARIN members 6 months in advance of the block being used. At the same time, announce the block from somewhere so people can check that they do in fact hear it as they open up their filters. 2) Notify people 3 months, 1 month, and 1 week before making the first allocation. 3) Drop the supernet test on the same day of the first allocation. 4) Listen to feedback from the first few people allocated space and if it still is not properly routed send out another notice to people and possibly delay additional allocations from the block for another month. -- Leo Bicknell - bicknell(a)ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org

3 2