|
||
|
||
DDoS attacks, phishing scams and malware. We battle these dark forces every day—and every day they get more sophisticated. But what worries me isn’t just keeping up with them, it is keeping up with the sheer volume of devices and data that these forces can enlist in an attack. That’s why we as an industry need to come together and share best practices—at the ICANN community, at the IETF and elsewhere—so collectively we are ready for the future.
The challenge before us is growing every day. The Internet ecosystem is comprised of roughly 3.5 billion global Internet users, millions of businesses, civil society organizations and governments operating over 900 million websites using 334 million domains. With this growth, we are seeing major shifts in the how the Internet is used: It isn’t just computers and smart phones anymore. Maintaining the security and stability of the internet means protecting more “things”—from smart watches to smart TVs to smart refrigerators—from more bots, scrapers, and spammers.
The domain industry must place a greater focus on creating trust through security and stability. At Afilias, I focus the company to not only manage and develop our systems to scale and meet technical demands and ensure 100% availability and uptime, but also to focus efforts on maintaining interoperability and to develop open standards for the industry.
How do we do this? Trustworthiness. In computing terms that means being able to rely on systems to be available and secure. While it sounds simple, it requires a combination of security, privacy and reliability to exist in all interactions with the registry system and DNS networks. It requires usage and storage practices to be well documented and audited to ensure that the organization does what it says. Trustworthiness is, in turn, dependent on several core principles:
These principles are essential to the security and stability of the ecosystem to meet the challenges of today, scale and grow in the future, and work harder to increase access for the billions of people yet to be connected. We believe—using the multi-stakeholder approach to Internet governance with broad participation from technical, business and civil society leaders—we can collaboratively develop a new model for the industry as a whole.
We will continue to do our part to harness secure, reliable, scalable and globally available technology and to encourage others to do the same. Our belief and vision is that sharing such best practices can help the global Internet community will share a strong and vibrant Internet. The DDoS attacks, phishing scams and malware are not going to stop but we will do our part to help and lead our community to be better prepared for the battle.
Sponsored byVerisign
Sponsored byVerisign
Sponsored byRadix
Sponsored byDNIB.com
Sponsored byIPv4.Global
Sponsored byWhoisXML API
Sponsored byCSC
A World-Renowned Source for Internet Developments. Serving Since 2002.
It’d also help if there was pressure on network operators, particularly edge-network operators like consumer ISPs, to implement ingress filtering on the downstream side (so customers can’t send packets into the ISP’s network with source addresses not within the customer’s expected netblocks) and egress filtering on the upstream side (so packets can’t exit their network unless their source address is in a netblock the ISP owns or that belongs to an ISP’s customer). It’s not a complete solution, but it’d cut down on a lot of the avenues for running DDoS attacks. One of the best defenses is to keep your opponent from launching an attack in the first place.
Todd -- that seems to make a lot of sense. Would this be a challenge for ISPs to deploy? Or is there no business case for ISPs to do this, so they don't.
For networks that carry mostly transit traffic it's hard to deploy, and the closer to the backbone you get the harder it is. But for edge networks like consumer ISPs who don't carry a lot of transit traffic from netblocks they don't directly own it's fairly straightforward. Back when I had little experience with iptables it only took me an hour or two to write a complete set of rules for it for my network (router handling 2 /24 netblocks). RFC 3704 covers the subject. Primarily I think it doesn't happen because there's no business case. The originating ISPs aren't the entities being damaged by the DDoS attacks, and disconnecting or suspending customers who're originating DDoS traffic might cost them those customers since those customers are unlikely to believe their systems have been infected. For them any effort expended is a dead loss. The damaged entities at present have no recourse against the originating networks, so there's no natural way of imposing any costs on the originating networks. What it'd take is standard language in interconnect contracts requiring downstream ISPs to implement RFC 3704 on their networks or face disconnection if they were caught originating part of a DDoS attack, with a possible exception for pure-transit networks who took appropriate measures to enforce 3704 compliance on their own internal networks and all downstream customers.