1) Edward Lewis discusses using the Regional Internet Registry (RIR) WhoIs databases to reach out to autonomous system (AS) operators with an important operational message from ICANN. 2) They had doubts it would work due to concerns about spamming, but contacted nearly 16,000 ASs anyway with few complaints. 3) The talk highlights issues with RIR WhoIs data like a lack of standard formats and fields that made the process challenging but also suggests how the new RDAP system could help improve coordination.

1. | 1
Edward Lewis
APRICOT 2019
27 February 2019
Experience using RIR WhoIs
... or Reaching Operators with a Message

2. | 2
The Setting
¤ From 2016-2018, ICANN had an operational message to deliver
¡ But no list of all "who need to know"
¡ Not everyone needed to know, but many did
¤ We tried conferences
¡ We spoke so often we were told "we've heard the message"
¤ We tried letters to IXPs, top-level domain registries, even regulators
¤ But "data" suggested we were missing operators (specifically DNS)
¤ We settled on trying issuing a survey

3. | 3
The Background
¤ The project involved is the "first" DNS root zone KSK rollover
¤ This is not "yet another KSK rollover talk"
¡ Nothing more in these slides is about that topic
¤ This a "lesson learned" about operational coordination, from that project

4. | 4
The Survey
¤ Designed to grab people's attention
¡ Some are carefully crafted to learn something
¡ This an exercise in getting a reaction
¤ Finding the target audience
¡ We have network traffic suggesting DNSSEC activity
¡ We convert the addresses into Autonomous System numbers
¡ Send email to the contacts for the Autonomous System operators
¤ Simple!

5. | 5
The Plan
¤ Beginning with a list of Autonomous System numbers
¡ And with a short deadline
¤ Make use of the Regional Internet Registries databases, via WhoIs, to get
a list of email addresses
¡ Yes, WhoIs,not RDAP
¤ Did we think this would work?
¡ No
¡ But it was our only hope and we had a really good reason

6. | 6
Our Doubts
¤ The threat of "Spamming"
¡ A specific case of data mining
¡ There's a history of people using databases of email addresses to send
unsolicited messages, usually for the purposes of advertising,
marketing, or anti-social behavior
• Rate limits on queries
• Obscured/hidden, missing email information
• Acceptable use claims
¡ The mail system is built to defend against unwarranted email
• Sender reputation scoring

7. | 7
Skipping to the End
¤ We survived
¤ We contacted nearly 16,000 autonomous systems
¤ We weren't accused of violating email rules
¤ We weren't labelled "Spammer!"
¤ And the project appears to have succeeded in getting our message out
¤But it wasn't easy (enough to prevent this talk!)

8. | 8
In This Talk...
¤ This work was done with the WhoIs systems in place
¡ RDAP is the still (in) the future
¤ There's no "how to" in this talk
¡ Avoiding providing a recipe for "spamming"/data mining
¤ With a goal of "how can we provide a means for global operations contacts"
suggestions are made

9. | 9
Disclaimer: not disparaging RIR functions
¤ What's presented here seems at first blush to be suggesting work on
contacting operators could be better
¡ Well, it can, but it isn't clear there are "guilty parties"
¤ Registration information is largely treated as "garbage in, garbage out"
¡ An issue with public safety (or extrajudicial efforts like reputation
managers) when investigating abuse from an address – long known
issue
¡ But now we see this as possibly hindering operations
¤ And note that the KSK rollover may be a unique event

10. | 10
WhoIs yesterday, RDAP tomorrow
¤ Yes, WhoIs (port 43) or its web-version is being replaced by RDAP
¤ At the time of the survey, RDAP didn't seem mature enough to use "in the
heat of the moment"
¤ Treat this more as a problem statement/observation than a request for
action or suggestion for updating

11. | 11
Approach to using the RIR WhoIs
¤ The activity – given a list of AutNums, find email addresses for each
operator to invite to the survey
¤ First step – determine the right RIR or NIR source
¤ Second step – determine query and how to parse results
¤ Third step – select the addresses per AutNum

12. | 12
Which WhoIs Server? – ARIN or LACNIC as starting
¤ To determine region
¡ ARIN made this easiest, based on response
¡ LACNIC was possible, except for rate limiting and the complication of
having an NIR
¡ Other regions either weren't tried or didn't make it easy
¤ Complication – RIR and NIR operators would enter their own addresses in
fields when there was no "correct answer"
¡ "Inside" knowledge to realize this

13. | 13
Special flags
¤ ARIN has its unique set of flags
¤ RIPE and AFRINIC use special flags, burned into some whois clients
¡ Clients on MacOS and Linux differed, one way was the flags
¡ Linux:
$ whois -B -h whois.ripe.net as0
% This is the RIPE Database query service. ...
¡ MacOS:
$ whois -B -h whois.ripe.net as0
whois: illegal option – B ...
¤ WhoIs clients don't help: no "—version" to tell which is installed

14. | 14
National Internet Registries
¤ NIRs are a great idea, but little known outside the RIR community
¤ WhoIs services at NIRs differ
¡ Some run WhoIs for their region's address space
¡ Some run WhoIs for Autonomous System numbers in addition to the RIR
¡ Some run WhoIs for Autonomous System numbers instead of the RIR
¡ Note: "in addition to" versus "instead of"
¤ No clear documentation of this state of affairs

15. | 15
APNIC & its NIRs
¤ APNIC presented three challenges in parsing its responses
¤ One: NIR handling
¡ Seven NIRs but only one exclusively manages AutNum registration
information
¡ Took time to "discover this" and automate a way to parse the results
¤ Two: AutNum block information
¡ Had to learn to discard the APNIC "enclosing AutNum block" information
to get to the AutNum specific information
¤ Three: For NIR managed space, needed unique parsing code

16. | 16
LACNIC & its NIRs
¤ LACNIC presented a first—order challenge
¡ Rate limiting, but this could be relaxed with justification
¤ LACNIC also has multiple (two) NIRs
¡ And like APNIC, only one actively manages its AutNum Registrations
¤ LACNIC's "AutNum-active" NIR
¡ Also has rate limiting, again, relaxed with justification
¡ Has the overwhelming number of AutNum information – 16% of the
global numbers we needed to contact

17. | 17
Parsing Responses
¤ There's a "latent desire" of operators to include more information:
remarks: trouble: | Operational issues: noc@example.com |
remarks: trouble: | Peering issues: peering-office@example.com |
¤ Or hide information
remarks: Contact < op AT example DOT com > re general operations
¤ Or restrict contact
Comment: DO NOT E-MAIL ... AS IT WILL NOT BE READ/ANSWERED.
¤ Or "lay down the rules"
Comment: Please ... Failure to comply with this statement ...

18. | 18
Comments and Remarks
¤ In a world where "one lookup" is done, these make sense
¤ Where automation is involved, these don't

19. | 19
Up-level comments
¤ Whether RDAP has matured enough to help this is something I haven't
studied yet
¡ Matter of time, priorities
¤ A major concern was whether this is acceptable use
¡ But we decided to give it a try anyway

20. | 20
Experience with the "acceptable use"
¤ 16,000 AutNums contacted
¡ Note – number of operators is less, many run multiple AutNums
¡ One invitee noted we had an error in our email message. One!
¡ One invitee suggested that we were dancing around GDPR. One!
¡ One invitee teased us "are you for real".
¤ We did receive more outright notes of appreciation
¤ We did answer dozens of questions in responses to us
¤ Many probably ignored our call to participate in a survey

21. | 21
General Issues with RIR "WhoIs" information
¤ A lot of domain specific knowledge is needed
¡ Knowing who the RIRs are and the NIR structure
¤ Lack of common query – language or service point
¤ Lack of common response format
¤ Lack of specific fields for contact
¡ Use of remarks or comment fields to supply information
¤ Use of "dummy values" to indicate a who is "referral"
¤ Blanket defense against data mining (rate limiting)

22. | 22
Specific Issues with APNIC whois information
¤ Remove the AutNum block contact information in a response to a query
about a specific AutNum
¡ This will uncover some errors – missing information or mislabeled
information
¤ Clearer documentation when information is available only at an NIR's
WhoIs service
¤ Haven't researched the process for formalizing that suggestion

23. | 23
A peak into the future – RDAP formatting
¤ Quick inspections seem that RDAP is deployed as a "drop in" replacement
for WhoIs
¡ JSON seen to have this in sampled output
"remarks" : [ {
"title" : "... Comments",
"description" : [ "Please ...." ]
¤ Would be good to revisit the policies behind WhoIs in light of what RDAP
can do
¡ Tiered-access, richer data structures, and so on

24. | 24
A peak into the future – RDAP locations
¤ "urls" need to strive for consistency:
¡ https://rdap.arin.net/registry/autnum/0
¡ https://rdap.db.ripe.net/autnum/0
¡ https://rdap.afrinic.net/rdap/autnum/0
¡ http://rdap.apnic.net/autnum/0
• Typing "https://rdap.apnic.net/autnum/0" – note the
"s" in https - makes my browser go to Afrinic
¡ https://rdap-web.lacnic.net/autnum/0
¤ Without commonality, we need tools, with tools we need to have output
suitable for automation

25. | 25
Engage with ICANN
Visit us at icann.org
Thank You and Questions
Email: edward.lewis@icann.org
flickr.com/icann
linkedin/company/icann@icann
facebook.com/icannorg
youtube.com/icannnews soundcloud/icann
slideshare/icannpresentations
instagram.com/icannorg