de-peering for security sake

William Waites wwaites at
Sat Dec 26 16:58:29 UTC 2015

On Sat, 26 Dec 2015 11:14:25 -0500, Joe Abley <jabley at> said:

    >> My gauge is volume of obnoxious traffic.  When I get lots of
    >> SSH probes from a /32, I block the /32.

    > ... without any knowledge of how many end systems are going to
    > be affected.  A significant campus or provider user base behind
    > a NAT is likely to have more infections in absolute terms, which
    > means more observed bad behaviour. It also means more
    > end-systems (again, in absolute terms) that represent collateral
    > damage.
Indeed this is only going to get worse with pressure on IPv4
addressing space. I often see this with small rural providers that
have not yet progressed to the level of getting their own address
space, and the available space is already insufficient in many cases.

Another important scenario where this happens is Tor exit nodes. I
have not observed any de-peering or network-layer filtering around
exit nodes, but the milder, but still very obnoxious, tactic of
application-layer capchas happens a lot. This is a serious problem for
privacy or security conscious users (i.e. most of Tor's userbase) that
tend not to enable JavaScript unless there is good reason. And a lot
of these capcha systems require JavaScript.

I see this every day since I live in a country where it would be
foolish not to use Tor as a matter of course. Large CDNs like
Cloudflare are guilty of this and this exascerbates the problem
because it prevents access to a very large set of resources and not
just a single web site. It's not nice. It has the effect of turning
the privacy-conscious into second-class netizens.

Rachel Greenstadt is presenting some research tomorrow at the CCC on
the effect this has on excluding contributions to common goods such as

William Waites <wwaites at>  |  School of Informatics      | University of Edinburgh             |      HUBS AS60241

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

More information about the NANOG mailing list