El documento discute los desafíos y cambios en Internet en 2017, enfocándose en la gestión de direcciones IPv4 e IPv6 por parte de LACNIC y el agotamiento de IPv4. Se analizan las implicaciones del NAT, la evolución del enrutamiento BGP, y las mejoras propuestas en seguridad DNS, incluyendo DNSSEC y minimización de nombres de consulta. Además, se abordan las necesidades de transición a IPv6 y las nuevas tecnologías para mejorar la privacidad y seguridad de las consultas DNS.

1. Internet en 2017
Desafíos y cambio
Carlos M. Martínez (@carlosm3011)
IEEE URUCON
Montevideo

2. Acerda de LACNIC
•LACNIC administra los recursos de numeración de
Internet para América Latina y parte del Caribe
–Es una organización basada en Membresía, sin fines
de lucro, establecida jurídicamente en Uruguay y
reconocida como Organismo Internacional por el
estado uruguayo
•¿Qué NO es LACNIC?
–Proveedor de servicios de Internet, Entidad
reguladora, policía de Internet, registro de nombres
de dominios

3. ¿Qué son los recursos de
numeración de Internet?
•Recursos fundamentales para el crecimiento y
despliegue de Internet:
–Direcciones IPv4
–Direcciones IPv6
–Números de Sistema Autónomo
•Servicios asociados
–Directorio Whois
–DNS inverso
–RPKI

4. Registros de Internet
Regionales (RIR)

5. Región de Servicio de LACNIC

6. Evolución de la membresía
2017

7. Cambios y Desafíos
•Agotamiento de IPv4 y el surgimiento del
IPv6
•Evolución del enrutamiento en Internet
•Desafíos y evolución a nivel de resolución
de nombres

8. Agotamiento de IPv4
IPv6

9. IPv4
•En uso desde ~1981
•Espacio de 4.294.967.296 direcciones IP (no todas
pueden ser utilizadas)
•Parecen muchas, pero…
– la población mundial es de casi 7 mil millones de
habitantes
–87% tiene celular y 35% usa Internet
–Todos solemos utilizar varias direcciones IP
•Ya no parecen tantas, ¿no?

10. Proyecciones de agotamiento
de IPv4
Fuente: Geoff Huston - http://www.potaroo.net/tools/ipv4/

11. Consecuencias del agotamiento
de IPv4
•Surgimiento de un mercado secundario de
direcciones IP
–Compra de IPs legadas de Nortel por parte de
Microsoft
•Cada vez va a ser más “caro” tener IPv4
–No solo en términos financieros (‘compra’ de
direcciones)
–Caro también en terminos de tiempo y dificultad en
obtenerlas. Caro en términos de la ‘suciedad’ del
espacio obtenido

12. Y entonces…¿cuáles son las
alternativas?
•No hacer nada
•Si no tengo suficientes direcciones IPv4 públicas
para todos los usuarios, podría tratar de
compartirlas
–Carrier-Grade NAT
–Renumeración de servicios
–Otras técnicas
•Empezar a desplegar IPv6

13. Network Address Translation
(NAT)
•Permite que varios dispositivos compartan la
misma IP pública.

14. Problemas del NAT
•Control de uso abusivo:
–ACLs (Listas de control de acceso) para evitar
ciertos ataques tienen importantes efectos
colaterales
–Al bloquear el tráfico de un cliente “malo”, también
bloqueamos el tráfico de muchos clientes “buenos”
•Para identificar que usario accedió a un servicio, no
solo hay que guardar la dirección IP sino también el
puerto de origen

15. Problemas del NAT (ii)
•Geo-localización
–Los usuarios ya no “están” (geográficamente) donde
su IP pública está
•Conectividad end-to-end
–Forwarding de puertos se dificula
–Toda conexión sería ”intermediada” por el CGN
•Implicaciones legales, de privacidad, etc.

16. IPv6
•128 bits de direcciones
•3.4 x 1038 direcciones IP
(340,282,366,920,938,463,463,
374,607,431,768,211,456
direcciones)
•Mismo modelo de servicio
–Datagramas, best effort
•Mayormente mismas
funcionalidades

17. Cuanto espacio IPv6 hay
disponible ?
•128 bits de direcciones

18. Pero …
•Dispositivos IPv4-only no pueden “hablar” con
dispositivos IPv6-only
–Necesitan un traductor (equipamiento extra,
costo extra, etc.)
–Este traductor interrumpe la comunicación.

19. ¿Entonces? Dual Stack
•Dual stack: Los dispositivos hablan los dos
protocolos, v4 y v6.
•Dispositivos dual-stack pueden comunicarse con
otros dispositivos dual-stack y con dispositivos
IPv4-only e IPv6-only

20. Principales diferencias IPv6 /
IPv4
•Las funcionalidades de ARP, auto-configuración,
ICMP quedan absorbidas por el ICMPv6
•Tipos de direcciones
–Link-local, Multicast, Unicast (ULA vs Global)
•Encabezados de extensión
•Fragmentación
–Únicamente los extremos de las conexiones
fragmentan

21. Descubrimiento de vecinos
•Descubrimiento de direcciones de capa de enlace
•Determina la dirección MAC de los vecinos del
mismo enlace (reemplaza ARP)
•El host envía un mensaje NS informando su
dirección MAC y solicita la dirección MAC del
vecino.

22. Descubrimiento de vecinos
•Descubrimiento de direcciones de capa de enlace
•Determina la dirección MAC de los vecinos del
mismo enlace (reemplaza ARP)
•El host envía un mensaje NS informando su
dirección MAC y solicita la dirección MAC del
vecino.

23. Descubrimiento de vecinos
•Descubrimiento de direcciones de capa de enlace
•Determina la dirección MAC de los vecinos del
mismo enlace (reemplaza ARP)
•El host envía un mensaje NS informando su
dirección MAC y solicita la dirección MAC del
vecino.

24. Estado del despliegue IPv6
•Tenemos ya varios casos de países con
penetración de IPv6 mayor a 1%
–¡Tendríamos que pensar en mover el umbral!
•América del Sur:
–PE, EC, BR, BO, AR, UY
•América Central + México:
–GT, MX
•Caribe
–TT

25. Despliegue por Sub-regiones
Code Region
IPv6
Capable
IPv6
Preferred
XA World 11.26% 10.54%
XC Americas 19.75% 18.56%
Code SubRegion
IPv6
Capable
IPv6
Preferred
XP
South
America, A
mericas
9.67% 9.27%

26. ASNs anunciando prefijos IPv6
•Aprox. 5200 ASNs
de la región son
“visibles”
•Aprox. 37% de ellos
anuncian al menos
un prefijo IPv6
•Fuente:
http://v6asns.ripe.net/v/6?
s=_ALL;s=_RIR_LACNIC

27. Evolución del enrutamiento en
Internet

28. BGP
•Uno de los pilares actuales de Internet es el sistema
de ruteo
–Mediante el ruteo, sabemos cómo llegar a una IP
determinada
•En Internet, el ruteo está basado en BGP
•Función crítica para el funcionamiento de Internet
•Sin embargo, estos protocolos tienen algunas
debilidades

29. Entradas en la tabla BGP v4
Gracias a Geoff Huston por el gráfico

30. Entradas en la tabla BGP v6
Gracias a Geoff Huston por el gráfico

31. Desafíos actuales
•Ataques contra el sistema de routing:
–Secuestros de rutas (route hijacking)
–Ataques contra el camino (path)
•Otras amenazas/debilidades:
–Route leaking
–Crecimiento de las tablas de ruteo

32. Algunas novedades en BGP
•RPKI
•Cambio de política BGP por default
•Roles para prevención de route-leaks
•Large communities
•Uso de BGP en datacenters de gran escala
•BGP neighbor autodiscovery y LLDP
•Nuevas address families (LS, EVPN, otras)

33. RPKI
•Solucion al secuestro de rutas mediante la validación de
origen
•Consta de 2 partes:
–PKI de recursos (IPv4, IPv6, ASN)
–Validación de las publicaciones en BGP
•Permite implementar otras funcionalidades:
–Mejor autorización en los IRRs (ver RFC7909)
–Construcción automática de filtros para BGP
–Mayor información mediante comunidades en los IXPs
•BGPsec: por ahora sin adopción a gran escala

34. ASN 65511
ASN 65536
ASN 65537
BGP default policy
•Comportamiento por
default en BGP
(muchas
implementaciones):
re-anunciar
automáticamente todo
lo que se aprende por
eBGP
2001:db8::/40 2001:db8:100:/40
2001:db8::/40
2001:db8:100::/40
Si no hay filtros configurados, esto trae
problemas

35. Roles en BGP para prevenir leaks
ASN 65511
ASN 65536
ASN 65537
Transito
Peering
2001:db8::/40
2001:db8:100:/40
2001:db8::/40
2001:db8::/40 2001:db8:100:/40Transito
2001:db8:100:/40
2001:db8::/402001:db8:100::/40

36. Roles en BGP para prevenir
leaks
•Draft en discusión que define roles al establecer una
sesión BGP:
–Provider
–Customer
–Peer
–Internal
•Un nuevo atributo (iOTC) que se configura para las rutas
recibidas como customer o peer
–Las rutas que tienen ese atributo no se anunciarán por
parte de un neighbor que es customer o peer.
•draft-ietf-idr-bgp-open-policy

37. Uso de BGP en datacenters
•Tradicionalmente la arquitectura de DC estaba basada
en tecnologías L2 y STP.
•En algunos casos se usa L3 con un IGP
•En los datacenter más masivos o de gran escala
(cientos de miles de servers) la tendencia es utilizar BGP
•Ventajas:
–Unico protocolo de ruteo
–Menor complejidad, más estabilidad
–Mayor control sobre la información de ruteo
•Ver RFC7938

38. Evolución del DNS

39. Desafíos en el DNS
•Seguridad en el DNS
–DNSSEC
•Proporciona protección frente a ataques de tipo MitM
•Introduce firmas digitales en
•Privacidad en el DNS
• La información contenida en el DNS es pública
• pero… las consultas específicas que hacemos no
necesariamente lo son
– ¿Por qué? Porque demuestran cierta intención

40. Introducción a DNSSEC (ii)
Gracias a Geoff Huston por el gráfico

41. Introducción a DNSSEC
•Se introducen firmas digitales en las respuestas de
DNS
•Ejemplo:
41
~ carlosm$ dig +dnssec www.nic.se
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1
;; ANSWER SECTION:
www.nic.se. 60 IN A 212.247.7.218
www.nic.se. 60 IN RRSIG A 5 3 60
20101021132001 20101011132001 23369 nic.se.
HeeUZ5h5iExK5uU1SuNRIf2Dbmh2/aWV8FkjmzixUzTAVrHv39PfmfnG
DHdHoZxoz85hqqYiWb+t9EZh5+iqxQk8AxRDic9Nn6WxifOoWeS+IUKQ
rVyqXf1NtkZvu1A325vwa8obtbeVGVkhqg6bDIjKYeHixjlQ4cRoFcEW Izk=
;; AUTHORITY SECTION:
nic.se. 2974 IN NS ns3.nic.se.
nic.se. 2974 IN NS ns2.nic.se.
nic.se. 2974 IN NS ns.nic.se.
nic.se. 3600 IN RRSIG NS 5 2 3600
20101021132001 20101011132001 23369 nic.se.
GSzAUC3SC3D0G/iesCOPnVux8WkQx1dGbw491RatXz53b7SY0pQuyT1W
eb063Z62rtX7etynNcJwpKlYTG9FeMbDceD9af3KzTJHxq6B+Tpmmxyk
FoKAVaV0cHTcGUXSObFquGr5/03G79C/YHJmXw0bHun5ER5yrOtOLegU IAU=

42. Privacidad en el DNS
QNAME minimization - RFC 7816
• Evitar divulgar demasiado las consultas que se
realizan en el DNS
• En la resolución recursiva tradicional se divulga
demasiada información
• ¿Como podemos minimizar esta fuga de datos?
• https://tools.ietf.org/html/rfc7816

43. Resolución recursiva
“tradicional”
Cliente
. (raíz)
.net
lacnic.net
(AAAA, www.lacnic.net)
?

44. Resolución recursiva
“minimizada”
Cliente
. (raíz)
.net
lacnic.net
(AAAA, www.lacnic.net)
?

45. Transporte seguro
• QNAME-minimization resuelve parte del problema,
pero las consultas siguen viajando en “texto plano”
• El WG “DPRIVE” está analizando diferentes
transportes que cifren la información de consultas
– DNS sobre TCP sobre TLS - RFC 7858
• https://tools.ietf.org/html/rfc7858
– Es la aproximación más “obvia”, ya que DNS
sobre TCP ya está definido, y TCP sobre TLS
también
• “... over some reliable transport protocol..” (RFC 5246)
• puerto 853

46. Transporte seguro (iii)
• DNS over QUIC
– ¿¿ Q U I … C ??
– Quick UDP Internet Connections
• QUIC es:
– cifrado por defecto, multiplexa conexiones
(streams), no sufre de NAT, basado en UDP (0-
RTT connection establishment)

47. ¡Muchas gracias! ¿Preguntas?