Since its inception, the IGF has provided a unique platform for all Internet stakeholders to engage in open and constructive discussions around Internet policy issues. Not only has the IGF succeeded in building and strengthening relationships between the various actors, but it has also stimulated the interest of stakeholders around the world to establish national and regional editions of this international fora.

As in past IGF meetings, ICANN is participating in the forthcoming meeting in Baku with a delegation including the President and CEO, the Chairman of the Board, and other senior executives and Board Directors. ICANN is organizing an Open Forum session, and two workshops. The Open Forum is an opportunity for ICANN leadership team and Board to engage in open dialogue with IGF participants on issues pertaining to ICANN mandate. This IGF meeting is the first for ICANN President and CEO, Fadi Chehade, who will have the chance at the Open Forum to shed some light on what he called “the new season at ICANN” as revealed in his opening address at the ICANN Toronto meeting. The two ICANN workshops at the IGF are on DNSSEC and new gTLDs, and are co-organized with Packet Clearing House and UNESCO respectively.

The details of ICANN sessions are as follows:

• DNSSEC For ccTLDs: Securing National Domains
Tuesday, 6 November 2012
16:30 – 18:00
Conference Room #3

• The Multistakeholder Model and the Evolving gTLD Space
Wednesday, 7 November 2012
16:30 – 18:00
Conference Room #4

• ICANN Open Forum
Thursday, 8 November 2012
16:30 – 18:00
Conference Room #8

In addition, ICANN community members will also be organizing a number of workshops. Here is a sample of several:

• New gTLD Program: An Opportunity for Development or a Means for More Digital Divide?
Organizer: ICANN African Regional At-Large Organization (AFRALO)
Wednesday, 7 November 2012
09:00 – 10:30
Conference Room #8

• Why is the participation of the social sector in the Internet Governance important for everybody?
Organizer: Not-for-Profit Organizational Concerns Constituency (NPOC)
Friday, 9 November 2012
09:00 – 10:30
Conference Room #8

• New gTLDs: Implications and Potential for Community Engagement, Advocacy and Development
Organizer: ICANN Asia, Australia and Pacific Islands Regional At-Large Organization (APRALO)
Friday, 9 November 2012
11:00 – 12:30
Conference Room #8

For all IGF sessions, remote participation will be available through the website: http://www.intgovforum.org/cms/.

We look forward for yet another round of rich discussions at IGF 2012 next week in Baku.

My excitement have reached to the utmost levels even though this wasn’t my first attendance to a RIPE meeting, it was my first time as ICANN staff member and also being involved with many of the hottest
topics of the DNS World , i had been looking forward to exchange ideas and discuss various subjects with members of the community.

Everybody who have read the meeting agenda was aware that there was a topic in today called “DNSSEC for the Root Zone” which was going to be presented jointly with Joe Abley , Director of DNS Group at ICANN and
Matt Larson, Vice President of DNS Research at VeriSign. Yet, nobody had been expecting a milestone announcement in the pages of this presentation (Page 25).

When the presentation slide changed from page 24 to page 25, one of the important moments of the Internet history had now been announced to public and long-time waited, “The date for fully deployment of the
DNSSEC at Root Zone” was confirmed; July 1, 2010. The presentation also included a brief timeline of other important dates before the DNSSEC is fully deployed.

Earlier announcements in June 2009 made it very clear that DNSSEC implementation was in the radar and
coming up soon with a collaborated work of ICANN, NTIA and Verisign however this is the first time the Internet community was informed with more details about how this relation would be and who would be
the holder of KSK,ZSK and given a solid date.

The laud applause and cheer from the community members were not only a moment that I realized how much internet community wanted to deploy DNSSEC but also importance of role we were starting to play on
assuring the enhanced security of the Global Internet as ICANN.

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.

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.