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:
- Contract btwn ICANN/OPS - Louie
- CRAIDA report - Louie
- Distribution Master - mark/bill
- Gen.Arch.
- migration
- whois et.al.
- schedule
- maintance
- Stats - bill, kc, cho
- New Location Criteria - johan
- Audit design - Liman
- V6 - kato
- TSIG - bill
- Homework, scheduling, housekeeping - jun
- AOB - anyone?
- Signing of the root zone, split key testing - bill
- 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.