[rssac-caucus] FOR REVIEW: Elements of Potential Root Operators
Dear RSSAC Caucus, On behalf of the work party for RSSAC Workshop 2 Statement 4, attached please find Key Technical Elements of Potential Root Operators. This work party first met on June 23, 2016 and roughly every other week thereafter. For more information on the creation of this work party, please see the section on Evolution from the Report from the 2nd RSSAC Workshop. https://www.icann.org/en/system/files/files/rssac-workshop-26jun16-en.pdf The work party invites you to review this document and provide your feedback by close of business 4 October 2016. Feedback should be sent to the RSSAC Caucus list directly. There will also be two teleconferences held to discuss this document and capture feedback. Doodle polls for exact times forthcoming. September 15th September 22nd Thanks, Andrew
Andrew, At 2016-09-06 20:42:07 +0000 Andrew Mcconachie <andrew.mcconachie@icann.org> wrote:
The work party invites you to review this document and provide your feedback by close of business 4 October 2016.
Feedback should be sent to the RSSAC Caucus list directly.
Interesting document. A bit strange but basically reasonable. ---- One thing that I would like to see is a request that all of the information in this document be public. For example, descriptions of zone distribution architecture. As someone without access to this for current root server operators I have to infer this - I often don't know whether something is broken in the root server system or whether they are merely acting in ways that I didn't expect because I don't know what's going on "under the hood". I realize that this may be out of scope for a technical requirements document, but on the other hand having details available for wider review can result in higher quality service, so I can possibly justify it in a hand-waving way. ;) ---- One minor point about addressing: 3.3.3 Addressing Resources The candidate operator MUST have its own AS number(s) and IPv4 and IPv6 address allocations. It is assumed that IP anycast will be used. If IP anycast will not be used, a technology providing similar or better service levels SHOULD be specified. Provider address space or addresses that cannot be used with anycast are undesirable. The expected production IPv4 and IPv6 address blocks MUST be severable from the candidate’s organization to facilitate emergency or planned transfers. Some RIRs have policies to allocate addresses for "critical use": https://www.nro.net/rir-comparative-policy-overview/rir-comparative-policy-o... This means that potential root server operators probably do not need to have address space in advance of being approved for being a root server operator. ---- In the section on diversity (3.4), I am a little confused. The introduction states: Diversity _within_ a given operator is of benefit, but the candidate will also be evaluated in terms of increased diversity among operators. But within each sub-section it is not at all clear which are intended to apply for a specific operator and which are intended to be used to analyze the root server system as a whole. My concern is that this will naturally lead to "diversity inflation" where each root server operator runs multiple versions of everything without any real benefit, and in fact a potential reduction in reliability of the overall system. (For example, if many root servers run a given DNS software to maximize diversity and there is an unpublished exploit, then it is possible that more root servers are compromised rather than fewer.) Nit: Unbound is a recursive resolver and would be unlikely to be run by a root server operator. :) ---- Nit: "triannual" is easily confused with "triennial", so probably it should just be stated that the root server operator meetings are three times a year. https://en.wiktionary.org/wiki/triannual#Usage_notes Cheers, -- Shane
Shane Kerr <shane@time-travellers.org> writes:
One thing that I would like to see is a request that all of the information in this document be public. For example, descriptions of zone distribution architecture.
I'm confused about whether you're asking about the internal documentation about a particular operator (many (most?) operators of any networks don't like advertising their exact internal architectures for security-through-obscurity related reasons, which we shouldn't argue about here), or are you asking about the root zone distribution system, which is how IANA/ICANN/Versign/and-the-roots get data changes propagated through the system. This last system is fairly well documented publicly I think, no? I would need to go search for the document that describes it, but I'm sure there is one (including how zone changes are reviewed, etc).
As someone without access to this for current root server operators I have to infer this - I often don't know whether something is broken in the root server system or whether they are merely acting in ways that I didn't expect because I don't know what's going on "under the hood".
I'd love to hear an example problem where you don't know of whether something is broken or not based on some external test.
3.3.3 Addressing Resources
The candidate operator MUST have its own AS number(s) and IPv4 and IPv6 address allocations. It is assumed that IP anycast will be used. If IP anycast will not be used, a technology providing similar or better service levels SHOULD be specified. Provider address space or addresses that cannot be used with anycast are undesirable. The expected production IPv4 and IPv6 address blocks MUST be severable from the candidate’s organization to facilitate emergency or planned transfers.
Some RIRs have policies to allocate addresses for "critical use":
https://www.nro.net/rir-comparative-policy-overview/rir-comparative-policy-o...
This means that potential root server operators probably do not need to have address space in advance of being approved for being a root server operator.
I think the paragraph is trying to say "the candidate MUST have address space before coming an operator" not "before getting approved to be one". But it could probably be made more clear?
My concern is that this will naturally lead to "diversity inflation" where each root server operator runs multiple versions of everything without any real benefit, and in fact a potential reduction in reliability of the overall system.
There is certainly a large amount of debate to be had about how much diversity is a good thing. Single points of failure are known to be bad, and it would be bad if everyone ran the exact same version of bind (eg) and FreeBSD (eg). But too much diversity leads to more points of failure, which I suppose could be bad. Though if the system could lose X% of it's deployed infrastructure without visibly affecting the service itself, then high diversity is likely to be helpful since it's unlikely that the entire system could go down if the diversity ensured it would take multiple vulnerabilities to pass the X% threshold. -- Wes Hardaker USC/ISI
Wes, [ I considered breaking this up into separate mails since there are a few topics here, but I am feeling lazy. Sorry. ] At 2016-09-07 08:20:39 -0700 Wes Hardaker <hardaker@isi.edu> wrote:
Shane Kerr <shane@time-travellers.org> writes:
One thing that I would like to see is a request that all of the information in this document be public. For example, descriptions of zone distribution architecture.
I'm confused about whether you're asking about the internal documentation about a particular operator (many (most?) operators of any networks don't like advertising their exact internal architectures for security-through-obscurity related reasons, which we shouldn't argue about here), or are you asking about the root zone distribution system, which is how IANA/ICANN/Versign/and-the-roots get data changes propagated through the system. This last system is fairly well documented publicly I think, no? I would need to go search for the document that describes it, but I'm sure there is one (including how zone changes are reviewed, etc).
Yes, I'm asking about the internal documentation... or rather, documentation about the architecture and design. For example, it appears that some root operators use some sort of push mechanism to get new versions of the root zone out, while others seem to rely on SOA timers. It looks like maybe some have a cron job for this purpose, or maybe they have a push mechanism with some slow-running validation process. It's impossible to know, and I think this could be useful, both because it gives a chance to have more eyeballs on the design as well as being able to understand the behavior of the system. I'm actually not aware of documentation about the IANA/ICANN/Verisign/all-the-roots setup. A quick search didn't really turn up anything more detailed than this: https://www.ntia.doc.gov/legacy/DNS/CurrentProcessFlow.pdf This information may exist though! I would love to see some better pointers (I have already shown that I am crap at finding ICANN documents, so there is a good chance that it is just me)....
As someone without access to this for current root server operators I have to infer this - I often don't know whether something is broken in the root server system or whether they are merely acting in ways that I didn't expect because I don't know what's going on "under the hood".
I'd love to hear an example problem where you don't know of whether something is broken or not based on some external test.
For example, K root normally gets a new copy of the root zone within a few seconds of it being available to the other roots. However, for a 5 day period (2016-07-25 to 2016-07-29) this jumped to being delayed by 1 to 6 minutes. The same seemed to happen to several others... D and I, and even B which is usually updated within a couple seconds... around the same time. I haven't done a full analysis, but it does seem like A did not have the same delay. Since I don't know the details of how the zone is published between Verisign and itself, or between Verisign and the other roots, or between the other roots and their various sites... it's impossible to know what happened here. It could be measurement error on my side (I need to dig into lookup error reports, although clustered errors like that for specific root servers would also be interesting to note), it could be some test of the root operators, it could be some operational change that was reverted or fixed, it could be FSB upgrading their wire taps... without knowing the architecture or design it's just guesswork.
3.3.3 Addressing Resources
The candidate operator MUST have its own AS number(s) and IPv4 and IPv6 address allocations. It is assumed that IP anycast will be used. If IP anycast will not be used, a technology providing similar or better service levels SHOULD be specified. Provider address space or addresses that cannot be used with anycast are undesirable. The expected production IPv4 and IPv6 address blocks MUST be severable from the candidate’s organization to facilitate emergency or planned transfers.
Some RIRs have policies to allocate addresses for "critical use":
https://www.nro.net/rir-comparative-policy-overview/rir-comparative-policy-o...
This means that potential root server operators probably do not need to have address space in advance of being approved for being a root server operator.
I think the paragraph is trying to say "the candidate MUST have address space before coming an operator" not "before getting approved to be one". But it could probably be made more clear?
Perhaps something like: The candidate operator MUST obtain its own AS number and IPv4 and IPv6 address allocations for operating a root server. ...
My concern is that this will naturally lead to "diversity inflation" where each root server operator runs multiple versions of everything without any real benefit, and in fact a potential reduction in reliability of the overall system.
There is certainly a large amount of debate to be had about how much diversity is a good thing. Single points of failure are known to be bad, and it would be bad if everyone ran the exact same version of bind (eg) and FreeBSD (eg). But too much diversity leads to more points of failure, which I suppose could be bad. Though if the system could lose X% of it's deployed infrastructure without visibly affecting the service itself, then high diversity is likely to be helpful since it's unlikely that the entire system could go down if the diversity ensured it would take multiple vulnerabilities to pass the X% threshold.
I think it should just be clear that applications will be evaluated on how they fit in the diversity of the root server system, rather than specifically on how much diversity they can provide within a single root server. Cheers, -- Shane
On Sep 6, 2016, at 8:45 PM, Shane Kerr <shane@time-travellers.org> wrote:
Andrew,
At 2016-09-06 20:42:07 +0000 Andrew Mcconachie <andrew.mcconachie@icann.org> wrote:
The work party invites you to review this document and provide your feedback by close of business 4 October 2016.
Feedback should be sent to the RSSAC Caucus list directly.
Interesting document. A bit strange but basically reasonable.
----
One thing that I would like to see is a request that all of the information in this document be public. For example, descriptions of zone distribution architecture. As someone without access to this for current root server operators I have to infer this - I often don't know whether something is broken in the root server system or whether they are merely acting in ways that I didn't expect because I don't know what's going on "under the hood".
I realize that this may be out of scope for a technical requirements document, but on the other hand having details available for wider review can result in higher quality service, so I can possibly justify it in a hand-waving way. ;)
Shane, This feels to me out of scope, but I want to make sure I understand your suggestion. Are you suggesting that the information provided by a candidate operator should be made public during the evaluation process, or afterwards? Responses from all candidates would be made public, or just the ones actually chosen? Again I think its out of scope but if you can provide text that fits within the scope of this document perhaps it can be included.
----
One minor point about addressing:
3.3.3 Addressing Resources
The candidate operator MUST have its own AS number(s) and IPv4 and IPv6 address allocations. It is assumed that IP anycast will be used. If IP anycast will not be used, a technology providing similar or better service levels SHOULD be specified. Provider address space or addresses that cannot be used with anycast are undesirable. The expected production IPv4 and IPv6 address blocks MUST be severable from the candidate’s organization to facilitate emergency or planned transfers.
Some RIRs have policies to allocate addresses for "critical use":
https://www.nro.net/rir-comparative-policy-overview/rir-comparative-policy-o...
This means that potential root server operators probably do not need to have address space in advance of being approved for being a root server operator.
I'm not sure the current text is in contradiction with the idea that an org can get root service address space later. Could you please suggest additions or edits if you feel they are necessary? If I put myself in the place of the (not yet existing) committee that would evaluate a potential operator, I would very much like to know if said operator already has the addressing resources, or says they'll figure out how to get them later if chosen.
----
In the section on diversity (3.4), I am a little confused. The introduction states:
Diversity _within_ a given operator is of benefit, but the candidate will also be evaluated in terms of increased diversity among operators.
But within each sub-section it is not at all clear which are intended to apply for a specific operator and which are intended to be used to analyze the root server system as a whole.
In working on this document we spend a lot of time finding the fine line between specifying what the elements are and saying how they should be applied. For some of these sub-sections I think the advice is pretty clear. For example, geographic diversity: "Ideally, the candidate operator will provide service in regions not already well-served by other root operators." Or human diversity: "The candidate operator SHOULD demonstrate or document that it does not rely on any single individual for technical operations." For other sub-sections there is no "SHOULD" for the candidate operator and these can be taken to apply to the system as a whole.
My concern is that this will naturally lead to "diversity inflation" where each root server operator runs multiple versions of everything without any real benefit, and in fact a potential reduction in reliability of the overall system. (For example, if many root servers run a given DNS software to maximize diversity and there is an unpublished exploit, then it is possible that more root servers are compromised rather than fewer.)
Nit: Unbound is a recursive resolver and would be unlikely to be run by a root server operator. :)
Yeah, thanks, we'll fix that.
----
Nit: "triannual" is easily confused with "triennial", so probably it should just be stated that the root server operator meetings are three times a year.
My personal feeling is that we should not be afraid to use these terms correctly. It brings a smile to my face imagining a candidate operator was selected, believing that root operators meet only once every 3 years, later learning its really 3 times per year, and then changing their mind. DW
Hello, I just have a very small comment and I'm curious about something: 1) In: 3.6.2 Sample “x.root-servers.org” Web Page The candidate operator SHOULD demonstrate their ability to maintain a <LETTER>.root-servers.org web page by providing a mock-up in HTML. I think it's a good idea to add one more sentence with something like: ".... " "<LETTER>.root-servers.org or whatever other naming architecture appears. My rationale is that in the future there is chance of root-servers.org to change, right? 2) Is it fair to ask the operator to keep up to date their software and be willing to adapt to new changes?. I think it's not mention in the document (sorry if it's and I missed it). For example something like this might happen: suppose the operator have an OS that does not support IDN?, or firewalls that refuses EDNS or AAAAs? Regards, Alejandro, El 9/6/2016 a las 4:42 PM, Andrew Mcconachie escribió:
Dear RSSAC Caucus,
On behalf of the work party for RSSAC Workshop 2 Statement 4, attached please find /Key Technical Elements of Potential Root Operators/.
This work party first met on June 23, 2016 and roughly every other week thereafter. For more information on the creation of this work party, please see the section on /Evolution/ from the /Report from the 2nd RSSAC Workshop/.
https://www.icann.org/en/system/files/files/rssac-workshop-26jun16-en.pdf
The work party invites you to review this document and provide your feedback by close of business *4 October 2016*.
Feedback should be sent to the RSSAC Caucus list directly.
There will also be two teleconferences held to discuss this document and capture feedback. Doodle polls for exact times forthcoming. *September 15th* *September 22nd*
Thanks, Andrew
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
Alejandro Acosta <alejandro@lacnic.net> writes:
I think it's a good idea to add one more sentence with something like: ".... " " <LETTER>.root-servers.org or whatever other naming architecture appears.
My rationale is that in the future there is chance of root-servers.org to change, right?
That makes sense to me and is a wise suggestion. I might pick "or other appropriate name" for simplicity.
2) Is it fair to ask the operator to keep up to date their software and be willing to adapt to new changes?. I think it's not mention in the document (sorry if it's and I missed it). For example something like this might happen: suppose the operator have an OS that does not support IDN?, or firewalls that refuses EDNS or AAAAs?
That's probably a good point too. 3.6.4 describes needing to be open and to participate, but does not ask them to agree to follow the current trends with respect to the distribution requirements itself. [note that I'm not sure the OS requiring IDN support is needed; we only care about the service as seen from the external point of view to the DNS server] -- Wes Hardaker USC/ISI
On Sep 6, 2016, at 9:09 PM, Alejandro Acosta <alejandro@lacnic.net> wrote:
Hello, I just have a very small comment and I'm curious about something:
1) In:
3.6.2 Sample “x.root-servers.org” Web Page The candidate operator SHOULD demonstrate their ability to maintain a <LETTER>.root-servers.org web page by providing a mock-up in HTML.
I think it's a good idea to add one more sentence with something like: ".... " "<LETTER>.root-servers.org or whatever other naming architecture appears.
My rationale is that in the future there is chance of root-servers.org to change, right?
Yes
2) Is it fair to ask the operator to keep up to date their software and be willing to adapt to new changes?. I think it's not mention in the document (sorry if it's and I missed it). For example something like this might happen: suppose the operator have an OS that does not support IDN?, or firewalls that refuses EDNS or AAAAs?
This sort of feels like two separate items to me. (1) you're suggesting that the operator needs to keep software up-to-date (2) systems must support certain DNS features (IDN, EDNS, all query types). I feel like (2) is already covered well by the requirements of RFC7720. For (1) I don't know what else we can do in this document other than say the candidate operator must promise to keep their software up-to-date: "Do you promise to keep your software up-to-date?" "I sure do!" "Okay, great!" Our existing section 3.4.6 on Openness and Participation is not much different than that, however. If you'd like to propose some text for a new section then we can all consider adding it. DW
Regards,
Alejandro,
El 9/6/2016 a las 4:42 PM, Andrew Mcconachie escribió:
Dear RSSAC Caucus,
On behalf of the work party for RSSAC Workshop 2 Statement 4, attached please find Key Technical Elements of Potential Root Operators.
This work party first met on June 23, 2016 and roughly every other week thereafter. For more information on the creation of this work party, please see the section on Evolution from the Report from the 2nd RSSAC Workshop.
https://www.icann.org/en/system/files/files/rssac-workshop-26jun16-en.pdf
The work party invites you to review this document and provide your feedback by close of business 4 October 2016.
Feedback should be sent to the RSSAC Caucus list directly.
There will also be two teleconferences held to discuss this document and capture feedback. Doodle polls for exact times forthcoming. September 15th September 22nd
Thanks, Andrew
_______________________________________________ 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
El 9/8/2016 a las 5:13 PM, Wessels, Duane escribió:
On Sep 6, 2016, at 9:09 PM, Alejandro Acosta <alejandro@lacnic.net> wrote:
Hello, I just have a very small comment and I'm curious about something:
1) In:
3.6.2 Sample “x.root-servers.org” Web Page The candidate operator SHOULD demonstrate their ability to maintain a <LETTER>.root-servers.org web page by providing a mock-up in HTML.
I think it's a good idea to add one more sentence with something like: ".... " "<LETTER>.root-servers.org or whatever other naming architecture appears.
My rationale is that in the future there is chance of root-servers.org to change, right? Yes
2) Is it fair to ask the operator to keep up to date their software and be willing to adapt to new changes?. I think it's not mention in the document (sorry if it's and I missed it). For example something like this might happen: suppose the operator have an OS that does not support IDN?, or firewalls that refuses EDNS or AAAAs?
This sort of feels like two separate items to me.
(1) you're suggesting that the operator needs to keep software up-to-date
Yes.., sort of that.
(2) systems must support certain DNS features (IDN, EDNS, all query types).
I feel like (2) is already covered well by the requirements of RFC7720.
Actually you are right.
For (1) I don't know what else we can do in this document other than say the candidate operator must promise to keep their software up-to-date:
"Do you promise to keep your software up-to-date?"
"I sure do!"
"Okay, great!"
Our existing section 3.4.6 on Openness and Participation is not much different than that, however. If you'd like to propose some text for a new section then we can all consider adding it.
It can be something like this.., excuse me that English is not my native language: " The operator is expected to follow and adapt to new technology changes that might arise in the future that could affect in a negative way the DNS Service being offered. " Thanks, Alejandro,
DW
Regards,
Alejandro,
El 9/6/2016 a las 4:42 PM, Andrew Mcconachie escribió:
Dear RSSAC Caucus,
On behalf of the work party for RSSAC Workshop 2 Statement 4, attached please find Key Technical Elements of Potential Root Operators.
This work party first met on June 23, 2016 and roughly every other week thereafter. For more information on the creation of this work party, please see the section on Evolution from the Report from the 2nd RSSAC Workshop.
https://www.icann.org/en/system/files/files/rssac-workshop-26jun16-en.pdf
The work party invites you to review this document and provide your feedback by close of business 4 October 2016.
Feedback should be sent to the RSSAC Caucus list directly.
There will also be two teleconferences held to discuss this document and capture feedback. Doodle polls for exact times forthcoming. September 15th September 22nd
Thanks, Andrew
_______________________________________________ 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
Caucus, Speaking as just a caucus member, I am very concerned about section 3.3.7 =-=-=-=-=-=-= 3.3.7 Address Registries The candidate operator’s address space SHOULD be registered in one of the Regional Internet Registry (RIR) public databases. The candidate SHOULD have entries in relevant public routing registries, and if possible Route Origin Authorization (ROA) objects in relevant Resource Public Key Infrastructure (RPKI) registries for their IPv4 and IPv6 address space. =-=-=-=-=-=-= I fully understand what RPKI (and BGPSEC) are meant to do, and I applaud that effort. However in this context My concern comes from two directions: 1) Looking at the diversity principle, any thus by extension, we have currently exactly 5 regional internet registries (and no more on the horizon) for currently 12 operators. So in effect if all operators adopt the SHOULD we are reducing the attack vector diversity for a key component of operating a root server. 2) The RPKI and BGPSEC is fairly well thought out, however I don't believe there is depth of experience there yet. For both of these reasons, I believe it is premature for RSSAC to make RPKI an element of a potential root operator without a deeper investigation into the benefits and risks (and scenarios of attack) of RPKI in the context of the root server system and the resiliency expected. Cheers Terry
On 7 Sep 2016, at 6:42 AM, Andrew Mcconachie <andrew.mcconachie@icann.org> wrote:
Dear RSSAC Caucus,
On behalf of the work party for RSSAC Workshop 2 Statement 4, attached please find Key Technical Elements of Potential Root Operators.
This work party first met on June 23, 2016 and roughly every other week thereafter. For more information on the creation of this work party, please see the section on Evolution from the Report from the 2nd RSSAC Workshop.
https://www.icann.org/en/system/files/files/rssac-workshop-26jun16-en.pdf
The work party invites you to review this document and provide your feedback by close of business 4 October 2016.
Feedback should be sent to the RSSAC Caucus list directly.
There will also be two teleconferences held to discuss this document and capture feedback. Doodle polls for exact times forthcoming. September 15th September 22nd
Thanks, Andrew
<Elements_of_Potential_Root Operators.docx> <Elements_of_Potential_Root Operators.pdf> _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
In-line reply, speaking only for myself (as an ordinary caucus member, of course): On Wed, Sep 7, 2016 at 5:26 PM, Terry Manderson <terry@terrym.net> wrote:
Caucus,
Speaking as just a caucus member,
I am very concerned about section 3.3.7
=-=-=-=-=-=-= 3.3.7 Address Registries
The candidate operator’s address space SHOULD be registered in one of the Regional Internet Registry (RIR) public databases. The candidate SHOULD have entries in relevant public routing registries, and if possible Route Origin Authorization (ROA) objects in relevant Resource Public Key Infrastructure (RPKI) registries for their IPv4 and IPv6 address space. =-=-=-=-=-=-=
I fully understand what RPKI (and BGPSEC) are meant to do, and I applaud that effort. However in this context My concern comes from two directions:
As I understand it, RPKI is also used by Origin Validation (OV) stuff. (I'm not overly familiar with OV, beyond that it is used in some manner to ensure the correct ASN appears to originate the route.)
1) Looking at the diversity principle, any thus by extension, we have currently exactly 5 regional internet registries (and no more on the horizon) for currently 12 operators. So in effect if all operators adopt the SHOULD we are reducing the attack vector diversity for a key component of operating a root server.
TL;DR: I disagree that recommending registration in RPKI is harmful, even if it is not necessarily widespread or mature. I think this needs a bit of pro/con analysis, on what attack vectors exist, what protections are available, and what the uptake is on those protections. The deployment states of both DNSSEC and of RPKI are moving targets, so the pro/con might change over time. I am pretty sure that already, they are respectively moving in directions that doesn't affect the following analysis... Basically, the choices on the table are RPKI or no-RPKI. The "target" is, IMHO, anything that can DOS one or more root servers, or anything that can hijack the IP of one or more root servers. The value of "hijack" is largely in the ability to do one of two things for DNS traffic: (a) MITM vs DNSSEC-protected traffic, or (b) forge responses vs non-DNSSEC-protected traffic. The MITM is only of value for staying in the loop of resolution, until a given resolver passes from signed to unsigned in the DNS tree. At the point where all DNS is DNSSEC, hijacking is of no value, vs validating resolvers. Non-validating resolvers are the low-hanging fruit, as are unsigned zones. This makes hijacking high-value. The value of "DOS" (other than nuisance DOS) is hijackers trying to tip the odds in their favor. Now consider the actual RPKI content, with respect to root server addresses. Of all the addresses on the Internet, those are likely to be the most stable, in terms of ownership and origin ASN. In addition, their single-purpose nature means they are likely to be handled very carefully, if/when any RPKI change for them is necessary. Anyone doing OV is likely to cache RPKI, and given the stable nature of root server ROAs, the caches can survive significant RPKI transferral DOS traffic for great lengths of time. OV caching increases the "availability surface" (the inverse of "attack surface") by many orders of magnitude. The decentralized nature of caching means that DOS vs the 5 RPKI central repos would only impact RPKI updates, rather than the usability of RPKI itself. OV itself, as I understand it, from cache to router, is pretty close to a closed system, assuming any given network operator is doing sensible things. RPKI caches are independent, and this is their strength. BGP, on the other hand, is inherently dependent; a hijacked route will propagate base on not only topology, but also based on the nature of BGP peering links. (qv route leaks.) The failure modes of OV, if they do occur, are likely to look like "damage" to the infrastructure; the route won't pass through the impacted network operator's network. Unless the viewpoint of a given resolver is basically "single homed beneath this network operator", there will be alternate announcements at the ASN level, of the affected root server. Combine this with the 13 root servers, and their multitude of anycast instances, and my calculations give the following result: The risk (and impact) of hijacking one or more root server addresses, far exceeds the chance of any significant risk of DOS vs RPKI-based OV.
2) The RPKI and BGPSEC is fairly well thought out, however I don't believe there is depth of experience there yet.
For both of these reasons, I believe it is premature for RSSAC to make RPKI an element of a potential root operator without a deeper investigation into the benefits and risks (and scenarios of attack) of RPKI in the context of the root server system and the resiliency expected.
Is the above analysis sufficient to sway your opinion?
Cheers Terry
Hi Brian,
On 8 Sep 2016, at 12:08 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
TL;DR: I disagree that recommending registration in RPKI is harmful, even if it is not necessarily widespread or mature.
Please re-read my email. I'm not saying it is harmful. I'm saying it is premature to place it in the "SHOULD" category without further and thorough analysis.
I think this needs a bit of pro/con analysis, on what attack vectors exist, what protections are available, and what the uptake is on those protections. The deployment states of both DNSSEC and of RPKI are moving targets, so the pro/con might change over time. I am pretty sure that already, they are respectively moving in directions that doesn't affect the following analysis...
Basically, the choices on the table are RPKI or no-RPKI.
Actually there are several more states than just RPKI or no-RPKI. Those two only represent the ideal (RPKI ubiquitous) world.
The "target" is, IMHO, anything that can DOS one or more root servers, or anything that can hijack the IP of one or more root servers.
Such as an RIR and their RPKI database and the RPKI repository state? which might then allow an entity to assert a competing ROA that then allows any number of vectors? I'm certainly not being all inclusive, my point is that this is not yet well understood in the context of the root server system.
The value of "hijack" is largely in the ability to do one of two things for DNS traffic: (a) MITM vs DNSSEC-protected traffic, or (b) forge responses vs non-DNSSEC-protected traffic. The MITM is only of value for staying in the loop of resolution, until a given resolver passes from signed to unsigned in the DNS tree. At the point where all DNS is DNSSEC, hijacking is of no value, vs validating resolvers.
In a world where all resolvers validate and all stub<->resolver exchanges are encrypted (DPRIVE) the option for a MiTM is decreased. One might then say that the routing state is irrelevant so long as the answer that is received is validated. But that is for a later discussion.
Non-validating resolvers are the low-hanging fruit, as are unsigned zones. This makes hijacking high-value.
The value of "DOS" (other than nuisance DOS) is hijackers trying to tip the odds in their favor.
Now consider the actual RPKI content, with respect to root server addresses. Of all the addresses on the Internet, those are likely to be the most stable, in terms of ownership and origin ASN. In addition, their single-purpose nature means they are likely to be handled very carefully, if/when any RPKI change for them is necessary.
By its very nature, using RPKI places a significant level of responsibility for the routing/RPKI state of root operators into at most 5 third parties. I'm not saying that is good or bad either way, but I think we need to be honest and critical of that new relationship. What is the agreement structure? What are the remediation and compliance states. Are there grounding service commitments in place?
Anyone doing OV is likely to cache RPKI, and given the stable nature of root server ROAs, the caches can survive significant RPKI transferral DOS traffic for great lengths of time.
OV caching increases the "availability surface" (the inverse of "attack surface") by many orders of magnitude. The decentralized nature of caching means that DOS vs the 5 RPKI central repos would only impact RPKI updates, rather than the usability of RPKI itself. OV itself, as I understand it, from cache to router, is pretty close to a closed system, assuming any given network operator is doing sensible things.
RPKI caches are independent, and this is their strength.
BGP, on the other hand, is inherently dependent; a hijacked route will propagate base on not only topology, but also based on the nature of BGP peering links. (qv route leaks.)
The failure modes of OV, if they do occur, are likely to look like "damage" to the infrastructure; the route won't pass through the impacted network operator's network. Unless the viewpoint of a given resolver is basically "single homed beneath this network operator", there will be alternate announcements at the ASN level, of the affected root server.
Combine this with the 13 root servers, and their multitude of anycast instances, and my calculations give the following result:
The risk (and impact) of hijacking one or more root server addresses, far exceeds the chance of any significant risk of DOS vs RPKI-based OV.
[..]
For both of these reasons, I believe it is premature for RSSAC to make RPKI an element of a potential root operator without a deeper investigation into the benefits and risks (and scenarios of attack) of RPKI in the context of the root server system and the resiliency expected.
Is the above analysis sufficient to sway your opinion?
No. Because, and despite your talent, I think this needs a more thorough review before I would see that paragraph pass. Cheers Terry
Sent from my iPhone
On Sep 7, 2016, at 8:54 PM, Terry Manderson <terry@terrym.net> wrote:
Hi Brian,
On 8 Sep 2016, at 12:08 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
TL;DR: I disagree that recommending registration in RPKI is harmful, even if it is not necessarily widespread or mature.
Please re-read my email. I'm not saying it is harmful. I'm saying it is premature to place it in the "SHOULD" category without further and thorough analysis.
Aaaah. I understand now. Sorry if my reply seemed at all condescending...
Such as an RIR and their RPKI database and the RPKI repository state? which might then allow an entity to assert a competing ROA that then allows any number of vectors?
I'm certainly not being all inclusive, my point is that this is not yet well understood in the context of the root server system.
Yes. My analysis presumed the RIRs/RPKIs were trusted/trustworthy. Since the 5 RIRs have their address space and corresponding RPKI roots "delegated" by ARIN/ICANN, what about a hypothetical situation where the root server operators were their own RIRs and RPKIs?
By its very nature, using RPKI places a significant level of responsibility for the routing/RPKI state of root operators into at most 5 third parties. I'm not saying that is good or bad either way, but I think we need to be honest and critical of that new relationship. What is the agreement structure? What are the remediation and compliance states. Are there grounding service commitments in place?
Is the above analysis sufficient to sway your opinion?
No. Because, and despite your talent, I think this needs a more thorough review before I would see that paragraph pass
And... I concur. ;-)
Cheers Terry
Brian
On Sep 7, 2016, at 5:26 PM, Terry Manderson <terry@terrym.net> wrote:
Caucus,
Speaking as just a caucus member,
I am very concerned about section 3.3.7
=-=-=-=-=-=-= 3.3.7 Address Registries
The candidate operator’s address space SHOULD be registered in one of the Regional Internet Registry (RIR) public databases. The candidate SHOULD have entries in relevant public routing registries, and if possible Route Origin Authorization (ROA) objects in relevant Resource Public Key Infrastructure (RPKI) registries for their IPv4 and IPv6 address space. =-=-=-=-=-=-=
I fully understand what RPKI (and BGPSEC) are meant to do, and I applaud that effort. However in this context My concern comes from two directions:
1) Looking at the diversity principle, any thus by extension, we have currently exactly 5 regional internet registries (and no more on the horizon) for currently 12 operators. So in effect if all operators adopt the SHOULD we are reducing the attack vector diversity for a key component of operating a root server.
2) The RPKI and BGPSEC is fairly well thought out, however I don't believe there is depth of experience there yet.
For both of these reasons, I believe it is premature for RSSAC to make RPKI an element of a potential root operator without a deeper investigation into the benefits and risks (and scenarios of attack) of RPKI in the context of the root server system and the resiliency expected.
Terry, Would you propose to just strike that second sentence altogether then? DW
Hi Duane, Here is some text I would be comfortable with. 'The candidate operator’s address space SHOULD be registered in one of the Regional Internet Registry (RIR) public databases. The candidate SHOULD have entries in relevant public routing registries. It is RECOMMENDED that the candidate maintain a watching brief on the use of Route Origin Authorization (ROA) objects in the Resource Public Key Infrastructure (RPKI).' Slightly different topic, and I guess I'll be in the rough here - using RFC2119 language seems an easy step for 'us', but is it suitable to communicate the message to non-technical and other folks who simply aren't accustomed to reading RFCs? Cheers Terry
On 9 Sep 2016, at 7:16 AM, Wessels, Duane <dwessels@verisign.com> wrote:
On Sep 7, 2016, at 5:26 PM, Terry Manderson <terry@terrym.net> wrote:
Caucus,
Speaking as just a caucus member,
I am very concerned about section 3.3.7
=-=-=-=-=-=-= 3.3.7 Address Registries
The candidate operator’s address space SHOULD be registered in one of the Regional Internet Registry (RIR) public databases. The candidate SHOULD have entries in relevant public routing registries, and if possible Route Origin Authorization (ROA) objects in relevant Resource Public Key Infrastructure (RPKI) registries for their IPv4 and IPv6 address space. =-=-=-=-=-=-=
I fully understand what RPKI (and BGPSEC) are meant to do, and I applaud that effort. However in this context My concern comes from two directions:
1) Looking at the diversity principle, any thus by extension, we have currently exactly 5 regional internet registries (and no more on the horizon) for currently 12 operators. So in effect if all operators adopt the SHOULD we are reducing the attack vector diversity for a key component of operating a root server.
2) The RPKI and BGPSEC is fairly well thought out, however I don't believe there is depth of experience there yet.
For both of these reasons, I believe it is premature for RSSAC to make RPKI an element of a potential root operator without a deeper investigation into the benefits and risks (and scenarios of attack) of RPKI in the context of the root server system and the resiliency expected.
Terry,
Would you propose to just strike that second sentence altogether then?
DW
Hi Terry, Duane (& others following this thread) I’ve followed the discussion about the RIR, RPKI & ROA and find the text that Terry’s comfortable with to be rather confusing since I really don’t have any idea what the phrase “maintain a watching brief on the use of …” is trying to get at? Terry, it sounds from your earlier posts that you don’t think that use of ROAs & RPKI should be a SHOULD/RECOMMENDED but I don’t think your current suggestion says that. Would you clarify what you intended with the wording? As you might imagine, I strongly support having SHOULD/RECOMMENDED wording that says a candidate operator should actually plan on using the technology - the candidate doesn’t think they actually should use the technology, then they can provide their explanation for deciding not follow this paragraph as they would for any SHOULD/RECOMMENDED that they do not want to follow - remembering that the last paragraph in section 1 gives candidate operators the latitude to submit candidate operations that do not comply with the recommendations of this document as long as they can explain their rationale for their approach. Russ
On Sep 8, 2016, at 9:09 PM, Terry Manderson <terry@terrym.net> wrote:
Hi Duane,
Here is some text I would be comfortable with.
'The candidate operator’s address space SHOULD be registered in one of the Regional Internet Registry (RIR) public databases. The candidate SHOULD have entries in relevant public routing registries. It is RECOMMENDED that the candidate maintain a watching brief on the use of Route Origin Authorization (ROA) objects in the Resource Public Key Infrastructure (RPKI).'
Slightly different topic, and I guess I'll be in the rough here - using RFC2119 language seems an easy step for 'us', but is it suitable to communicate the message to non-technical and other folks who simply aren't accustomed to reading RFCs?
Cheers Terry
On 9 Sep 2016, at 7:16 AM, Wessels, Duane <dwessels@verisign.com> wrote:
On Sep 7, 2016, at 5:26 PM, Terry Manderson <terry@terrym.net> wrote:
Caucus,
Speaking as just a caucus member,
I am very concerned about section 3.3.7
=-=-=-=-=-=-= 3.3.7 Address Registries
The candidate operator’s address space SHOULD be registered in one of the Regional Internet Registry (RIR) public databases. The candidate SHOULD have entries in relevant public routing registries, and if possible Route Origin Authorization (ROA) objects in relevant Resource Public Key Infrastructure (RPKI) registries for their IPv4 and IPv6 address space. =-=-=-=-=-=-=
I fully understand what RPKI (and BGPSEC) are meant to do, and I applaud that effort. However in this context My concern comes from two directions:
1) Looking at the diversity principle, any thus by extension, we have currently exactly 5 regional internet registries (and no more on the horizon) for currently 12 operators. So in effect if all operators adopt the SHOULD we are reducing the attack vector diversity for a key component of operating a root server.
2) The RPKI and BGPSEC is fairly well thought out, however I don't believe there is depth of experience there yet.
For both of these reasons, I believe it is premature for RSSAC to make RPKI an element of a potential root operator without a deeper investigation into the benefits and risks (and scenarios of attack) of RPKI in the context of the root server system and the resiliency expected.
Terry,
Would you propose to just strike that second sentence altogether then?
DW
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
Hi Russ,
On 12 Sep 2016, at 2:44 PM, Russ Mundy <mundy@tislabs.com> wrote:
Hi Terry, Duane (& others following this thread)
I’ve followed the discussion about the RIR, RPKI & ROA and find the text that Terry’s comfortable with to be rather confusing since I really don’t have any idea what the phrase “maintain a watching brief on the use of …” is trying to get at?
In which case I'm also comfortable to omit the sentence completely. Therefore the text would be: 'The candidate operator’s address space SHOULD be registered in one of the Regional Internet Registry (RIR) public databases. The candidate SHOULD have entries in relevant public routing registries."
Terry, it sounds from your earlier posts that you don’t think that use of ROAs & RPKI should be a SHOULD/RECOMMENDED but I don’t think your current suggestion says that. Would you clarify what you intended with the wording?
As above. Cheers Terry
Based on the current architecture, BGP/Anycast is still the core technology to extend the DNS root servers. So I think RPKI is a good basis to guarantee the legal relationship between the AS and IP used by the root server. But the potential operator may not have it's own AS/IP space (for example it relies on other ISP) and can not decide to adopt RPKI. 2016-09-12 YAN Zhiwei 发件人： Terry Manderson 发送时间： 2016-09-12 13:09:50 收件人： Russ Mundy 抄送： rssac-caucus@icann.org 主题： Re: [rssac-caucus] FOR REVIEW: Elements of Potential Root Operators Hi Russ,
On 12 Sep 2016, at 2:44 PM, Russ Mundy <mundy@tislabs.com> wrote:
Hi Terry, Duane (& others following this thread)
I’ve followed the discussion about the RIR, RPKI & ROA and find the text that Terry’s comfortable with to be rather confusing since I really don’t have any idea what the phrase “maintain a watching brief on the use of …” is trying to get at?
In which case I'm also comfortable to omit the sentence completely. Therefore the text would be: 'The candidate operator’s address space SHOULD be registered in one of the Regional Internet Registry (RIR) public databases. The candidate SHOULD have entries in relevant public routing registries."
Terry, it sounds from your earlier posts that you don’t think that use of ROAs & RPKI should be a SHOULD/RECOMMENDED but I don’t think your current suggestion says that. Would you clarify what you intended with the wording? As above. Cheers Terry
rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
Zhiwei, “The candidate operator’s address space SHOULD be registered in one of the Regional Internet Registry (RIR) public databases. “ means this candidate is required to get INRs from RIRs, which by the way, are ready to issue INR certificates. Should this root operator be required to employed RPKI, it would just need to sign a ROA/router certificate -:) Di
在 2016年9月12日，13:46，YAN Zhiwei <yanzhiwei@cnnic.cn> 写道：
Based on the current architecture, BGP/Anycast is still the core technology to extend the DNS root servers. So I think RPKI is a good basis to guarantee the legal relationship between the AS and IP used by the root server. But the potential operator may not have it's own AS/IP space (for example it relies on other ISP) and can not decide to adopt RPKI.
2016-09-12 YAN Zhiwei 发件人： Terry Manderson 发送时间： 2016-09-12 13:09:50 收件人： Russ Mundy 抄送： rssac-caucus@icann.org 主题： Re: [rssac-caucus] FOR REVIEW: Elements of Potential Root Operators Hi Russ,
On 12 Sep 2016, at 2:44 PM, Russ Mundy <mundy@tislabs.com> wrote:
Hi Terry, Duane (& others following this thread)
I’ve followed the discussion about the RIR, RPKI & ROA and find the text that Terry’s comfortable with to be rather confusing since I really don’t have any idea what the phrase “maintain a watching brief on the use of …” is trying to get at?
In which case I'm also comfortable to omit the sentence completely. Therefore the text would be: 'The candidate operator’s address space SHOULD be registered in one of the Regional Internet Registry (RIR) public databases. The candidate SHOULD have entries in relevant public routing registries."
Terry, it sounds from your earlier posts that you don’t think that use of ROAs & RPKI should be a SHOULD/RECOMMENDED but I don’t think your current suggestion says that. Would you clarify what you intended with the wording? As above. Cheers Terry
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
Yepp, got it~ 2016-09-12 YAN Zhiwei 发件人： Declan Ma 发送时间： 2016-09-12 15:45:19 收件人： YAN Zhiwei 抄送： Terry Manderson; Russ Mundy; rssac-caucus@icann.org 主题： Re: [rssac-caucus] FOR REVIEW: Elements of Potential Root Operators Zhiwei, “The candidate operator’s address space SHOULD be registered in one of the Regional Internet Registry (RIR) public databases. “ means this candidate is required to get INRs from RIRs, which by the way, are ready to issue INR certificates. Should this root operator be required to employed RPKI, it would just need to sign a ROA/router certificate -:) Di
在 2016年9月12日，13:46，YAN Zhiwei <yanzhiwei@cnnic.cn> 写道：
Based on the current architecture, BGP/Anycast is still the core technology to extend the DNS root servers. So I think RPKI is a good basis to guarantee the legal relationship between the AS and IP used by the root server. But the potential operator may not have it's own AS/IP space (for example it relies on other ISP) and can not decide to adopt RPKI.
2016-09-12 YAN Zhiwei 发件人： Terry Manderson 发送时间： 2016-09-12 13:09:50 收件人： Russ Mundy 抄送： rssac-caucus@icann.org 主题： Re: [rssac-caucus] FOR REVIEW: Elements of Potential Root Operators Hi Russ,
On 12 Sep 2016, at 2:44 PM, Russ Mundy <mundy@tislabs.com> wrote:
Hi Terry, Duane (& others following this thread)
I’ve followed the discussion about the RIR, RPKI & ROA and find the text that Terry’s comfortable with to be rather confusing since I really don’t have any idea what the phrase “maintain a watching brief on the use of …” is trying to get at?
In which case I'm also comfortable to omit the sentence completely. Therefore the text would be: 'The candidate operator’s address space SHOULD be registered in one of the Regional Internet Registry (RIR) public databases. The candidate SHOULD have entries in relevant public routing registries."
Terry, it sounds from your earlier posts that you don’t think that use of ROAs & RPKI should be a SHOULD/RECOMMENDED but I don’t think your current suggestion says that. Would you clarify what you intended with the wording? As above. Cheers Terry
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
Hello, In 3.4.2 Network Provider Diversity *Utilizing multiple upstream network providers can be of benefit to candidate operators that use third-party network providers. Candidate operators SHOULD demonstrate or document that they are not susceptible to the problems and sustained outages of a single network provider. * I think we can add one more sentence like : Candidate operators SHOULD assure a comfortable round trip time (RTT) on local cross-network-provider query traffic. Andrew Mcconachie <andrew.mcconachie@icann.org>于2016年9月7日周三 上午4:42写道：
Dear RSSAC Caucus,
On behalf of the work party for RSSAC Workshop 2 Statement 4, attached please find *Key Technical Elements of Potential Root Operators*.
This work party first met on June 23, 2016 and roughly every other week thereafter. For more information on the creation of this work party, please see the section on *Evolution* from the *Report from the 2nd RSSAC Workshop*.
https://www.icann.org/en/system/files/files/rssac-workshop-26jun16-en.pdf
The work party invites you to review this document and provide your feedback by close of business *4 October 2016*.
Feedback should be sent to the RSSAC Caucus list directly.
There will also be two teleconferences held to discuss this document and capture feedback. Doodle polls for exact times forthcoming. *September 15th* *September 22nd*
Thanks, Andrew
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
-- Best Regards Pan Lanlan
participants (11)
-
abby pan -
Alejandro Acosta -
Andrew Mcconachie -
Brian Dickson -
Declan Ma -
Russ Mundy -
Shane Kerr -
Terry Manderson -
Wes Hardaker -
Wessels, Duane -
YAN Zhiwei