[dnsext] Re: Time-line for forgery resilience phase #2
Stephane Bortzmeyer
Ólafur Gušmundsson /DNSEXT chair <og...@ogud.com> wrote
a message of 238 lines which said:
> At this point we have following drafts submitted:
http://tools.ietf.org/id/draft-ietf-dnsext-forgery-resilience-07.txt
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Ólafur Guðmundsson
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Dear colleagues
It has been rather quiet on the mailing list on this topic.
So far only 3 people have volunteered to be on the design team.
Nicholas Weaver
Matt Larson
David Blacka
The chairs are looking for a design team that includes people from
different backgrounds and experiences. In particular we are looking
for volunteers from the ISP and non-TLD authorative server side.
(contact me privately if you want to be included, only vetted volunteers
will get the magic email telling them the location of the design team
gathering).
If you think this effort is important, please volunteer, or say on the
mailing list what your "solution space would look like" as a template for
the design team to look at.
In addition if there are operational practices that we should recommend=
please
put them forward as well.
thanks
Olafur
At 15:24 17/10/2008, =D3lafur Gu=F0mundsson /DNSEXT wrote:
>Dear colleagues,
>
>Thank you for taking the suggestions below to heart and following the plan.
>
>At this point we have following drafts submitted:
>=20
>http://tools.ietf.org/id/draft-barwood-dnsext-fr-resolver-mitigations-04.tx=
t
> http://tools.ietf.org/id/draft-reid-dnsext-aleatoric-00.txt
> http://tools.ietf.org/id/draft-weaver-dnsext-fr-comprehensive-00.txt
>=20
>http://tools.ietf.org/id/draft-wijngaards-dnsext-resolver-side-mitigation-0=
0.txt
> http://tools.ietf.org/html/draft-hubert-ulevitch-edns-ping-00
> http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
>
>If we forgot any please reply to this message with the link for the draft.
>
>The forum is now open for discussion.
>We propose that you start a new thread for each subject rather than just=
reply
>to this message, in the Subject line put
> FR: Topic
>
>As far as we can tell the ideas contained in the drafts can be summarized=
into
>following rough categories:
> Packet acceptance
> Data admission
> Data integrity checks
> Attack detection
>
>Please use these words in your messages to facilitate clearer=
understanding.
>Feel free to propose new categories.
>
>In Minneapolis the WG is scheduled to meet on Tuesday afternoon.
>The chairs have asked for a small meeting room on Monday (during one
>of the first 2 sessions) and on Tuesday morning for a "design" team to=
meet.
>If you want to be invited to these meetings send us an e-mail, we want to
>get a broad balance of expertise and experience in that room.
>The "design" team will present the recommendations (if any) at the
>Working Group meeting.
>
> Olafur and Andrew
>
>At 12:22 04/09/2008, =D3lafur Gu=F0mundsson /DNSEXT wrote:
>
>
>>The WG has had 2 months to learn about the issues and kick ideas around.
>>At this point the discussion has reach the point of diminishing returns.
>>The discussion needs to become more focused!
>>
>>The chairs propose following plan to make progress:
>>0. Discussion on namedroppers on ideas without drafts comes to an end.
>> If you need to ask a clarifying question, please put the tag [CLARIFY]=
in
>> your Subject: line.
>>
>>1. By September 30'th everyone that has ideas they want to share
>> should have an ID published.
>> suggested names for drafts: draft-<editor>-dnsext-fr-<name>-xx.txt
>>
>>2. During October the WG will discuss the ideas and recommendations from=
the
>> drafts. Editors are encouraged to update their drafts frequently=
during
>> this window based on the discussions.
>>
>>3. During November the WG will select from the ideas on what to recommend=
as
>> the extended Forgery Resilience approach.
>> The chairs plan to have a special session early in the week at the=
IETF
>> meeting for interested parties to hash out what makes sense.
>> Recommendations from that session will be proposed to the WG at
>> the official WG meeting.
>>
>>4. If the WG does not reach a rough consensus by late November the chairs
>> may form a design team to come up with a recommendation.
>>
>>5. An official WG document(s) will be submitted no later than early
>> December.
>> (we will need editors for this document(s))
>>
>>6. By late January we will have WGLC on the document(s).
>> The document(s) will be advanced to the IESG by March 1'st.
>>
>>Based on this plan, please stop all Forgery=20
>>Resilience (FR) discussion right now.
>>If you are not writing down your FR ideas in a draft,
>>please review and comment on the following WG last calls:
>>
>>http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01190.html
>>http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01430.html
>>
>> Olafur and Andrew
--=====================_68823973==.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<body>
<font size=3D3>Dear colleagues <br>
It has been rather quiet on the mailing list on this topic. <br>
So far only 3 people have volunteered to be on the design team. <br>
<x-tab> </x-tab>Nicholas
Weaver<br>
<x-tab> </x-tab>Matt
Larson<br>
<x-tab> </x-tab>David
Blacka<br>
The chairs are looking for a design team that includes people from<br>
different backgrounds and experiences. In particular we are looking<br>
for volunteers from the ISP and non-TLD authorative server side. <br>
(contact me privately if you want to be included, only vetted
volunteers<br>
will get the magic email telling them the location of the design
team<br>
gathering). <br><br>
If you think this effort is important, please volunteer, or say on the
<br>
mailing list what your "solution space would look like" as a
template for<br>
the design team to look at. <br><br>
In addition if there are operational practices that we should recommend
please <br>
put them forward as well. <br><br>
<x-tab> </x-tab>thanks
<br>
<x-tab> </x-tab>Olafur
<br><br>
At 15:24 17/10/2008, =D3lafur Gu=F0mundsson /DNSEXT wrote:<br><br>
<blockquote type=3Dcite class=3Dcite cite=3D"">Dear colleagues,<br><br>
Thank you for taking the suggestions below to heart and following the
plan.<br><br>
At this point we have following drafts submitted:<br>
<a=
href=3D"http://tools.ietf.org/id/draft-barwood-dnsext-fr-resolver-mitigatio=
ns-04.txt" eudora=3D"autourl">
http://tools.ietf.org/id/draft-barwood-dnsext-fr-resolver-mitigations-04.txt=
</a>
<br>
<a href=3D"http://tools.ietf.org/id/draft-reid-dnsext-aleatoric-00.txt" eudo=
ra=3D"autourl">
http://tools.ietf.org/id/draft-reid-dnsext-aleatoric-00.txt</a><br>
<a=
href=3D"http://tools.ietf.org/id/draft-weaver-dnsext-fr-comprehensive-00.tx=
t" eudora=3D"autourl">
http://tools.ietf.org/id/draft-weaver-dnsext-fr-comprehensive-00.txt</a>
<br>
<a=
href=3D"http://tools.ietf.org/id/draft-wijngaards-dnsext-resolver-side-miti=
gation-00.txt" eudora=3D"autourl">
http://tools.ietf.org/id/draft-wijngaards-dnsext-resolver-side-mitigation-00=
.txt</a>
<br>
<a href=3D"http://tools.ietf.org/html/draft-hubert-ulevitch-edns-ping-00" eu=
dora=3D"autourl">
http://tools.ietf.org/html/draft-hubert-ulevitch-edns-ping-00</a><br>
<a href=3D"http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00" eudora=
=3D"autourl">
http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00</a><br><br>
If we forgot any please reply to this message with the link for the
draft.<br><br>
The forum is now open for discussion.<br>
We propose that you start a new thread for each subject rather than just
reply<br>
to this message, in the Subject line put<br>
FR: Topic<br><br>
As far as we can tell the ideas contained in the drafts can be summarized
into<br>
following rough categories:<br>
Packet acceptance<br>
Data admission<br>
Data integrity checks<br>
Attack detection<br><br>
Please use these words in your messages to facilitate clearer
understanding.<br>
Feel free to propose new categories.<br><br>
In Minneapolis the WG is scheduled to meet on Tuesday afternoon.<br>
The chairs have asked for a small meeting room on Monday (during one<br>
of the first 2 sessions) and on Tuesday morning for a "design"
team to meet.<br>
If you want to be invited to these meetings send us an e-mail, we want
to<br>
get a broad balance of expertise and experience in that room.<br>
The "design" team will present the recommendations (if any) at
the<br>
Working Group meeting.<br><br>
Olafur and Andrew<br><br>
At 12:22 04/09/2008, =D3lafur Gu=F0mundsson /DNSEXT wrote:<br><br>
<br>
<blockquote type=3Dcite class=3Dcite cite=3D"">The WG has had 2 months to le=
arn
about the issues and kick ideas around.<br>
At this point the discussion has reach the point of diminishing
returns.<br>
The discussion needs to become more focused!<br><br>
The chairs propose following plan to make progress:<br>
0. Discussion on namedroppers on ideas without drafts comes to an
end.<br>
If you need to ask a clarifying question, please put the tag
[CLARIFY] in<br>
your Subject: line.<br><br>
1. By September 30'th everyone that has ideas they want to
share<br>
should have an ID published.<br>
suggested names for drafts:
draft-<editor>-dnsext-fr-<name>-xx.txt<br><br>
2. During October the WG will discuss the ideas and recommendations from
the<br>
drafts. Editors are encouraged to update their drafts
frequently during<br>
this window based on the discussions.<br><br>
3. During November the WG will select from the ideas on what to recommend
as<br>
the extended Forgery Resilience approach.<br>
The chairs plan to have a special session early in the week
at the IETF<br>
meeting for interested parties to hash out what makes
sense.<br>
Recommendations from that session will be proposed to the WG
at<br>
the official WG meeting.<br><br>
4. If the WG does not reach a rough consensus by late November the
chairs<br>
may form a design team to come up with a
recommendation.<br><br>
5. An official WG document(s) will be submitted no later than early<br>
December.<br>
(we will need editors for this document(s))<br>
<br>
6. By late January we will have WGLC on the document(s).<br>
The document(s) will be advanced to the IESG by March
1'st.<br><br>
Based on this plan, please stop all Forgery Resilience (FR) discussion
right now.<br>
If you are not writing down your FR ideas in a draft,<br>
please review and comment on the following WG last calls:<br><br>
<a=
href=3D"http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01190.h=
tml" eudora=3D"autourl">
http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01190.html</a>
<br>
<a=
href=3D"http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01430.h=
tml" eudora=3D"autourl">
http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01430.html</a>
<br><br>
Olafur and
Andrew</font></blockquote></blockquote></body>
</html>
--=====================_68823973==.ALT--
bert hubert
circulated. Additionally, some of the criticism I voice below applies
to the original forgery-resilience draft as well.
So take the below with more than a single grain of salt.
Sadly it appears we have not found the magic bullet, where magic bullet is
defined as a clear solution that can help us quickly. This rules out
anything that takes a lot of parties and time to deploy, or anything that is
more of a 'strategy' than a clear cut solution.
0x20 is nice, but breaks some stuff. Repeating queries is nice but breaks
some stuff. Determining if we are under attack is nice, but is a DoS vector
in some circumstances. Getting smart with disregarding parts of answers is
nice, but is not a perfect solution, plus might break some stuff. Etc etc.
Summarising, I think the current state of affairs does not allow us to write
a draft that recommends full solutions. Sadly, the best we can do right now
is standardise things that will give implementors the tools to implement
working strategies, strategies which are unkown right now.
There is some room for a concise document outlining simple things that help
a lot though.
Looking at the drafts below:
> At this point we have following drafts submitted:
> http://tools.ietf.org/id/draft-barwood-dnsext-fr-resolver-mitigations-04.txt
Describes a number of valuable strategies, and mandates some others.
Unsure if it would reach consensus.
> http://tools.ietf.org/id/draft-weaver-dnsext-fr-comprehensive-00.txt
Outlines a lot of theory. Reads like an academic paper. Does not mandate
anything, or at least not in capital letters.
> http://tools.ietf.org/id/draft-reid-dnsext-aleatoric-00.txt
> http://tools.ietf.org/html/draft-hubert-ulevitch-edns-ping-00
Both of these provide a way to add more entropy to a query, making it far
harder to spoof answers. One of these drafts uses a new record type, the
other (mine) a new EDNS0 option. Jim Reid did a great job finding a novel
and very hackish way of stuffing in said entropy.
The interesting thing about the above two drafts is that they only provide a
portal which can be used to develop further spoofing resilience. The
strategy of how to use these methods is left up to the caching nameserver
implementations, and this strategy is therefore free to evolve over time.
> http://tools.ietf.org/id/draft-wijngaards-dnsext-resolver-side-mitigation-00.txt
I find this draft to be concise, and it provides a nice mix between theory,
recommendations and exhortations.
> http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
0x20 is an impressive hack, but does not provide any protection for
numerical domains like '123.', and only two bits for '123.nl'. In this
sense, it is a very limited measure - as it leaves TLDs especially
vulnerable.
What would be good is to slip in somewhere that all responding
implementations MUST do a bitwise copy of the request name. Implementations
are then free to act on the liberty they've gained to assume that complying
responders will do a proper copy.
Summarising, I'd prefer to focus our attention on:
1) Wouter's document, since it is brief and has the potential to reach
consensus.
2) One of the two ways to add entropy to queries (aleatoric,
edns-ping)
An optimum might be reached if Wouter's document would contain a line like
'responders MUST perform a bitwise copy of the query name'. This would open
the door over time for people to rely on 0x20.
Kind regards,
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services