RIPE 46 Amsterdam, Netherlands DATABASE WORKING GROUP, 1st SESSION 2003/09/03 URL for the presentations: http://www.ripe.net/ripe/meetings/ripe-46/presentations/ A. Administrative Stuff: Scribe Can Bican B. Action Items 45.3 to expose development process inside RIPE NCC database department: SK: we moved whois client to sourceforge. We are thinking about the rest of it. WW: considered to be done. 45.1 add maintainer contact to erx mail exchange. Done. C. WORKING GROUP MANDATE AND CHARTER: Wilfried Woeber: I ask you to review the old mandate of the group and other working groups and try to find out if we have any overlapping with those. We want to avoid doing the same thing in two different working groups. Any ideas? Shane Kerr: My initial idea was to split database update presentation. Software we develop, and the service level would go to services working group. I'm open to any suggestions from the community. WW: I usually prefer new functionality from user working groups. Then we can (db-wg) deal with the implementation. I'd like to come back to this issue tomorrow at the end of the meeting of this working group. You can send either to the mailing list or to me. D. DB Operational Update (SK): - Statistics: -- number of objects going down, query and update rate is getting higher. -- Historical contents displayed, Person cleanup and SK TLD removal mentioned. -- irt objects increased by ~150%. -- domain objects declined, and inet6nums increased. -- Update sources displayed. -- Gentle increase in syncupdates, up to 10% expected. -- query load is increasing, but no operational problems. -- domain referral queries are on the rise. -- so many people query database that it's a public service than a member service. -- no news in database ops, and it's good news! Unreferenced person cleanup: -- 35% of unrefed person objects are deleted. Process began in 29 May 2003. -- ripe-dbm receives about 70 tickets per day. -- spam still a problem. We filter spam, and notify senders that we filtered them. -- ripe-dbm is an open mailbox. -- version 3.2.0 has been published. Denial messages now contain client IP. There are also several internal changes. -- rpslng server prototype and changes to irrtoolset has been published. Supports ipv6 and multicast RPSL objects. Prototype sees little use. Proposals: - status attribute changes - x509 changes - org object Previous proposals: - default to protected inetnum inet6num domain: - seperate presentation - notification for more specific. Done - removal of cross notifications: partially done. - reclaim functionality, mnt-lower on set objects: ongoing - CIDR to range conversion for inetnum. - route authorization for more specifics, to improve aggregation. No action, not forgotten: - deprecate NONE - CRISP - RIRs submitted a requirements draft. Expect to operate in conjunction to whois. -- End of the Presentation WW: who knows about irrtoolset and rpslng? (some people raise hands) Is irrtoolset using one server for ipv4 and other for ipv6? Katie Petrusha: It doesn't have this functionality yet. WW: How many of those cross notification stuff are in the database? SK: Not so much, but no figures. WW: Where are the RIR requirements for CRISP? SK: It's probably in the ietf page. But we can send it to the list. --------- E. The status: attribute (SK): - Current state explained (allocated pa/pi, etc...) - PA and PI have nonobvious meanings. There are no enforcement of rules. There are differences between ipv4 and ipv6. Unspecified status is overused. Many objects have no status at all. - recent draft document proposes a lot of status values. - feedback from APNIC: "that's a lot of rules! Maybe two attributes would be clearer." - organization object could make registry clear, by using a simple status, combined with the org object. - sub allocation policy depends on this attribute. LIRs are also waiting. These changes should be done once. So the proposal is to implement a simple change: SUB ALLOCATED. -- End of the presentation WW: Which parties consensus do we need to go ahead with this proposal? Anyone against this proposal? (no one objects) SK: Let's bring this up in the planary. -- End of the presentation F. Organization object Proposal (EG): - Idea: Provide information about an organization, LIR, or any other company, university, charity. Add a mechanism to tag objects to reference via the org: attribute. Also the ability to find objects held by an organisation, with an inverse query. - (Object template displayed) - unique id for each organization, basically a nic handle. It will be regenerated and reuse won't be allowed. - org-name and org-type are obvious in usage. Org-name is a lookup key, is ascii only. Org-type is IANA, RIR, NIR, LIR or NON-REGISTRY. - org: attribute in all objects, points to an organisation object representing the entity that hold the object. Mandatory in allocation inet(6)nums. Mandatory(?) in aut-nums, optional otherwise. - authorization checks: adding an org attribute requires authentication from the holder of the organization object. Removing the reference won't require any authentication from the organization object holder. - examples for the object and the references presented --> WW: does the addition need both authentications? --> EG: Yes. - querying for the objects presented, like 'whois -r -i org ORG-RT34-RIPE'. This will return all inetnums, etc that references this object. - queries will also return relevant organization object: inetnum: organization: person: person: this can be turned off by '-r' flag. - Deployment: Each LIR receives an organization object. Preliminary plan is presented, available in the presentation. - open issues: business-id: proposal. Motivation is not clear, the query user would not know what to do with it and remarks: attribute can be used instead. - open issue: put org: attribute in the organisation object itself? Could be useful to show dependencies among organizations. - open issue: mandatory in aut-num: or not? - do we really want to have these open issues? HPH: The idea is to create a strong mapping between the organization and the company. It will make it possible to track companies. ??: Not all organisations has this information. So it can't be mandatory, so it better should be put into remarks. JM: For hijacking purposes, hackers look for closed businesses. If we collect this ID, we can make sure the work is valid. Hank Nussbacher: we have ERX transfers, so we need to have also 'ALLOCATED BY ERX'. Engin Gunduz: Not all of these statuses are handled by LIRs. SK: We have 'EARLY REGISTRATION' status already. We don't have strict guidelines, so we change or keep the information depending on the response from owners. ??: Do you have status fields for suballocations? SK: Policy is to implement. ??: suggestion for business id: We can have a prefix to point to the country code and the type of the number? Engin Gunduz: What's the point in having another attribute? Joao Silva Damas: the point is to parse it. EG: I propose implementing this later. ??: how to convert he information from person/role to organisation? EG: We can create multiple person objects. AV: May it be a restriction to have only one org reference? EG: If there are multiple duties, there are already multiple person objects. WW: Why not restrict the org link to 1? For assignments, this may be required. EG: we can think about it more. If there is a use case, we should implement it. AV: observation - who is required to approve the link to an org object? in irt, they have two authentications. Maybe this scheme can also be implemented in org objects. ??: we can have the same problems implementing authorization as we had in route authorizations. EG: we can enable some changes through lir-portal. WW: I think different update paths shouldn't provide different capabilities. SK: I think it may be plausible implement maintainer authentication only for specific attributes. WW: I want to come back to HP's explanation of why he wants a business id. The intention is reasonable, but should also be discussed in different working groups. Also making it mandatory may be problematic for legacy address space. EG: any organization can create an organization object. RIPE 46 Amsterdam, Netherlands DATABASE WORKING GROUP, 2nd SESSION 2003/09/04 Wilfried Woeber: Any status about org object? Engin Gunduz: 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 Hank Nussbacher : Can you document how to handle inverse DNS? It may not be clear for the people. Leo Vegoda: 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. Bill Woodcock: 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. Ray Plzak: 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 Shane Kerr: 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? Katie Petrusha: 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. HN: 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. Andrei Robacevsky: While this may be a good proposal, we should think about the security consequences of keeping no longer valid ranges in the database. It may be used by address space hijackers. ?: 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. HN:: 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. HN:: 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. RIPE 46, Amsterdam, Netherlands DATABASE WORKING GROUP, Action Points 2003/09/04 1. (RIPE NCC) Send the RIR requirements for CRISP to the database working group list. 2. (RIPE NCC) Prepare documentation on how to handle inverse DNS for the address space transferred by ERX. 3. (RIPE NCC) Add reverse lookup feature for key-cert objects. 4. (RIPE NCC) Implement a tag in the database to denote that the network range is no longer valid. 5. (Wilfried Woeber) Coordinate with RIPE NCC to prepare a document summarizing basic assumptions about the use of the database.