RIPE 46 Amsterdam, Netherlands DATABASE WORKING GROUP, 2nd SESSION 2003/09/04 WW: Any status about org object? EG: Ulriche sent a message to the wg last evening. I have changed his proposal a little. It should work now, we have to come up with a new proposal in a few weeks time. G. ERX Status (Leo Vegoda): Story so far: Central registry predates RIRs, and the data was inherited by ARIN. Many of the registrants were based outside North America. There is now an RIR coordination activity to move these IPs to respective RIRs. In August 2002 we started moving as numbers, In December 2002 we started moving ip numbers. So far, 15 /8's have been moved, that are former "class B" networks. 27 /8's to come. One more than expected, that popped up a few weeks ago. 2 by 2 transfer process continues until next summer - about 2oo records per month. There is also a plan to mve former "Class C" space, where there are over 3000 receords to be transferred. -- End of the presentation Henk: Can you document how to handle inverse DNS? It may not be clear for the people. LV: As soon as the transfer is complete, you can use RIPE NCC facilities. I'll make sure that the messages are clear enough. WW: Which parties get prenotified before transfer? LV: We try to notify everyone who is a contact. ARIN also sends prenotifications. ??: Why are you moving records? Is it worth the headache? What advantages are there? LV: One advantage is that they're familiar with RIPE NCC, so they can use same procedures. ??: The idea was that people don't have to apply different spaces. ??: Comment: Documentation is now easy to find, contrary to a few months ago. WW: In the past, people kept unauthoritative records in the RIPE database, but had to apply ARIN for changes, which caused problems. H. Revised PKI Proposal (Shane Kerr): PGP authentication is the current strong authentication for the database. PGP authentication is widely supported. But it is e-mail only. We want X509 to make it easier and more secure for LIRs to interact with RIPE NCC services. It will allow webupdates to use strong authentication. Proposal take 1: add a new auth: attribute, get dn from certificate messages. Certificates will be signed by RIPE NCC CA. Problems with this: Database is not self contained in this model. Certificates from onl specific CAs would be allowed. Users may already have certificates. Proposal, take 2: Add a new auth: attribute, contains the identifier of a keycert object. Add a new keycert object. Don't verify the message, not the certificate. It will be similar to PGP key-cert objects. Method: attribute distinguishes PGP and X509. There will be a unique identifier, so no collisions or DoS possible. Usage: create mntner, key-cert, and change auth: to new keycert. Making it transparent: LIR portal can make it easier for members. --- end of the presentation SK: I'm very pleased to receive input from the community. We're now working on conforming e-mail clients. WW: Can we add reverse lookup for keycerts? SK: With the organization object, we'll have this opportunity. RPSL says every object has contacts. So it might be reasonable to add these attributes. WW: What's the timeline of the implementation? SK: It's a matter of few weeks. I'd like to have it in production before the next meeting. I. Change of default behavior of DB software (KP): RPSS have rules defined for object creation, applying to autp-num, route and sets. If no mnt-lower, it defaults to mnt-by. For inetnum, if no mnt-lower, there is no protetion. It is unsafe by default. Allocations are maintained by RIPE NCC. People that have mnt-lower will be blocked. All ipv6 have mnt-lower. So there will be no problems. Domain objects have no need to be changed. (Heuristics to determine proper mnt-lower: presented, available from the presentation) Migration path: prepare list of allocations, notify allocation contacts about the proposed changes, wait for feedback, gather new data, generate new maintainers, update the allocations, deploy rpss style authorisation algorithm in the RIPE database software for inetnum, inet6num and domain objects. Ulrich: what is the procedure when things go wrong? KP: We expect the user to contact us, so that we can change it. WW: We also have to go to the services working group for this, about timelines and how to do this. WW: How do feel about the working group mandate? J. Input from other working groups: - Anti Spam WG: Default output from whois queries is by default used. People contact for abuse whatever comes up. WW: We're also discussing the meaning of 'r'. Can anti spam wg come up with a proposal. R: We'll try to do that. SK: Olaf asked me to say that he's giving a presentation about changing inaddr services, which may interest this working group attendants also. ??: It would be helpful to have a tag in the database to denote that the network range is no longer valid. This may help finding out bogons. AR: This is a good proposal. We should also think about the securityof keeping the invalid objects in the database. ?: As long as it's maintained by RIPE NCC, it may be kept up to date. Antisp: time to keep the data is more important to discuss. ?: RIRs should decide on service closure policies. WW: proposal to remove NONE. Henk: removing mail-from was nice, but we still have NONE. It opens doors for spammers and hijackers. We should deprecate this. Can RIPE NCC tell how many addresses have been hijacked and had to be rolled back? LV: Nobody notified us of hijacking in our address spaces. We have an account for reporting these incidents. We have so far not really have had any problem. Henk: Would you notice if I hijacked address space? LV: We don't proactively monitor this. We don't want to be a routing police. J. Cross Registry Consistency: (MCICW): we have customers in all cross registries. We constantly have consistency issues. It is difficult to direct the customer to where he should update. I would like to mention that the cross registry consistency is important in terms of our business. Less people are using automatic tools, and inconsistencies will result in less automatic users. WW: should we spend on human resources to come up with a document summarizing basic assumptions about the use of the database? (about 5 hands raise) WW: I'll contact RIPE NCC to offer some documents.