Summary

 

The "Rogue Operator" Work party held its kickoff meeting on Friday, 1 May 2020. Participation was good with approximately 20 people.  With only mild interest in volunteering for the role of Work Party Leader, it was decided to postpone the selection of a leader until the next meeting, allowing participants to learn more about the topic. The Statement of Work was presented and a few topics were discussed among the group. For future meetings, a doodle poll will be initiated to determine one or two standing times for monthly calls. Plans to hold a work party meeting as part of the ICANN 68 (Kuala Lumpur, virtual) meeting were dismissed as the work party preferred to decide on a time slot on their own versus being tied to local time in KL.

 

 

Action Items

 

1. Staff will conduct a poll to determine a standing meeting time for monthly calls

2. Work Party members are encouraged to volunteer to act as work party leader

3. Work Party members are encouraged to continue discussions on the RSSAC Caucus mail list on new or existing topics related to this work party.

4. Ken Renard and staff will send out meeting summary to RSSAC Caucus mail list

 

 

Topics discussed

 

  1. A good definition of “rogue”
  2. The original use of the term "rogue" came from RSSAC037 in reference to how an existing Root Server Operator could be removed from its duty. There are negative connotations of the term rogue (in US English), but the term seems to be fitting as long as we can define what it means in the perspective of an RSO. Some of the scenarios discussed were:
  1. "Unexpected behavior"
  2. Serving anything other than the true IANA root zone to users outside of your organization/scope-of-authority. This means that enterprises who extend the root zone _only_ for their internal users would _not_ be considered rogue. If such an enterprise serves users outside of their authority, then that would be considered rogue
  3. Restricting the term "rogue" to only legitimate RSOs versus non-RSOs acting as an RSO (answering queries on one or more of the 26 ‘official’ addresses)
  4. "Intention" - while the intention to deceive is an obvious indication of a rogue operator (or server), it is not up to this WP to determine intention.
  1. Organization / Government roles

There may be cases where an organization or government requires (by law?) that the root zone must be modified. These are outside the scope of our determination of "rogue-ness" and are not true RSOs (what if they are responding on RSO IP addresses?) Are these "fake" instances (use term other than "rogue").  Other potential terms: "non-IANA", "non-standard", "non-sanctioned"

  1. RSOs serving zones other than '.', '.arpa', or '.root-servers.net’

It was brought up that some RSOs may serve zones other than these 3 on their Root Server IP addresses. This should not lead to any change in the root zone information served, but it could mean that some root servers return different results to the same query (such as additional records). A follow-on email from Wes indicated that no RSOs are actually doing this now. This might be an interesting hypothetical discussion for root ops.

 

 

Agenda topics for next meeting

 

  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
    1. RSO-gone-bad (example, serving incorrect zone data)
    2. 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

 

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