May 2020 - rssac-caucus - lists.icann.org

Nomination Period: RSSAC Liaison to the ICANN Nominating Committee
by Ozan Sahin June 18, 2020

June 18, 2020

Dear RSSAC Caucus Members, It is time to begin the selection process for the Outgoing RSSAC Liaison to the 2021 ICANN Nominating Committee. The role is a one-year term beginning at the conclusion of the Annual General Meeting to be held during ICANN69. Please refer to this page<https://www.icann.org/nomcom2020> for more information about the Nominating Committee. I have also copied below the relevant sections from “RSSAC000v4: Operational Procedures” for your reference. With this notice, a one-month nomination period via this distribution list is now open. Nominations or self-nominations will be accepted and require a second. Nominees must then accept or decline their nomination and may provide a statement with more context for their decision. The nomination period will close at 23:59 UTC on 21 June. The RSSAC will then consider the slate of candidates at its 7 July teleconference. As you may recall, the RSSAC appointed Amir Qayyum to this role in 2019. Amir’s term will expire by ICANN69, the Annual General Meeting. Amir is eligible for re-appointment as per the RSSAC Operational Procedures. The RSSAC Leadership appreciates your consideration. Please do not hesitate to contact the RSSAC Chair and Vice Chair or support staff with any questions or concerns. Best, Ozan Sahin on behalf of Fred Baker, RSSAC Chair Brad Verd, RSSAC Vice Chair 1.2.8.6 Outgoing RSSAC Liaison to the ICANN Nominating Committee The outgoing RSSAC Liaison to the ICANN Nominating Committee is specified in the ICANN Bylaws.3 The term for the outgoing RSSAC Liaison to the ICANN Nominating Committee shall be one year. A person may only serve for three consecutive terms. The eligibility status for a previous liaison is reset one year after having stepped down. The RSSAC must elect the outgoing RSSAC Liaison to the ICANN Nominating Committee according to the outgoing RSSAC liaisons election procedure (Section 1.2.8.9) from the members of the RSSAC Caucus. The outgoing RSSAC Liaison to the ICANN Nominating Committee acts as a conduit between the RSSAC and the ICANN Nominating Committee reporting on matters that need to be coordinated or communicated between the two bodies. The role requires discretion, management skills, and considerable time commitment. 1.2.8.9 Outgoing RSSAC Liaisons Election Procedure One month prior to each election, qualified nominees will be accepted for the outgoing liaison position and announced on the RSSAC distribution list. During the meeting that includes election of an outgoing liaison position on its announced agenda, additional nominations will be accepted, and all nominees will indicate their intentions: to accept or to decline their nomination. In the event that only one candidate is standing for election, the RSSAC may elect the new outgoing liaison by acclamation. In the event that two or more candidates are standing for election, the RSSAC Chair will call for a vote. Members will indicate their selection. A simple majority (half plus one) of the voting members will establish the new liaison. In the event a simple majority is not achieved due to having more than two nominees, the nominee with the least number of votes is eliminated and the voting is repeated with the reduced slate of names. The process is repeated until a nominee achieves a simple majority. In the event of a tie, a runoff election will occur with members indicating their selection. In the event of a second tie, the floor will be opened for discussion followed by a new vote with the simple majority designating the new liaison. The RSSAC Chair will forward the name of the outgoing liaison-elect to the reciprocating body. If a vacancy exists in an outgoing liaison role, the RSSAC will elect a new outgoing liaison through this process.

4 4

Reviewing RSSAC023v2: History of the Root Server System version 2
by Andrew McConachie June 1, 2020

June 1, 2020

Dear RSSAC Caucus Members, Thanks everyone who joined the call on Monday April 6th to discuss RSSAC023v2: History of the Root Server System version 2. As discussed on the call I accepted many suggestions in the Google doc and cleaned it up a bit. <https://docs.google.com/document/d/16FaQzGJnqBsy5zk4xmLPU2v7FUqLQT8readmSYI…> The major new edits we discussed on the call were to the following sections. 1.1 Terminology 2.11 Proposed Governance Model for the DNS Root Server System 7.2 Historical Copies of Root Name Server Information Please review those sections specifically and if you have any suggestions please add them to the document. There are still some formatting and whitespace issues that I need to fix in the document. I will be working on that this week and will produce a new version next week for the full 2 week RSSAC Caucus review cycle. Thanks, Andrew

3 6

ICANN68 Prep Sessions Schedule and Registration
by Ozan Sahin May 29, 2020

May 29, 2020

Dear RSSAC Caucus members, ICANN has announced the schedule for ICANN68 Prep Sessions, eleven webinars to help prepare the ICANN community ahead of the Virtual Policy Forum. The announcement includes a link to the registration form: https://www.icann.org/news/announcement-2020-05-28-en To attend any of the webinars please register here<https://go.icann.org/prepweeksignup> by Friday, 5 June. Best, Ozan Sahin Policy Specialist Internet Corporation for Assigned Names and Numbers (ICANN) Telephone: +90 212 999 6218 Mobile: +90 533 641 0007 Skype: ozan.sahin.icann www.icann.org<applewebdata://021EB1F1-F6B6-443A-908F-419605BF3A61/www.icann.org>

1 0

Updating the RSSAC FAQ
by Andrew McConachie May 28, 2020

May 28, 2020

Dear RSSAC Caucus Members, According to the RSSAC Work Plan the RSSAC should update its FAQ before December every year. <https://www.icann.org/en/system/files/files/rssac-work-plan-05feb20-en.pdf> Recently the RSSAC recieved a question via the ask-rssac(a)icann.org<mailto:ask-rssac@icann.org> mailing address concerning why the limit of 13 root servers had been set in the 1990s. Through researching that question with the help of input from community members we developed a new answer for this question in the RSSAC FAQ. Rather than just update that single question in the FAQ the RSSAC Admin Committee decided to use this as an opportunity to update the entire FAQ for 2020. The current FAQ: <https://www.icann.org/groups/rssac/faq> The draft new FAQ: <https://docs.google.com/document/d/13znyayqFMBXxPIRrKbhyQDk1dO7LOy9oFwedy-o…> Please review the new Draft FAQ and provide any input by May 14th, 2020. Thanks, Andrew

5 8

RSSAC Caucus Rogue RSO WP Teleconference #2 | Tuesday, 2 June 2020 | 13:00 - 14:00 UTC
by Ozan Sahin May 19, 2020

May 19, 2020

Draft Agenda: Please see below at the bottom of the invitation. Work Party Wiki Space: https://community.icann.org/x/IonsBw Ozan Sahin is inviting you to a scheduled Zoom meeting. Topic: RSSAC Caucus Rogue RSO WP Call #2 Time: Jun 2, 2020 01:00 PM Universal Time UTC Join Zoom Meeting https://icann.zoom.us/j/91224566829 Meeting ID: 912 2456 6829 Password: 2p#X3SHVDJ One tap mobile +16699006833,,91224566829#,,1#,775019# US (San Jose) +13462487799,,91224566829#,,1#,775019# US (Houston) Dial by your location +1 669 900 6833 US (San Jose) +1 346 248 7799 US (Houston) +1 253 215 8782 US (Tacoma) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) +1 929 436 2866 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 912 2456 6829 Password (for dial-ins only): 775019 Find your local number: https://icann.zoom.us/u/adws9ETwvz Draft agenda topics 1. Select a work party leader 2. Document examples of changing the root zone that could cause problems 3. Discussion of scenarios that would be considered rogue * RSO-gone-bad (example, serving incorrect zone data) * Non-sanctioned RSO (a recursive resolver that uses an alternate root server list) 4. Practicality of detection strategies 5. Discussion of damage that could be done by a rogue operator

1 0

RSSAC Caucus Local Perspective Tool WP Teleconference #2 | Monday, 1 June 2020 | 15:00 - 16:00 UTC
by Ozan Sahin May 19, 2020

May 19, 2020

Ozan Sahin is inviting you to a scheduled Zoom meeting. Draft Agenda: Please see below at the bottom of the invitation. Work Party Wiki Space: https://community.icann.org/x/gInsBw Topic: RSSAC Caucus Local Perspective Tool WP Call #2 Time: Jun 1, 2020 03:00 PM Universal Time UTC Join Zoom Meeting https://icann.zoom.us/j/98955172191 Meeting ID: 989 5517 2191 Password: 9r#1yTHA5i One tap mobile +16699006833,,98955172191#,,1#,570661# US (San Jose) +13462487799,,98955172191#,,1#,570661# US (Houston) Dial by your location +1 669 900 6833 US (San Jose) +1 346 248 7799 US (Houston) +1 253 215 8782 US (Tacoma) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) +1 929 436 2866 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 989 5517 2191 Password (for dial-ins only): 570661 Find your local number: https://icann.zoom.us/u/aea952dUFq Draft agenda topics 1. Select a work party leader 2. Enumerate end-user use cases: * Researcher/curious user in a University or Enterprise network * Enterprise IT staff (recursive resolver operators) * Topologically-remote network. * Well-connected data centers (Google/CloudFlare) good for comparison? * Home users (testing ISP versus public DNS perspective of root) * RSOs 3. Discussion of CAIDA research 4. What set of measurements would be useful for testing perspective directly to RSS? Let's get an initial list to ground general thoughts on the set. We will revisit this periodically. * Local IP (ASN), geo-location?, RSS RTT (v4/v6/udp/tcp), RTT to first-hop router, RTT to well-known Internet infrastructure, traceroutes to RSS 4. What set of measurements would be useful for testing perspective of the RSS via the local resolver? Let's get an initial list to ground general thoughts on the set. We will revisit this periodically. * IP (ASN) of RR, RTT to RR, RSS RTT (v4/v6/udp/tcp), RTT to first-hop router, RTT to well-known Internet infrastructure, traceroute (from where?) * Compare RTT for cache miss versus cache hit * Compare RTT of configured RR versus well-established resolver (google/cloudflare/etc)

1 0

Zoom Updates
by Ozan Sahin May 19, 2020

May 19, 2020

Dear RSSAC and RSSAC Caucus members, Please note the changes below to all Zoom meetings organized by ICANN: * All meetings will require password protection. We are no longer able to embed a password in the meeting Zoom link. You can find the passwords in the calendar invitations. * Waiting room will be enabled in all meetings for participants. The host of the meeting will need to manually move participants over to the meeting room. * ICANN Expected Standards of Behavior will be enforced during the meetings. The text below including a link to the Expected Standards of Behavior will be shared in the chat: “Please review ICANN Expected Standards of Behavior here: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en.” Please let me know if you have any questions. Best, Ozan Sahin Policy Specialist Internet Corporation for Assigned Names and Numbers (ICANN) Telephone: +90 212 999 6218 Mobile: +90 533 641 0007 Skype: ozan.sahin.icann www.icann.org<applewebdata://021EB1F1-F6B6-443A-908F-419605BF3A61/www.icann.org>

1 0

Publication of RSSAC050
by Andrew McConachie May 16, 2020

May 16, 2020

Dear RSSAC Caucus Members, The RSSAC has recently published RSSAC050: RSSAC Statement on Identification of Root Server Operators. RSSAC050 can be found here. <https://www.icann.org/en/system/files/files/rssac-050-13may20-en.pdf> Thanks, Andrew

1 0

New RSSAC Caucus Member
by Ozan Sahin May 15, 2020

May 15, 2020

Dear all, The RSSAC recently adopted the recommendation of the RSSAC Caucus Membership Committee to appoint a new RSSAC Caucus member: * Barbara Schleckser Barbara has been subscribed to this mailing list and her statement of interest is available here: https://community.icann.org/display/RSI/RSSAC+Caucus+Statements+of+Interest Please join me in welcoming Barbara. Best, Ozan Sahin Policy Specialist Internet Corporation for Assigned Names and Numbers (ICANN) Telephone: +90 212 999 6218 Mobile: +90 533 641 0007 Skype: ozan.sahin.icann www.icann.org<applewebdata://021EB1F1-F6B6-443A-908F-419605BF3A61/www.icann.org>

3 2

Re: [RSSAC Caucus] [Non-DoD Source] Re: Work Party [Rogue RSO]: Thoughts on a definition of "Rogue Operator"
by Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) May 11, 2020

May 11, 2020

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. 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. 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? 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(a)mail.mil On 5/5/20, 7:36 PM, "Wessels, Duane" <dwessels(a)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(a)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(a)mail.mil > > _______________________________________________ > rssac-caucus mailing list > rssac-caucus(a)icann.org > Caution-https://secure-web.cisco.com/1exAFAzXHjmETsRjUrrDmy0r0Cv7oMt1WXxIx4… > > _______________________________________________ > 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-oQkh…) and the website Terms of Service (Caution-https://secure-web.cisco.com/17fOdMyxlceIQHihFHIvLaUBKkF7_CDaE2Qv8M…) 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.

2 1