Archive for the 'Suggestions' Category

Help save the Internet: Install the new Spoofer client (v1.1.0)!

Sunday, December 18th, 2016 by Josh Polterock

The greatest security vulnerability of the Internet (TCP/IP) architecture is the lack of source address validation, i.e., any sender may put a fake source address in a packet, and the destination-based routing protocols that glue together the global Internet will get that packet to its intended destination. Attackers exploit this vulnerability by sending many (millions of) spoofed-source-address packets to services on the Internet they wish to disrupt (or take offline altogether). Attackers can further leverage intermediate servers to amplify such packets into even larger packets that will cause greater disruption for the same effort on the attacker’s part.

Although the IETF recommended best practices to mitigate this vulnerability by configuring routers to validate that source addresses in packets are legitimate, compliance with such practices (BCP38 and BCP84) are notoriously incentive-incompatible. That is, source address validation (SAV) can be a burden to a network who supports it, but its deployment by definition helps not that network but other networks who are thus protected from spoofed-source attacks from that network. Nonetheless, any network who does not deploy BCP38 is “part of the DDoS problem”.

Over the past several months, CAIDA, in collaboration with Matthew Luckie at the University of Waikato, has upgraded Rob Beverly’s original spoofing measurement system, developing new client tools for measuring IPv4 and IPv6 spoofing capabilities, along with services that provide reporting and allow users to opt-in or out of sharing the data publicly. To find out if your network provider(s), or any network you are visiting, implements filtering and allow IP spoofing, point your web browser at and install our simple client.

This newly released spoofer v1.1.0 client has implemented parallel probing of targets, providing a 5x increase in speed to complete the test, relative to v.1.0. Among other changes, this new prober uses scamper instead of traceroute when possible, and has improved display of results. The installer for Microsoft Windows now configures Windows Firewall.

For more technical details about the problem of IP spoofing and our approach to measurement, reporting, notifications and remediation, see the slides from Matthew Luckie’s recent slideset, “Software Systems for Surveying Spoofing Susceptibility”, presented to the Australian Network Operators Group (AusNOG) in September 2016.

The project web page reports recently run tests from clients willing to share data publicly, test results classified by Autonomous System (AS) and by country, and a summary statistics of IP spoofing over time. We will enhance these reports over the coming months.

This material is based on research sponsored by the Department of Homeland Security (DHS) Science and Technology Directorate, Homeland Security Advanced Research Projects Agency, Cyber Security Division (DHS S&T/HSARPA/CSD) BAA HSHQDC-14-R-B0005, and the Government of United Kingdom of Great Britain and Northern Ireland via contract number D15PC00188. Views should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of Department of Homeland Security, the U.S. Government, or the Government of United Kingdom of Great Britain and Northern Ireland.

RFC 7514 : Really Explicit Congestion Notification (RECN)

Wednesday, April 1st, 2015 by kc

I feel that somewhere up there Jon Postel is smiling about Matthew’s RFC 7514, published today:

The deployment of Explicit Congestion Notification (ECN) [RFC3168] remains stalled. While most operating systems support ECN, it is currently disabled by default because of fears that enabling ECN will break transport protocols. This document proposes a new ICMP message that a router or host may use to advise a host to reduce the rate at which it sends, in cases where the host ignores other signals such as packet loss and ECN. We call this message the “Really Explicit Congestion Notification” (RECN) message because it delivers a less subtle indication of congestion than packet loss and ECN.

NASA’s recent DNSSEC snafu and the checklist

Thursday, February 16th, 2012 by kc

Reading about NASA’s recent DNSSEC snafu, and especially Comcast’s impressively cogent description of what went wrong (i.e., a mishap that seems way too easy to ‘hap’), I’m reminded of the page I found most interesting in The Checklist Manifesto:


Thoughts on Internet2/UCAN business models

Friday, April 15th, 2011 by kc

This month Internet2’s new UCAN project issued a call for white papers on how they could use their $65M BTOP grant in operationally sustainable ways, i.e., so the infrastructure they build will have a chance of surviving when the federal stimulus project money runs out.

We held a relevant workshop 5 years ago, part of which was published in CommLaw the following year. I’ve also written several other essays on related issues:


Proposal for ICANN/RIR scenario planning exercise

Monday, May 25th, 2009 by kc

Internet infrastructure economics research”, and how to do reasonable examples of it, has come up a lot lately, so i’m posting a brief description of an academic+icann community workshop i’ve been recommending for a few years, which has yet to happen, and (I still believe) is long past due, and specifically more important than passing policies, especially emergency ones to allow IP address markets with no supporting research on the impact on security and stability of the Internet, and even at the risk of killing IPv6 altogether.]


Top ten ($7.2B) broadband stimulus: ideal conditions

Monday, April 13th, 2009 by kc

Last month (23 March) I was on an NTIA panel at the Department of Commerce, to recommend conditions on this broadband stimulus money, aka arm wrestling between companies. Gigi covers it in her blog; today was the deadline to finish my recommendations to DOC and NTIA:


IPv4 exhaustion research agenda, qty 1.

Sunday, March 29th, 2009 by kc

[drafted this entry a few months ago but have been reluctant to post because it’s incomplete. but after reading about the ARIN Board’s emergency proposal last week to create IPv4 address markets, variations of which have already been approved in European (RIPE) and Asia-Pacific (APNIC) IP address policy communities, i decided it’s complete enough. -k.]

A few policy questions on which the RIR-community should funnel address-registration tax dollars into peer-reviewed research:


proposition: International Bureau of Internet Statistics

Friday, January 9th, 2009 by kc

Last month I submitted two proposals to the National Cyber Leap Year call for input from the U.S. Networking Information Technology Research and Development (NITRD) Program. I submitted two ideas, the International Bureau of Internet Statistics, and Cooperative Measurement and Modeling of Open Networked Systems (COMMONS, a two-year old idea). The Bureau of Internet Statistics still strikes some as batty, but over the holidays I caught up on some panicky OECD state-of-malware-landscape papers on how uninformed we are and how little data we have, while the only concrete recommendation in the “ITU’s study on the financial aspects of network security: malware and spam” report was

Although the financial aspects of malware and spam are increasingly documented, serious gaps and inconsistencies exist in the available information. This sketchy information base also complicates finding meaningful and effective responses. For this reason, more systematic efforts to gather more reliable information would be highly desirable.


recommended reading in internet technology policy

Saturday, August 9th, 2008 by kc

(gathered earlier this year upon a student’s request)

  1. Abatte, Janet. Inventing the Internet. 2000.
  2. Benkler, Yochai. The Wealth of Networks. 2006.
  3. Benkler, Yochai. Freedom in the COMMONS: Towards a Political Economy of Information., Duke Law Journal. 2003.
  4. Brin, David. Transparent Society. 1999.
  5. (more…)

top ten things lawyers should know about the Internet: #10

Saturday, August 2nd, 2008 by kc

[Jump to a Top Ten item: #1 #2 #3 #4 #5 #6 #7 #8 #9 #10]
[Originally written as a series of blog entries, this document was later converted to a booklet/pamphlet, seeĀ  “Top Ten Things Lawyers Should Know About the Internet“]

#10: Moreover, even in the dim light of the underattended interdisciplinary research into the network, the available data implies clear directions for solutions, all of which cross policy-technology boundaries.