Dirección RFC 1918 en internet abierto?

Al tratar de diagnosticar un problema de conmutación por error con mis firewalls Cisco ASA 5520, ejecuté una ruta de seguimiento a www.btfl.com y, para mi sorpresa, algunos de los saltos volvieron como direcciones RFC 1918.

Para que quede claro, este host no está detrás de mi firewall y no hay una VPN involucrada. Tengo que conectarme a través de internet abierto para llegar allí.

¿Cómo / por qué es esto posible?

asa# traceroute www.btfl.com

Tracing the route to 157.56.176.94

 1  <redacted>
 2  <redacted>
 3  <redacted>
 4  <redacted>
 5  nap-edge-04.inet.qwest.net (67.14.29.170) 0 msec 10 msec 10 msec
 6  65.122.166.30 0 msec 0 msec 10 msec
 7  207.46.34.23 10 msec 0 msec 10 msec
 8   *  *  *
 9  207.46.37.235 30 msec 30 msec 50 msec
 10 10.22.112.221 30 msec
    10.22.112.219 30 msec
    10.22.112.223 30 msec
 11 10.175.9.193 30 msec 30 msec
    10.175.9.67 30 msec
 12 100.94.68.79 40 msec
    100.94.70.79 30 msec
    100.94.71.73 30 msec
 13 100.94.80.39 30 msec
    100.94.80.205 40 msec
    100.94.80.137 40 msec
 14 10.215.80.2 30 msec
    10.215.68.16 30 msec
    10.175.244.2 30 msec
 15  *  *  *
 16  *  *  *
 17  *  *  *

y hace lo mismo desde mi conexión FiOS en casa:

C:\>tracert www.btfl.com

Tracing route to www.btfl.com [157.56.176.94]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  myrouter.home [192.168.1.1]
  2     8 ms     7 ms     8 ms  <redacted>
  3    10 ms    13 ms    11 ms  <redacted>
  4    12 ms    10 ms    10 ms  ae2-0.TPA01-BB-RTR2.verizon-gni.net [130.81.199.82]
  5    16 ms    16 ms    15 ms  0.ae4.XL2.MIA19.ALTER.NET [152.63.8.117]
  6    14 ms    16 ms    16 ms  0.xe-11-0-0.GW1.MIA19.ALTER.NET [152.63.85.94]
  7    19 ms    16 ms    16 ms  microsoft-gw.customer.alter.net [63.65.188.170]
  8    27 ms    33 ms     *     ge-5-3-0-0.ash-64cb-1a.ntwk.msn.net [207.46.46.177]
  9     *        *        *     Request timed out.
 10    44 ms    43 ms    43 ms  207.46.37.235
 11    42 ms    41 ms    40 ms  10.22.112.225
 12    42 ms    43 ms    43 ms  10.175.9.1
 13    42 ms    41 ms    42 ms  100.94.68.79
 14    40 ms    40 ms    41 ms  100.94.80.193
 15     *        *        *     Request timed out.

Es permisible que los enrutadores se conecten entre sí utilizando RFC1918 u otras direcciones privadas, y de hecho esto es muy común para cosas como enlaces punto a punto y cualquier enrutamiento que tenga lugar dentro de un AS.

Solo las puertas de enlace fronterizas en una red realmente necesitan direcciones IP públicamente enrutables para que el enrutamiento funcione. Si la interfaz de un enrutador no se conecta a ningún otro AS (o cualquier otro proveedor de servicios, más simplemente), no es necesario anunciar la ruta en Internet, y solo los equipos pertenecientes a la misma entidad deberán conectarse directamente al interfaz.

Que los paquetes vuelvan a usted de esta manera en traceroute es una ligera violación de RFC1918, pero en realidad no es necesario usar NAT para estos dispositivos, ya que no se conectan a cosas arbitrarias en Internet; simplemente pasan por el tráfico.

Que el tráfico tome la ruta (posiblemente tortuosa) a través de varias organizaciones que hace es simplemente una consecuencia de la operación de los protocolos de enrutamiento de puerta de enlace exterior. Parece perfectamente razonable que Microsoft tenga algo de backbone y algunas personas lo hayan observado; No es necesario ser un ISP mayorista para enrutar el tráfico.

No es especialmente extraño que el tráfico haya pasado por múltiples series de enrutadores con IP privadas, transitando a través de uno con IP públicas en el medio, simplemente indica (en este caso) dos redes diferentes a lo largo del camino han enrutado el tráfico a través de sus propios enrutadores que han elegido numerar de esta manera.

No solo RFC 1918 ... también RFC 6598 , es decir, 100.64.0.0/10espacio CGN. Ambas son redes privadas, pero la última está más recientemente estandarizada y es menos conocida.

Esto no es inusual desde el punto de vista de traceroute. En realidad no estás hablando directamente con esos hosts de 10 espacios y 100 espacios, estás enviando paquetes con TTL incrementalmente más grandes a tu enrutador de próximo salto. Para evitar que la respuesta sea demasiado larga, este enlace de Wikipedia resume el proceso.

Lo que es inusual es que este paquete atraviesa el espacio público de IP y luego se canaliza a través del espacio privado de IP para alcanzar una red "pública" una vez más. 157.56.176.94es propiedad de Microsoft, y el paquete atraviesa las redes propiedad de MS antes de llegar a la red privada ... así que es simplemente lo que Microsoft está eligiendo hacer con su espacio de red en ambos extremos del espacio privado. Anuncian las rutas; los otros enrutadores solo hacen lo que se les dice.

Como regla general, no, los operadores de red generalmente no exponen sus redes privadas a lo largo de una ruta al espacio público de IP desde fuera de su red. Por eso es tan inusual.

(podría ser una ruta faltante en algún lugar de su frontera, lo que hace que los paquetes atraviesen una ruta no óptima que finalmente llega a su destino, pero no soy un hombre de redes y alguien probablemente pueda apuñalarlo mejor)