[db-wg] Minutes for the RIPE 46 meeting Database Working Group Sessions

Dear Colleagues,

Here are the minutes for the two sessions of the Database Working Group in 
RIPE 46. Please let me know if they need additions or corrections.

Best Regards,

-- 
Can Bican
DB Group
RIPE NCC
-------------- next part --------------
RIPE 46 Amsterdam, Netherlands

DATABASE WORKING GROUP, 1st SESSION

2003/09/03

A. Administrative Stuff:
   Scribe Can Bican

B. Action Items

45.3 to expose development process inside RIPE NCC database department:

  SK: we moved whois 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:

WW: 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?

SK: My initial idea was to split database update. 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) can 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?

KP: 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.

HN: we have ERX transfers, so we need to have also 'ALLOCATED BY ERX'.

EG: 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?

EG: What's the point in having another attribute?

JSD: 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.
-------------- next part --------------
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.