ICANN ICANN Email List Archives


<<< Chronological Index >>>        Thread Index >>>

Returning is potentially dangerous, and my suggestions for an alternative

  • To: "comments-name-collision-26feb14@xxxxxxxxx" <comments-name-collision-26feb14@xxxxxxxxx>
  • Subject: Returning is potentially dangerous, and my suggestions for an alternative
  • From: Aaron Beck <A.Beck@xxxxxx>
  • Date: Fri, 28 Feb 2014 05:46:07 +0000


Many Linux systems will respond to requests made of the address, 
and in general any packet addressed within unless specifically 
configured otherwise.  I've include an example from an Ubuntu 12.04 machine:

ab@phrygian:~$ ping -c 1
PING ( 56(84) bytes of data.
64 bytes from icmp_req=1 ttl=64 time=0.031 ms

--- ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.031/0.031/0.031/0.000 ms

This may present a denial of service vector wherein these "friendly" looking 
gTLDs could inadvertently lead someone to direct traffic to many sensitive 
daemons.  This could also present opportunities to traverse tunneled services 
over a VPN or tethered connection that would otherwise not be available, where 
both technologies often make use of the address space and may 
assign to something listening.

To avoid the above DoS vectors, I suggest looking at returning an address from 
the TEST-NET2 or TEST-NET3 ranges, as defined by RFC 5737.   I believe that an 
address from TEST-NET in RFC 1166 is likely to conflict with the most existing 
documentation.  In light of that and alongside inspiration from, I 
quote two sections from RFC 5737 as my basis for a recommendation of the 


1<http://tools.ietf.org/html/rfc5737#section-1>.  Introduction

   This document describes three IPv4 address blocks that are provided
   for use in documentation.  The use of designated address ranges for
   documentation and examples reduces the likelihood of conflicts and
   confusion arising from the use of addresses assigned for some other

   [RFC1166] reserves the first of the three address blocks,  The other two address blocks have recently been
   allocated for this purpose, primarily to ease the writing of examples
   involving addresses from multiple networks.


      Addresses within the TEST-NET-1, TEST-NET-2, and TEST-NET-3 blocks

   SHOULD NOT appear on the public Internet and are used without any
   coordination with IANA or an Internet registry 
[RFC2050<http://tools.ietf.org/html/rfc2050>].  Network
   operators SHOULD add these address blocks to the list of non-
   routeable address spaces, and if packet filters are deployed, then
   this address block SHOULD be added to packet filters.

   These blocks are not for local use, and the filters may be used in
   both local and public contexts.


I believe the future from RFC 6890 could be considered now.  Therefore, another 
approach may be an assignment from the address space. 
is my recommendation from this space, so that only the first /26 of is 
"tainted" by actual assignment.

Thanks for listening,  Aaron Beck.

<<< Chronological Index >>>        Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy