[NCAP-Discuss] Addressing concerns in context

Mon Dec 5 18:05:59 UTC 2022

Casey,

Thanks for this explanation.

Out of curiosity, regarding this comment: "Also, the last time something
like this was done at similar scale (Site Finder), the public outcry was
huge."

How would you characterize the relative scale of Site Finder in 2003
compared to the relative scale of name collision analysis for the next
round of new gTLDs in ~2025?

thanks,

tom

On Mon, Dec 5, 2022 at 12:54 PM Casey Deccio <casey at deccio.net> wrote:

> Hi all,
>
> I mentioned in last Wednesday's call that I wanted to make some
> clarifications with regard to some of the back-and-forth discussions that
> were had on the mailing list in recent weeks.  The discussions got
> complicated because they lost context over time.  This message is intended
> to restore some context and address three points in particular.  Please
> note that they are not about endorsing a particular solution but to address
> concerns about the proposed solutions.
>
>
> 1. The criticality of IPv6 support in manifesting name collisions.
>
> First, let me be clear on the following: 1) I am on board with promoting
> and helping with increased adoption of IPv6; and 2) I am a researcher in
> the area of Internet measurement, and as such, for me, more data is better.
>
> That being said, an IPv4-only name collision alerting system is effective
> for all systems and applications that include *any sort* of IPv4
> connectivity.  It is only deficient for systems that *lack IPv4 support*.
> In other words, it is independent of general IPv6 growth, promotion, or
> support, until systems and applications drop IPv4 functionality.
>
> Finally, in saying this, I am neither promoting controlled interruption
> nor saying that we should not desire IPv6 support.  I am merely stating
> that in terms of today's Internet (and frankly for the foreseeable future),
> IPv6 support is not essential to manifesting name collisions, and it
> certainly does not make IPv6-supporting solutions "vastly superior" by that
> characteristic alone.  That is simply a mischaracterization.
>
> For more, please see the sub-section "Application Coverage" under
> "Alerting Effectiveness and Coverage" in the comparison document.
>
>
> 2. The comparison of risk and disruptiveness between active collision
> assessment and controlled interruption.
>
> It was stated that "active collision assessment and controlled
> interruption are equivalently risky and equivalently disruptive."
>
> "Equivalently disruptive."  Both active collision assessment and
> controlled interruption involve 1) DNS servers returning an answer to a
> requesting client, where a negative response was the expected response; and
> 2) the application acting on that answer (i.e., with transport-layer
> communications), where it previously would not have.  Thus, in both cases,
> communications are interrupted.
>
> The interruptions, however, are not equivalent.  Controlled interruption
> is expected to always return a "quick-response" error, while the error
> behavior for active collision assessment varies, depending on several
> factors, including network configuration, server configuration, and more.
>
> "Equivalently risky."  As I have mentioned before, "risk" is a term that
> is both highly loaded and highly ambiguous.  Nonetheless, the very fact
> that transport-layer communications leave the client with active collision
> assessment is a significant leap from transport-layer communications never
> leaving the host systems, as it is with controlled interruption.
>
> More importantly, active controlled interruption involves intercepting
> communications for proposed ports/applications and returning custom content
> (ports and applications that are not even enumerated at this point).
> Perhaps the two biggest concerns are that 1) application-layer data *will
> be* communicated; and 2) the user experience *will be* fraught with issues,
> including (but not limited to) TLS certificate warnings.  Also, the last
> time something like this was done at similar scale (Site Finder), the
> public outcry was huge.
>
> For more, please see the sections entitled "Operational Continuity,
> Security, and Privacy", "User Experience", and "Public Response" in the
> comparison document.
>
>
> 3. The evaluation of controlled interruption in meeting its goals.
>
> It has been stated that "controlled interruption did not achieve its
> desired objective."  This is based on the finding from the root cause
> analysis that "[c]ontrolled interruption is effective at disruption, but
> not at root cause identification." The problem is that it focuses only on
> the second half of the sentence and ignores the first half that indicates
> that it was "effective at disruption."  Disruption was part of the goal
> related to alerting.  But more important than that was *change*.  Note that
> another finding from the root cause analysis is the following: "Usage of
> private DNS suffixes colliding with newly delegated TLDs has decreased over
> time."  Measurements show that potential collisions have consistently
> decreased since 2014.  To me, this is the more important part--the fact
> that changes in the ecosystem were observed related to queries associated
> with name collisions.  Even though we have some qualitative data that help
> us anecdotally understand problem resolution, we c
>  annot definitively point to controlled interruption as the cause for the
> decrease in queries.  Nevertheless, the trend suggests that there was a
> clear decrease in queries associated with name collisions, which is a "good
> thing".
>
> For more, please see "Findings" section in the root cause analysis doc.
>
>
> Cheers,
> Casey
> _______________________________________________
> NCAP-Discuss mailing list
> NCAP-Discuss at icann.org
> https://mm.icann.org/mailman/listinfo/ncap-discuss
>
> _______________________________________________
> 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 (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). 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.
>

-- 
Thomas Barrett
President
EnCirca, Inc
+1.781.942.9975 (office)
400 W. Cummings Park, Suite 1725
Woburn, MA 01801 USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20221205/bd0b7bf4/attachment.html>