It is being held 28 February through 5 March, at the Sheraton and also at the nearby Melia Mexio Reforma hotel.

All ICANN staff, board members, and community members are invited and encouraged to attend the sessions, all of which are open to everyone.

As proposed by At-Large Community, the Summit has the following objectives:

• Develop the Community’s capacity for engagement in ICANN by increasing its knowledge and understanding of the key issues confronting ICANN and ICANN’s roles and responsibilities;

• Provide an opportunity for the community to finalise and present its advice on some of the most important issues facing the ICANN community today, and last but not least,

• Highlight the successes of the community in recent years and build upon them to ensure that the interests of the world’s more than 1 billion individual Internet users are well represented in the development of Internet name and number policy.

Summit activities include:

• An opening and closing General Session of all participants (Saturday the 28th),

• Five working groups on key policy issues confronting ICANN,

• Thematic Sessions (workshops on topics submitted by community members for inclusion in the Summit programme)

and much more!

The structure, format, and content of the Summit have been developed through a completely bottom-up process. For example, the five policy working group topics were chosen by surveying the entire At-Large community. Members were asked to rank in order of preference their priorities for policy work during the Summit, and the top five choices were then automatically selected as the subjects for the five working groups to tackle. The subjects are:

• At-Large Community Engagement in ICANN

• The Future Structure and Governance of ICANN

• New gTLDs including IDN gTLDs

• ICANN Transparency and Accountability

• DNS Security Issues within ICANN’s Remit

The Thematic Session subjects are all community driven, too. Community members were asked to propose topics and the format for these sessions and the Summit working group is then taking the proposals and scheduling them. Details of these sessions will shortly be posted to the main meeting schedule at http://mex.icann.org/full-sched.

These sessions are designed to provide Summit delegates with a greater understanding of At-Large and ICANN mandates, structures, and processes and supply the tools needed by At-Large to better involve and engage their members in ICANN activities and policy development processes. Many of them delve into specific policy subjects in more detail and with an At-Large-specific viewpoint.

The opening General Session on Saturday will consist of a full schedule of briefings and panel discussions on current work in ICANN, many led by community members with expertise in the subjects concerned, such as DNSSec, IDNs, and the IPv4-IPv6 transition.

The Closing General Session on Thursday will provide a wrap up of key outcomes and deliverables and identify next steps for the At-Large Community. Expect the unexpected on Thursday morning – it will be a tour-de-force summary of the Summit using a very audiovisual format that should keep everyone engaged.

Last but not least, the public workshop on Wednesday entitled “eCrime and Abuse of the DNS Forum” which is sure to be one of the most popular workshops of the entire ICANN meeting is being organised in cooperation with the Summit and will have various experts from At-Large participating in it.

For those who are interested in learning more, visit the Summit microsite at http://www.atlarge.icann.org/summit. We hope to see you in Mexico City!

The Conflicker/Downadup worm infects computers running Windows operating systems variants. The infected computers can be remotely controlled (i.e. forming a botnet) and the infection propagates through a number of different routes. The worm has been estimated as infecting as many as 10 million hosts and data from the security community indicates the number is at least 1.5 million. One mechanism the worm’s code uses to enable control is to download commands by accessing specific date-based domain names.

In mid-January, security community researchers began to understand which future domain names that the botnet would seek to utilize. These researchers sought cooperation from these registries to protect the names that would potentially be utilized. ICANN has worked with the registries, the security researcher community and Microsoft to share information, discuss specific mitigation steps and reach out globally across all involved parties to block the spread of the worm and formation of a massive botnet. This type of collaborative response is a model for dealing with distributed, evolving threats to the Internet’s security and resiliency.

We believe that malicious code using the DNS to enable propagation of worms and establishment of large botnets is likely to continue, even increase, in the short term. We are continuing our collaboration in response to the Conflicker/Downadup worm/botnet. DNS registries, the security community, and ICANN staff have agreed to initiate a working group to establish how ICANN can enable timely and effective responses to such worm/botnet situations that involve abuse of the DNS and threaten Internet security and resiliency.

Greg Rattray

ICANN Chief Internet Security Advisor

L.root-servers.net, operated by ICANN, became the seventh of the root servers to have it’s IPv6 address records (AAAA) added into the DNS root-zone. The addition of IPv6 service is part of ICANN’s ongoing commitment to act as a leader in enabling IPv6 services throughout the DNS.

The new IPv6 address is 2001:500:3::42

To access this service DNS operators should update their hints files. In fact checking that you have the latest hints file on a regular basis is always good operational practice.

The latest hints files are available at the following URLs:

ftp://rs.internic.net/domain/named.root
ftp://ftp.internic.net/domain/named.root

The root servers currently answering on IPv6 are:

A.ROOT-SERVERS.NET 2001:503:ba3e::2:30
F.ROOT-SERVERS.NET 2001:500:2f::f
H.ROOT-SERVERS.NET 2001:500:1::803f:235
J.ROOT-SERVERS.NET 2001:503:c27::2:30
K.ROOT-SERVERS.NET 2001:7fd::1
L.ROOT-SERVERS.NET 2001:500:3::42
M.ROOT-SERVERS.NET 2001:dc3::35

How does the DNS work?

The DNS can be considered to be a question-and-answer system. When you type in an address like “icann.org” into a web browser, your computer needs to turn that into a numeric address of the computer hosting that website. To do this, it sends a question over the Internet to a DNS server “Where is icann.org?” The DNS server sends back an answer, “The address is 192.0.2.0”.

How do you attack the DNS?

Let’s say I want to execute an attack on this question and answer exchange, in order to convince the computer to go to the wrong address. When the computer I wish to attack asks a question, my goal is to provide a fake response back to that computer quicker than the real server comes back with the response. By getting my forged answer back faster, the computer will proceed using my answer, rather than the official one.

So, if I send back a fake address to a computer, I can get that computer to go to a different address than the one intended. For example, on that address I might have set up a fake website intended to take someone’s sensitive data, like a replica of a bank’s website.

If I manage to attack one computer why is that a big deal?

A successful attack on one computer in isolation can be problematic for the user of that computer, but it is not that interesting to an attacker to succeed against only one person. Unlucky for us, just one successful attack can very easily have wider consequences. Let me explain.

The DNS is made much more efficient by the use of “caching” name servers. These name servers sit at ISPs, or on corporate networks, and perform DNS lookups on behalf of customers. It then stores the answers it receives in a cache, so for future lookups for the same domain it does not repeat the lookup – it just remembers the previous answer.

This means that if you execute an attack and it gets stored in a cache, it can actually impact many people over and over again, because that answer will be redistributed to everyone that uses that same caching server.

This is why this type of attack is usually called a “cache poisoning” attack, because by poisoning the cache with the wrong data, it creates a much more serious problem.

So I just send back an answer quicker, and that’s it?

It is not quite as simple as just sending a quicker answer back to a computer, you also have to guess certain attributes correctly on the answer that match the question. For example, your answer needs to go back to the same computer the question originated. You also need match the question that was being asked in your answer.

It is simple, however, to guess most of the attributes. As you know which computer you are trying to attack, you don’t need to guess that. As you know which domain you are trying to impersonate, that is also a given. Conventionally, there are only two variables. One variable is you need to guess which server the answer is coming from. The average domain on the Internet has around two or three name servers, only one of which will respond to any given query. Therefore you have about a one in three chance of guessing that correctly. The second variable is a unique reference number (formally, a “transaction ID”), that has about 65000 possibilities. Therefore you have about a 1 in 65000 chance of guessing that correctly.

Earlier this year, security researcher Dan Kaminsky found that it is devastatingly simple to exhaust all those possibilities in a very short amount of time by performing an attack in a certain way. How short? Well, British DNS researcher John Dickinson did some tests and found that on average he could successfully attack a server in just 1.3 seconds.

How do you fix the problem?

The sad news is there is no real solution as far as the regular DNS is concerned. It is not like a security hole in a piece of software that can be repaired with an update. This is an architectural flaw in the DNS protocol itself. There are patches for DNS software, but these only attempt to make executing an attack more difficult, they don’t solve the problem.

Some of the short term approaches to make attacks more difficult are as follows:

1. Randomise the “source port”. One of the attributes in the packet that an attacker needs to guess is called the port number. For architectural reasons, this needs to be port 53 on the way to the server — this is how the server realises it is a DNS query as opposed to a different type of query. However, the port number that a response is sent back to doesn’t need to be port 53. By randomising this, you make it harder for an attacker to guess. Much of the software updates to this problem in mid-2008 related to adding source port randomisation.
2. Block open recursive name service. If you provide access to a caching name server to the whole Internet, then it is very easy for the whole Internet to execute an attack against your server. If you limit access to just those who need it (i.e. your local network), then you reduce that risk.
3. Experimentation with capitalisation of domains. Domains in practice are not case sensitive – if you type ICANN.ORG or icann.org, it means the same thing. However, inside the DNS protocol itself, the encoded transmission between computers actually is case sensitive. This property can be used to add some more randomness to transmissions. If my computer sends off a question asking about “iCaNn.OrG” and gets back an answer for “icann.org”, it can throw it away as untrustworthy. This approach is still experimental and being discussed.

The net effect of these attempts to reduce the risk of attacks primarily involve adding more randomness for the attacker to guess. These approaches approximately double the number of “bits” of randomness. To be clear though, they only make an attack harder, but an attack is still viable. Furthermore, we know that both network speeds and computer speeds get faster and faster each year. These are the two things that slow down an attacker. Therefore, we know that successful attacks will just be easier and easier into the future.

If there is no short term solution, what is the long term solution?

While the DNS itself can’t be properly fixed for the security problem, a new protocol that overlays the DNS called DNSSEC does. DNSSEC uses a system of certification to show that a DNS answer has not been modified. If someone tries to execute an attack, the certificate won’t validate, and the incorrect answer will be thrown away.

DNSSEC is difficult to deploy. It requires upgrades in DNS servers, it changes the way domain name holders manage their name servers, and it adds extra complexity. However, with the knowledge that DNS attacks are so simple to execute without it, there is growing consensus that the pain it will take to deploy is less than the pain of a DNS that you can no longer trust.

More information

You can view the presentation slides used in Cairo.

As a graduate student at UCLA in the late 1960s, Jon was deeply involved in the ARPANET project, becoming the first custodian of the Request for Comment note series inaugurated by Stephen D. Crocker. He also undertook to serve as the “Numbers Czar” tracking Domain Names, Internet Addresses, and all the parameters, numeric and otherwise, that were key to the successful functioning of the burgeoning ARPANET and, later, Internet protocols. His career took him to the east and west coasts of the United States but ultimately led him to the University of Southern California’s Information Sciences Institute (ISI) where he joined his colleagues, Danny Cohen, Joyce K. Reynolds, Daniel Lynch, Paul Mockapetris and Robert Braden, among many others, who were themselves to play important roles in the evolution of the Internet.

It was at ISI that Jon served longest and as the end of the 20th Century approached, began to fashion an institutional home for the work he had so passionately and effectively carried out in support of the Internet. In consultation with many colleagues but particularly with Joseph Sims of the Jones Day law firm and Ira Magaziner, then at the Clinton administration White House, Jon worked to design an institution to assume the IANA responsibilities. Although the path to its creation was rocky, the Internet Corporation for Assigned Names and Numbers (ICANN) was officially created in early October, 1998, just two weeks before Jon’s untimely death on October 16.

In 1998 there were an estimated 30 million computers on the Internet and an estimated 70 million users. In the ensuing decade, the user population has grown to almost 1.5 billion and the number of servers on the Internet now exceeds 500 million (not counting episodically connected laptops, personal digital assistants and other such devices). As this decade comes to a close, the Domain Name System is undergoing a major change to accommodate the use of non-Latin character sets in recognition that the world’s languages are not exclusively expressible in one script. A tidal wave of newly Internet-enabled devices as well as the increasing penetration of Internet access in the world’s population is consuming what remains of the current IPv4 address space, driving the need to adopt the much larger IPv6 address space in parallel with the older one. Over three billion mobiles are in use and roughly 15% of these are already Internet-enabled.

Jon would take considerable satisfaction knowing that the institution he worked hard to create has survived and contributed materially to the stability of the Internet. Not only has ICANN managed to meet the serious demands of Internet growth and importance in all aspects of society, but it has become a worked example of a new kind of international body that embraces and perhaps even defines a multi-stakeholder model of policy making. Governments, civil society, the private sector and the technical community are accommodated in the ICANN policy development process. By no means a perfect and frictionless process, it nonetheless has managed to take decisions and to adapt to the changing demands and new business developments rooted in the spread of the Internet around the globe.

Always a strong believer in the open and bottom-up style of the Internet, Jon would also be pleased to see that the management of the Internet address space has become regionalized and that there are now five Regional Internet Registries cooperating on global policy and serving and adapting to regional needs as they evolve. He would be equally relieved to find that the loose collaboration of DNS root zone operators has withstood the test of time and the demands of a hugely larger Internet, showing that their commitment has served the Internet community well. Jon put this strong belief into practice as he was founder and ex-officio trustee of ARIN.

As the very first individual member of the Internet Society he helped to found in 1992, Jon would certainly be pleased that it has become a key contributor to the support of the Internet protocol standards process, as intended. The Internet Architecture Board and Internet Engineering and Research Task Forces as well as the RFC editing functions all receive substantial support from the Internet Society. He might be surprised and pleased to discover that much of this support is derived from the Internet Society’s creation of the Public Internet Registry to operate the .ORG top level domain registry. The Internet Society’s scope has increased significantly as a consequence of this stable support and it contributes to global education and training about the Internet as well as to the broad policy developments needed for effective use of this new communication infrastructure.

As a computer scientist and naturalist, Jon would also be fascinated and excited by the development of an interplanetary extension of the Internet to support manned and robotic exploration of the Solar System. This very month, the Jet Propulsion Laboratory will begin testing of an interplanetary protocol using the Deep Impact spacecraft now in eccentric orbit around the sun. This project began almost exactly ten years ago and is reaching a major milestone as the first decade of the 21st Century comes to an end.

It is probable that Jon would not agree with all the various choices and decisions that have been made regarding the Internet in the last ten years and it is worth remembering his philosophical view:

“Be conservative in what you send and liberal in what you receive.”

Of course, he meant this in the context of detailed protocols but it also serves as a reminder that in a multi-stakeholder world, accommodation and understanding can go a long way towards reaching consensus or, failing that, at least toleration of choices that might not be at the top of everyone’s list.

No one, not even someone of Jon’s vision, can predict where the Internet will end up decades hence. It is certain, however, that it will evolve and that this evolution will come, in large measure, from its users. Virtually all the most interesting new applications of the Internet have come, not from the providers of various Internet-based services but from ordinary users with extraordinary ideas and the skills to try things out. That they are able to do this is a consequence of the largely open and non-discriminatory access to the Internet that has prevailed over the past decade. Maintaining this spirit of open access is the key to further development and it seems a reasonable speculation that if Jon were still with us, he would be in the forefront of the Internet community in vocal and articulate support of that view.

A ten-year toast seems in order. Here’s to Jonathan B. Postel, a man who went about his work diligently and humbly, who served all who wished to partake of the Internet and to contribute to it, and who did so asking nothing in return but the satisfaction of a job well done and a world open to new ideas.

Vint Cerf
Woodhurst
October 2008

As these events occur, ICANN invariably receives requests to recognise new sovereign entities. In some cases we see very inaccurate press reports by “experts” on how country codes will be assigned. Thankfully, we have a very clear process for this that it is worth repeating.

I said in a blog post a couple of years ago the following:

Another thing ICANN is not involved in is deciding the actual codes, or what constitutes a country eligible for a code. Valid country codes are defined by the ISO 3166-1 standard, which is used internationally not just for domain names — but for physical mail routing, currency codes, and more. The ISO 3166 Maintenance Agency is responsible for keeping the list of codes up to date, taking advice from the United Nations Statistics Office on what constitutes a country eligible for a country code.

By ensuring ICANN is not tasked with deciding what country codes are valid, ICANN can focus its coordination role by ensuring the country-code domains in the DNS root zone match those allowed by the ISO standard. When new countries are formed, new ISO codes are created, and ultimately they can be added as new country code domains. Similarly, countries disappear, their codes are revoked, and they are retired from the DNS root zone.

It is as true today as it was when this policy was introduced in the mid-1980s. We have a more formal description up online, but fundamentally recognition of a new entity that might be granted a country code originates with recognition by the United Nations. Once that occurs, it will kick off a chain of events that will see a new two letter code added to the ISO 3166-1 standard. Once it is in that standard, IANA will accept applications from suitably qualified candidates to operate the country code domain (see our delegation process described here).

This is what happened most recently in the case of Montenegro. In June 2006 it declared independence, was recognised by the United Nations, and added to the ISO 3166-1 standard in September 2006. Some time after this, the Government of Montenegro approached ICANN for delegation, and once the formal process was concluded, .ME was added to the DNS root zone in September 2007.

As at this time, Abkhazia, Kosovo, Transnistria, Somaliland, South Ossetia and others are not in the ISO 3166-1 standard, so ICANN is not in a position to grant any corresponding country-code domain for them. By strictly adhering to the ISO 3166-1 standard, we ensure that ICANN remains neutral by relying upon a widely recognised and impartial international standard.

Duane Wessels of The Measurement Factory analysed DNS queries for evidence of how unallocated IPv4 addresses are being used and presented them at the last OARC meeting, last month. The results cannot give a complete view of what is happening, as it does not see what is happening in private, behind closed firewalls. Nonetheless, these are useful data.

We will be using these data to help plan for the last few IPv4 allocations to the RIRs.

At ICANN and for those who were aware of the situation this raised some eyebrows. Immediately after we turned off the old DNS server and noticed queries for the old address kept getting answers, we began looking into the issue by checking the DNS responses, reviewing routing system logs (including asking folks at Renesys and others for assistance), doing traceroutes from various points in the Internet, etc. Our investigation determined that the answers being provided by the machines now answering for the old L-root address were correct, returning proper referrals and answers including returning the correct address (199.7.83.42) for L-root, and as such, no immediate damage was being done. However, those answers should not have been returned period.

Why did the old L-root address keep answering?

As is well known, there are 13 root server IP addresses (and many DNS servers behind those addresses), referenced by a single letter (A through M) in the domain ROOT-SERVERS.NET. ICANN has operated L-root since 1997 or so. As part of an ongoing effort to improve L-root service, and after an extensive community consultation process, ICANN obtained a “critical infrastructure” block of addresses from ARIN and renumbered L-root out of a block that was originally intended for use at exchange points into the new block. Back in October 2007, ICANN announced this renumbering and continued to provide root name service on the old address for L-root while turning up a much beefier service on the new address. As part of the announced renumbering process, ICANN continued to answer DNS queries on the old address for 6 months, at which time root DNS service on 198.32.64.12 would cease.

On May 2, the 6 month clock expired, and we turned off root DNS service at the old address as planned. To our surprise, however, the registrant for the Exchange Point block, Bill Manning of “EP.NET, LLC.” (who under some relationship with the University of Southern California, Information Sciences Institute helps operate B.ROOT-SERVERS.NET) had entered into an agreement with a DNS hosting provider, CommunityDNS, to continue answering DNS root queries for the old L-root address.

As the folks at Renesys note, Bill Manning, as the current registrant for the superblock out of which for historical reasons the old L-root address was numbered, has the ability to re-provision the 198.32.64.0/24 address space as part of the Exchange Point block of address space. However, the continued availability of DNS root service on a “decommissioned” root server address violates the “Principle of Least Surprise”, at least for those who take a keen interest in the DNS infrastructure such as ICANN. Historically, when a root server has been renumbered, the root server operator maintains a DNS server at the old address for some period of time and then turns off service, with the address not being put back into use. The fact that queries to the old L-root address continued to be answered and ICANN, the operator of the L-root server, was unaware of agreements to continue service by a third party raises some significant areas of concern, not least of which is what should be done with IP addresses formerly used by root servers and who has the authority to make those sorts of decisions.

What did ICANN do?

After some discussion with the relevant parties, the DNS root service being provided at the old L-root address was discontinued. While undoubtedly a number of DNS queries were (and are) still being sent to the old L-root IP address, it is important to remember that the nature of the queries. When a typical DNS resolver first starts up, it uses information called the “root hints” as a list of known IP addresses for root servers. The DNS resolver will then ask one of those IP addresses (typically chosen at random) for an updated list, and then use that updated list from then on. This initial query is known as a “priming query” and only a fraction (1/13th to be precise) of priming queries from resolvers that had not updated their root hints file would have been affected — any queries following that priming query would not be affected since the answer to the priming query returns the correct root server address list.

ICANN has also been monitoring the results returned by these IP addresses through the entire time it was advertised, and believes it was always providing accurate root responses throughout its existence. ICANN continues to work with the root server operator community to improve monitoring and analysis of the root server system, aiming to ensure the continued security and stability of this critical component of the Internet.

So what does this mean for the Internet?

This incident highlights firstly how robust the DNS system is, that it continued to work flawlessly despite this issue. Given the existence of 13 root server IP addresses, only 1/13th of DNS resolvers that have not updated their root hints would have sent a priming query to the IP address formerly associated with the L-root server. However this incident also highlights how important it is for system administrators and DNS software developers to update their root hints as it becomes necessary. Thankfully, this usually only happens once every few years, and IANA sends announcements to the network operator communities when this information is updated.

ICANN, though its Root Server System Advisory Committee (RSSAC), is bringing some of the questions and issues raised by this incident to the root server community, who undoubtedly will want to consider this incident carefully.

In order for comments to be considered by the Review Team, please send comments by 23:59 UTC 24 May 2008 to pir-dnssec-proposal@icann.org.

Not sure what DNSSEC is? “DNSSEC is a mechanism to assure the authenticity and integrity of DNS data. DNSSEC facilitates a chain of trust that starts with the root name servers and proceeds through the hierarchical resolution of a domain name. At each level in the DNS, the signature of the upper level zone is verified using an associated public encryption key (see http://www.icann.org/committees/security/dns-security-update-1.htm).” A useful non-ICANN site on DNSSEC is www.dnssec.net.

ICANN и Координационный центр домена RU (Администратор национального домена верхнего уровня .RU), начиная с 2007 года, проводят совместную работу, направленную на расширение представления российских интернет-пользователей о развитии Интернета и обеспечение возможностей для участия в этом процессе.

«Мы хотим быть уверены, что российское интернет-сообщество является частью глобального процесса определения дальнейшего пути развития Интернет” – сообщил Вени Марковский, представитель ICANN в России и странах СНГ. «Наша работа с Координационным центром домена RU является прямым доказательством успеха модели, используемой ICANN для разработки политик, которая построена на основе консенсуса и принятии решений, инициированных сообществом (bottom-up model). Участие Координационного центра в деятельности ICANN на разных уровнях высоко ценится».

В рамках дальнейшей совместной работы ICANN и Координационный центр домена RU планируют сконцентрировать своё внимание на следующих областях:
- Управление использованием Интернет – сотрудничество в области повышения уровня знаний участников процесса;
- Обеспечение безопасности и стабильности системы DNS домена RU;
- Дальнейшее развитие возможностей для участия российских интернет-пользователей в деятельности, процессах разработки политик и конференциях ICANN;
- Продолжающаяся работа по интернационализации доменных имен, прежде всего, с символами кириллицы, в том числе, работа по поддержке тестирования IDN;
- Совместное участие в Круглом столе, посвящённом актуальным для российского интернет-сообщества вопросам на Российском Интернет Форуме 2008 (http://2008.rif.ru).

«Основная задача – помочь российским пользователям познакомиться с тем, как устроен Интернет, поддержать их желание участвовать в различных мероприятиях, где они могут услышать мнение ключевых в сети Интернет фигур со всего мира», – прокомментировал Андрей Романов, Директор Координационного центра домена RU. «В нашей стране также огромное количество высоко-квалифицированных экспертов в различных областях знаний, которые способны внести свой вклад в деятельность ICANN сообщества. Кроме этого, мы рассчитываем, что ведущие мировые эксперты смогут поделиться своими опытом и знаниями, посещая форумы, конференции и семинары, которые проводятся здесь, у нас в России».

Сотрудничество ICANN и Координационного центра домена RU началось еще задолго до марта 2007 года, когда две организации формализовали свои отношения. С этого момента Вени Марковский принял участие в Российском Интернет Форуме 2007 года, члены Правления и сотрудники ICANN провели ряд встреч с официальными представителями российского Интернет-сообщества, Координационный центр домена RU вошёл в состав ccNSO (country code Names Supporting Organisation), организации созданной из и для администраторов национальных доменов верхнего уровня с целью разработки политик и решения глобальных вопросов о порядке использования национальных доменов верхнего уровня (ccTLD) в рамках структуры ICANN.