Cambodia looking at new registry overseer

The Cambodian government is reportedly planning to create a new group to oversee its national ccTLD, .kh.

According to The Phnom Penh Post, the local telecommunications ministry is considering legislation that would create KH Network Information Centre.

KHNIC would be modeled on APNIC and combine domain name and IP address management under one roof, the report says.

.kh is currently delegated to Telecommunication Regulator of Cambodia and managed by Telecom Cambodia.

There are reportedly only around 3,000 .kh domains under management. The infrastructure-poor south-east Asian country has about 16.5 million inhabitants but only around 250,000 fixed broadband subscribers.

ICANN CTO: no reason to delay KSK rollover

ICANN’s board of directors will be advised to go ahead with a key security change at the DNS root — “the so-called KSK rollover” — this October, according to the organization’s CTO.
“We don’t see any reason to postpone again,” David Conrad told DI on Monday.
If it does go ahead as planned, the rollover will see ICANN change the key-signing key that acts as the trust anchor for the whole DNSSEC-using internet, for the first time since DNSSEC came online in 2010.
It’s been delayed since last October after it emerged that misconfigurations elsewhere in the DNS cloud could see potentially millions of internet users see glitches when the key is rolled.
Ever since then, ICANN and others have been trying to figure out how many people could be adversely affected by the change, and to reduce that number to the greatest extent possible.
The impact has been tricky to estimate due to patchy data.
While it’s been possible to determine a number of resolvers — about 8,000 — that definitely are poorly configured, that only represents a subset of the total number. It’s also been hard to map that to endpoints due to “resolvers behind resolvers behind resolvers”, Conrad said.
“The problem here is that it’s sort of a subjective evaluation,” he said. “We can’t rely on the data were seeing. We’re seeing the resolvers but we’re not seeing the users behind the resolvers.”
Some say that the roll is still too risky to carry out without better visibility into the potential impact, but others say that more delays would lead to more networks and devices becoming DNSSEC-compatible, potentially leading to even greater problems after the eventual rollover.
ICANN knows of about 8,000 resolver IP addresses that are likely to stop working properly after the rollover, because they only support the current KSK, but that’s only counting resolvers that automatically report their status to the root using a relatively new internet standard. There’s a blind spot concerning resolvers that do not have that feature turned on.
ICANN has also had difficulty reaching out to the network operators behind these resolvers, with good contact information apparently only available for about a quarter of the affected IP addresses, Conrad said.
Right now, the best data available suggests that 0.05% of the internet’s population could see access issues after the October 11 rollover, according to Conrad.
That’s about two million people, but it’s 10 times fewer people than the 0.5% acceptable collateral damage threshold outlined in ICANN’s rollover plan.
The 0.05% number comes from research by APNIC, which used Google’s advertising system to place “zero-pixel ads” to check whether individual user endpoints were using compatible resolvers or not.
If problems do emerge October 11 the temporary solution is apparently quite quick to implement — network operators can simply turn off DNSSEC, assuming they know that’s what they’re supposed to do.
But still, if a million or two internet users could have their day ruined by the rollover, why do it at all?
It’s not as if the KSK is in any danger of being cracked any time soon. Conrad explained that a successful brute-force attack on the 2048-bit RSA key would take longer than the lifetime of the universe using current technology.
Rather, the practice of rolling the key every five years is to get network operators and developers accustomed to the idea that the KSK is not a permanent fixture that can be hard-coded into their systems, Conrad said.
It’s a problem comparable to new gTLD name collisions or the Y2K problem, instances where developers respectively hard-coded assumptions about valid TLDs or the century into their software.
ICANN has already been reaching out to the managers of open-source projects on repositories such as Github that have been seen to hard-code the current KSK into their software, Conrad said.
Separately, Wes Hardaker at the University of Southern California Information Sciences Institute discovered that a popular VPN client was misconfigured. Outreach to the developer saw the problem fixed, reducing the number of users who will be affected by the roll.
“What we’re trying to avoid is having these keys hardwired into firmware, so that that it would never be changeable,” he said. “The idea is if you exercise the infrastructure frequently enough, people will know the that the key is not permanent configuration, it’s not something embedded in concrete.”
One change that ICANN may want to make in future is to change the algorithm used to generate the KSK.
Right now it’s using RSA, but Conrad said it has downsides such as rather large signature size, which leads to heavier DNSSEC traffic. By switching to elliptical curve cryptography, signatures could be reduced by “orders of magnitude”, leading to a more efficient and slimline DNS infrastructure, Conrad said.
Last week, ICANN’s Root Server Stability Advisory Committee issued an advisory (pdf) that essentially gave ICANN the all-clear to go ahead with the roll.
The influential Security and Stability Advisory Committee has yet to issue its own advisory, however, despite being asked to do so by August 10.
Could SSAC be more cautious in its advice? We’ll have to wait and see, but perhaps not too long; the current plan is for the ICANN board to consider whether to go ahead with the roll during its three-day Brussels retreat, which starts September 14.

.sexy may be blocked in Iran

Some networks in Iran appear to be systematically blocking Uniregistry’s .sexy gTLD.
That’s one of the conclusions of a slightly odd experiment commissioned by ICANN.
The newly published An Analysis of New gTLD Universal Acceptance was conducted by APNIC Labs. The idea was to figure out whether there are any issues with new gTLDs on the internet’s DNS infrastructure.
It concluded that there is not — new gTLDs work just fine on the internet’s plumbing.
However, the survey — which comprised over 100 million DNS resolution attempts — showed “One country, Iran, shows some evidence of a piecemeal block of Web names within the .sexy gTLD.”
The sample size for Iranian attempts to access .sexy was just 30 attempts. In most cases, users were able to resolve the names with DNS, but HTTP responses appeared to be blocked.
The survey did not test .porn or .adult names, but it might be safe to assume similar behavior in those gTLDs.
APNIC also concluded that Israel’s .il ccTLD, included in the report as a known example of TLD blocking at the national level, is indeed blocked in Iran and Syria.
The study also found that there may be issues with Adobe’s Flash software, when used in Internet Explorer, when it comes to resolving internationalized domain names.
That conclusion seems to have been reached largely because the test’s methodology saw a Flash advertisement discretely fetching URLs in the background of web pages using Google Ads.
When the experimenters used HTML 5 to run their scripts instead, there was no problem resolving the names.
The study did not look at some of the perhaps more pressing UA issues, such as the ability for registrants and others to use new gTLD domain names in web applications.

IPv4 addresses to run out Thursday

ICANN will announce the final depletion of its pool of IPv4 addresses this Thursday.
The Number Resource Organization will hold a “ceremony and press conference to make a significant announcement and to discuss the global transition to the next generation of Internet addresses”.
The NRO is ICANN’s supporting organization representing Regional Internet Registries, the outfits responsible for handing out IP addresses to network operators.
ICANN, the Internet Society and the Internet Architecture Board will also participate in the event, scheduled for Thursday February 3 at 1430 UTC. It will be webcast here.
Today, APNIC, the Asia-Pacific RIR, said that it has been assigned two /8 blocks of addresses, meaning IANA is down to its Final Five chunks.
Thursday’s ceremony will presumably entail ICANN/IANA officially handing out these last five blocks to the five RIRs, one each, as called for by its allocation policy.
After that, it’s all gone. No more IPv4. The age of IPv6 is upon us.
It is currently estimated that the RIRs will themselves run out of IPv4 in September. After that, if they need IP addresses they’ll receive IPv6.
IPv4 is rapidly becoming a scarce commodity.
Many people, including ICANN chairman Peter Dengate Thrush, have predicted a “gray market” for addresses to appear, with address blocks changing hands for less than the cost of upgrading to IPv6.
The focus on Thursday, however, will be all about the measures network operators need to implement in order to remain viable on an internet increasingly running IPv6 equipment.

IPv4 depletion “imminent”

The pool of IPv4 address space available to regional internet registries will likely expire in “early 2011”, according to the Number Resource Organization.
ICANN/IANA said today that it has allocated two more /8 blocks of IPv4, approximately 33.5 million addresses, to APNIC, the Asia-Pacific RIR.
This means there are only 12 /8 blocks left, about 5% of the total allowable addresses under IPv4.
Under IANA’s rules, the final five /8s will all be allocated at the same time, one to each of the five RIRs. So there are only seven left to be handed out under the normal process.
The NRO followed up ICANN’s blog post with a press release stressing the importance of adopting IPv6. From the release (my emphasis):

“This is a major milestone in the life of the Internet, and means that allocation of the last blocks of IPv4 to the RIRs is imminent,” states Axel Pawlik, Chairman of the Number Resource Organization (NRO), the official representative of the five RIRs. “It is critical that all Internet stakeholders take definitive action now to ensure the timely adoption of IPv6.”
…
According to current depletion rates, the last five IPv4 address blocks will be allocated to the RIRs in early 2011. The pressure to adopt IPv6 is mounting. Many worry that without adequate preparation and action, there will be a chaotic scramble for IPv6, which could increase Internet costs and threaten the stability and security of the global network.

There’s a danger that things could start getting messy over the next couple of years, as the RIRs themselves start running out of IPv4 and network managers worldwide start discovering their IPv6 capabilities are not up to scratch.