Internet Corporation for Assigned Names and Numbers

RSSAC Meeting, Salt Lake City, UT

RSSAC meeting 11 - multiple draft notes
Salt Lake City, Utah, US

Jun Murai called the meeting to order.
Bill Manning & Cathy Murphy took notes

(Two sets of notes are presented here)

Attendees:

"I" lars liman, johan ihren
"B" bill manning
ARIN ray plzak, cathy murphy
CAIDA km claffy, nevil brownlee
kenjiria cho - wide
"M" akira kato, jun murai
ICANN louie touton
IAB harold alvestrand
"F" paul vixie
"L" suzanne woolf
"D" gerry schneiring
"G" randy runkles
"A&J" matt larson, brad verd
APNIC george michaelson, anne lord
RIPE MiR
"H" Howard Kash (telephone)

Agenda Items:

  1. Contract btwn ICANN/OPS - Louie
  2. CRAIDA report - Louie
  3. Distribution Master - mark/bill
  4. Gen.Arch.
  5. migration
  6. whois et.al.
  7. schedule
  8. maintance
  9. Stats - bill, kc, cho
  10. New Location Criteria - johan
  11. Audit design - Liman
  12. V6 - kato
  13. TSIG - bill
  14. Homework, scheduling, housekeeping - jun
  15. AOB - anyone?
  16. Signing of the root zone, split key testing - bill
  17. Discuss CRAIDA report, esp. security - jun

1. Contract:

  • Louie: 6-8 wks ago, new MOUs sent to OPS management & legal teams.
  • F & B are close, need to hear from others
  • johan - single text or different per operator?
  • louie - minor differences based on organization.
  • gerry - there are problems getting the MOU through legal. they think its a contract. section H may be a sticking point.
  • bill - what is the status of G & H with regards to the MOU?
  • louie - sent to DoC, Ted Kassinger (GC) who said he would work the issues with other agencies.
  • randy & howard have heard nothing on this from their mgmt.

2. CRAIDA - two reports, on 31Dec2001 and next in Sept.2002

  • First on Distribution Master, DoC needs to approve then; Second to deal w/ statement of work in CRADIA.
  • Recent focus on security - more focus on security even if it is
  • late. say EOM Jan 2002.
  • jun - is the scheduling critical? Do they want something by 31dec?
  • What are the bullet points? - bill
  • louie & jun - this agenda + security and add a recovery plan.
  • bill - since this will be a USG report, how much detail?
  • suzanne - a public document?
  • louie - probably not. may wish to create a public summary like tht recent presentation done at the ICANN mtg in MDR. The report can be small (8 pgs) if dense. likely larger.
  • louie - it could be two documents

Commentary:

LT: Try to come up with structure of points that we agree to, then ship outline to DoC and add comment that RSSAC desires that this not be made public because ... and wait for them to respond.

Jun: For report, need to cover all items, but especially focus on how we'll come up with a monitoring system, and what the documentation will be.

stats: - cho

"A Study on the Performance Impact of Root nameserver ___"
[Question raised about this slide:]

Next step

  • experiment phase - Feb 2002
    -- test s by a small group of volunteers
  • oper phase - Apr 2002
    -- wide are long term measurement
  • report at 54th ietf, July in Yokohama

BM: Do you consider 3 mos a long term project? (Now to April)

Kenja: No, will last longer, probably a couple of years.

Placement: - kc
picking locations....

"Picking root name server locations monitoring, analysis & visualization"

KC: Are any of the roots measuring "peak" load, per RFC 2870 section 2.3?

BM: Some are doing that, but its in root-ops, haven't percolated up to rssac yet.

KC: Lots of questions like that, won't continue asking [refer to slides]

Brief summary: [only thing that could get better is to get this up at more sites, preferrably at least 10 sites.]

BM is also doing some stuff.

BM: Doing with WIDE; e.g. the work with Cho.

KC: Nevil's stuff looks at the client side, passive listening; this other monitoring originates at the roots and goes out to the net.

Loading: nevil

nevil - (presumption that servers are only root)

AK: yes. - but we should do logfile analysis.

LT: none of these nubmers meet the 3x loading spec in 2870.

LT: Related topic. None of data presented goes to the issue of robustness, which is important premise of the root server design.

KC: Who checks that? (that per rfc 2870, should handle 3x load)

PV/LT: roots check that.

LT: another complicating factor: 2870 says "peak" load - what does that mean? Avg daily load or crisis peak load?

BM: What is crisis peak?

ML: See scary spikes; is that considered peak?

BV: e.g., if MS crashes.

LT: Best they could figure is that 7K is peak, about 20K is 3x-peak

KC: Please make public - would help figure out how to make better.

LL: Could also make someone figure out how to hurt the system.

LT: Has anyone actually tested at 20K?

BM: Yes. Recently replaced hardware. During that, had opportunity to test multiple platforms using something in bind9 called query-perf

Jun: Could we make this available to researchers?

BM: Could, but the h/w is not static, or not as static as the measurement people would like. In fact, sometimes put in h/w know will not handle load because we know others can handle the load in the emergency.

Jun - would like to have better communication w/ measurement folks.

ML: How many recursive nameservers are these coming from?

Nevil: Probably about 20; 12 ns and 2-3 seconds for each.

BM: Note that identification about who has which server is incorrect in Nevils data.

NB: Meet afterwards to get it straightened out.

GGM: How much path richness?

NB: fairly diverse.

LT: Only plotting DNS queries?

NB: Yes, only looking at queries that are answered.

RR: Any info pre- Sept 11?

NB: No.

AK: Do you have any other statistics ? Info not considered root server measurements..

NB: KC answered that; proposal with Jun.

AK: Does the data distinguish TLDs at roots?

BM: Some of the root servers are still authoritative for TLDs.

NB: No, doesn't distinguish.

AK: Will you be doing more to isolate root queries?

NB: Shouldn't matter since doesn't care about what is being asked.

Only matters how well it performs.

- henk for RIPE data (not present - MIR went to look...)

(while waiting)

renumbering servers - protable prefixes or no?

GGM: [to KC] longer term issue, committing to a location depends on current economic decision.

KC: Not convinced that making a decision about where a root will be doesn't have to be a 5-10 year decision; should be able to do in one month.

BM: Could do with a small number of roots.

KC: Not convinced that we can't move roots more often. It would be a lot easier than doing the predictions for 5-10 years out.

ML: All roots on swamp space; could pick up and move easily enough

BM: If prefix is static, a lot harder move. If root keeps IP, easier to do.

ML: Yeah, that's what I said.

BM: Last root to move renumbered (M)

Lars:

[Lots of back and forth about portability versus new prefix. Some ISPs don't want to route the ... missed who said what]

Matt: Not arguing a particular point, just pointing out the feasibility of portablity if all roots are on legacy /24 space.

Brad: gTLD numbered in /24 and, though difficult to transition, once deployed was very successful.

PV: using /24s for GTLDs is questionable net citizenship. Everyone else wants to do the same this. Good enough for gTLDs, good enough for us. But roots can't go there, do that.

Jun: Need to move on.

No RIPE date.

KC: DNSMEAS - IRTF-bof. vern seems to be driving it.

Louie - need something for the CRAIDA rpt on robustness.

e.g. %of servers offline and the service works.

BV: What do you want? How many roots do you have to take out?

KC: eleven

LT: Always going to be deficiencies in the type of data, so what's going to be credible to the data. Not suggesting turning off 8 roots.

KC: What's a metric for robustness?

LT: Let me approach differently. We've defended the system on the basis of diversity (KC: which is not defined). All premised on the idea that there is so much excess capacity that we could loose 2/3's of the roots and still operate ok. You should tell me what/how to measure it.

BM: WIDE simulation might work + load measurements (extrapolate queryrate to BW.

Jun - improve the relationship w/ the 3rd party measurements.

3. Distribution Master issues

  • Waiting on schedule. Need first report before moving. Aproposed sched may be ideal. Hold off on "shadow" until the first move is done.
  • Mark & Bill to work with Louie on building a proposed sched.

10. New location criteria

From root-ops: RTT is a lead criteria - we may need others.

WIDE project only measures RTT - not robustness.

johan - if we degrade stability, we should rethink.

louie - A point - a theme - the way this group is organized is the correct way. Flexable is best. Does the potential candidate bring things to the group? Split the problem into technical & political/respect.

11. Audit design

Many people want audits. we can wait or we can do it ourselves. Liman will start working on this after IETF.

12. V6.

need testing with non-bind code.`

adding two AAAA records. may need to wait on edns0 deployment.

do not wish to share a single AAAA btwn servers.

may touch on this in DNSOPS this week. - Johan

can we get a schedule for deployment? - bill

Brad 2 Louie - can we do this? Louie - yes.

brad - will need registry SOP changes.

Bill - we need a workplan & draft timeline

kato - plan for 2 servers initally.

kato/jun - should have something done prior to march.

johan - need testing before changing hints file.

13. TSIG

BM: Mark, Susan, and Bill put together a draft on how to use TSIG. BM polished it and pushed testing. All roots have tested TSIG and all are nearly ready to put into production. The plan was posted to RSSAC, suggesting that it would go into use by mid-January. Read that! Post concerns to RSSAC list. Good thing toput in CRADA report. TSIG ready to go. Proposed date is 10jan2002.

BM: On security related, discussed desireaility of getting the root zone signed, even though none of children would be signed, since ICANN owns that zone, would like to begin that process.

LT: Ok, but please send an explanation.

--

Next mtg, rssac 11 - 17march in Minn.

--

V6.

adding two AAAA records. may need to wait on edns0 deployment.

do not wish to share a single AAAA btwn servers.

may touch on this in DNSOPS this week. - Johan

can we get a schedule for deployment? - bill

Brad 2 Louie - can we do this? Louie - yes.

Bill - we need a workplan & draft timeline

---

TSIG

Prepared report & ready to go. Proposed to do this 10jan2002.

Need to sign root. - Open dialog w/ ICANN.

--

Next mtg, 17march in Minn.

====================================================================

Jun Murai called the meeting to order. Would like at least 2 people to

take notes.

Volunteers? Bill Manning and Cathy Murphy.

Introductions

Lars Liman

Johan

Bill Manning

Ray Plzak, ARIN

Cathy Murphy, ARIN

KC Claffy, CAIDA

Neville Brownlee, CAIDA

Kenjoro Jo, WIDE

Kato __,

Louis Touton, ICANN

Harald Alvestrand, IETF Chair

Susan Wolf, "L"

Paul Vixie, "F"

Jerry "D"

Randy "D"

Matt Larson, "A" & "J"

Brad Verd, "A" & "J"

Jun Murai "M"

Howard Cash "H" (on the phone)

George Michaelson, APNIC

Anne Lord, APNIC

1. Agenda Bashing

Contract btwn Ops/ICANN (louis)

CRADA report overview (louis)

Distribution server (mark, bill)

-General architecture

-Distribution server migration

-Shifting (including whois, etc)

-Schedule

-Maintenance procedure

Statistics and measurements (bill: kc,cho)

New location criteria (johan)

Audit design (liman)

IPv6 (kato)

tsig (bill)

Homeworks, scheduling,housekeepings(jun)

Anything else?

BM - Lump signing of the root under TSIG (discussed earlier)

Jun - Also discuss CRADA Report re: security from Root-ops

---

Louis Touton:

re: Contract - sent out 6-8 weeks ago, MOUs sent out to operators'

legal

depts

- spoken with F and B about questions, no one else had Qs; please

remind

mgmt

to get back to Louis ASAP.

Johan: still one text or different for each operator?

LT: same, but config diff and little wording changes, but not trying to

have

absolute sameness; (that would be impossible to achieve)

Jun: Anyone have problem with different contracts?

LT: Any ideas on how long it will take to get MOUs signed?

Jerry: Problem getting thru legal depts.

LT: It's an MOU; not supposed to create contract, rather supposed to

create a

process

- If lawyers got a hold of section H, they would try to cancel it.

BM: Concern re MOU and G and H b/c those are "special cases"; what is

the

status of those special cases?

LT: Sent those MOUs to the Dept of Commerce and haven't heard back

Randy: Please elaborate.

LT: DoC, Ted Kassinger (General Counsel), thought that the

best way to get done is to send to him, and he will work

thru working with other govt depts to get done -- new to you?

Randy: Yes.

BM [asking Howard (on phone)]: Have you heard anything about this?

Howard: Problems hearing what's the question?

LT: Heard from DoC?

Howard: No

LT: re CRADA report

Original idea was that there would be two reports:

1) distribution of servers, which DoC wd look at and approve. Then do

2) a more comprehensive plan and how everything fits into the big

picture.

Recent increase/desire to focus on security has changed what USG has

decided

they want. The first report should be more comprehensive, even if it

doesn't

meet the Dec 31 2001 deadline.

Jun: Scheduling?

LT: End of January to have a more comprehensive first report. But if

that is

unrealistic, end of February would probably be okay.

Jun: Still wants to produce something by Dec 31.

BM: Altho all are participating in CRADA, he would look to Jun or LT to

send

to the rssac list bullet points that the report should cover.

LT: In view of the schedule, that's a lot of work to do in a short

time.

Wd prefer to discuss and decide here what those bullet pts should be.

[Joined by Andre/CAIDA and Mirjam/RIPE NCC]

Jun: Nothing new. Bullets are the same as already discussed:

- distribution of root NSs

- DNSSEC

The issues are the same that we want to define.

1/3 of reqts are ... also distribution

[Difficulty following Jun.]

LT: The bullets on the agenda, distribution of root NS and going down

the list,

are a good starting point. One additional question: emergency plan --

what happens if something goes wrong? Know that that is dependent on

what

happens, but would like the group to start thinking about it and

include

in report.

BM: Second piece, since report going to USG, how big (detailed)

do they want the report?

LT: "Impressive looking" but if the content is really good, it can be

only 8 pages.

SW: Will this be made public?

LT: No, but should probably have a public summary to accompany it,

something

along the lines of the recent presentation to ICANN at Marina del Rey.

BM: Are you speaking for the DoC?

LT: No, wouldn't presume to speak for them, but this is what they've

told me.

BM: ...

LT: Try to come up with structure of points that we agree to, then ship

outline to DoC and add comment that RSSAC desires that this not be made

public because ... and wait for them to respond.

Jun: For report, need to cover all items, but especially focus on how

we'll come

up with a monitoring system, and what the documentation will be. At

same

time, we

don't have idea how we'll use these monitoring things. So, would like

to

have

KC and CAIDA speak first.

---

Kenja (CAIDA)

"A Study on the Performance Impact of Root nameserver ___"

[Question raised about this slide:]

next step

- experiment phase - Feb 2002

-- test s by a small group of volunteers

- oper phase - Apr 2002

-- wide are long term measurement

- report at 54th ietf, July in Yokohama

BM: Do you consider 3 mos a long term project? (Now to April)

Kenja: No, will last longer, probably a couple of years.

BM: Please provide slides in html to BM for Rssac meeting notes.

Jun: Other discussion, questions?

LT: Questions better left until after KC talks.

---

KC:

"Picking root name server locations monitoring, analysis &

visualization"

KC: Are any of the roots measuring "peak" load, per 2.3?

BM: Some are doing that, but its in root-ops, haven't percolated up to

rssac yet.

KC: Lots of questions like that, won't continue asking [refer to

slides]

[only thing that could get better is to get this up at more sites,

preferrably at least 10 sites.]

BM also doing some stuff

BM: Doing with WIDE; let them discuss.

KC: Nevil's stuff looks at the client side, passive listening; this

other

monitoring originates at the roots and goes out to the net.

[Now Neville will present on "real" data.]

---

Neville Brownlee "Measuring DNS Server Performance"

Matt: How many recursive nameservers are these coming from?

NB: Probably about 20; 12 ns and 2-3 seconds for each.

BM: Note that identification about who has which server is incorrect.

NB: Meet afterwards to get it straightened out.

GGM: How much path richness?

NB: fairly diverse.

LT: Only plotting DNS queries?

NB: Yes, only looking at queries that are answered.

Randy: Any info pre- Sept 11?

NB: No.

Kato: Do you have any other statistics ? Info not considered root

server

measurements..

NB: KC answered that; proposal with Jun.

Kato: Does the data distinguish TLDs at roots?

BM: Some of the root servers are still authoritative for TLDs.

NB: No, doesn't distinguish.

Kato: Will you be doing more to isolate root queries?

NB: Shouldn't matter since doesn't care about what is being asked.

Only matters how well performs.

KC: Do that by looking at the logs; strongly advise that shouldn't

confuse

response from payload.

LT: ...

KC: Skitter is just doing light-weight traceroutes; not determining the

sites

to probe.

LT: Info is largely dependent on where the looking is coming from. B

looks

great from UCSD.

KC: Yes, need to take measurements from other sites.

Matt: Is it useful to do near roots versus away from roots?

NB: If too close to roots, not going to be as interesting. Might be

more

interesting from the periphry.

KC: Perhaps from proposed location of root?

LT: Related topic. None of data presented goes to the issue of

robustness, which

is important premise of the root server design.

KC: Who checks that? (that per rfc 2870, should handle 3x load)

PV/LT: roots check that.

LT: another complicating factor: 2870 says "peak" load - what does that

mean?

Avg daily load or crisis peak load?

BM: What is crisis peak?

Matt: See scary spikes; is that considered peak?

Brad: e.g., if MS crashes.

LT: Best they cd figure is that 7K is peak, about 20K is 3x-peak

KC: Please make public - wd help figure out how to make better.

Lars: Cd also make someone figure out how to hurt.

LT: Has anyone actually tested at 20K?

BM: Yes. Recently replaced hardware. During that, had opportunity to

test

multiple platforms using something in bind9 called query-peak. (?)

Jun: Could we make this available to researchers?

BM: Could, but the h/w is not static, or not as static as the

measurement people

would like.

BM: In fact, sometimes put in h/w know will not handle load b/c know

others can handle the load.

Jun: Would like to hear about RIPE data.

KC: Me too. Could you call Henk?

GGM: [to KC] longer term issue, committing to a location depends on

current

economic decision.

KC: Not convinced that making a decn about where a root will be doesn't

have

to be a 5-10 year decision; sd be able to do in one month.

BM: Cd do with a small number of roots.

KC: Not convinced that can't move roots more often. It wd be a lot

easier

than doing the predictions for 5-10 years out.

Matt: All roots on swamp space; cd pick up and move easily enough

BM: If prefix is static, a lot harder move. If root keeps IP, easier to

do.

Matt: Yeah, that's what I said.

BM: Last root to move renumbered (M)

Lars:

<Lots of back and forth about portability versus new prefix.

Some ISPs don't want to route the ... missed who said what>

Matt: Not arguing a particular point, just pointing out the feasibility

of

portablity if all roots are on legacy /24 space.

Brad: gTLD numbered in /24 and, though difficult to transition,

once deployed was very successful.

PV: using /24s for GTLDs is questionable net citizenship. Everyone else

wants

to do the same this. Good enough for gTLDs, good enough for us.

But roots can't go there, do that.

Jun: Need to move on.

KC: Still want to hear more about what gTLDs do.

Brad: Do after the meeting.

KC: But thinks it is the same thing; wants to hear about that.

Mirjam: Couldn't get a hold of Henk; Olaf doesn't know about it, so

RIPE

can't comment now.

KC: Note the OPS-Measurement BOF on Wed (being done by Vern). Wd like

to

see

operators there.

LT: Coming back one last time to robustness issue. Wd like the report

to

include that robustness has been tested out.

SW: Neville's data shows that,

if you are talking about taking out the best perf server in

the area.

Jun: What kind of data do you want?

LT: To be able to say that there exists reliable, test data that proves

out

the robustness model of the root server system.

Jun: Need to explore further.

---

Let's move on.

Brad: What do you want? How many roots do you have to take out?

KC: 11

LT: Always going to be deficiencies in the type of data, so what's

going

to be credible to the data. Not suggesting turning off 8 roots.

KC: What's a metric for robustness?

LT: Let me approach differently. We've defended the system on the basis

of diversity (KC: which is not defined). All premised on the idea that

there is so much excess capacity that we could loose 2/3's of the roots

and still operate ok. You should tell me what/how to measure it.

BM: Cutting off. Only 15 minutes left and lots of topics still to

cover.

Jun: What's most important to discuss?

BM: Already talked about infrastructure; that's ok.

Brad: Last mtg was talk of security,

BM: Talk of moving all roots and whois for roots off to ICANN/IANA.

Brad: ?? <missed his comment>

LT: Talked with former VeriSign employee about this, but haven't talked

recently.

Brad: Ok.

BM: Wd like to revisit status, get a backup somewhere else. What the

holdup?

Scheduling?

LT: Hold up is that need to provide first report. Schedule is

proposed schedule.

Jun: ... not this group?

LT: right,

Jun: Sources has already been discussed in group (root-ops?) and will

put

together, discuss with Louis.

---

Jun: next item: New location criteria

Johan: Discussed at last meeting. one parameter is RTT. need to have

other

parameters. Discussing what those will be.

Jun: we can discuss other parameters forever. We need to decide,

today's

issue,

to decide on what those will be, to suggest to ICANN so that a decision

can be made.

Johan: in stats presentation (re: Japan), they did not look at

robustness issues,

only measured things that could be meas'd ,e.g., RTT. But robustness sd

be

discussed and measured. If we degrade stability, taking a step back.

LT: One comment on this: the way this group and root servers are

organized

is correct. In Marina del Rey, there were suggestions to the contrary.

Daniel Karrenberg made this point: does the location contribute to the

overall

diversity of the system.

BM: There was a suggestion that there be two components:

1) technolical - geographic diversity component

2) political - operator diversity - who's running the root? will that

get along with

the group?

LT: Heard more than that. Is it a diverse viewpoint being brought in?

Don't want

all root operators to think alike.

BM: As long as they all respect the operator.

Jun: That will probably be included anyway based on previous

discussions.

So, time-frame based on CRADA, we have certain criteria and could

include

original criteria in report. We know that wd not be complete, but

submit

with that assumption.

---

Jun: Next topic: Audit design (Liman)

- Cd wait for someone to require this of us, but better if we come up

with this ourselves. So we'd better start working on this. Need someone

to start working on this. Liman?

Liman: Sure, right after the IETF.

---

Next topic: v6?

Kato: Need to try some other implementations than BIND, e.g., MS so

we can test; said that MS implementations do not have v6 yet.

(current status)

Jun: Is there any agenda item about IPv6?

Johan: Yes, likely to say something, but it's a problem for zone

administrators

further down the tree, but doesn't really effect the root.

BM: Before next meeting, could we get implementation plan for the root?

Brad: Is this about getting implementation at the root? Then need

permission from IANA to put AAAA records in the root. Louis, can we?

LT: Yes. No problem if that is what this group suggests.

Brad: Than that's okay with us. Will have to modify database ...

Kato: Will want to do a couple at the root.

BM: If it goes into root, then goes into hints file.

Paul: Yes.

BM: Then I want to put together a plan for putting these in and when.

Brad: How many?

Kato: 2

Paul: Only room for 2. Really long question will take up a lot of

space,

only roomfor two answers.

Brad: if answer is longer, then cut off?

Paul: <missed his comment>

LT: What is your question Bill?

BM: Don't want to happen what happened last time: talked about, but

because

didn't set a timeframe, didn't get anything done. Want timelines so

that

we can measure our progress.

LT: Good idea to do a work plan, but need to identify the limits of the

project.

BM: Kato's document says some of that, but not widely read. Need to

read

and

include in plan.

Jun: (restating suggestion) Provide plan that cd be circulating in the

community

for putting AAAA in root.

Kato: Have plan by next meeting in March?

Jun: Wd like to see something more before than.

Kato: Will try imple on MS, then will know.

Jun: Good to write done.

Johan: Wd advise against adding to hints file, b/c wd like to have

independent

varification first.

Liman: Schedule wd have when that would be done.

----

TSIG

BM: Mark and Susan put together a draft on how to use tsig. BM worked a

little

more on that. All roots have tested TSIG and nearly ready to put into

production. Plan posted to RSSAC, suggesting that it would go into use

by mid-January. Read that! Post concerns to RSSAC list. Good thing to

put in

CRADA report. TSIG ready to go.

On security related, discussed desireaility of getting the root zone

signed,

even tho none of children wd be signed, since ICANN owns that zone,

wd like to begin that process.

LT: Ok, but please send an explanation.

BM: Any concern about using TSIG for zone transfers early next year?

<None.>

Jun:

Schedules:

10th meeting of RSSAC is planned (Minneapolis)

BM: notes to bmanning@isi.edu

Jun: Slides to Jun and Bill.

Stay Connected

  • News Alerts:
  • Newsletter:
  • Compliance Newsletter:
  • Policy Update: