Minutes

BOF: APNIC/APCERT whois database

Wednesday 25 February 2004, Palace of the Golden Horses, Kuala Lumpur, Malaysia

Minutes

BOF commenced 6:10pm

Chair: George Michaelson, APNIC

Contents

1. Participant introductions
2. APCERT as trusted introducer
3. Accessing data from the APNIC Whois Database
4. IRT object

1. Participant introductions

Attendees at the BOF introduced themselves and explained their interest in the BOF.

Top

2. APCERT as trusted introducer

Yuri Ito (YI), JPCERT

YI explained that APCERT had just introduced the Trusted Iintroducer scheme and was interested in seeing how that would fit into APNIC's IRT object scheme.

Top

3. Accessing data from the APNIC Whois Database

George Michaelson (GGM), APNIC

• It was acknowledged that there was not enough care to ensure that the data in the APNIC Whois Database is accurate or to help CERTs access the data.
• It was noted that the quality of whois data is very important. A principal problem is that the data is becoming out of date.
• APNIC has implemented rate limiting to help the APNIC infrastructure cope with the load of queries. Up to 50% of all queries are being limited.
• All participants were encouraged to contact APNIC if they experience any issues with being blocked. APNIC has an AUP (Acceptable Use Policy) that organisations can sign to gain access to bulk downloads of APNIC whois data.
• GGM noted that he was interested in the investigations happening in China regarding distributed whois. He suggested having further talks with the Chinese participants to discuss possible problems and solutions.
• A current IETF activity called CRISP (Cross Registry Information Service Protocol) was highlighted. The aim is to create a new protocol to read whois data. The current whois protocol deals with both reading and writing data. CRISP addresses issues of internationalisation, so that field names will be in the local language of the user performing the queries. The traditional whois protocols will not be disappearing, but there will be benefits from using other forms of data access.

Top

4. IRT object

Andrei Robachevsky (AR), RIPE NCC

• When a person wants to find a contact to report an incident, it can be difficult to locate. The "admin-c" and "tech-c" are not necessarily the right points of contact. It may be necessary to go higher up the tree of IP allocations and assignments to find an incident contact. Such a contact may be contained in the "remarks" field. The solution proposed to this problem was the IRT object.
• The IRT object includes a signature field, PGP keys, etc. Both the organisation responsible for administering the address space and the IRT have to agree before the reference can be included in an "inetnum" object.
• The object is also implemented hierarchically, to allow users to move up the chain of IP allocations and assignments to find the IRT covering a larger address block.
• The IRT object was introduced into the RIPE database three years ago.
• There are two procedures to create an IRT. The first, the Trusted Introducer model, allows European CERTs to be certified and registered. The other procedure allows for independent teams to approach RIPE and have an IRT object created for them.

  Discussion

• It was noted that the agreement between the parties before the IRT object can be referenced is an important point. In normal whois database objects, there is nothing to stop a person from making a "tech-c" or "admin-c" reference any other person object in the database. The IRT object provides a two way exchange of responsibility.
• It was suggested that if the CERT community is willing, APNIC is happy to discuss the IRT object with the CERT community.
• YI noted that at APSIRC 2003, Paul Wilson (APNIC Director General) gave a presentation on the IRT object, but there has not been any discussion between the two communities.
• GGM asked participants for the types of lookups they perform most commonly perform. He noted that many systems are increasingly doing whois lookups when sensing an event. Many contact any email address embedded anywhere in a whois object, regardless of applicability. GGM explained that in the past, APNIC could cope with reports of occasional invalid contacts in the database, but that now APNIC is swamped by general spam and abuse complaints. He noted that many people query the parent /8 object to contact APNIC.
• It was stated that there had been some consideration of instituting a "wall of shame" where all bad contact information for networks could be listed by IP address.
• It was noted that there is a possible development for very large organisations to implement their own whois databases which APNIC could mirror. ChinaMobile is currently working on a similar project. Such activities could dramatically increase accuracy of whois data.
• A MyCERT representative stated that they regularly use the APNIC Whois Database and regularly find invalid contacts. It was explained that MyNIC has its own database of IP addresses and contacts for organisations within Malaysia. It was suggested that if similar databases existed in CERTs around the AP region, these databases could be used to help collate data on invalid APNIC contacts, find the appropriate correct data within the CERT database, and that this information could be passed on to APNIC.
• GGM agreed that this was an idea worth discussing further. He explained that a recent analysis of 192.0.0.0/8 had found that 75% of the objects (a total of approximately 5000 objects) within that range had not changed since 1998. So he acknowledged that invalid data was a problem. He noted that the problem with the early registrations currently being transferred to the appropriate registry (the ERX project) was that there was no way for registries to make the networks involved keep their records up to date. Contacts for APNIC delegated address space are more reliable because we must maintain financial contact with the organisations. While the financial information is separate from whois, it assists in keeping in contact with the organisations.
• It was suggested that it might be possible for APNIC to accept information from the CERTs on the out of date information for address blocks in the database, and perhaps add a remark to the object like ARIN currently does. APNIC could also perhaps contact the reporting CERT when the information has been updated. - Sanjaya (SS) asked if organisations like MyNIC existed in other parts of the AP region. He asked if it would make sense for the APNIC Whois Database to make reference to the country-based CERT for the origin of any abuse.
• The MyCERT representative explained that in most cases, abuse reporters have CCed the CERT. But the problem is that some countries may have more than one CERT.
• YI agreed that the situation was similar in Japan. She explained that while there were many CERTs, JPCERT is the most general point of contact for IRTs in Japan.
• AR noted that there were two problems people perceived with the IRT object: 1) the procedure to create the IRT object and update the database is very complex; 2) people are not aware of the IRT object or the flag to use to return it when making queries. Developers assume that all data is out of date, and so harvest any contact information anywhere in the database objects. At the RIPE 47 meeting, there was a suggestion to use an "abuse-c" as an alternative to the IRT object. The process for using an "abuse-c" would be simpler than the IRT object, but AR was not sure if it was the solution to the contact problem.
• GGM explained that APNIC was considering whether to filter objects returned by queries so that the "tech-c" and "admin-c" details would only be returned if the user included the right query flags. If "abuse-c" was implemented, perhaps this would be the only contact returned by default.
• Roman Danyliw (RD) from CERT-CC commented that it could be dangerous to have a better quality, but complex, IRT object and a lesser quality, but simpler to implement, "abuse-c" option. He noted that most networks would opt for the simpler option at the expense of the quality of the data.
• GGM noted that ARIN tags bad data in its database and that APNIC could implement this approach as well. He suggested that if CERTs preferred a template for such comments to be standard across databases, APNIC could liaise with ARIN to achieve this.
• AR noted that the most recent discussions on the "abuse-c" proposal in the RIPE database working group had swung back around to an IRT format.
• AR suggested that two issues to consider where how to educate external users of whois databases and how to keep the information in the databases current.
• GGM suggested that the APNIC database SIG could be a good venue to ongoing discussion on the topics discussed in the BOF. Within the APNIC meeting format, it would be possible, if there was enough interest in the relationship between the CERT community and the whois database, to create an ongoing BOF session at future APNIC meetings, or possibly a SIG or separate mailing list.
• GGM also asked to continue the discussion with MyCERT outside the BOF session.

BOF closed: 7.00pm

Minuted by Sam Dickinson

Top

Minutes