- Test - lists.nanog.org

Re: Who uses RADB? [was BGP to doom us all]
by Danny McPherson 03 Mar '03

03 Mar '03

Yes, at iMCI (we) had our own registry, MCI-RR, but we only used it (in addition to data from the other IRRs) to generate customer prefix filters, not peers. Cable & Wireless still uses the RR, now know as CW-RR. -danny > As I remember and I could be wrong, its been a few years now, when I worked > for iMCI we did and we moved over to C&W we still did.

1 0

RE: Who uses RADB? [was BGP to doom us all]
by Jim Deleskie 03 Mar '03

03 Mar '03

As I remember and I could be wrong, its been a few years now, when I worked for iMCI we did and we moved over to C&W we still did. -Jim -----Original Message----- From: Danny McPherson [mailto:danny@tcb.net] Sent: Saturday, March 01, 2003 10:48 AM To: nanog(a)merit.edu Subject: Re: Who uses RADB? [was BGP to doom us all] > > > Who actually uses RADB to build filters other than Verio? While my > > experience with other providers is limited Verio is the only one (of the > > ones we have used) who used RADB entries for BGP peers. > > Level3 do atleast. Most European providers do. For customers, though not inter-provider. -danny

1 0

look for contact @Nordnet France
by Pascal Gloor 03 Mar '03

03 Mar '03

I'm looking for a contact @Nordnet France, concerning a DNS problem. I have tried all ways to contact you... but unfortunatly I cant escalade over the 1st level support which doesnt understand my problem. Please contact me off-list. Thanks, P.

1 0

RE: BGP to doom us all
by Kuhtz, Christian 03 Mar '03

03 Mar '03

Why not? Can you be more specific as to why you think that LDAP is not suitable? Thanks, Christian > I believe that LDAP can be the core of this toolset. > > --Michael Dillon > Why not put everything into a MySQL db? :) LDAP is a fine tool but it was not designed to do some of the things that other tools do. We are not yet at the point where all we have the the LDAP hammer so everything looks like a db-nail. --bill ***** "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers."

3 2

Re: BGP to doom us all
by Michael.Dillon＠radianz.com 03 Mar '03

03 Mar '03

> It has to be separate from SWIP though, as rwhois servers don't issue SWIP. This is basically where I started thinking about LDAP. If rwhois doesn't do the job, then we could either fix/enhance rwhois or move to something else. Anyone who has ever delved into the internals of rwhoisd knows what kind of quick hackery it is, therefore moving to something else is the only realistic option. LDAP is designed for read-mostly databases therefore it does support updating the database as long as the frequency of updates is low. So it is entirely practical for LDAP to be used as a replacement for SWIP, i.e. sending update transactions to an aggregating database. If you want to try some of this, the open source server from http://www.openldap.org is the place to start. But please consider developing tools in Java/jython or Python or Ruby rather than Perl. This makes it a lot easier for other people to re-use, improve and contribute http://www.jython.org/ http://python-ldap.sourceforge.net/ http://ruby-ldap.sourceforge.net/ --Michael Dillon

1 0

Re: BGP to doom us all
by Michael.Dillon＠radianz.com 03 Mar '03

03 Mar '03

> > I believe that LDAP can be the core of this toolset. > Why not put everything into a MySQL db? :) Arrgghhh!!! he yells running and screaming in horror... Of all the example products you could have chosen to represent database software, why on earth did you choose this abomination. Is it a dbm-style unordered hash or a B+tree database or an SQL relational database? No, none of the above, it's a stew of pieces hacked from all the above-mentioned carcasses all boiled up in a pressure-cooker until nothing is left but a quick meal. If you had asked, why not use a relational or SQL database, I would have answered thusly. There's nothing wrong with relational databases even those using SQL. However, these are storage systems and I suggested a communications protocol, namely LDAP. If you want to store your directory data in an SQL database and serve it up via LDAP, this can be done with most of the commercial LDAP servers and with openLDAP as well. IBM has done some good work in showing how an LDAP schema can be effectively mapped into an SQL database schema. > LDAP is a fine tool but it was not designed to do some > of the things that other tools do. This applies to SQL/relational databases as well. In fact, LDAP was specifically designed to do things that SQL/relational systems don't do very well. And the set of things that LDAP does maps quite well to things like directories, DNS, whois, rwhois, IRR, RIPEdb, PKI and similar things. More or less, relational systems handle tables well, while LDAP handles hierarchically structured data objects well. In the relational world the focus is on the storage systems and the standards are application programming interfaces like SQL or ODBC. In the LDAP world, the focus is on an efficient and effective communications protocol that can be the frontend to any storage system. > We are not yet at the > point where all we have the the LDAP hammer so everything > looks like a db-nail. I beg to differ. We are at the point where there are numerous commercial LDAP servers, where Sun and Microsoft have integrated LDAP into their OS for yp/NIS types of services and where the open-source server has matured and become a credible solution for serving LDAP. Added to this are the large number of LDAP-related tools for browsing, schema design, interfacing, replication/backup etc. And then there are the many books on LDAP and the courses on LDAP and the fact that LDAP knowledge is a basic part of the skillset for certification by Novell, Microsoft, Cisco, Sun, etc. We all do have the LDAP hammer or we can easily rent or buy one. And we can easily find people who know what one is and who know how to use it. Have you ever tried to hire someone with rwhois experience or RADB experience? If so, put out the same ad asking for LDAP experience and note how much larger the pile of resumes is. In the early '90's the Internet community had to invent a lot of protocols and tools to make things work. Today, this is no longer necessary because we can leverage a lot of stuff from the commercial world. The military have discovered the same thing and generally look for COTS solutions before building their own. I'm not saying that we never have to design another protocol, just that we should use more pre-existing work by others in those areas where our needs are not so unique. --Michael Dillon

1 0

Re: BGP to doom us all
by Michael.Dillon＠radianz.com 03 Mar '03

03 Mar '03

> I like the idea of people being able to START on the authentication > datbase of ownership/announcement in a distributed fashion, but > perhaps there are other ways (perhaps DNS-based) of getting there > as well... Yes there are other ways and I suggest that the optimal choice of protocol for publishing this information is LDAP, not DNS. That's because there is no need for kludges to get the data that you need into LDAP since it supports a wide variety of data types. It can also be used in a hierarchical referral chain just like DNS. I am suggesting that the starting point here is to get ARIN to set up an LDAP server to authoritatively identify the leaseholder for all IP address space. Next step is to get ISPs to replace their creaking antiquated rwhois servers with LDAP servers. And then build up tools that use the data from the LDAP hierarchy to generate route filters, configure firewalls, manage SMTP filters, etc. If people want a PKI cert hierarchy, that data can go into the same servers. If people want to have secure BGP sessions they can have their network management system talking to the LDAP hierarchy to check certs and then tell their routers what to do. A router should never have to do any crypto itself. > : My opinion is that lazy operational practices are the single biggest threat to > : the Internet. One of the lazy operational practices is the proliferation of crudely hacked tools, often written in PERL which is like a swiss army knife made by tying together a knife, pliers, nailfile and screwdriver using dental floss and duct tape. There was a time when the net was growing too fast to plan and nobody had any experience or any benefit of hindsight. But times have changed and we now need to replace some of this rotting infrastructure with better general purpose tools that have some architectural planning behind them. Something like a Leatherman tool or a Victorinox swiss army knife. I believe that LDAP can be the core of this toolset. I also believe that we need to stop relying on the packet-forwarding box to do the entire job of routing and start using more auxiliary CPU power in a vendor independent way. There is plenty of experience in building rackmount Intel-based BSD/Linux servers that run as reliably as the routers themselves. Let these boxes do the job of authenticating and authorising route exchange and similar jobs. --Michael Dillon

3 2

RE: BGP to doom us all
by St. Clair, James 03 Mar '03

03 Mar '03

Good point, Sean. The problem is the business process and the risk to the process, vs. the cost to fix it. Jim -----Original Message----- From: Sean Donelan [mailto:sean@donelan.com] Sent: Friday, February 28, 2003 7:25 PM To: 'nanog(a)merit.edu' Subject: Re: BGP to doom us all On Fri, 28 Feb 2003, Jim Deleskie wrote: > http://news.com.com/2100-1009-990608.html?tag=fd_lede1_hed > > Seems the BGP will be the down fall of the internet, the sky is falling the > sky is falling Other than pending patents and a cool name Secure BGP, you still have the fundamental problem. Garbage In, Garbage Out. The only difference is now you have Secure Garbage(tm). There is a problem that needs to be solved. But like the whole micro-payments, SET, etc thing; if the solution is more complicated and more expensive than the alternatives; it won't get used no matter how "secure" it is.

1 0

Re: BGP to doom us all
by Avi Freedman 03 Mar '03

03 Mar '03

In article <103128.211654.21906(a)avi.netaxs.com> Barry wrote: : Now - show me an operational environment on the Internet were this authorization : chain is _working_ today. RIRs and RADB do not count. As you mention before, : those databases and keeping them up to date are a "pulling teeth" exercise. Well, while I don't advocate S-BGP *in particular*, I think starting with something based on in-addr, which is already delegated right down to the level of an origin AS owner (almost always), is the right idea. It wouldn't be too hard for me to trust: 4969.24.origin.0.254.200.10.in-addr.arpa returning something like "true." to check whether 4969 is allowed to originaate 10.200.254.0/24. First level use of something like that would be for detection of unauthorized routing, second could be some level of filtering - perhaps eventually in routing devices, perhaps not. Want authentication? DNSSEC perhaps - but poisoning attacks aside, I assert that if you get root on the in-addr box for a typical network, there are other problems you can cause anyway, especially at edge-y type networks. I think (as usual) we have this political problem with the idea of getting routing databases updated, either because of people who don't want others to see routing policy, or because of those who won't use anything that isn't 100% complete. All I assert about that is that building filters from the existing databases would indeed be silly. : As mentioned here and NANOGs in the past, our biggest problem are providers not : using the tools that they have to build incident resistance into today's : network. Agreed. :> My own opinion is that sophisticated routing attacks are the :> single biggest threat to the Internet. Well, I think redistribution attacks and worms that slam connected IPs with forged-source packets of various types are more worrisome than people leaking malformed BGP updates or trying mass blackholio attacks like the 7007 effect. Those may be sophisticated routing attacks (the former), but I don't really think so. Re: S-BGP in particular, I think that the analysis on S-BGP has been... limited. Ironic for a security protocol that I haven't seen any real analysis of the effect on router CPUs when *under attack*. I am not saying "oh, the authentication will drive things way too high". I'm just saying that we don't know because the simulations have used very conservative parameters. I have problems with statements from S-BGP-land like - "Networks upgrade their routers every 2 years" (paraphrase) Not the last 2 or the next 1. "Router CPUs average 50%, and S-BG adds 10%" (paraphrase) Average is somewhat less relevant than common peaks. GSRs and 7500s and 7200s all get up there at 90+% on the real Internet. And with the assumption that people will be willing to front their big iron with offboard routing CPU boxes. I just don't see these things happening. And even if they could/would, I think S-BGP needs more paranoid simulation/attack/analysis before it in particular could be the grand fix. I like the idea of people being able to START on the authentication datbase of ownership/announcement in a distributed fashion, but perhaps there are other ways (perhaps DNS-based) of getting there as well... : My opinion is that lazy operational practices are the single biggest threat to : the Internet. What's the point of building security and robustness into a system : when people choose not to turn it on? Agreed on point 1! Not on point 2... It is still worth considering what security and robustness one can build in, esp. those things that allow you to do something even if the rest of the 'net doesn't... Avi

7 6

RE: DNS records for routers
by Cutler, James R 03 Mar '03

03 Mar '03

Pete, <passion>Since I do NOT believe in "Security through Obscurity" as effective</passion>, I name every address and publish both A and PTR views of this relationship. This applies to all network-addressable entities. CNAME records may be added to taste. Naming should facilitate maintenance of good network operation. So, it depends on how you like to operate. In addition, most automated IP management systems provide both A and PTR entries without extra work, so it becomes a question of "Why not?" for the A records. Round-robin does not seem (to me) to provide any particular business value. - James R. Cutler, EDS 800 Tower Drive, Troy, MI 48098 1 248 265 7514 james.cutler(a)eds.com -----Original Message----- From: Pete Kruckenberg [mailto:pete@kruckenberg.com] Sent: 2003-03-01, Saturday 2:05 PM To: nanog(a)nanog.org Subject: DNS records for routers Any passionate opinions about DNS record conventions for routers? Or recommendations? I'm not particularly concerned about device naming conventions (we have that down), I'm more interested in what makes sense for public-viewable DNS names (so I can put those beautiful fully-compliant names where people can see them). Some traces show individual interface names, some just show device names. Any particular reason to go one way or the other for PTR records (doing a single device name for every interface seems easier and less-likely to screw up to me)? What about A records? A matching one per PTR, or just one A per device? Or no A records in the public DNS? Would round-robin A records (an A record for every interface address, all using the same device name) break anything (like performance measurement tools or network management tools)? Thanks. Pete.

1 0