[At-Large] The SSAC has published SAC123 and SAC122
Karl Auerbach
karl at cavebear.com
Fri Dec 22 23:45:31 UTC 2023
I am concerned about fragmentation of the net, but in ways that seem to
be divergent than the concerns I usually hear.
Many, probably most, of us Internet grey beards think of "the Internet"
in terms of the end-to-end principal of IP (v4 or v6) packets moving
without much hindrance from a source network interface with an
global/public IP address to another network interface with its own
global/public IP address.
I think that world is dead.
NATs put a nail into the end-to-end principle, but a nail that actually
helped us expand the IPv4 net without too much damage (except to some
old protocols, such as FTP, that carry IP addresses as data - most
modern protocols are reasonably amenable to NATs and TCP-concatenating
proxies.)
But there is a different way of looking at The Internet that is not
based on the old packet-based end-to-end principle. That way is to look
at The Internet as a collection of underlying internets (lower case) of
various technologies and addressing that are connected together so that
favored (there is much danger in that word "favored" - I'll get to that
in a moment) applications work between users.
This is really saying that we have turned the wheel once more in our
long progression from "networks" (e.g. ARPAnet) to "network of networks"
(Postel's "Internet") and now a "network of networks of networks" - a
world in which "end-to-end" refers not to packets but to application
inter-operation.
(This idea is the underlying theme of my somewhat long blog item from
2016: "Internet: Quo Vadis (Where are you going?" at
https://www.cavebear.com/cavebear-blog/internet_quo_vadis/ That note
envisioned an evolution - one that I believe is happening - in which the
once unified Internet changes into a system of highly protected
"islands" [such as a Google island, a Facebook island, a China island,
various fundamentalist religious islands, etc] that are interconnected
by guarded, taxed, filtered, and inspected bridges. This is not unlike
the walled cities of medieval Europe where the gates in the walls were
used as much for taxation and excluding undesirables and foreigners as
they were for defense in war.)
I mentioned that there is danger - that danger is that these
inter-island bridges will be open only to the most popular of
applications. To use a modern example, this future
Internet-of-internets, might allow protocols such as Twitter or Facebook
but might exclude new ideas such as Activity Pub (used by things like
Mastodon.) In other words, our notion of "innovation at the edge" will
not necessary be valid across this global Internet-of-internets.
I have concerns about this future that I see. But those concerns are
not necessarily fears as much as concessions to the reality that despite
our protestations, we humans tend to form clumps - tribes, nations,
corporations, religions - and we seem to like having the means to pull
up the drawbridges, in full or in part, that connect us with others. In
addition, security concerns, intellectual property concerns, and the
like are pushing in that direction - note recent legal developments
around the world to impose content restrictions or require proof-of-age
or proof-of-identity. Or there may be content restrictions, for
instance music that is still under copyright in the US may be in the
public domain elsewhere.
The early Internet grew out of the one-world ideas of the hippie culture
of the late 1960s - I know, I was there. But rather than tearing down
borders, the Internet is drawing more boundaries and making the old ones
more complicated.
--karl--
On 12/22/23 1:04 AM, Wolfgang Kleinwächter wrote:
> Thanks Karl,
> not totally new, but very helpful in the new environment of the 2020s.
> Isn´t this a more serious threat to "Internet Fragmentation" than
> govermental efforts to introduce "national sovereignty" (on the
> application layer) into the borderless cyberspace?
> And "Happy Holidays"!!
> Wolfgang
>> Karl Auerbach via At-Large <at-large at atlarge-lists.icann.org> hat am
>> 21.12.2023 20:31 CET geschrieben:
>> You make good points.
>> I have long accepted the concept of competing root systems and have
>> suggested various ways in which they could co-exist without causing
>> discomfort for users, particularly with regard to collisions between
>> divergent versions of the same TLD string. (See my year 1999 note:
>> https://www.cavebear.com/archive/cavebear/growl/issue_2.htm#multiple_roots
>> )
>> As you mention, we most definitely have some strong neo-root (as opposed
>> to fully distinct competing root) systems, such as Google's 8.8.8.8,
>> Comcast's 75.75.75.75, Cloudflare's 1.1.1.1, etc (and their IPv6
>> equivalents.) Whether the query streams to these are being data mined
>> is unknown to me. However, I doubt that in today's world of "shareholder
>> value" that commercial companies, particularly those who strongly
>> leverage their revenue streams from personal network usage data they
>> gather, will long resist the temptation to monetize those query streams
>> - indeed I would be surprised if some have not done so already. One may
>> ask, as I will do here: Why are these for-profit companies spending
>> not-inconsequential amounts of money to deploy services that are
>> redundant with the legacy root system? We would be naive to think that
>> these for-profit companies will long expend shareholder owned assets
>> without expectation of some compensating business advantage or revenue
>> stream.
>> The legacy root server system has one characteristic that we too often
>> overlook: It is run at an extremely high level of professionalism. It
>> is so high that there is usually no incentive to look to any other
>> offering.
>> And that professionalism has little to do with ICANN.
>> For instance, remember the limitation (caused by the way that names are
>> encoded into 512 byte UDP DNS packets) that places a limit of about 13
>> root name servers? Remember the contention that that caused in the
>> early days of ICANN because those 13 places were not equitably
>> distributed around the world? It was not ICANN that came up with the
>> notion of anycast groups of name servers, rather it was the external
>> community that created the idea and it was the root server operators who
>> went forth and did the work to make it happen - they did not give ICANN
>> notice of this, nor await ICANN permission, nor did they ask for ICANN
>> funding - they just did it. And as a result, the net is a better place.
>> DNS technology is not the perfect answer to all questions - I've written
>> about how DNS is insufficient to support the naming needs of net based
>> distributed applications that move, split, and merge like blobs in a
>> lava lamp. E.g. My 2010 note "On Entity Associations In A Cloud
>> Network" https://www.cavebear.com/archive/public/cloud-entities.pdf
>> And I see some well intentioned efforts that are trying to push DNS for
>> uses that it is not necessarily appropriate or in ways that could create
>> unnecessary risks of code flaws that could lead to attacks or security
>> vulnerabilities (this is especially true in the Internet-of-Things world
>> where code is often weak and relies on use in a confined, non-stressful
>> network environment. For example, should the coming generation of
>> TCP/IP based Engine Control Units [ECU] in a vehicle have to implement
>> Punycode and UTF-8 or ought they take the safer path of simply rejecting
>> any non-ASCII names?)
>> --karl--
>> On 12/21/23 3:34 AM, Christian de Larrinaga via At-Large wrote:
>>> I suspect it may well be too late (20 years too late!) to use the
>>> "reserve for posterity" approach for namespaces. A call to do this
>>> would
>>> no doubt be taken up at WIPO not ICANN anyway given the long standing
>>> issue with ICANN surrendering names as solely for business and
>>> governmental utility over its designed use for edge to edge resolution
>>> services. That would further push DNS away from the Internet edge
>>> and so
>>> itself be destabilising.
>>> There's also a question whether the single root argument made by IAB
>>> in 2000 is still gospel in a world where e2e offers secure
>>> frameworks for attestations of an infinite variety of namespaces and
>>> identifiers than is even conceivable for the DNS infrastructure.
>>> Particularly as DNS resolution is interpretative (punycode etc) today
>>> and largely anycast with geographical routing depending source and
>>> destination addressing which in turn depend on unofficial geo IP
>>> databases which are far from dependable given the growth in over and
>>> under private networks using their own choice of gateways into the
>>> "Internet". I am almost never in the place "The Internet" tells me I am
>>> in!
>>> But I take your insider political perspective on the ICANN
>>> firmament. But it rather confirms my concern that ICANN has been far to
>>> comfortable with the DNS industry as a private club believing everybody
>>> has to go through the DNS that it "controls".
>>> The reality is ICANN does not control the DNS just access to the root
>>> server resolution system. That is implemented as a tax and unsurprising
>>> if users think differently
>>> C
>>> Alejandro Pisanty via At-Large <at-large at atlarge-lists.icann.org>
>>> writes:
>>>> 1. ( ) text/plain (*) text/html
>>>> Matthias,
>>>> thanks very much for this rich information. The summaries alone
>>>> should be considered as strong alarm signs. The
>>>> foci of attention of ALAC and At-Large seem way out of phase,
>>>> lagging years behind these developments. This is
>>>> not uniform; some RALOs are in even worse shape, considering recent
>>>> publicly available evidence.
>>>> Alejandro Pisanty
>>>> On Thu, Dec 21, 2023 at 12:21 AM Matthias M. Hudobnik via At-Large
>>>> <at-large at atlarge-lists.icann.org> wrote:
>>>> Hi colleagues, the SSAC has published SAC123 and SAC122.
>>>> ### SSAC Report on the Evolution of Internet Name Resolution (SAC123):
>>>> · Internet name resolution is evolving beyond just the global DNS
>>>> to include alternative naming systems
>>>> that are experimenting with different approaches for reasons like
>>>> speed, privacy, censorship resistance, and
>>>> governance.
>>>> · Many alternative systems adopt DNS name syntax to leverage
>>>> existing software.
>>>> · Two concerning trends are increased ambiguity where the same name
>>>> can resolve differently in
>>>> different systems, and less visibility of names to end users even
>>>> as names remain vital for security and trust.
>>>> · Maintaining integrity and coordination in the shared domain
>>>> namespace is important.
>>>> · The report explores different perspectives on these trends from
>>>> end users and developers.
>>>> · It identifies proposals to facilitate namespace coordination and
>>>> recommends ICANN continue tracking
>>>> these issues and provide regular updates to the community.
>>>> I highly recommend having a look at chapter: 7.1 End Users (some
>>>> key aspects as follows):
>>>> · Domain names used to play an important role for end users in
>>>> discovering web resources, but search
>>>> engines have now replaced them as the primary method of discovery.
>>>> · End users today rarely directly interact with domain names due to
>>>> the dominance of search engines and
>>>> mobile devices. Features like browser "omnibars" also allow more
>>>> free-form input.
>>>> · Other identifiers like QR codes and social media handles now also
>>>> compete for users' attention rather
>>>> than domain names.
>>>> · Domain names are becoming less visible in users' environments,
>>>> yet they still provide an underlying
>>>> ubiquitous resolution context relied upon by other technologies.
>>>> · Surveys found search engines are by far the predominant method
>>>> for accessing websites, with domain
>>>> name usage declining. QR code usage is increasing but still limited
>>>> except in Asia.
>>>> · Decreased domain name visibility makes it easier for fraudsters
>>>> to deceive users with lookalike names.
>>>> Users are also generally unaware that some TLDs signal a different
>>>> resolution context.
>>>> In summary, domain names are no longer the primary method end users
>>>> employ to find and access Internet
>>>> resources, decreasing their visibility and understandability while
>>>> introducing security issues.
>>>> Link to the report:
>>>> https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-123-15-12-2023-en.pdf
>>>>
>>>> ### SSAC Report on Urgent Requests in gTLD Registration Data Policy
>>>> (SAC122)
>>>> · Focus is on handling of Urgent Requests in proposed gTLD
>>>> registration data policy
>>>> · Urgent Requests refer to imminent threats to life, injury,
>>>> infrastructure or child exploitation
>>>> · Proposed policy requires response to Urgent Requests in 24 hours
>>>> generally
>>>> · SSAC contends proposed policy for Urgent Requests is not fit for
>>>> purpose
>>>> · Definition and required response times are incompatible
>>>> · Questions if need and rationale for separate Urgent Request
>>>> process is fully justified
>>>> · Existing ICANN policy and industry practices offer useful precedents
>>>> · Proposed extensions allow responses up to 7 days, not reflecting
>>>> urgency
>>>> · Lack of concrete data on frequency and handling of such requests
>>>> currently
>>>> · Risks reputation of ICANN multistakeholder model effectiveness
>>>> - Provides 3 recommendations
>>>> § Add structure to ensure Urgent Requests handled expediently
>>>> § Tighten response time requirements to be fit for purpose
>>>> § Gather data on Urgent Requests for future policy making
>>>> Link to the report:
>>>> https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-122-12-12-2023-en.pdf
>>>>
>>>> Have a nice evening!
>>>> Best,
>>>> M.
>>>> ______________________________
>>>> Ing. Mag. Matthias M. Hudobnik
>>>> FIP • CIPP/E • CIPT • DPO • CIS LA
>>>> matthias at hudobnik.at
>>>> http://www.hudobnik.at
>>>> @mhudobnik
>>>> _______________________________________________
>>>> At-Large mailing list
>>>> At-Large at atlarge-lists.icann.org
>>>> https://atlarge-lists.icann.org/mailman/listinfo/at-large
>>>> At-Large Official Site: http://atlarge.icann.org
>>>> _______________________________________________
>>>> 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.
>> _______________________________________________
>> At-Large mailing list
>> At-Large at atlarge-lists.icann.org
>> https://atlarge-lists.icann.org/mailman/listinfo/at-large
>> At-Large Official Site: http://atlarge.icann.org
>> _______________________________________________
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://atlarge-lists.icann.org/pipermail/at-large/attachments/20231222/e0207184/attachment-0001.html>
More information about the At-Large
mailing list