[rssac-caucus] Second round review on "Technical Analysis of the Naming Scheme Used For Individual Root Servers"
Greetings. The Work Party has made some significant changes to the document at the request of a few folks from RSSAC. The new edition is at: https://docs.google.com/document/d/17eGSbMMo6GbyG8gE4l1uK1LW8Q1iCIouN4PATcVc... The major changes from the last version that Caucus saw are are: - Tightening of the introduction, talking only about what the RSSAC asked the Caucus to look at - Huge changes to the recommendations in Section 7, aiming more on the need for future work - More focused tables in Appendix A Please check all of these carefully and make tracked changes or comments in the document, plus let the list know. We would like this finished in about ten days, by May 5. --Paul Hoffman
Paul and the RSN Work Party, Thank you for this latest version. I have read it and I am very pleased with the tone of the document and the reserved recommendations. The scope of work was certainly a substantial ask, and with investigation it seems entirely premature to make any recommendations of change based on what we know today. I especially like recommendation 7.2. It is finally the shift (IMHO) that is required here in terms of gaining a deeper understanding of resolver behaviours such that should RSSAC at some future point make recommendations for the Root Server System, those changes are well grounded and cognisant of the true technical impact(s) on resolvers. Well done. Terry
On 27 Apr 2017, at 9:32 AM, Paul Hoffman <paul.hoffman@icann.org> wrote:
Greetings. The Work Party has made some significant changes to the document at the request of a few folks from RSSAC. The new edition is at: https://docs.google.com/document/d/17eGSbMMo6GbyG8gE4l1uK1LW8Q1iCIouN4PATcVc...
The major changes from the last version that Caucus saw are are: - Tightening of the introduction, talking only about what the RSSAC asked the Caucus to look at - Huge changes to the recommendations in Section 7, aiming more on the need for future work - More focused tables in Appendix A
Please check all of these carefully and make tracked changes or comments in the document, plus let the list know. We would like this finished in about ten days, by May 5.
--Paul Hoffman
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
On Wed, Apr 26, 2017 at 9:22 PM, Terry Manderson <terry@terrym.net> wrote:
Paul and the RSN Work Party,
Thank you for this latest version. I have read it and I am very pleased with the tone of the document and the reserved recommendations. The scope of work was certainly a substantial ask,
I have no useful comment (yet), other than to pillory Terry for using ask as a noun. I hope to have comments on the doc by Monday. W
and with investigation it seems entirely premature to make any recommendations of change based on what we know today.
I especially like recommendation 7.2. It is finally the shift (IMHO) that is required here in terms of gaining a deeper understanding of resolver behaviours such that should RSSAC at some future point make recommendations for the Root Server System, those changes are well grounded and cognisant of the true technical impact(s) on resolvers.
Well done.
Terry
On 27 Apr 2017, at 9:32 AM, Paul Hoffman <paul.hoffman@icann.org> wrote:
Greetings. The Work Party has made some significant changes to the document at the request of a few folks from RSSAC. The new edition is at: https://docs.google.com/document/d/17eGSbMMo6GbyG8gE4l1uK1LW8Q1iCIouN4PATcVc...
The major changes from the last version that Caucus saw are are: - Tightening of the introduction, talking only about what the RSSAC asked the Caucus to look at - Huge changes to the recommendations in Section 7, aiming more on the need for future work - More focused tables in Appendix A
Please check all of these carefully and make tracked changes or comments in the document, plus let the list know. We would like this finished in about ten days, by May 5.
--Paul Hoffman
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
-- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
Warren Kumari writes:
On Wed, Apr 26, 2017 at 9:22 PM, Terry Manderson <terry@terrym.net> wrote: I have no useful comment (yet), other than to pillory Terry for using ask as a noun.
I hope to have comments on the doc by Monday.
Yesterday I had, but now I see my nits have suggested by others as well, so that's fine. One thing I'm wondering is why there is such an attention towards preventing an extra roundtrip duirng the primeming phase. A resolver should only do ythe primimng once in its life time so I don;t think an extra roundtrip will hurt the performance that much. jaap
Hi Paul and Caucus, A side bar discussion elsewhere came around to this document, and it highlighted something I hadn't considered. I would like to suggest some changes: Terminology Node re-delegation attack – These attacks, which were described almost a decade ago, potentially allow an attacker to poison the cache of a recursive resolver much more quickly than the well-known “Kaminsky attack”. Node re-delegation attacks hypothetically affect the resolution of all zones in resolvers that do not validate, and all unsigned zones in validating resolvers. [1] [1] https://www.sec-consult.com/fxdata/seccons/prod/downloads/whitepaper-dns-nod... ** my rationale, 1. after reading the cited document I find it difficult to seperate it's method and the kaminsky attack. This is precisely why I would like to see the citation. 2. since this is the topic of one of the recommendations I feel the current wording (terminology) is a confirmation of the attack, even before ascertaining its validity. So therefore I propose the recommendation text: Further study is required to understand if the current infrastructure is susceptible to various cache poisoning attack-scenarios including the cited node re-delegation attack and, if so, what the effects of such attacks might be. Understanding these risks is necessary to assess the risk of changing the current root naming infrastructure. Any study conducted in this area should also be accompanied with proof-of-concept code so that it can be observed and further studied by the RSSAC Caucus and other researchers. Cheers Terry
On 27 Apr 2017, at 11:22 AM, Terry Manderson <terry@terrym.net> wrote:
Paul and the RSN Work Party,
Thank you for this latest version. I have read it and I am very pleased with the tone of the document and the reserved recommendations. The scope of work was certainly a substantial ask, and with investigation it seems entirely premature to make any recommendations of change based on what we know today.
I especially like recommendation 7.2. It is finally the shift (IMHO) that is required here in terms of gaining a deeper understanding of resolver behaviours such that should RSSAC at some future point make recommendations for the Root Server System, those changes are well grounded and cognisant of the true technical impact(s) on resolvers.
Well done.
Terry
On 27 Apr 2017, at 9:32 AM, Paul Hoffman <paul.hoffman@icann.org> wrote:
Greetings. The Work Party has made some significant changes to the document at the request of a few folks from RSSAC. The new edition is at: https://docs.google.com/document/d/17eGSbMMo6GbyG8gE4l1uK1LW8Q1iCIouN4PATcVc...
The major changes from the last version that Caucus saw are are: - Tightening of the introduction, talking only about what the RSSAC asked the Caucus to look at - Huge changes to the recommendations in Section 7, aiming more on the need for future work - More focused tables in Appendix A
Please check all of these carefully and make tracked changes or comments in the document, plus let the list know. We would like this finished in about ten days, by May 5.
--Paul Hoffman
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
Paul, Terry and I talked about this in person. Please consider his proposed text in lieu of what I owed you for that recommendation. DW
On May 4, 2017, at 2:24 PM, Terry Manderson <terry@terrym.net> wrote:
Hi Paul and Caucus,
A side bar discussion elsewhere came around to this document, and it highlighted something I hadn't considered.
I would like to suggest some changes:
Terminology
Node re-delegation attack – These attacks, which were described almost a decade ago, potentially allow an attacker to poison the cache of a recursive resolver much more quickly than the well-known “Kaminsky attack”. Node re-delegation attacks hypothetically affect the resolution of all zones in resolvers that do not validate, and all unsigned zones in validating resolvers. [1]
[1] https://www.sec-consult.com/fxdata/seccons/prod/downloads/whitepaper-dns-nod...
** my rationale, 1. after reading the cited document I find it difficult to seperate it's method and the kaminsky attack. This is precisely why I would like to see the citation. 2. since this is the topic of one of the recommendations I feel the current wording (terminology) is a confirmation of the attack, even before ascertaining its validity.
So therefore I propose the recommendation text:
Further study is required to understand if the current infrastructure is susceptible to various cache poisoning attack-scenarios including the cited node re-delegation attack and, if so, what the effects of such attacks might be. Understanding these risks is necessary to assess the risk of changing the current root naming infrastructure. Any study conducted in this area should also be accompanied with proof-of-concept code so that it can be observed and further studied by the RSSAC Caucus and other researchers.
Cheers Terry
On 27 Apr 2017, at 11:22 AM, Terry Manderson <terry@terrym.net> wrote:
Paul and the RSN Work Party,
Thank you for this latest version. I have read it and I am very pleased with the tone of the document and the reserved recommendations. The scope of work was certainly a substantial ask, and with investigation it seems entirely premature to make any recommendations of change based on what we know today.
I especially like recommendation 7.2. It is finally the shift (IMHO) that is required here in terms of gaining a deeper understanding of resolver behaviours such that should RSSAC at some future point make recommendations for the Root Server System, those changes are well grounded and cognisant of the true technical impact(s) on resolvers.
Well done.
Terry
On 27 Apr 2017, at 9:32 AM, Paul Hoffman <paul.hoffman@icann.org> wrote:
Greetings. The Work Party has made some significant changes to the document at the request of a few folks from RSSAC. The new edition is at: https://docs.google.com/document/d/17eGSbMMo6GbyG8gE4l1uK1LW8Q1iCIouN4PATcVc...
The major changes from the last version that Caucus saw are are: - Tightening of the introduction, talking only about what the RSSAC asked the Caucus to look at - Huge changes to the recommendations in Section 7, aiming more on the need for future work - More focused tables in Appendix A
Please check all of these carefully and make tracked changes or comments in the document, plus let the list know. We would like this finished in about ten days, by May 5.
--Paul Hoffman
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
Hi Paul and the RSN Work Party, I'm sorry that I did not follow the drafting process very closely untill recently. After reviewing the latest version, I think it is well composed and balanced. And I do leave some comments and minor edits in the Google doc. I would like to put some points donw in this mail for discussion. I hope it will be helpful. * Regarding the fragmentation, the concern can be relieved by optionally excluding partially or all glues in the additional section at the cost of increasing the round-trip delay. IMHO, the round-trip delay or additional queries for priming or DNSSEC priming is not a big issue because priming query is quite rare and only emitted when resolver bootstraps itself. * In section 5.5 "Names Delegated to Each Operator", the additional section of the priming response may not return all A and AAAA glue. It depends on the DNS implementations. AFAIK, Bind9 only returns the A and AAAA glue of responding root server. It is in that If the zones hosted by root server A is not authoritative for the name of root server B, the additional section of priming response from A will not include the glue of B. It is exactly the case in Yeti DNS Project where normal domain name is used as the name of root server. I think it is also true for "a.root-servers" and the case of short label "a". * In addition, #5.5 makes it possible to incrementally deploy DNSSEC support for individual root names. The DNSSEC deployment overhead is durable I think if you intend to ask for multiple participants to run the root system. In contrary, it introduces diversity to the system. * If possbile, i would like to make a recommandation on : Study the impact of additional queries after priming exchange. It is possible that by adding addtional queries, it will make it easier to balance the priming performance and response size limitation. Again, thanks Paul and other contributors of this document. It's an excellent piece of work. Cheers, Davey On 27 April 2017 at 07:32, Paul Hoffman <paul.hoffman@icann.org> wrote:
Greetings. The Work Party has made some significant changes to the document at the request of a few folks from RSSAC. The new edition is at: https://docs.google.com/document/d/17eGSbMMo6GbyG8gE4l1uK1LW8Q1iC IouN4PATcVcRr8/edit
The major changes from the last version that Caucus saw are are: - Tightening of the introduction, talking only about what the RSSAC asked the Caucus to look at - Huge changes to the recommendations in Section 7, aiming more on the need for future work - More focused tables in Appendix A
Please check all of these carefully and make tracked changes or comments in the document, plus let the list know. We would like this finished in about ten days, by May 5.
--Paul Hoffman
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
On May 5, 2017, at 1:17 AM, Davey Song <songlinjian@gmail.com> wrote:
* Regarding the fragmentation, the concern can be relieved by optionally excluding partially or all glues in the additional section at the cost of increasing the round-trip delay. IMHO, the round-trip delay or additional queries for priming or DNSSEC priming is not a big issue because priming query is quite rare and only emitted when resolver bootstraps itself.
* In section 5.5 "Names Delegated to Each Operator", the additional section of the priming response may not return all A and AAAA glue. It depends on the DNS implementations. AFAIK, Bind9 only returns the A and AAAA glue of responding root server. It is in that If the zones hosted by root server A is not authoritative for the name of root server B, the additional section of priming response from A will not include the glue of B. It is exactly the case in Yeti DNS Project where normal domain name is used as the name of root server. I think it is also true for "a.root-servers" and the case of short label "a".
* In addition, #5.5 makes it possible to incrementally deploy DNSSEC support for individual root names. The DNSSEC deployment overhead is durable I think if you intend to ask for multiple participants to run the root system. In contrary, it introduces diversity to the system.
These all seem like topics for the next round of study.
* If possbile, i would like to make a recommandation on : Study the impact of additional queries after priming exchange. It is possible that by adding addtional queries, it will make it easier to balance the priming performance and response size limitation.
Can you say more about "impact"? Impact for whom? --Paul Hoffman
The addtional round-trip delay was mentioned 3 times and is listed as a concerns in table of section 6. My argument is that it is not a big concern, because the priming query is rare and the delay is trivial compared to the concern of fragmentation or other complexity. I think people go too far to avoid multiple queries and struggle with packet size limitation. An additional recommandation on this may be not necessary, but we can leave a note somewhere to lower the concern on addtional round-trip delay by multiple queries after priming, if my suggestion is accepted. Davey On 5 May 2017 at 23:19, Paul Hoffman <paul.hoffman@icann.org> wrote:
On May 5, 2017, at 1:17 AM, Davey Song <songlinjian@gmail.com> wrote:
* Regarding the fragmentation, the concern can be relieved by optionally excluding partially or all glues in the additional section at the cost of increasing the round-trip delay. IMHO, the round-trip delay or additional queries for priming or DNSSEC priming is not a big issue because priming query is quite rare and only emitted when resolver bootstraps itself.
* In section 5.5 "Names Delegated to Each Operator", the additional section of the priming response may not return all A and AAAA glue. It depends on the DNS implementations. AFAIK, Bind9 only returns the A and AAAA glue of responding root server. It is in that If the zones hosted by root server A is not authoritative for the name of root server B, the additional section of priming response from A will not include the glue of B. It is exactly the case in Yeti DNS Project where normal domain name is used as the name of root server. I think it is also true for "a.root-servers" and the case of short label "a".
* In addition, #5.5 makes it possible to incrementally deploy DNSSEC support for individual root names. The DNSSEC deployment overhead is durable I think if you intend to ask for multiple participants to run the root system. In contrary, it introduces diversity to the system.
These all seem like topics for the next round of study.
* If possbile, i would like to make a recommandation on : Study the impact of additional queries after priming exchange. It is possible that by adding addtional queries, it will make it easier to balance the priming performance and response size limitation.
Can you say more about "impact"? Impact for whom?
--Paul Hoffman
participants (6)
-
Davey Song -
Jaap Akkerhuis -
Paul Hoffman -
Terry Manderson -
Warren Kumari -
Wessels, Duane