December 2002 - Test - lists.nanog.org

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

09 Dec '02

> I think we can all agree that whoever's responsibility it is, the > current system is broken. You can't actually count on people to read > this list. Absolutely right! And all of this discussion that you have sparked on the list will actually help solve the problem. Unfortunately it ain't gonna happen fast. That's why I would like to see some work done on a general solution to the problem because that will get us a lot more benefit from the effort expended. I wouldn't be surprised to see this picked up in the Cook Report and some of the trade press because of your postings. The more people become aware of how the system is broken, the sooner we can fix it. > Maybe if IANA and ARIN and the other organizations that are > supposed to work together to make all this stuff work weren't so busy > trying to pass the buck, someone might have time to figure something > out... There are more than a few people in ARIN et al. and most of them really do care about finding solutions to these issues. But the Internet is no longer an old boys club which means that there has to be a certain amount of public discussion and process before decisions are made and action is taken. Sadly, this problem could have been predicted but there are too few people willing to think about what we are doing and do some forward planning. ARIN and other membership organizations are only as good as the members themselves. When the members of an organization are apathetic, then the organization doesn't do much more than the same old thing. -- Michael Dillon

4 3

RE: The magic security CD disc Re: HTTP proxies
by Hunter Pine 09 Dec '02

09 Dec '02

As much of a flame magnet as this post may be, I'd actually like to commend MS for their security efforts on Windows XP. If you don't know how to update your system, who cares, XP bugs you by default to install updates. If you don't click on "OK" when it tells you to patch security wholes, who's to blame? MS can't push it, or there'd be yet another lawsuit. If you're not clued enough to understand the concept of passwords in networking security, they've put in a very simple fix, which disallows any user to be used to connect to an SMB share if it has a blank password. Quite a leap from Windows 2000 which doesn't even prompt you for a password to the administrator account it creates. While none of this would stop a determined hacker who has some reason to get to data on your hard drive or something, it does stop the casual exploit scanner from finding machines with open admin access and easy access to install backdoor services, which is more than I can say for most distros of various Unixes. Most computer manufacturers offer their computers with antivirus which automatically update. The adware and spyware stuff, well, users install software, not much you can do about it. Couldn't you just see MS not allowing the install of a program on Windows because it's got spyware? That's a PR nightmare. As another flame magnet statement, I'd just like to point out that linux/freebsd/solaris et al are not designed for the average user to install. The entire lure of linux as a desktop OS is that it's customizable by the user who feels too confined in a "spoon-fed windows environment". Wouldn't shipping a system that has functionality disabled in lieu of security go against this simple principle? If you're such a "computer geek" that you decide you need linux, you'd think you'd do a small bit of reading before jumping into it and installing an insecure machine. As for systems in a server environment, well, I just can't think of any excuse for a sysadmin who installs insecure servers. If you didn't know, than you shouldn't be installing the OS in a server environment anyway. Best regards, Hunter Pine -----Original Message----- From: Alex Bligh [mailto:alex@alex.org.uk] Sent: Monday, December 09, 2002 6:07 AM To: Sean Donelan; Steven M. Bellovin Cc: nanog(a)merit.edu; Alex Bligh Subject: Re: The magic security CD disc Re: HTTP proxies --On 08 December 2002 23:16 -0500 Sean Donelan <sean(a)donelan.com> wrote: > 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. How unfortunate that the magic CD you refer is not the one with "Microsoft Windows" written on the front :-p Seriously, it is faintly ridiculous that we have operators talking about a magic CD to fix the broken default installations of various operating systems (I include Linux etc. here too). If OS vendors shipped, by default, less broken configs (or at least configs that turned services off - e.g. port 137 - when not required), much, though not all, of this problem would go away. Just like it is (now) considered irresponsible to ship a PABX/Voicemail system with open dialthrough, the same should be true of operating systems. In many such OS's, like it or loath it, automatic or semiautomatic update mechanisms already exist. This would seem to be a good use to put them too. Perhaps NIPC etc. should start talking to OS vendors. Concrete example (not to pick on MS for a change) - every time I've installed a Linux machine I spend 10 or 20 minutes rewriting the (kernel) firewall rules for the box to suit the apps I have installed. It's a completely automable task. Someone unfamiliar with either IP or UNIX would find writing such a script very hard and it would take them much longer. Do mainstraim distributions include such an automatically built script by default? Not to my knowledge. Alex Bligh

2 1

Re: Operational Issues with 69.0.0.0/8...
by bdragon＠gweep.net 09 Dec '02

09 Dec '02

> Hello Everyone, > > I appreciate all of the discussion regarding this issue. Nothing has > changed. This is getting worse. We spoke to one network on Friday that > said they had cleared the problem, yet our users still can't go there. > > For those of you that feel this is not anyone's problem, and that the > internet should just "work it out"; > > I hereby challenge one of you to trade CIDRs with us. You take this > 69.1.192.0/19 ARIN assigned us and you go spend your valuable time, > resources, and money working out what seems to be "nobody's problem". > Also, if you would like to come over and answer the support calls and > explain to our customers why the competitor's networks can reach these > sites, but ours can't. Hey - after all, it's just CIDR - it's all the > same, right? Ok, you give back the address space to the RIR and get a /19 from your provider. There, problem solved.

1 0

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

09 Dec '02

>Why would ARIN specifically provide such a list? ARIN is not responsible >for the unallocated space, and there is more in the world than just ARIN. >There are liability issues with that, not to mention the fact that it is >more an IANA function (if for the sake of argument someone would implement >the list). I consider this to be more of a minor technical issue. ARIN can certain provide an authoritative directory for the unallocated portions of its own allocations. And to answer your why question; because only ARIN has an authoritative and up-to-date view of exactly which addresses are and are not allocated. Rob Thomas is doing some fine work but he is just plugging a gap created by inaction on the part of the RIRs. I'd like to see RIPE, APNIC and LACNIC also set up authoritative LDAP directories for unallocated IP space at the largest aggregate level. I'd also like to see them all dump the quirky and antiquated whois protocol and move to LDAP as the standard way of querying their directories. The details of which data goes in which directory and whether or not to use referral LDAP or mirrored databases is something which I'm not concerned about. We know a lot about running a distributed directory from experience with DNS so I'm sure that a distributed LDAP hierarchy for the IP address space won't raise any major issues. There is a lot of LDAP expertise out there in the world, lots of books, multiple implementations with years of production experience and people running LDAP directories on a much larger scale than we need. There is no question that it would work, we just need the will to prevail against these problems instead of throwing up our hands and claiming it's too hard, it's impossible and it's not my problem. --Michael Dillon

3 2

Re: Operational Issues with 69.0.0.0/8...
by Todd A. Blank 09 Dec '02

09 Dec '02

Hello Everyone, I appreciate all of the discussion regarding this issue. Nothing has changed. This is getting worse. We spoke to one network on Friday that said they had cleared the problem, yet our users still can't go there. For those of you that feel this is not anyone's problem, and that the internet should just "work it out"; I hereby challenge one of you to trade CIDRs with us. You take this 69.1.192.0/19 ARIN assigned us and you go spend your valuable time, resources, and money working out what seems to be "nobody's problem". Also, if you would like to come over and answer the support calls and explain to our customers why the competitor's networks can reach these sites, but ours can't. Hey - after all, it's just CIDR - it's all the same, right? Some of you have accused others of being too lazy to call the networks that don't work - I assure all of you we have called the ones we know of - over and over. They still don't work. Some of you have suggested that all we need to do is talk to people. We have been calling and talking for a months (almost three to be exact), and the list of inaccessible sites continues to grow. We have called and talked until we are blue in the face. What all of you don't know, is that for the first month we had this CIDR, we could not register hosts on it at NetSol/Verisign, because their core registry did not recognize it. We have been getting F***ed by this CIDR since day one. We have only been successful with two networks in getting filters removed. How many more are out there? I think we can all agree that whoever's responsibility it is, the current system is broken. You can't actually count on people to read this list. Maybe if IANA and ARIN and the other organizations that are supposed to work together to make all this stuff work weren't so busy trying to pass the buck, someone might have time to figure something out... Somebody out there has to have a spare /19 lying around :-) You know - the good old IP numbers like the ones I used to get - they actually worked ;-) What we do know is that the number ARIN took from us sure worked for them. Do you think they would be calling us if their bank suddenly told them that even though they had delivered IP Addresses to us, they could not receive our 3,000.00 dollars because it originated from a bank that has a previously restricted routing code? Todd

3 2

Re: The magic security CD disc Re: HTTP proxies
by Alex Bligh 09 Dec '02

09 Dec '02

--On 09 December 2002 08:39 -0800 Scott Francis <lists-nanog(a)darkuncle.net> wrote: > *cough*OpenBSD*cough* I've had lots of people off-list me to say how wonderfully secure X Y or Z OS distribution is. I am quite sure there is indeed a huge variation. MS fits somewhere into the scale too. The sort of thing I meant though, for example, was how many Linux/BSD distributions, on a *desktop* install, when you select a caching nameserver, have it only bound to 127.0.0.1 rather than bound to INADDR_ANY? Yes, you can tweak the config file, but what % of menu-using users know they should do that, and, if so, do it? How many machines then got infected by a BIND worm that needn't have done? > Taking off my evangelism hat for a moment, I think commercial software > vendors in general will continue to ship whatever maximizes profit. When > it becomes unprofitable to ship insecure buggy bloatware (through legal > liability, for instance), companies will stop doing so. This is exactly my point. If the US government (which appears to be taking an interest), took an interest in making life less comfortable (read profitable) to ship insecure OS's, vendors will start stopping. Until then, security is only something they need package in for those who think they need it - as opposed to 'for the common good'. >From the point of view of traditional microecomics, operating system security has 'externalities' - i.e. costs incurred by third parties. Much the same as pollution. In the general case, sufficient externalities are a good reason to examine some form of government intervention (taxation, regulation etc.). Even when the problems are international, there are historical precedents (drug regulation for instance) for international coordination. Alex Bligh

2 1

Re: Operational Issues with 69.0.0.0/8... (fwd)
by william＠elan.net 09 Dec '02

09 Dec '02

LDAP is where this kind of technology is going, I agree. But until such time as this is deployed, we'll still be using email and publishing information on the website. It can also be noted that those that create filters, have to get the information from somewhere - they most likely got it from email and website and these are the places where updates should go (and on websites listing currently allocated blocks, there should be BIG notice that information here will change and those using it should come back and check on it every few months) Also in my view it is responsibility of whever has the filters to keep them updated - they are taking a chance that this might not remove legitimate traffic (and take their time to create and deply the filter) and so they should have the time to maintain the same filter. In my view the whole point of discussion here was that 1 month is NOT enough for everybody involved to know about new block being made available for allocations by RIR. What has been suggeted which is good is to have large RIRs (ARIN, APNIC, RIPE) keep one class-A on reserve ready for new allocations and when they begin allocating from such block, then there would be 6 month or year in advance notice about next block that allocation would be made from. Such policy of having one "extra" class-a allocated to RIRs should be discussed by either ICANN ASO or by yet-to-be-formed NRR (number resource registry). On Mon, 9 Dec 2002 Michael.Dillon(a)radianz.com wrote: > > > 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 >

1 0

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