Direccionamiento y enrutamiento en Internet

Direccionamiento y enrutamiento en
Internet
Avi Freedman
Ravi Sundaram
Esquema
Orígenes de Internet
Protocolos y paquetes
Direccionamiento - IPv4 frente a IPv6
Enrutamiento – visión global
BGP - modelo
BGP - convergencia y dificultades
Introducción
• Internet es una RED de redes – tanto desde el punto
de vista lógico como físico.
• Millones de ordenadores son capaces de comunicarse
entre sí en tiempo real.
• Almacenamiento y envío basados en paquetes.
• Direccionamiento – modo de identificar ordenadores.
• Enrutamiento – transmisión de paquetes desde un
origen hasta un destino.
Orígenes
• Experimento académico realizado en la década de los 60,
financiado por ARPA - Advanced Research Projects
Agency, conocida ahora como DARPA.
• Diciembre de 1969 – se activó la primera red de 4 nodos,
utilizando para ello una conexión de 56 kbps.
• 1978 – surge el protocolo IP.
• 1982 – surge TCP, ARPANET se divide en MILNET e
Internet.
• 1983 - Internet consta de 200 ordenadores.
Orígenes
• 1984 – nacen los grupos de noticias.
• 1986 – surge el DNS y, motivado por el correo electrónico,
sustituye a la tabla de host.
• 1988 – surge el gusano, creado por el CERT.
• 1989 – 100.000 ordenadores en Internet, con readaptación
del protocolo TCP para evitar congestionamiento.
• 1990 – tráfico comercial aún prohibido en el backbone de
Internet.
• 1991 – fin de la prohibición comercial, nace la www.
Orígenes
• Mayo de 1993 – última petición de la NSFNET para NAPs
privados.
• 1995 – vBNS sustituye a NSFNET – un servicio de
backbone de alto rendimiento que conecta ciertas
universidades y centros de investigación a una velocidad de
155 Mbps e incluso más, contrato otorgado a MCI
(reemplazado por Abilene 10 Gbps?).
• 2002 - 350 millones de hosts.
Observaciones
•
•
•
•
•
•
•
•
Crecimiento sin precedentes.
Control descentralizado – desafíos y oportunidades.
Rendimiento.
Fiabilidad.
Contabilidad.
Seguridad.
Directorio.
Argumentos finales sobre el diseño del sistema. ACM Trans
on Comp systems, noviembre de 1984, págs. 277-288.
Protocolos
FTP
SMTP
DNS
UDP
TCP
ICMP
IP
SNMP
Paquetes
De 46 a 1500 bytes
Cabecera IP
Ethernet
Cabecera
Datos de la aplicación
TCP/UDP
Cola
Ethernet
Direccionamiento
•
•
•
•
Direcciones de 32 bits - a.b.c.d
4.000 millones de direcciones posibles.
250 millones de hosts aproximados.
IPv4 basado en RFC791 en 1981.
Direccionamiento
• Clasificación en el pasado:
Class A - primeros 8 bits fijos.
Class B - primeros 16 bits fijos.
Class C - primeros 24 bits fijos.
• CIDR – Enrutamiento de interdominio sin clases.
a.b.c.d/m - primeros bits m fijos.
p.ej. 0.0.0.0/29 = 0.0.0.0 a 0.0.0.7
• Regla de enrutamiento de correspondencia más concreta.
Direccionamiento
• Cuestiones relacionadas con IPv4.
Reducción del espacio de direcciones.
Control realizado por el registro central.
Ninguna consideración sobre redes/enrutamiento.
Ninguna consideración de seguridad.
Ninguna consideración en cuanto a calidad de
servicio (QoS).
Esto quedaría resumido como escalabilidad, seguridad y
calidad de servicio (QoS).
Direccionamiento
• IPv6 o IPng
128 bits
jerárquico (basado en la red);
seguro (usa IPSec);
calidad de servicio (bits repartidos para el etiquetado
de flujos).
Direccionamiento
• La migración tendrá lugar de 4 a 6.
Escalabilidad - CIDR/NAT (no antes del 2010).
Seguridad - IPSec y nivel de aplicación.
Calidad de servicio – nivel de aplicación.
Enrutamiento
• Internet – colección de sistemas autónomos.
• Sistema autónomo (AS) – conjunto de enrutadores que
comparten la misma política de enrutamiento, los
enrutadores de un AS son parecidos a las oficinas de
correo de un país.
• Protocolo de enrutamiento – colección de reglas para el
envío de paquetes.
Enrutamiento
• Distancia (ruta)- protocolos de vector.
Las actualizaciones de enrutamiento incluyen vector
de distancias (rutas);
Cada nodo posee un árbol de ruta más corta
(basado en una política).
Ejemplos: RIP, BGP4
Enrutamiento
• Protocolos de estados de conexión.
Las actualizaciones de enrutamiento incluyen estados
de conexión y otras actualizaciones;
Cada nodo contiene un grafo completo;
Ejemplo: OSPF
Localización de rutas
[koods@koods-desktop ~]$ traceroute www.berkeley.edu
traceroute to arachne.berkeley.edu (169.229.131.109), 30 hops max, 40 byte packets
1 172.24.80.1 (172.24.80.1) 0.401 ms 0.308 ms 0.291 ms
2 corp2-primary.kendall.akamai.com (172.24.8.2) 0.411 ms 0.334 ms 0.331 ms
3 akafire.kendall.akamai.com (172.24.44.4) 0.280 ms 0.208 ms 0.368 ms
4 65.202.32.3 (65.202.32.3) 0.608 ms 1.651 ms 0.923 ms
5 65.202.33.246 (65.202.33.246) 0.754 ms 0.664 ms 0.832 ms
6 serial4-0-2.hsipaccess1.Boston1.Level3.net (166.90.184.53) 0.912 ms 0.888 ms 0.881 ms
7 unknown.Level3.net (64.159.3.141) 1.349 ms 1.696 ms 2.018 ms
8 so-2-0-0.mp2.SanJose1.Level3.net (64.159.0.218) 85.658 ms 85.287 ms 84.278 m
9 gige9-1.hsipaccess1.SanJose1.Level3.net (64.159.2.103) 84.682 ms 84.666 ms 84.404 m
10 unknown.Level3.net (209.247.159.110) 80.145 ms 80.630 ms 80.860 m
11 ucb-gw--qsv-juniper.calren2.net (128.32.0.69) 83.634 ms 84.703 ms 110.922 m
12 vlan196.inr-201-eva.Berkeley.EDU (128.32.0.74) 83.906 ms 87.205 ms 85.161 m
13 vlan209.inr-203-eva.Berkeley.EDU (128.32.255.2) 138.753 ms 141.608 ms 142.004 m
14 arachne.Berkeley.EDU (169.229.131.109) 140.416 ms 128.705 ms 143.716 ms
BGP - modelo
• Modelado como una colección de sistemas autónomos
con relaciones no jerárquicas entre sí.
• Se puede considerar como un grafo G=(V,E) con
sistemas autónomos representados por los vértices v
en V, y por relaciones no jerárquicas por
extremidades e en E.
12222
701
BGP- Protocolo de puerta de enlace en el borde
• Protocolo vector-ruta – cada vértice mantiene un árbol de
camino más corto, arraigado en sí mismo.
• “más corto” – combinación de política y distancia basada
en métrica.
• Cada sistema autónomo selecciona sus rutas basadas en
su propia política, junto a las mejores rutas de sus vecinos.
BGP – modelo idealizado
• Internet está modelada como un grafo no dirigido G=(V,E), donde
V corresponde a los sistemas autónomos y E a las relaciones no
jerárquicas.
• Cada vértice asimila un conjunto de avisos de ruta de sus vecinos.
• Un aviso de ruta es un registro con los siguientes atributos:
nlri: información sobre accesibilidad de capa de red, ej. 1.2.3.4
as_path: lista ordenada de vértices, comenzando con el próximo
salto, ej. 701 12222.
loc_pref: preferencia local con dlp usado para representar un valor
por defecto.
BGP – modelo idealizado
• Cada vértice selecciona la mejor ruta para un determinado
destino. Si posee muchas rutas r_1, r_2 … r_k con el
mismo destino, es decir, r_i.nlri = r_j.nlri, éste selecciona la
primera con base en la más alta local-pref, luego con base
en el as_path más corto, con vínculos rotos arbitrariamente.
• Transformaciones de ruta:
- Las preferencias locales no son comunicadas.
- Sin bucles: v nunca acepta rutas r donde v ε r.as_path.
- El conjunto de rutas seleccionadas en v se pasa a los vecinos
de v con v colgando de as_path.
- Política de importación y exportación.
BGP – modelo idealizado
• Política de importación y exportación.
Exportar
Verdadero=> aceptar
Importar
17 ε as_path => rechazar
• Si todas las reglas de importación y exportación fuesen
“verdadero => aceptar”, BGP quedaría reducido a un
puro protocolo de vector de distancia.
BGP – modelo idealizado
• Comportamiento dinámico.
Informalmente, un sistema BGP S = <G, Policy(G), S0>,
compuesto de un grafo AS G= (V,E), posee una
política de importación y exportación para cada v_j en V,
y un estado inicial S0 = (c0_1,c0_2,…c)_n), donde
c0_j es el destino originado por v_j.
• Si v_j se activa, obtendrá avisos de ruta de sus vecinos
más próximos y seleccionará sus mejores rutas.
BGP – cuestión de convergencia
• Grafo de estado.
- Grafo dirigido de todos los estados con S_j => S_k, si existe un v
cuya activación provoque el cambio.
- Se dice que un estado S es final si S => S en la activación de
cualquier v.
- Se dice que un sistema BGP se puede solventar si posee un
estado final.
- Se dice que un sistema BGP es convergente si termina en un
estado final independientemente de la secuencia de
activación.
BGP - cuestión de convergencia
• ¿Es posible que la política configurada localmente de modo
correcto provoque anomalías globales de enrutamiento?
• ¿Puede el protocolo divergir, es decir, puede hacer que
una colección de sistemas autónomos intercambien
mensajes continuamente sin llegar a converger?
BGP - cuestión de convergencia
• ¿Es un sistema BGP divergente en la práctica? Existen historias
terroríficas sobre redes que se han configurado accidentalmente para
absorber todo el tráfico, pero que no dan pruebas de trampas a gran
escala.
• Sin embargo, se dan muchos y frecuentes casos de convergencia
retrasada hasta 50 minutos. En Labovitz, C., Ahuja, A., Bose, A. y
Jahanian, F., “Delayed Internet Routing Convergence”, Proceedings
of Sigcomm, 2000, págs. 175-18, los autores realizan experimentos en
los que apartan una ruta y la sustituyen por otra, para ver cuánto
tiempo antes descarga en Internet, mientras es observada desde
varios puntos con ventaja.
BGP - cuestión de convergencia
• Además de las varias anomalías específicas del
fabricante, la principal razón para que se dé una
convergencia larga, es que los protocolos de vector
de ruta consideren múltiples rutas de una longitud
determinada, a diferencia de los protocolos de vector
de distancia, que tienen en cuenta sólo una ruta de
una longitud específica. En la referencia
anteriormente mencionada, los autores construyen un
ejemplo en el que se tiene en cuenta cada ruta libre
de bucles en toda la red, pues, dado que existe un
número exponencial de dichas rutas, cabe esperar
que la convergencia se retrase.
BGP - cuestión de convergencia
• El siguiente ejemplo ha sido tomado de:
Varadhan, K., Govindan, R. y Estrin D.
Persistent route oscillations
ISI TR 96-631
BGP - cuestión de convergencia
dest
DISPOSITIVO CON
PROBLEMA
2
1
0
3
Todas las reglas son en mod. 3
Reglas de exportación: nlri=dest => aceptar
Reglas de importación: si i+1 => i entonces nlri=dest y as_path=[I+1,0]
=>
loc_pref = dlp +1; nlri=d => loc_pref=dlp
si i-1 => I entonces nlri=dest => aceptar
BGP - cuestión de convergencia
dest
DISPOSITIVO CON
PROBLEMA
1
2
0
33
¿Tiene solución el DISPOSITIVO CON PROBLEMA?
BGP - cuestión de convergencia
dest
DISPOSITIVO CON
PROBLEMA
11
2
0
3
¿Tiene solución el DISPOSITIVO CON PROBLEMA?
BGP - cuestión de convergencia
dest
DISPOSITIVO CON
PROBLEMA
1
2
0
3
¿Tiene solución el DISPOSITIVO CON PROBLEMA?
BGP - cuestión de convergencia
dest
DISPOSITIVO CON
PROBLEMA
1
2
0
33
¿Tiene solución el DISPOSITIVO CON PROBLEMA?
BGP - cuestión de convergencia
• ¿Tiene solución el DISPOSITIVO CON PROBLEMA?
- Para que un DISPOSITIVO CON PROBLEMA tenga solución,
debe tener un estado final.
- En el caso de sistemas de un único destino, es fácil observar que
en un estado final, el grafo inducido por as_path en cada vértice
para un destino, es un árbol orientado hacia el destino, y que
este estado final se puede alcanzar al activar todos los nodos
del árbol, siguiendo un orden de primer ancho.
- El DISPOSITIVO CON PROBLEMA no posee un estado final, y
esto se puede comprobar observando los 6 árboles arraigados en
0, y verificando que ninguno de ellos funciona.
BGP - cuestión de convergencia
• Los siguientes resultados se han tomado de:
Griffin, T. y Wilfong, G.,
“An Analysis of BGP Convergence Properties”
Proceedings of Sigcomm 99, págs. 277-288
BGP - otro problema
• ACCESIBILIDAD: dado un sistema S, los vértices v y w, y
el destino d originado por w, ¿existe un estado final en el
que d se pueda alcanzar desde v?
• ACCESIBILIDAD está en NP
Pf (función programada): se considera un estado final, y
se verifica la accesibilidad (y la finalidad).
• Para mostrar que la ACCESIBILIDAD es un problema
NP-difícil, demostramos una reducción a partir de 3SAT.
La ACCESIBILIDAD es NP-difícil
Ejemplo de 3-SAT: (x1 V x2’ V x3) y (x1’ V x2’ V x3’) …
x1
x2
xn
w
z
d
X1’
X2’
Xn’
C1
C2
Cm
La ACCESIBILIDAD es NP-difícil
X1=verdadero; x2=falso; x3=falso…
x1
x2
xn
w
z
d
X1’
X2’
Xn’
C1
C2
Cm
La ACCESIBILIDAD es NP-difícil
• Política de exportación: verdadero => aceptar.
• Política de importación: asegura que sólo uno de xj o xj’
está en el atributo as_path de una ruta hacia d, y una vez
que la ruta se haya escogido, es obligatorio un bloqueo.
Ejemplo: xj Æ xj’: nlri=d => loc_pref = dlp + 1;
xj-1 Æ xj : nlri=d & xj-1’ no en
as_path => loc_pref = dlp;
Para la cláusula Cj = xk V xl V xm: xk en as_path o xl en
as_path o xm en as_path => loc_pref = dlp.
La ACCESIBILIDAD es NP-difícil
• Se puede satisfacer => ACCESIBLE
Pf (función programada): se activa por las
erratas que se definen como verdaderas.
• ACCESIBLE => se puede satisfacer
Pf (función programada): Proviene superficialmente del
modo en el que la política funciona para garantizar una
única ruta.
Otros problemas e implicaciones
• ASIMETRÍA
• SOLVENCIA
• ROBUSTEZ
• RADB (base de datos de arbitraje de enrutamiento) y
verificación centralizada.
Investigación
Considere un protocolo de vector de ruta como BGP – en
cada paso, un nodo obtiene información de sus vecinos y
utiliza su política (local) para actualizar su tabla de rutas.
Una topología y una colección de políticas se pueden
satisfacer si existe un estado en el que las actualizaciones
no cambien. Se dice que un sistema converge si éste
alcanza dicho estado.
El problema consiste en probar y caracterizar el
comportamiento de estos sistemas, es decir, cuándo
divergen, y si pueden converger en más de un estado que
se pueda satisfacer.
Referencia:
www.acm.org/pubs/citations/proceedings/comm/3
16188/p277-griffin/
¿Preguntas?