DDoS attacks are serious problems. While ICANN’s role in mitigating these threats is limited, the Security Team offers these insights to raise awareness on how to report DDoS attacks

Distributed Denial of Service attacks have increased in scale, intensity and frequency. The wide range of motives for these attacks – political (hacktivism), criminal (coercion), or social (malice) – makes every merchant or organization with an online presence a potential target. The shared nature of the Internet infrastructure – whether hosting, DNS, or bandwidth – puts many merchants or organizations at risk of becoming collateral damage, as well. If you find that your site or organization is under attack, it’s important that you report such attacks quickly to parties that are best positioned to help you mitigate, weather, and restore normal service.

I’m under attack. What should I do? Whom should I call?

Any Internet service – web, DNS, Internet voice, mail – can be the target of a DDoS attack. If your organization uses a hosting provider for a service that is attacked, first contact the hosting provider. If your organization hosts the network or Internet service that is under attack, first take measures to contain or dampen the attack. Next, call the service provider that provides Internet access for your network. Most hosting providers and ISPs post emergency contacts on their web sites and many include at least general contact numbers on bills. If you only have a general contact number, explain that you are under attack and ask the customer care agent to escalate (forward) your call to operations staff with the ability and authority to investigate.

Helping Hands

Traffic associated with a single DDoS attacks may originate from hundreds or thousands of attack sources (typically compromised PC or servers). In many cases, your hosting provider or your Internet access provider should act on your behalf (and in self-interest). They will contact “upstream” providers and the ISPs that route traffic from the DDoS attack sources to notify these operators of the nature and suspected origins of the attack. These operators will investigate and will typically revoke routes or take other measures to squelch or discard traffic close to the source.

If you cannot find contacts, or if the contacts you find are unresponsive, try contacting a Computer Incident, Emergency, or Security Incident Response Team (CERT/CIRT/CSIRT), or a Trusted Introducer (TI) team. CERT/CIRT organizations (find a national list here) or TI teams will investigate an attack, notify and share information with hosting providers or ISPs whose resources are being used to conduct the attack, and work with all affected parties to coordinate an effective mitigation.

Should I contact Law Enforcement?

Contact your national law enforcement agency if you believe that a crime is being committed; for example, you should contact law enforcement if your organization received a threat prior to the attack, or received a demand for money in return for not being attacked, or if you believe that critical infrastructure or delivery of a critical service (such as Emergency 911) is threatened.

Contact law enforcement to report a crime, not to mitigate an attack. DDoS attacks are criminal acts in many jurisdictions. By filing a report, you and other victims provide valuable information that may be relevant in any subsequent investigation or prosecution of the attackers.

Provide Good Intel

At an operational level, you, your hosting provider or ISP should gather as much information related to the attack as possible. The Operations Security Trust Forum recommends collecting the following kinds information:

1. Provide as much time information as possible: identify the start of attack, end of attack, whether the attacks are repeated, and whether there are observable patterns or cycles to the attacks.
2. Share any insights or suspicions you have regarding the nature of the attack. Does it appear to correlate with a geo-political event? Did you receive threatening correspondence prior to or during the attack and if so, what was the nature of the threat?
3. Provide detailed traffic information including: type of traffic (ICMP, DNS, TCP, UDP, application), source and targeted IP addresses and port numbers, packet rate, packet size, and bandwidth consumed by the attack traffic.
4. Describe any unique traffic or packet characteristics you observe. Is the attack targeting a particular virtual host or domain? What have you observed from application protocol headers? Have you observed any unusual patterns of flag settings in underlying protocols (TCP, UDP, ICMP, IP)?
5. Identify any changes you observe in the attack over time (i.e., to packet sizes, rates, unique IPs seen per epoch, protocols, etc.). These may be indications that the attacker is reacting to mitigation efforts you or others have implemented.
6. Provide your assessment of the impact; for example, explain whether you are managing the attack using mitigations and assistance, or that your services or performance is {moderately, severely} affected, or that your services have been disrupted entirely.

Don’t Wait Until You Are a Victim

If you have not already prepared a plan to respond to a DDoS attack, please consider doing so. The article Preparing for the (Inevitable) DDOS Attack offers a checklist of contacts, information, and mitigation strategies. Some helpful resources to better understand different kinds of DDoS Attacks, mitigation techniques and how your organization can help reduce the overall threat of these attacks are included below:

• SAC004, Securing The Edge
• SAC008, DNS Distributed Denial of Service (DDoS) Attacks [PDF, 963 KB]
• BCP 38, Network Ingress Filtering
• BCP 140, Preventing Use of Recursive Nameservers in Reflector Attacks
• Protecting the World from YOUR Network
• Mitigating DNS Denial of Service Attacks
• The Worrisome Threat of DNS DDoS Amplification Attacks
• Do More to Prevent DDoS Attacks
• Firewall Best Practices – Egress Traffic Filtering
• Distributed Denial of Service (Attacks/Tools)

In recent weeks, numerous high profile organizations and financial institutions have been targets of massive service disruption attacks. Several of these attacks are characteristically similar to attacks against top level domain name servers in 2006. ICANN’s Security and Stability Advisory Committee published an Advisory, SAC008 [PDF, 963 KB]: Distributed Denial of Service (DDoS) Attacks, shortly after the 2006 incidents. Recommendations from that Advisory remain relevant today.

We encourage private organizations, service operators and governments to carefully consider the recommendations from SAC 008, which describe the best known means to mitigate DDoS attacks.

“the most effective means of mitigating the effects of… numerous DoS attacks is to adopt source IP address verification” – SAC008

DDoS attacks commonly use IP addresses that are not allocated to the subscriber or IP addresses from reserved/private space to make it difficult to identify sources of attack traffic. This is called IP address spoofing. Access service providers or corporations should apply network ingress filtering (described in SAC004 and recommended by the Internet IAB in BCP038) to prevent spoofing. Squelching attack traffic close to its origins has the added benefit of relieving ISPs from forwarding malicious or criminal traffic. Everyone benefits when every operator filters spoofed source addresses, except would be attackers.

“Document operational policies relating to countermeasures… to protect [your] name server infrastructures against attacks that threaten [your] ability to offer service, give notice when such measures are implemented, and identify the actions affected parties must take to have the measures terminated.” – SAC008

I recently wrote an article, Preparing for the (Inevitable) DDoS Attack, that describes how to develop policies and prepare a response should your organization come under attack.

“disable open recursion on name servers from external sources and only accept DNS queries from trusted sources to assist in reducing amplification vectors for DNS DDoS attacks – SAC008

When open recursion is enabled on a DNS server, that server will accept DNS queries from any client (any IP source address). Attackers exploit open recursive servers in DDoS attacks and amplification attacks. US-CERT Alert TA13-088A recommends that all DNS operators:

• Disable recursion on authoritative name servers
• Limit recursion to authorized clients, and
• Rate limit responses of recursive name servers

Alert TA13-088A also identifies ways for every organization to test whether any of its name servers are open resolvers, and lists sources that describe how to do so for major operating system and name server software. (Note: TA13-088A does not have a resource for Microsoft DNS server, try here.)

The ICANN Security Team encourages you to help mitigate this increasing threat to security, stability, and resiliency.

ICANN would like to announce that the transition of the technical management function for the IN-ADDR.ARPA zone from ARIN to ICANN has been completed. ICANN would also like to thank ARIN for carrying out the DNS zone maintenance function for IN-ADDR.ARPA since 1997 and their cooperation during this transition period.

For more details on the history of this transition please see the project web page.

The IPv4 Reverse DNS uses the special domain IN-ADDR.ARPA. For many years the IN-ADDR.ARPA zone has been served by twelve of the thirteen DNS root servers. The changes we are planning will see the IN-ADDR.ARPA zone move to new, dedicated nameservers, five operated by the Regional Internet Registries (RIRs) and one operated by ICANN.

The deployment of dedicated DNS infrastructure for IN-ADDR.ARPA provides additional protection for clients and for root servers from high IPv4 reverse DNS traffic loads, and is consistent with the direction identified by the Internet Architecture Board (IAB) in RFC 3172. The naming scheme for the
new nameserver set will be as described in RFC 5855, as was recently implemented by ICANN for IP6.ARPA, the domain which supports the reverse DNS for IPv6.

ARIN has carried out the DNS zone maintenance function for IN-ADDR.ARPA since 1997. This function will transition to ICANN and will be managed concurrently with the central assignment of IPv4 address space to RIRs. Once the IN-ADDR.ARPA zone is being maintained by ICANN it will also be signed using DNS Security Extensions (DNSSEC), providing end-users with the ability to validate answers to reverse DNS queries.

Work on this set of changes began in November 2010, and is expected to be complete in February 2011. For more details please see <http://in-addr-transition.icann.org/>.

Nonetheless, there are a lot of addresses and lots of new things to learn if you are only familiar with an IPv4 environment. But as we implement IPv6 across our networks we will see IPv6 addresses popping up in mail headers, system logs, traceroutes and all sorts of other places where IPv4 used to be used exclusively. Knowing quickly whether an address is part of your own network or someone else’s; whether an address is intended for private use or Internet use; and knowing whether an address is used by a transition mechanism or a native connection will help save lots of time.

Last year, ICANN staff worked with the staff at APNIC and the RIPE NCC to produce a single sheet that identified the key address groups, explained what they were and gave IPv4 examples of IPv4 equivalents where they existed. This year we have updated the sheet and you can grab a copy of the updated reference from here.

This reference will be useful for anyone working on an abuse desk, in a Network Operations Centre or a corporate IT department. Even if you don’t plan to roll out IPv6 on your own network in the next few months, you are likely to see it appearing on other networks. Using our cheat sheet can help bring you up to speed quickly and identify where to look for an address faster than by just consulting the on-line registries.

We want this reference guide to be as useful and current as possible, so as things change in the future we will produce further updates for you to use.

As you may know, one of the ICANN Board resolutions from the recent ICANN meeting in Nairobi directed staff to develop an extension to the Fast Track Process: a mechanism to introduce Synchronized IDN ccTLDs. A Proposed Implementation Plan was subsequently published for public comments.

The Proposed Implementation Plan can be found here: http://icann.org/en/announcements/announcement-22mar10-en.htm

Since Synchronized IDN ccTLDs in the Fast Track context is a new concept, naturally this has raised some concerns and confusion. The best place to record comments and questions is in the public forum: http://icann.org/en/public-comment/#synch Still, we thought it would be helpful to point to some resources, and answer questions we have seen in mail lists and elsewhere.

If you haven’t read it yet, we encourage you to read the recently published Q&A. The Q&A addresses concerns raised by the technical community due to the usage of certain terminology in the Board resolution and the Proposed Implementation Plan. In particular the Q&A explains that “synchronized” relates solely to policy and procedural requirements. The Q&A further clarifies that there is no (DNS) technical mechanism by which domains under Synchronized IDN ccTLDs will be made to resolve identically (same address/value etc) at the DNS protocol level. As a result, from a purely technical/DNS protocol perspective, two synchronized IDN ccTLDs are simply two separate delegations from the root zone.

If you have further questions, we encourage you to attend one or both of two upcoming webinars. These webinars will be recorded and the recordings will be published at the public comment forum for review by all interested parties. The webinars are scheduled for 14 April at 01:00 and 14:00 UTC. Registration and access information can be found at: http://icann.org/en/announcements/announcement-2-08apr10-en.htm or directly at the e-learning site at: http://icann.org/en/learning/

In addition it is important to note that the plan for synchronized IDN ccTLDs is not a general statement from ICANN about how all variant TLD introductions can or should be made. Quite the contrary, the requirements in the Proposed Implementation Plan for Synchronized IDN ccTLDs assures that it is limited. As one example of these limitations it is required that Synchronized IDN ccTLDs request first must complete the String Evaluation step in the Fast Track Process. Again, the Synchronized IDN ccTLD Process is an extension of the Fast Track Process and all Fast Track rules apply.

Given these designed-in requirements/limitations, the volume of Synchronized IDN ccTLDs will not really increase the total volume of new TLDs already contemplated within the Fast Track Process. Also, confusingly similar IDN ccTLDs will not be allowed for delegation regardless of whether they are considered synchronized or not (this type of variant TLDs needs additional work, see below). And, there are no current activities ongoing towards a notion of “Synchronized IDN gTLDs”.

As mentioned, more work is required to create a general mechanism by which all variant IDN TLDs (not just the very limited set of Synchronized IDN ccTLDs) can be introduced. The term variant has been used loosely; other related terminology used is aliasing, sameness, and so forth. A clarification of the terminology and what is meant by it is needed before the ongoing work can be initiated. A more general solution depends on (at least!):

• Definition of what exactly it is that is being sought by a “variant solution”. What is the desired behavior of variants in all cases?

• Definition of the different types of variants – which may inform the answers to 1).

• Review and test of DNAME as a technical solution, and its adequacy to achieve variant TLD management.

• Review/test of BNAME as a technical solution, and its adequacy to achieve variant TLD management. It is noted that the BNAME proposal is rather new and currently exist as an Internet Draft in the IETF.

• Review/test of variant management via procedures and registration policies. This based on the experience with the Synchronized IDN ccTLDs.

Along with the technical community, ICANN wants to contribute to finding the answers to these questions, and is launching a project to address them. Part of this work will be looking to use the community experience on this subject. In particular ICANN is seeking advice from the technical community, such as for example the work currently ongoing in the IETF/DNSEXT on the subject of sameness and variants in context of the DNS.

Meanwhile we look forward to your comments in the public forum, and your participation in the upcoming webinars!

These are associated with: Egypt, the Russian Federation, United Arab Emirates, and Saudi Arabia.

See the full announcement here: http://icann.org/en/announcements/announcement-21jan10-en.htm

So what does that mean?

It means that these may now initiate the String Delegation process, which is the last step before the strings are actually in the DNS root zone and hence available for use.

The remaining 12 requests are still being processed and at ICANN we are very much looking forward to completing more requests as well as receiving additional new requests

Overall, the Fast Track Process has three main steps:

1) Preparation (by the requester in the country / territory). Community consensus is built for which IDN ccTLD to apply for, how it is run, and which organization will be running it, along with preparing and gathering all the required supporting documentation.

2) String Evaluation: incoming requests to ICANN in accordance with the criteria described above: the technical and linguistic requirements for the IDN ccTLD string(s). Applications are received through an online system available together with additional material supporting the process at http://www.icann.org/en/topics/idn/fast-track/

3) String Delegation: requests successfully meeting string evaluation criteria are eligible to apply for delegation following the same ICANN IANA process as is used for ASCII based ccTLDs. String delegation requests are submitted to IANA root zone management.

The problem is that the unofficial usage makes it more difficult for ISPs to bring these addresses into use when they are officially allocated and so less desirable. But we have to allocate IPv4 addresses to the RIRs as long as we still have them and they still request them. We just need to implement a mechanism to select which /8 is allocated to which RIR.

The mechanism we have implemented reserves two of the /8s showing the least unofficial use for each of the newest RIRs. AfriNIC and LACNIC have fewest IPv4 /8s and service the regions with the most developing economies. We decided that those RIRs should have four of the easiest to use /8s reserved for them.

The other /8s are split between two pools and when APNIC, ARIN or the RIPE NCC qualify for additional IPv4 address space they will be allocated one /8 from each pool, with the /8 being chosen using a verifiable random selection mechanism. The mechanism is based on the “Publicly Verifiable Nomcom Random Selection” mechanism described in RFC 2777.

The sources of randomness used are the prices of the FTSE 100, Dow Jones Industrial Average and Hang Seng Index from midday at the exchange site the day after the request is received, as published on the Yahoo! Finance web site.

The pool of /8s which have been used to number IP networks in an unofficial and improper way is larger than the other pool. So when the smaller pool runs out, all allocations to APNIC, ARIN and the RIPE NCC will come from the larger pool until it too is empty. Then, if any of the /8s reserved for AfriNIC and LACNIC have not been allocated they will become part of a single pool used for all RIRs.

Of course, when all of this is done, there are still five /8s set aside for the implementation of the Global Policy for the Allocation of the Remaining IPv4 Address Space. Very little use of those /8s was detected in our 2008 research.

The networks using these officially unallocated addresses are intended to be private, not visible to the global Internet. Nonetheless, their use can be detected when the private parts of networks connect to their public Internet facing connections, such as the connections to their service providers. The addresses leak in e-mail message headers, DNS queries and other random traffic. In some cases, this unofficial use can cause operational problems.

IANA staff has tried to research which /8s are being used in this way. In 2008 we sponsored research by Duane Wessels into which /8s see the most use. He reported on his research at OARC’s DNS Ops meeting and I wrote about it on this blog. Based on this work, we think the /8s with the most unofficial use are:

1, 2, 5, 14, 23, 39, 42, 100, 101, 107, 175 and 176

Duane Wessels’ research was part of a number of presentations that were part of an awareness campaign we worked on. This included talks at network operator groups and articles in industry journals and in some cases discussions with the users of the unallocated space where we could identify them. While we have discussed the issue with some of these network operators, we haven’t been able to speak directly to everyone making unofficial use of this address space because they tend to do so in private networks.

We know that newly allocated IPv4 /8s can be difficult for assigned users to use at first because old filters which block unallocated addresses are slow to be updated with new allocation information. There might be some extra operational difficulties with these particular /8s if unofficial users of the addresses try to communicate with the newly assigned official users of the same addresses.

The longer-term solution to this problem is for network operators to switch to IPv6 and to stop using the unallocated blocks entirely.

Over the next two years we will continue to allocate from these /8s when making allocations to the RIRs. The RIRs use about one /8 per month and so over the next couple of years we know that all of these /8s will be allocated.

One of the more interesting insights involved looking at network diversity. We want top-level domains to keep functioning no matter what is happening — any conceivable disaster shouldn’t knock a top-level domain off-line. One thing we ask is that top-level domains’ name servers be hosted in at least two distinct networks, so it is guarded against a failure (be it a technical failure, or some other business failure event).

Here is a map of all the country-code top-level domains, and one possibly measure of diversity — the number of “autonomous systems” their name servers are hosted in. Countries marked red are reliant on a single network, and if that network failed it could be disastrous for its users without alternatives. Those orange through green have increasing amounts of diversity in the networks that host their name servers:

If we take a minimum of two networks as our baseline requirement, we can look at how TLDs have met this criteria over a period of time — say the last five years:

The blue line shows IPv4 connectivity and it is pretty good, and rather consistent. But if we judge IPv6 connectivity against the same diversity requirement, shown as the green line, not even 50% of ccTLDs have this level of diversity. If we look at TLDs with any IPv6 it is a little better, but there is still about a third of all ccTLDs with no IPv6 connectivity at all!

The good news is the IPv6 trend lines are heading in the right direction, with the growth of IPv6 deployment even accelerating a little recently. Lets hope this continues so that these critical resources are stable not just for existing Internet users, but for future Internet users as well.