The Chair introduced the SIG and explained the agenda. He provided general guidelines for the presenters and encouraged a wide range of participation in the discussions.
- Joint efforts in incident response in AP region and future work with RIR
[Presentation]
Suguru Yamaguchi, JPCERT
This presentation provided an overview of APSIRC, first developed by APNG in 1998 as an effort to coordinate country based CERTs. The presentation outlined the model used to describe the types of CERTs existing in the Asia Pacific region.
The presentation also noted that the mission of APCERTF is to maintain a trusted contact network of computer security experts in the AP region. The presentation outlined the proposed structure of APCERTF and how it may interact with APNIC and the NIRs. It was noted that there could be more contact, collaboration and sharing of information between the AP CERTs and the Internet Registries.
APSIRC is the regional forum of CSIRT and related organisations. APCERTF is the task force for upgrading CSIRT activities in the AP region.
Questions and discussion
- It was suggested that it may be useful to work with the APCERTF to create IRT objects in the APNIC Whois Database.
Action items
Top
- Whois database upgrade
[Presentation]
Sanjaya, APNIC
This presentation provided an overview of the recent upgrade of the APNIC Whois Database to RIPE v3 database software.
Questions and discussion
Action items
Top
- Proposal to deprecate MAIL-FROM in maintainer object
[Presentation]
George Kuo, APNIC
This presentation presented a proposal to deprecate MAIL-FROM in the APNIC Whois Database maintainer object as it is not a secure authentication method.
Questions and discussion
- It was clarified that reminders would be sent out if the proposal to deprecate MAIL-FROM was accepted. The reminder would include details on how to change authentication method. Objects not changed by the 17 December date would then have a CRYPT-PW generated by APNIC.
- Some concern was expressed about the proposal as JPNIC often uses it as an temporary value and then changes the method later. The current practice allows JPNIC members to pass over control of maintainer objects more easily than giving out a password. It was suggested that MAIL-FROM continue to be available when objects are created with a time limit set to change the authentication to a more secure method. This would be technically possible. JPNIC accepted an alternative proposal to use "none" as the auth attribute instead of MAIL-FROM.
- It was noted that the creation of a maintainer objects is performed manually. If a maintainer object was received with a MAIL-FROM attribute, hostmasters could advise the maintainer owner to change it.
- Concern was expressed that, since more than one auth field can be used, more secure authentication methods included in the maintainer object would be cancelled out by the insecure nature of MAIL-FROM.
- It was noted that when RIPE deprecated MAIL-FROM, there was a long cutover period. However, in RIPE's case, there were over 1000 MAIL-FROM objects. APNIC has less than 200, so it was noted that there wasn't a need for such a long cutover period. It was noted that there were no complaints from RIPE members during the deprecation process.
- The Chair called for a sow of hands on the proposal. After some clarification, this call was made again. There was a show of hands in favour of accepting the proposal. There were no objections.
Action items
- Action db-14-001: The proposal to deprecate MAIL-FROM to be taken to the AMM for approval.
Top
- Whois database upgrade: maintainer administration
[Presentation]
Sanjaya, APNIC
This presentation outlined the implications of the mandatory mnt-by attribute in the upgraded APNIC Whois Database on inetnum objects from the version 2 database that did not include mnt-by attributes. At the time of the upgrade, APNIC inserted MAINT-NULL into all objects without a mnt-by attribute. The presentation proposed to use a hierarchical structure of maintainer objects for APNIC, member, and customer objects.
Questions and discussion
- It was noted that RIPE has a maintainer object with a NONE auth scheme to fulfil the same purpose. Some people are using it to create new objects. Although it is possible that RIPE NCC may also deprecate the use of NONE, there are currently thousands of objects maintained this way. It was noted that a problem with the NONE maintainer is that simple typing errors can accidentally place one organisation's maintainer on another's database object.
- The Chair suggested that some examples should be tried in the current database, with the results to be presented at the next meeting.
- It was suggested that discussion continue on the mailing list.
Action items
- Action db-14-002: Secretariat to create sample hierarchical inetnum objects with associated maintainer objects in the APNIC Whois Database. Results to be presented at APNIC 15.
- Action db-14-003: Discussion on mandatory maintainers for inetnum objects to be carried out on the db mailing list.
Top
- APNIC IRR Pilot Project
[Presentation]
George Michaelson, APNIC
This presentation outlined the development of the APIRR project and the integration of an IRR into the APNIC Whois Database. The presentation highlighted the benefits of an integrated whois and IRR database.
Questions and discussion
Action items
Top
- Problem of AS number database registration
[Presentation]
Written by Toshi Tachibana, Ani and Company
Presented by Kuniaki Kondo, NetCore Inc
This presentation outlined the proposal to delete import, export, and default attributes in the aut-num object template in the APNIC Whois Database, as connectivity information often includes confidential business plans and private peering. The proposal suggested separating the IRR and Whois databases so that import, export, and default attributes are not disclosed by the whois database but would appear in the IRR. The presentation also proposed that APNIC create a new object for managing AS number assignments that would not contain import, export, and default attributes.
Questions and discussion
- It was noted that import, export, and default are optional attributes. Networks may decide to include these attributes or omit them if they feel the information is too sensitive to make public.
- It was also noted that routing information is needed to justify requests for AS number. However, after a network receives the AS number from APNIC, it is the member's choice whether the import, export, and default fields are retained in the object.
- It was suggested that this proposal needed to be discussed further on the mailing list.
- Some concern was expressed that the proposal would mean that a new object would need to be created by RIPE NCC for use in the APNIC Whois Database.
Action items
Action db-14-004: Discussion of the proposal to create a new AS object to take place on the database mailing list.
Top
