On May 10, 2020, at 5:28 AM, Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) <kenneth.d.renard.ctr@mail.mil> wrote:
I like this approach, and I think your list is comprehensive. Comments here do not provide clarity, but maybe more questions for discussion.
For cases 1, 2 [7706-style or non-IANA configuration of a recursive]: As an Internet user, am I misplacing trust in my recursive resolver (or DHCP response) ? There is no agreement (that I know of) between a user and an ISP that defines the accuracy requirements for DNS service. We know that deception (resolving non-existent domains to web advertisements) has been practiced by ISPs. Again, we have a tough problem of discerning a mistake from an intentional act.
Yes I agree. The question of discerning mistake from something intentional is very complicated and rather than say what is right vs wrong we may just want to say what is possible and describe the risks and consequences. I hadn't really considered the question of trust in DHCP responses. That feels out of scope to me, but maybe something we want to (briefly) document anyway.
For the cases 3, 4, and 6: [route hijack, on-path attacker, off-path attacker] : Should we consider these improper, even if the response is correct? That sure would be hard to detect. With an incorrect response, I certainly feel this is improper. For a correct response, I still feel it is improper, but more-so from the traffic tampering perspective.
Given that DNS privacy is a hot topic at the moment, it seems to me that where a query goes is important, even if the response is correct.
For case 5: [incorrect from an RSO]: This definitely falls in to the 'improper' category, but is it intentional incorrectness? Old data (beyond grace period) would fall in to this category. Is there something that can discern a temporary mistake versus an intentional act?
I think discerning intention in this category would be really hard. DW
Thanks, Duane!
Ken Renard S&TCD Contractor – ICF Sustaining Base Network Assurance Branch C5ISR Center, Space and Terrestrial Communications Directorate Office: 443-395-7809 kenneth.d.renard.ctr@mail.mil
On 5/5/20, 7:36 PM, "Wessels, Duane" <dwessels@verisign.com> wrote:
All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.
----
Thanks for starting the discussion Ken.
I've been looking at this at doodling on paper and sort of come to the conclusion that we should not be focusing on the *types* of rogue/fake/bad operators, but rather on the various ways that a DNS client can get anything other than a correct response from an IANA recognized root server. I apologize in advance if this takes us in the wrong direction, but it feels right to me so I figured I'd share it.
Thinking about a DNS query from a recursive resolver (client) to a root server, a number of things can happen that prevents it from getting correct response from a real root server:
1) The recursive resolver might be configured for RFC7706-style operation, which is to say that the query is answered locally, without leaving the recursive resolver itself or the local network. I'm not saying this is bad/wrong, but we may want to describe the risks around it.
2) Does the recursive resolver have non-IANA root NS RRset and associated addresses? This is like your "non-sanctioned operator" case, and also like the Yeti DNS project. In this case queries do not (always) reach real RSOs. Probably two sub-cases here where one is opt-in/intentional and the other is not.
3) Route hijacks. Even though a DNS query has a proper RSO destination IP address, it may be routed to another entity. I would include here both BGP hijacks and static routes to serve RSO addresses locally, which is also covered in your non-sanctioned operator case.
4) On-path attacker. Although the query is on its way towards a proper RSO, an on-path device or attacker may interfere. Think "great firewall" style.
5) Incorrect or unexpected data served by an RSO. The query was delivered to a proper RSO, but the response was incorrect somehow, either due to compromise, software bug, misconfiguration, or intentional interference. We've seen an example of a software bug like this just recently. A long time ago (probably 2008?) I remember there was a root server that was serving "localhost," I'm guessing because about that time it came as part of the default BIND configuration.
6) Off-path attacker? Not sure this is in scope, but perhaps.
Of all these different possibilities, I think the likelihood that a client gets bad data because of an RSO's intentional actions is quite low. Nonetheless we could describe these various scenarios and the extent that mitigations are needed and effective.
DW
On May 5, 2020, at 1:11 PM, Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) via rssac-caucus <rssac-caucus@icann.org> wrote:
Throwing out some ideas on terminology for the rogue operator work party. Please feel free to share your thoughts on these.
-Ken
Non-sanctioned Operator: This could be an enterprise that serves the root zone [possibly with modifications] to its internal users, fully within their authority. This purposefully avoids the term "rogue" and its negative implications. This could be done via recursive resolvers configuring non-standard root servers, or by impersonating RSO address space only within the domain of their authority. Do we need a separate term for cases where they do this outside of their authority?
Impersonating Operator: An authoritative server, serving the Root Zone publicly, that is run by someone other than the 12 Root Server Organizations, responding to one or more the 26 root server addresses. These organizations do not necessarily uphold the guiding principles of the root server operators. Correctness of the served zone is irrelevant? This also purposefully avoids the term "rogue" and its negative implications. (Impersonating Operator, Imposter Operator, Fake Operator, … word-smithing encouraged)
Rogue Operator: A legitimate Root Server Operator that decided to do "bad things". A starting point for defining "bad things" would be a violation of some set of the 11 principals defined in Section 3 of RSSAC037. Specifically:
• Guiding Principal #2: IANA is the source of DNS root data -- If an RSO serves a non-IANA root zone or a modified IANA root zone, they are in violation of this principal • Guiding Principal #6: The IETF defines technical operation of the DNS -- If an RSO does not support the protocols as defined by the IETF, they are in violation of this principal. Serving protocols in addition to IETF protocols should not be considered in violation (flame away, here) • Guiding Principal #7: RSOs must operate with integrity and an ethos demonstrating a commitment to the common good of the Internet -- this one is pretty open-ended. • Guiding Principal #11: RSOs must be neutral and impartial -- serving data with intentional bias of query source/content (e.g. serving slow or incorrect data to market competitors or governments) Lots of room for discussion here • More ideas welcome
There could be more definitions and we can certainly refine these.
Ken Renard S&TCD Contractor – ICF Sustaining Base Network Assurance Branch C5ISR Center, Space and Terrestrial Communications Directorate Office: 443-395-7809 kenneth.d.renard.ctr@mail.mil
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org Caution-https://secure-web.cisco.com/1exAFAzXHjmETsRjUrrDmy0r0Cv7oMt1WXxIx43ciJUX8aU...
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (Caution-https://secure-web.cisco.com/1aef_Y0-7xwmr_Q-eoPH1VxGyE_5wLxRL-oQkhD_InQmLOQ...) and the website Terms of Service (Caution-https://secure-web.cisco.com/17fOdMyxlceIQHihFHIvLaUBKkF7_CDaE2Qv8M8VoksDHau...). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.