Database SIG
Minutes
Wednesday 1 March 2006, Perth Convention and Exhibition Centre, Perth, Australia
Meeting commenced: 11:10 am
Chair: Xing Li
The Chair introduced the session and explained the agenda.
Contents
- Status on proposal for the whois database query
- What I Want for Eid ul-Fitr: An Operational ISP and RIR PKI
- Whois data privacy issues in Japan
- RIPE's IRIS (CRISP) prototype and features update
Status on proposal for the whois database query
- The Chair requested input from the SIG attendees about the next steps for dealing with the proposal. It was suggested that the Chair send an email to the Database SIG mailing list summarising the proposal's history and asking for community feedback on the proposal. If there is no response on the mailing list asking that the proposal be kept open, the proposal can be closed.
- Action db-21-001: Database SIG Chair to post an item to the Database mailing list giving the status of proposal prop-019-v001, "A proposal for whois database query", and asking for community input on whether to close the proposal or continue with it.
What I Want for Eid ul-Fitr: An Operational ISP and RIR PKI
- There was discussion on the use of the term "lease expiry" in the resource certificate proposed in the presentation. It was noted that "lease" was more appropriate a term than "buy and sell".
- The speaker explained that different certificates would be needed for each IP delegation as different IP address blocks could be leased for different time periods. For example, an ISP could have a block of historical IP addresses and a block allocated for experimental purposes. The experimental block would have to be returned in one year's time, whereas the historical address would be usable, under current policies, ad infinitum.
- It was pointed out that, while the speaker had suggested that there was no need for transport security as a way of distinguishing between real and false data in certificates, there was a need for transport security in order to receive the certificates in the first place. For example, security would be needed to stop DoS attacks.
- It was noted that while the speaker's model had separate resource certification and resource holder identify certification, this separation might not be necessary as RIRs were capable of doing both. As well as being able to certify resources, RIRs regularly do need to identify the holder of resources. Examples given for this included the problem of working out the legitimate holder of resources in cases of hijacked address space. It was pointed out that a self-signed identity certificate from an ISP would not be strong enough to authenticate identity. The speaker responded that the presentation had not detailed the naming component of the certificates, and that it was this naming area that would address the issue.
- The speaker noted that he was not suggesting that the new certificate model would replace whois.
- It was suggested that, while RIRs did need to establish the identity of organisations using or requesting resources, RIRs were not in the business of giving organisations a unique identity. The speaker noted that, with the RIRs, the identity of the client is based in the paper contract with RIRs - not in digital form.
- It was suggested that perhaps certificates could be bound to whois records. It was noted that many sectors, including law enforcement, use whois to identify users of address space.
- The speaker clarified that the identity certificate does not expire on the date listed as the "lease expiry" in the resource attribute certificate. Therefore, if one particular resource certificate expires, it would still be possible to route other space using the still-current identity certificate with resource certificates issued for other ranges.
- The speaker noted that within the scheme he proposed the IP resource field might not be unique.
- None.
Whois data privacy issues in Japan
- A RIPE NCC representative noted that RIPE had similar laws to Japan regarding data protection. RIPE does not have a formal policy on implementing those laws, but probably will have to implement such a policy at some point. Currently, RIPE encourages people not to register end user assignments in the database because it is understood that end users are not technically competent. Instead, RIPE encourages LIR information to be registered and suggests that the whois object should make it clear that LIR information has been registered in place of the user information.
- An ARIN representative explained that the data privacy issues are currently under discussion in the ARIN region. The representative suggested that the reasons a registry collects information about an assignment might not be the same reasons you display information about an assignment. For example, when trying to verify an organisation, a registry will request far more information about the organisation than will never be available in the database. The ARIN representative suggested that when dealing with what to make publicly available in whois, it is more appropriate to ask the question "Why should this info be displayed?" than "What should I withhold".
- An AfriNIC representative asked why it was necessary for JPNIC to stop providing bulk whois for research and suggested that it might be sufficient to delete the private information from the whois and provide the remaining data to researchers. The representative explained that this is how AfriNIC deals with the issue of user privacy while still catering to the needs of researchers. It was explained that in the AfriNIC region, while there are no privacy laws to deal with, AfriNIC receives complaints regarding spam that has resulted from contact data in whois. Therefore, AfriNIC removes the contact data from bulk whois access. In response, the presenter explained that JPNIC had consulted a lawyer who had advised that an IP address could be considered personal information because it can identify a user. Therefore, JPNIC had decided to follow the course of action described in the presentation.
- There was a comment that a general principle was to "open up only the ports that are needed". That is, with bulk whois, registries should establish what information researchers need from bulk whois, and only publish that specific information.
- None.
RIPE's IRIS (CRISP) prototype and features update
- There was a question about how many customers had signed their DNS using the "ds-data" attribute in the domain object. The presenter was unsure, but knew of at least one customer doing this. The presenter noted, however, that this was a new feature that had only been available for a short time.
- It was clarified that while the data sources for whois and IRIS queries were identical, not all parts of the source were displayed when responding to an AREG class query. For example, an AREG query will not return the mntner object.
- None.
Xing Li, CERNET
The Chair summarised the history of proposal prop-019-v001, noting that the proposer, since sending the proposal to the mailing list, had not been able to attend an APNIC meeting to present the proposal and had not responded to follow-up emails enquiring about the proposal. The Chair also noted that there had been no discussion in the Database SIG mailing list about the proposal.
Questions and discussion
Action items
Randy Bush, IIJ
Presentation [pdf]
This presentation summarised an alternative view of the resource certification model proposed by Steve Kent and described in the APRICOT 2006 plenary session.
The speaker explained that there is a need for resource certification as there is currently no way to be certain of the accuracy of whois and IRR data. As an ISP, there is no way to know if a new customer really has the right to the IP address space they want announced. Resource certification would prevent BGP being used by networks to route resources they have no rights to.
The speaker summarised his proposal for a PKI database for routing data. It was explained that, in terms of resource certificates, there could be a chain of certificates from IANA to RIR to RIR member to customer. The speaker proposed, however, that identity certificates should not necessarily be issued by RIRs. Instead, individuals should be able to certify themselves by getting accreditation from established CAs.
It was suggested that it would be useful to have a common set of tools for all RIRs to use in resource certification processes, but that RIRs may then implement the tools in different ways according to their individual business models.
The speaker explained that in the first stage of certification deployment, an ISP could use the PKI database to manually check if customers have rights to IP addresses. ISPs could do this by looking at a verifiable crypto chain all the way back to IANA. The second stage would be to validate IRR data against the PKI data. The speaker suggested that this could eventually make the IRR redundant. In five years? time, the speaker suggested that he hoped there would be secure BGP that combines BGP security and PKI.
The speaker elaborated on the concept of registering role certificates with upstreams. For example, an ISP accredited by a higher CA could generate certificates for separate activities when dealing with RIRs, such as finance and IP address requests. The speaker suggested that such role certificates would be useful for larger ISPs and that smaller ISPs would probably be satisfied with RIR-generated identity or role certificates such as those already possible by using APNIC certificates and MyAPNIC role differentiation.
The speaker noted that open issues with his proposed PKI model include coordinated updates and the fact that one central repository is not operationally feasible. However, the presenter suggested that LDAP might be a potential solution that could provide both distribution and replication.
Questions and discussion
Action items
Izumi Okutani, JPNIC
This presentation gave an overview of the effects of spamming and privacy laws in Japan on whois registration.
The speaker explained that under APNIC policy, any assignment larger than /30 should be registered in whois. The speaker noted that when that policy was created, there seemed to have been an assumption that assignments larger than /30 would be given to technically proficient customers. However, now, the average end user is receiving assignments of this size, which has resulted in end users being spammed because their contact details are listed in whois registrations. Additionally, the 2004 privacy law passed in Japan is having an effect on what can be registered in whois.
The presenter explained that APNIC's customer privacy policy has allowed customer assignments to be hidden from public view, for LIR contact details to be substituted for customer contact details, and for role accounts to take the place of individual user accounts. The speaker explained that there was a similar situation in JPNIC: JPNIC does not provide bulk whois data to third parties other than APNIC; minimum information in disclosed in whois; and use of role object is encouraged. In addition, the JPNIC whois database has a hidden "notify" field and hides selected information in the POC details. But even with these measures, the speaker explained that some end users have asked that absolutely no information about them be available in whois because of privacy and spam issues.
The speaker proposed that it may be worth considering upgrading the definition of an end user assignment to /29.
The presented explained that JPNIC had set up a working group of 12 volunteers in December 2005. The working group hopes to draft a proposal on whois registration policy in Japan by the next JPNIC Open Policy Meeting. The draft will consider issues of data privacy, spam, and consistency with APNIC and global RIR policies.
The speaker opened the floor to RIRs and NIRs to share their experience on privacy and spam issues related to whois registration.
Questions and discussion
Action items
Leo Vegoda, RIPE NCC
Presentation [pdf]
This presentation outlined recent changes to the RIPE Whois Database. Recent changes include the new attribute "abuse-mailbox", the removal of "trouble" from role object, and the introduction of RPSLng.
The speaker reported that the default output for a whois query result now removes any email references that are only relevant to maintainers (for example, email addresses specified in the "notify" attribute). However, flags can be used in the query to return the full input, including all email references.
To support DNSSEC, domain objects now include a "ds-data" attribute.
PGP-signed email updates to the database now expire after one week to prevent replay attacks in PGP.
The presenter reported that RIPE NCC has implemented a CRISP server that allows whois referrals and that RIPE NCC has also implemented a prototype IRIS server to answer AREG queries.
The speaker noted that the RIPE whois software is now at v3.3.0 and that the code is now available in a read-only CVS repository.
Questions and discussion
Action items
The Chair closed the Database SIG by encouraging more participation in the mailing list and the development of more proposals for policies and presentations related to the whois database.
Meeting closed: 12:25 am
Minuted by: Sam Dickinson
Open action items
- Action db-21-001: SIG Chair to post an item to the Database mailing list giving the status of proposal prop-019-v001, "A proposal for whois database query", and asking for community input on whether to close the proposal or continue with it.
