ICANN participation

RSSAC Meeting #6

Adelaide, AU

Jun presented agenda and attendees introduced themselves.

Attending:

Jun noted that his term as ICANN representative to RSSAC expires in July after the Yokohama,
Japan meeting, and so it would be nice if we could get all the work done by then! It was noted that his term as chair of RSSAC was not tied to his being the ICANN representative.

Agenda:

1. Technical criteria for root servers operations (DK)
2. Segmentation of GTLDs from root servers A-I (MK)
3. localhost and 127.0.0.1 (BM)
4. Analysis/Measurement/skitter (EN)
5. Y2K and other security issues (DC)
6. BIND v9 update (DC)
7. Statements on new features:
   
   IPv6 (AK)
   

   DNSSEC (DC)

8. The root transition plan (BM)
9. MoP and other contractual process (Mark Bohannon,DoC)
10. Multi-lingual issues in DNS (PW)

1. Technical criteria for root servers operations

Issue: RSSAC needs to recommend to ICANN technical criteria for

an RFP for operating root servers. What should those criteria be?

DK: We should work with the IETF on draft-dnsops-req-04.

BM: We should be careful; the draft has the IETF strong must/should language. Any recommendation to ICANN that references the draft, should suggest that they temper the draft with operational experience and implementation capabilities, as they currently exist. An issue is the use of the word "deployable" in the draft and its definition.

MK: What are the details of the problems.

BM: There are words about deployable that are related to cost, mostly of DNSSEC. This might
be deployable for one root operator and not for another.

JM: What is status of the draft?

DK: It's before the IESG. He realizes it's ambitious and parts

are not currently deployable. We should put a rider on our

recommendation, that ICANN should not just require operators

conform fully to the draft (or RFC if has been finished).

Consensus of the group: Recommend that ICANN use the draft/RFC as a basis for the RFP but add
common sense so operators are not forced into using things that are not current implementation capabilities ("deployable").

MK: Tom Newell (NSI) promised a straw man contract for root servers. He posted it to the list
this week; it's a start -- comes from NSI.

2. Segmentation of GTLDs from root servers A-I

Issue: Many of the current root servers handle the root zone and the GTLDs (com, net, org,
etc.) on the same server. These are being separated onto different machines.

MK: This is currently underway, 2 machines have been done recently, D and H (F and J were done
previously). Just com, net, and org have moved. Need a more precise schedule than just "done at the end of May".

BM: the TTL is 7 days on some, 2 days on others; there can be problems if it's not consistent.

JM: Can information about separating the GTLDs be publicly available?

MK: will ask, lots of folks have to approve it (DOC, IANA).

RP: The MIL zone is planning to move in April, are adding 3 more servers.

JM: What is the status of EDU?

BM: EDU will be taken over by EDUCOM.

DC: How about INT. and ARPA.?

JM: Are there issues with CCTLDs

BM: CCTLDs and INT. are not tied to any of the roots.

ARPA is still under discussion (by DOC and ICANN).

DK: We recommended having ARPA. Stay with the roots (ICANN) in Singapore.

BM and MK debate two views on ARPA evolution: ARPA to stay with roots (BM), ARPA to go to the regional registries that need to populate them MK). Trouble is that the regional registries aren't ready and the registries involved may not agree. [There was agreement that ARPA could stay with ICANN/IANA if it was deployed on different machines from the roots.]

Historical Note: Jon Postel gave ARIN day-to-day responsibility for IN-ADDR.ARPA while ICANN
was formed. BM thinks his intent was that ARPA should come back to ICANN/IANA after the infrastructure existed to support it, just as the root distribution server will come back to ICANN/IANA. If ARIN or another regional registry wants to have ARPA, they would need to submit a proposal to ICANN. They have not done so yet.

Action Items:

1. MK will fix the TTL issue.
2. MK will also coordinate a schedule for GTLD migration off the remaining root servers.
3. RSSAC will revisit the ARPA issue when ICANN is ready.

3. localhost and 127.0.0.1

Issue: The localhost name and 127.0.0.1 address are special, like addresses 0.0.0.0 or 255.255.255.255. Should a new TLD for them be created, and the zone file for it signed for DNSSEC. RFC 2606 created new "local host." TLD. Should the root servers authoritatively answer for localhost? Should they answer for 0.0.0.127.in-addr.arpa? Should they sign it? Are you (=root operators) responsible for answering localhost queries for anyone else but yourself? Do we want to do "localhost." too?

BM: when and if DNSSEC is deployed, who should sign them? They are special cases like 0.0.0.0
and 255.255.255.255 and can only really be signed by IANA or left unsigned.

DC: this is one of the many areas of DNSSEC that needs to be played around with.

BM: We raised issue and need to think about it.

MK: should they be hosted in the root, we put them in, took them

out, etc. If advertised by the roots, then they should be signed.

JM: cannot recommend anything at this point; bring up the issue again. It's not a good idea to tell the ICANN board we don't know the answer, don’t have an opinion.

Action Items: JM to report to ICANN that RSSAC has raised the issue of the localhost/0.0.0.127.in-addr.arpa domains and whether they should be served by the roots and signed for DNSSEC. RSSAC is studying the issue.

4. Analysis/Measurement/skitter

Issue: CAIDA's skitter boxes are being located at root server locations to study the reachablility and round trip times to a set of clients from the root servers perspective. What can be done to get this moving more quickly and get more monitoring in place? Currently the only server that has been monitored regularly is F.

EN reported the status of the skitter boxes used for these measurements. Presented a variety
of excuses, no disk space at CAIDA to store the data, lack of sysadmin help at CAIDA delayed things a bit, politics at ISI and NSI blocking things for a while, etc. The current status is:

F - monitored continuously since August, 1999. Data is automatically collected and put into daily web pages.

B - being set up

X - set up and running, data collection postponed till disk

space fixed, fixed now

A,J - box being set up

EN asked about European and Asian sites re. electrical power. Switching power supplies and local power cables will work.

EN also asked for sites to gather a client list in advance of

being sent a box. A client list can be gathered in 3 ways:

1- by running tcpdump on a host on the same network segment

(shared), for example:

tcpdump xxx

2- by enabling Cisco's netflow on the upstream router and using a special version of cflowd that was created by Daniel McRobb (CAIDA) to gather a host matrix instead of a network matrix and then create a client list.
3- by capturing transaction logs and running a script over them to extract
the client list.

EN mentioned that they see a lot of churn in the destination list.

The list collected at the F root server 8-9 months ago has about

exact numbers and trends in the churn seen.

JM: resources needed?

EN: responded that DARPA had agreed to fund the additional boxes as an add-on to an existing
DARPA grant that supports skitter research with boxes at other locations.

JM: May we have a copy of the contract with DARPA?

EN: agreed to ask CAIDA and supply it.

Action Items:

• EN to provide DARPA contract
• EN to get boxes sent out to other root operators
• EN to ask CAIDA about just supplying the software and letting the root operators supply
  the PC to run it on.
• Root operators to get client destination list prior to the arrival of the skitter box.
• EN to get exact numbers re. churn in the destination list.

5. Y2K and Other Security Issues

Issue: what is the status of the root servers against security incidents.

JM: Y2K went well, no problems with root servers; nice statement

regarding Y2K risk was generated. What is the status of root servers against terrorist attack.

BM: Vint Cerf (WorldCom) did a threat analysis of MAE's and found items that should be addressed to increase resiliency of MAEs. Did they consider the roots that are close to the MAEs?

MK: We should not publish a document listing the vulnerability of the roots or the number
of roots you need to take out to cripple the root server system.

RP: Should there be a survey/questionnaire that each root server uses to access vulnerability.

DC volunteered to take on the task of preparing such a survey; BM, RP joined in too. Lars Liman (I) has data taken at the bar BOF in Minneapolis. DC to contact, work with BM & RP on the survey.

DC: to do Y2K postmortem statement. But other security report re vulnerability of the roots to
remain a confidential internal report.

Action Items: DC, RP, and BM to prepare a survey/questionnaire for root operators to use to access vulnerability of their site to terrorist attack. DC is to do Y2K postmortem report.

6. BINDv9 Update

DC: BIND version 9 is in B1, soon to go out in B2 [did during the Adelaide IETF]. It is still
on target for 01may as release date. The missing piece in B2 is the validator for DNSSEC signatures. It will be in the B3. DC expects the performance to be significantly improved especially for multiprocessors; memory usage is better too.

JM: inquired on the status of testing on the roots. DC said that

F would not begin formal testing until the final release in May.

7. Statement on New Features in BINDv9

IPv6 (AK):

A subset of operators is planning to test IPv6. They are talking to the 6bone folks to get advice. Testing is going on now with BSDI and BIND9 B1.

JM: What is the timeline, are there customers demanding it?

BM: There was an enthusiastic implementation group at the DC

IETF that talked about it. We offered to experiment with it and get

back to them. They were OK with that (Perry Metzger, Jim Bound,

and a Sun guy [didn't get his name]). BM thinks that as long as we show forward progress they will be probably OK. The IPv6 range 3ff3:00/24 has been delegated for use by the root-server system.

DNSSEC

DNSSEC is still under development in BINDv9. The root server community needs to look at the
signing issues more than the software implementation issues. ISC has been contacted by CERTCO (certco.com) who holds a patent on dividing up a single key, so you can have multiple private keys all decryptable with the same public key. It would use a quorum technique for deciding if a zone transfer should be done. CERTCO seems to be willing to share, but wants the certificate business.

BM: Students have done some split key work so there might be a split key technology in the
public domain available. It might still violate the patent.

JM: We need to see what materializes and then need to make a recommendation to ICANN. BM
and DC will follow up.

8. The Root Transition Plan

BM: Suzanne Woolf posted a plan a long time ago -- 9 months or so, to move the distribution server from NSI to ICANN. It is provisionally on hold because ICANN is not quite ready topologically or with infrastructure. They are currently unable to proceed. Suzanne is on a temporary leave of absence; BM has inherited the transition folder now and has picked up a more prominent role in the operation of L. How to finish the transition plan and make it go forward using a distribution master. ICANN wants the whois data
to follow the transition. Time frame is the end of april to get set up. Biggest complaint is they (ICANN) don’t have a 24x7 help desk. Their existing connectivity is OK, will need to be augmented.

PW: Are there any issues on numbering. BM answered no.

RP asked that the latest copy be resent to all operators to ensure

that everyone is looking at the same document. BM will do so.

MK: If the transition occurs, how are outages to be addressed?

BM: That is a weakness in document; you should raise it on

the list.

DK: The distribution server doesn't need 24x7 coverage, the

whois server might.

BM: whois is part of it since the Department of Commerce won't approve the transition without
it.

DK: We can do secondary or mirror sites, don't need 24x7 coverage on the distribution server.

BM: Will send the transition document out again, with 10-day response time.

9. MOP and Other Contractual Process

Mark Bohannan did not call in to present this item, however it was discussed.

JM: Asked if there was consensus among the group that the MOP is OK.

DK: We will sign it if it’s necessary (to sign a physical copy);

we already sent email saying we would sign.

JM: Had a conversation with Mark Bohannon (USDoC) and he wants

progress on this pretty soon.

DK: Thinks it would be totally bad for the root operators

to go one-on-one into negotiations with ICANN.

BM: Suggested moving the discussion to root server list.

MK: What do we have to do to fulfill the MOP? Is it enough

to email saying we agree. MK will send email saying NSI will agree.

10. Multi-Lingual issues in DNS

PW: Some country NICs have started taking registrations and have a technical solution to do
it. Commercial companies too. They are forming a consortium to deal with multi-lingual naming, patching browsers, etc. It is still very early. The consortium to be wc3 type structure. If these islands of development need to integrate with the Internet they will need to integrate with this group. Sounds totally political. PW suggesting thinking of it as new GTLD's.

Next physical meeting, in Pittsburgh at IETF. JM requested an interim meeting via teleconference before INET in Yokohama. We need an announcement to the ICANN board and
the public from RSSAC; the timeline is important.