- NANOG - lists.nanog.org

Route Views
by Harsha Narayan 10 Dec '02

10 Dec '02

Hello, Some prefixes in the Route Views routing table do not have a prefix length specified. For example, 4.0.0.0 and 61.0.0.0 do not have a prefix length specified in the Route Views routing table. 61/8 belongs to APNIC. 4/8 belongs to Genuity. Why is this? How does one find out the prefix length in such cases? Harsha.

3 2

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

10 Dec '02

> > 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. > People actually read that? Yes. The people who don't read NANOG do read the Cook Report and the trade press. If you want to reach everyone in charge of operating a network then you need to use more media than just NANOG. > A simple solution: > 1) IANA creates an IANA-RESERVED IRR object > 2) Entities switch to using this for their filters, and the > updates happen automagically This is essentially what I am suggesting except using LDAP rather than RADB/IRR technology. I don't believe that RADB will ever be used by the majority of North American network operators but I do believe that LDAP has a chance of 100% penetration in the same way that 100% of network operators use UNIX servers and scripting languages in their network operations. --Michael Dillon

1 0

by popular request, was Guam
by David Lesher 10 Dec '02

10 Dec '02

http://longlines.addr.com/places-routes/Monrovia/020719B-11.jpg http://longlines.addr.com/places-routes/Monrovia/Monrovia.html I think Mt. Weather had same, also. -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

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

10 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 10 Dec '02

10 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