[NCAP-Discuss] Workflow methods

Thu Nov 30 19:46:40 UTC 2023

> On Nov 30, 2023, at 11:59 AM, Matt Larson <matt.larson at icann.org> wrote:
> 
> 
> 
>> On Nov 29, 2023, at 1:54 PM, Casey Deccio <casey at deccio.net> wrote:
>> 
>> This is why I was suggesting a few calls ago that if the user experience is the same for (2) and (3), why don't we just skip to (3), so we also get better data?
> 
> (i.e., skipping controlled interruption and going directly to reject all)
> 
> The user experience between (2) and (3) might be the same (or essentially the same), but to channel Jeff Schmidt,

Well-channeled! :)

> there is notification value in the returned value of 127.0.53.53 for those administrators who investigate a failure, see that IP address, and do a Google search.

Yes!  Although, I have several thoughts on this.

(Please accept my apologies.  I'm going to shamelessly include quotes from previous messages sent to the mailing list...)

1. The Brand of 127.0.53.53

"... 127.0.53.53 is a thing.  But it is a thing for the very small population of Internet users that were affected by name collisions during the past eight or so years.  By referring to the population as "small", I'm not saying that those effects are insignificant (particularly to those that experienced them) or that we needn't care about those or any future collisions.  But this simply is not a universal thing; only those that were 1) somehow associated with it or 2) affected by it, have had any need to know anything about 127.0.53.53.  Why would anyone else need to know or care?" [1]

"... while 127.0.53.53 does now has a decade of experience, what does that really mean?

"... Does [this] mean that a new signaling method would now be confusing or that someone might rule out name collisions if they see an address other than 127.0.53.53?  Let me suggest that an individual or org that has experienced name collisions (and fixed the problem) will likely not experience it again (though possible).  And for a first-timer, does it really matter what the signal used to be?" [2]

2. Search Methodology

"... I don't doubt that searching the Web for an IP address is a thing.  But one of the challenges of the controlled interruption IP address -- and in fact the very reason that they *had* to search the Web -- was because they couldn't use any of the other, more common tools that have been available *much longer* than controlled interruption -- like Whois and reverse DNS (in-addr.arpa and ip6.arpa).  As a network operator, vulnerable Jedi sysadmin, and network researcher, Whois and reverse DNS (e.g., "dig -x") have always been my go-to tools, way before a Web search." [1]

"... While 127.0.53.53 has s decade of experience, sysadmins have been using other tools a lot longer and in other situations, including reverse DNS.  nslookup (or dig -x) can easily be used to issue a reverse lookup on an IP address--something that could not be done with 127.0.53.53." [2]

3. Analysis of Usage of 127.0.53.53

"There is clear evidence that "127.0.53.53" is being found.  In addition to the NCAP Study 1 and the JAS "Phase 2 report", the root cause analysis report also discusses this in sections 4.4 (Root Cause Identification of Name Collisions Reports) and 5 (Web Search Results Analysis).  However, these data points are biased because they don't tell us anything about those that experienced collisions and did *not* observe 127.0.53.53.  That was the point of the survey.  Nonetheless, I do not believe that either of these results can or should be looked at in isolation.  There are a lot of Web results, but they are biased.  The survey results are not biased (at least not in the same way) - but they are fewer.  Both data sets need to be considered!" [3]

"It appears that most of the ineffectiveness [in root cause identification] was due to the controlled interruption IP address not even being observed, which occurred in 71% of cases, according to the survey.  However, when the controlled interruption IP address was observed, the success rate in identifying ICANN and controlled interruption as the cause was between 50% and 76%, according to the survey results and the Web search results analysis, respectively." [4]

4. Proposals for Whois and Reverse DNS

In connection with the suggestion above that reverse DNS could work, here is a proposal for how the reject-all DNS would work:

Zone for the TLS suffix example:
------------
*.example. IN A 192.0.2.1

Zone for 2.0.192.in-addr.arpa:
------------
1.2.0.192.in-addr.arpa. IN PTR there-is-a-problem-with-your-dns.please-visit.name-collisions.icann.org.

Zone for icann.org:
------------
there-is-a-problem-with-your-dns.please-visit.name-collisions.icann.org. IN A 192.0.2.2
please-visit.name-collisions.icann.org. IN A 192.0.2.2
name-collisions.icann.org. IN A 192.0.2.2

192.0.2.1 is the server that actively rejects all incoming TCP communication attempts.
192.0.2.2 is a Web server that hosts information on name collisions.

Similarly, IP address block and/or ASN used could be registered with a special Whois entry.

> 
> The other thing that controlled interruption has going for it was that we’ve already used the technique many times and it didn’t break the Internet.

I cannot argue with this one. :)

However, let me say that I am not opposed to controlled interruption.  I think it's a relatively safe option, with which we have some experience -- and frankly the only experience related to name collisions.  However, given these other considerations, I don't know that that experience alone sets the bar so high that another methodology that gets us much more value could not be preferred.  Based on the fact that we had so little visibility in the last round, I think the value of the data logged in the reject-all proposal is too high to ignore.

I know that we're trying to reach consensus, and I know that part of the reason we are ending up with a "toolbox" is that there have been longstanding disagreements, so consensus looks more and more like name collisions smorgasbord.  And I also know that others (maybe all others) won't agree with me on this.  And that's okay.  I just want to make sure that I'm communicating my thoughts effectively.

Casey

[1] https://mm.icann.org/pipermail/ncap-discuss/2023-August/001233.html
[2] https://mm.icann.org/pipermail/ncap-discuss/2023-March/001132.html
[3] https://mm.icann.org/pipermail/ncap-discuss/2023-March/001130.html
[4] Root Cause Analysis Report.  https://docs.google.com/document/d/1YSvdH9Slws0iW3e6yoS04s5zANBnyMMFn9DUNE19fkg/edit?usp=sharing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20231130/7d0c383c/attachment.html>