Analisis e Implementacion de Mecanismos para La Gestion Del Algoritmo Selector de Direcciones Por Omision en IPv6

Proyecto Fin de Carrera An lisis e Implementaci n de Mecanismos a o para la Gesti n del Algoritmo Selector de Direcciones o por Omisi n en IPv6 o
Autor: H ctor Cordob s de la Calle e e Tutor: Alberto Garca Martnez Enero de 2003
El hijo que no ha alcanzado la sonrisa de sus padres no es admitido a la mesa de los dioses ni en el lecho de las diosas. Virgilio, Egloga IV Poli n o
A mis padres, por haber cometido la bendita insensatez de responderme cuando preguntaba por qu e (y pagar las consecuencias).
Agradecimientos
En n, que el Prestige lleva unos dos meses soltando porquera, los EEUU quieren entrar en Irak, y los m s peque os creen que Las dos torreses una referencia al 11-S. Y es en este momento a n cuando me da por terminar mi proyecto. Por mucho que me pare a pensar, tengo que reconocer que muchas veces me queda algo por decir, y otras tantas digo demasiado. Sin embargo, en esta ocasion, preero no dejar a nadie fuera, y, si a n intentando no olvidarme, alguien se echa en falta, espero que sepa disculparme. u Gracias a todos los compa eros que han compartido conmigo las horas de clase, de pr cticas, n a de esperas, de as llamadas comidas, de mus en Mediterr neo, de prisas, de noches sin dormir, de a ex menes de campos, de revisiones de campos. . . Valio la pena. C mo no, a todos los amiguetes a o de las dos residencias de estudiantes, aunque casi todos est n ya fuera y casi no se les vea. e Alg n que otro profesor tambi n se merece estar aqu, pero como en casi toda esta p gina u e a obviar los nombres para que no se me olvide nadie. Aunque no son pocos. e A los amigos que he encontrado aqu, con los que en cualquier momento se poda hablar, a los que siempre escuchan o te echan la bronca si es necesario. O smplemente pasar el rato. Sobre todo por aguantarme de vez en cuando algunas tonteras. Ellos saben qui nes son, y tambi n saben e e cu les son las tonteras. . . Por supuesto, a los que ya tena cuando llegu a la Universidad, aunque a e no les guste jugar al Trivial (ni al mus). Y esto incluye tambi n a los estivales y los moralos. Y a e los que no olvidar . e A aquellos desconocidos que sin saber qui n eres te saludan por los pasillos de la Universidad. e O ser que estoy perdiendo la memoria? a A los profesores y colegas del antiguo GSyC, por mostrar como se puede ense ar de verdad, n y sobre todo, c mo se puede aprender de verdad. Y por qu no? Tambi n a los del DEI, por o e e recogernos alg n tiempo. u A todos, espero seguir teni ndoos cerca, para darnos la brasa acerca de lo viejos que nos estae mos volviendo. Se podra pensar as sin ser viejo? Uf. Para este proyecto, mis sinceras gracias a Alberto Garca, por propon rmelo y tutelarme, y por e el empuj n del ultimo mes, a JFRH, por la gran ayuda con FreeBSD y dem s, a Guillermo, por o a
A sus oportunas apreciaciones sobre seguridad, su habilidad con LTEX, y su disposici n a prueba de o
bombas, y a Beatriz, por intentar comprender lo ininteligible de mi discurso y ayudarme a vericar la memoria, que hay que tener ganas. . . Bueno, y a los administradores del laboratorio, que tambi n sufrieron un poco. e Tambi n querra agradecer especialmente a mi tio Alberto (suena a dedicatoria de televisi on, e pero as son las cosas), por apoyarme desde el principio con la carrera y ayudarme en lo que estuviera en su mano. Ya soy del gremio!
Y c mo no, por ultimo (but not least), a mis padres, por estar siempre al lado. Y por aceptar o las tasas univeristarias con resignaci n. Y sobre todo, por lo que os queda por aguantar. o H ctor e
Proyecto n de carrera - H ctor Cordob s de la Calle e e
Indice general
1. Introducci n al proyecto o 11
1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I Introducci n o
2. El algoritmo DAS
14
15
2.1. Escenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2. Marco de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3. Tabla de polticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4. Descripci n del algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 o 2.4.1. Funcionamiento del algoritmo de seleccion de direcci n origen . . . . . . . 19 o 2.4.2. Funcionamiento del algoritmo de seleccion de direcci n destino . . . . . . 20 o 2.5. Consideraciones sobre el algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.1. Interacciones con routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.2. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.6. Ejemplos de funcionamiento del algortimo . . . . . . . . . . . . . . . . . . . . . . 22 2.6.1. Selecci n de la direcci n origen . . . . . . . . . . . . . . . . . . . . . . . 22 o o 2.6.2. Selecci n de la direcci n destino . . . . . . . . . . . . . . . . . . . . . . . 23 o o 2.6.3. Conguraciones de preferencia por IPv4 . . . . . . . . . . . . . . . . . . . 25 2.6.4. Conguraciones de entornos multihoming . . . . . . . . . . . . . . . . . . 26
II An lisis de los mecanismos candidatos a

3. Caractersticas necesarias para el mecanismo de propagacion de DAS 4. An lisis sobre seguridad a
29
30 34
4.1. Los problemas de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1.1. Funciones resumen (hash ) . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4
Indice general 4.1.2. Esquemas de clave sim trica vs. clave p blica . . . . . . . . . . . . . . . . 35 e u 4.2. Soluciones a los problemas de seguridad . . . . . . . . . . . . . . . . . . . . . . . 36 4.2.1. Problemas de seguridad en una red . . . . . . . . . . . . . . . . . . . . . . 38 4.3. Aplicaci n al caso presente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 o 4.3.1. Aplicaci n al caso habitual . . . . . . . . . . . . . . . . . . . . . . . . . . 41 o 4.3.2. Aplicaci n a QoS multihoming . . . . . . . . . . . . . . . . . . . . . . . . 41 o 4.4. Conclusiones sobre seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5. An lisis de mecanismos a 44
5.1. Router advert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.1.1. Resumen de caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.2. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.2.1. Resumen de caractersiticas . . . . . . . . . . . . . . . . . . . . . . . . . 5.3. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1. Equipos actuando como gestores SNMP, un agente con la informaci on . . . 5.3.2. Equipos agentes, un gestor por unidad de administraci on . . . . . . . . . . 46 47 49 50
5.3.3. Consideraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.3.4. Resumen de caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.4. COPS (Common Open Policy Service) . . . . . . . . . . . . . . . . . . . . . . . . 53 5.4.1. Resumen de caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.5. LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.5.1. Resumen de caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6. Relaciones entre los mecanismos de conguracion 58 6.1. DHCP como mecanismo de conguracion autom tica . . . . . . . . . . . . . . . . 59 a 6.2. Router advert como mecanismo de conguracion . . . . . . . . . . . . . . . . . . 59 6.3. Conguraci n manual de las direcciones . . . . . . . . . . . . . . . . . . . . . . . 60 o 7. Conclusiones sobre los mecanismos analizados 62
III Implementaci n de mecanismos o

8. Introducci n a las implementaciones o
64
65
8.1. Sobre las implementaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 8.2. Escenarios de los mecanismos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 9. DHCPv6 67
9.1. Punto de partida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 9.2. DHCPv6 dentro de la red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Proyecto n de carrera - H ctor Cordob s de la Calle e e 5
Indice general 9.3. La implementaci n KAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 o 9.3.1. El programa servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 9.3.2. El programa cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 9.4. Cambios realizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 9.4.1. Funcionamiento propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . 75 9.4.2. La extensi n DHCPv6 DAS . . . . . . . . . . . . . . . . . . . . . . . . . 75 o 9.4.3. Cambios en el servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 9.4.4. Cambios en el cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 9.4.5. Resumen de los cambios en los cheros . . . . . . . . . . . . . . . . . . . 78 9.5. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 9.5.1. Conguraci n general . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 o 9.5.2. Conguraci n general y de cliente . . . . . . . . . . . . . . . . . . . . . . 83 o 9.5.3. Uso de rapid commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 9.5.4. Envio de datos incorrectos . . . . . . . . . . . . . . . . . . . . . . . . . . 87 9.6. Conclusiones sobre DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 10. SNMP 89 10.1. Punto de partida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 10.2. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 10.2.1. Generaci n de la MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 o 10.2.2. El agente SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 10.2.3. El gestor SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 10.3. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 10.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 11. LDAP 97
11.1. Punto de partida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 11.2. Generaci n de un schema LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 o 11.3. Organizaci n del espacio LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 o 11.4. Conguraci n de los niveles de acceso . . . . . . . . . . . . . . . . . . . . . . . . 103 o 11.5. Uso de la capa TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 11.6. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 11.7. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
IV
Conclusiones nales
113
114
12. Conclusiones nales
12.1. Sobre los resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Indice general 12.2. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 13. Bibliografa y referencias 117
Ap ndices e
119
120 123 129
A. Glosario B. SNMP MIB para DAS C. Manuales de instalaci n, conguraci n y uso o o
C.1. Implementaci n de DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 o C.1.1. Compilaci n e instalaci n de los programas . . . . . . . . . . . . . . . . . 130 o o C.1.2. Conguraci n de los programas . . . . . . . . . . . . . . . . . . . . . . . 130 o C.1.3. Ejecuci n de los programas . . . . . . . . . . . . . . . . . . . . . . . . . 131 o C.2. Implementaci n de SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 o C.2.1. Instalaci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 o C.2.2. Conguraci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 o C.2.3. Ejecuci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 o C.3. Implementaci n del servidor LDAP . . . . . . . . . . . . . . . . . . . . . . . . . 133 o C.3.1. Instalaci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 o C.3.2. Conguraci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 o C.3.3. Generaci n de una CA y su certicado . . . . . . . . . . . . . . . . . . . . 135 o C.3.4. Generaci n de un certicado para el servidor . . . . . . . . . . . . . . . . 137 o C.3.5. Implantaci n del certicado en LDAP . . . . . . . . . . . . . . . . . . . . 139 o C.3.6. Fichero de conguraci n nal . . . . . . . . . . . . . . . . . . . . . . . . 140 o C.3.7. Ejecuci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 o C.4. Generador de archivos de conguracion . . . . . . . . . . . . . . . . . . . . . . . 143 D. Licencias y marcas 145
D.1. Sobre las marcas registradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 D.2. Sobre el software utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 D.3. Sobre esta memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 D.4. Descripci n de las licencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 o D.4.1. GNU General Public License . . . . . . . . . . . . . . . . . . . . . . . . . 147 D.4.2. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 D.4.3. KAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 D.4.4. GNU Free Documentation License . . . . . . . . . . . . . . . . . . . . . . 154
Indice general E. Contenido del CD 161
VI Presupuesto
162
Indice de tablas
2.1. Tabla de polticas por omisi n . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 o 2.2. Ejemplo de tabla de polticas para IPv4 . . . . . . . . . . . . . . . . . . . . . . . 25 2.3. Prejos de cada empresa por ISP . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.4. Ejemplo de tabla de polticas para multihoming . . . . . . . . . . . . . . . . . . . 27 7.1. Resumen de los mecanismos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 11.1. Niveles de acceso por clientes y zonas al servidor LDAP . . . . . . . . . . . . . . 104
Indice de guras
2.1. Esquema del ejemplo para el caso multihoming . . . . . . . . . . . . . . . . . . . 26 4.1. Esquema del fucionamiento de la rma digital . . . . . . . . . . . . . . . . . . . . 37 4.2. Esquema de man-in-the-middle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.3. Esquema de man-in-the-middle junto con IPSec, SSL o TLS . . . . . . . . . . . . 40 5.1. Esquema b sico del arbol de OIDs . . . . . . . . . a 5.2. Equipos gestores, un agente con la informacion . . 5.3. Equipos agentes, un gestor con la informacion . . . 5.4. Ejemplo de un arbol LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 . . . . . . . . . . . . . . . . . 49 . . . . . . . . . . . . . . . . . 51 . . . . . . . . . . . . . . . . . 56
9.1. Esquema de funcionamiento de DHCPv6 . . . . . . . . . . . . . . . . . . . . . . 69 9.2. Estructura del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 9.3. Estructura del cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 9.4. Estructura de la opci n DAS dentro del paquete DHCPv6 . . . . . . . . . . . . . . 76 o 10.1. Estructura de la MIB planteada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 11.1. Arbol OID correspondiente a LDAP . . . . . . . . . . . . . . . . . . . . . . . . . 101 11.2. Organizaci n LDAP propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 o 11.3. Men de conexiones de LBE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 u 11.4. Opciones de conexi n para un equipo . . . . . . . . . . . . . . . . . . . . . . . . 110 o 11.5. Opciones para una nueva CA no reconocida . . . . . . . . . . . . . . . . . . . . . 110 11.6. Visi n general del arbol LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 o 11.7. Atributos disponibles para el equipo bacterio . . . . . . . . . . . . . . . . . . . 111 11.8. Atributos de la entrada default . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 11.9. Atributos de la entrada mortadelo . . . . . . . . . . . . . . . . . . . . . . . . . 112 11.10. nforme de errores del programa LBE . . . . . . . . . . . . . . . . . . . . . . . . 112 I
10
Captulo 1 Introducci n al proyecto o
La presente memoria trata del estudio pormenorizado y el desarrollo de mecanismos para enviar una informaci n de gesti n. Particularmente, se tratar con la informaci n necesaria para un o o a o algoritmo que forma parte de la nueva especicacion del protocolo IP, IPv6, que se encarga de realizar la selecci n de las direcciones que se utilizar n durante una comunicaci n. o a o La importancia de este algoritmo radica, principalmente, en posibilitar el uso adecuado de los distintos tipos de direcciones que puede tener asignados un interfaz de red en IPv6. Como es de imaginar, lo adecuado del uso depende en gran medida del entorno en el que se trabaje. Por ello, el algoritmo est dotado de una tabla, gestionable, en la que un administrador puede incorporar a aquellas entradas que m s convengan a la red. Esta ser la informaci n a transmitir y el centro de a a o este proyecto.
1.1.
Objetivos
La intenci n principal en todo este proyecto es lograr una base solida para trabajos futuros en o torno a este algoritmo. Por una parte, se ha querido realizar un an lisis completo de todos los factores que afectan a la a o transmisi n, es decir, c mo ha de ser enviada la informacion, c mo se debe acceder, y qu medidas o o e han de ser tenidas en cuenta. Particularmente, se han previsto implicaciones de seguridad, abilidad de la comunicaci n, facilidad de implantaci n de las soluciones, y con qu otros mecanismos o o e
11
Captulo 1. Introducci n al proyecto o tendr que coexistir, entre otros. a Por otra parte, se ha procurado generar una serie de realizaciones pr cticas, donde se muesa tren de manera efectiva los resultados a los que se llega en el an lisis. Como es de esperar, cada a mecanismo tendr ciertas ventajas e inconvenientes dependiendo de la aplicacion. Por ello, en las a implementaciones se intentar maximizar las ventajas, para aprovechar la verdadera potencia de a cada mecanismo utilizado.
1.2.
Estructura de la memoria
Esta documentaci n est estructurada en cuatro partes principales, cada una de las cuales hace o a incidencia en un objetivo. La primera parte, la introducci n, presenta la informaci n m s importante para poder tener o o a conciencia del problema a resolver. A destacar un resumen completo del algoritmo, comentan do su necesidad, su funcionamiento, e ilustrado con multiples ejemplos en distintos entornos de aplicaci n. Aunque la totalidad de este apartado no es imprescindible para la comprensi on del cono tenido del proyecto, es sin duda de lectura muy recomendable, puesto que ayuda a tener conciencia de todas las necesidades que habr que cubrir. a La segunda parte, el an lisis, est subdividida en varios captulos que seccionan los puntos a a m s importantes a tener en cuenta en los mecanismos que implementar n la transmisi n. Primeraa a o mente se analizar n, en funci n de consideraciones generales, cu les deben ser las caractersticas a o a del mecanismo tipo a utilizar. Posteriormente se realizar un an lisis en materia de seguridad, y a a se observar n las implicaciones en el entorno del funcionamiento del algortimo. Una vez que se a han presentado las necesidades y las caractersticas a analizar, se entra de lleno en varios mecanis mos ya existentes, observando c mo encajan en las ya mencionadas necesidades. Por ultimo, se o mostrar un resumen donde se podr n apreciar de manera sencilla los resultados del an lisis. a a a La tercera parte, las implementaciones, es la logica continuaci n de las dos anteriores. En ella o se muestran los desarrollos de algunos de los mecanismos anteriormente analizados, donde se intenta, adem s, poner de maniesto las ventajas que cada uno de ellos aportan. A lo largo de estos a captulos se presentan los puntos de partida antes de comenzar el desarrollo: especicaciones, he rramientas disponibles. . . Desde estos puntos se evoluciona en el desarrollo de la implementaci on, atendiendo a decisiones de dise o y a otras consideraciones propias de cada mecanismo. Y por n ultimo, se muestra un peque o resumen de las principales dicultades, y qu ha sido necesario n e Proyecto n de carrera - H ctor Cordob s de la Calle e e 12
Captulo 1. Introducci n al proyecto o manejar para poder realizar el desarrollo comentado. Finalmente, la cuarta parte es un punto y seguido al trabajo llevado a cabo en este proyecto. En ella se muestran la reexiones sobre los resultados logrados, el grado de consecuci on de los objetivos propuestos, y muy especialmente pinceladas de lo que seran nuevas posibles vas de investigaci n y desarrollo. o Esta memoria concluye con la presentacion del presupuesto nal, aportacion necesaria en todos los proyectos de Fin de Carrera.
13
Parte I Introducci n o
14
Captulo 2 El algoritmo DAS
En este captulo se ver una presentaci n completa sobre algoritmo DAS. Principalmente, se a o mostrar el origen de la necesidad del algoritmo en la implementacion de IPv6, as como una a peque a reexi n acerca de las caractersticas que debe poseer. n o Posteriormente, se mostrar el marco de trabajo sobre el que el algoritmo debe funcionar. Tama bi n se ver c mo se aborda el problema en t rminos de implementaciones en el sistema (como e a o e se comportar el algoritmo junto con las aplicaciones), y como consigue resultados utiles para los a prop sitos de una comunicaci n eciente. o o M s tarde, se mostrar una pieza clave en el funcionamiento del algoritmo, que es la que mueve a a todo este proyecto. La tabla de polticas DAS es el elemento gestionable que permite los cambios en el funcionamiento del algoritmo, adapt ndolo a cada situaci n. a o Despu s, se realizar una descripci n detallada del funcionamiento del algoritmo, mostrando e a o el proceso paso a paso y c mo se consigue que la decisi n nal sea v lida tanto para el nodo que o o a inicia la conexi n como para el que recibe la petici n. o o Finalmente, se mostrar n m ltiples ejemplos del funcionamiento del algoritmo en varias situaa u ciones, mostrando la importancia que puede cobrar en entornos no demasiado extra nos.
15
Captulo 2. El algoritmo DAS
2.1.
Escenario
Una de las nuevas caractersticas que aporta IPv6 sobre IPv4 es la asignacion de m ltiples di u recciones de red a un mismo interfaz [Hinden02]. Adem s, existen distintos tipos de direcciones a que son v lidas o preferibles en distintas situaciones. Por ejemplo, existen direcciones con distintos a rangos de alcance: link-local (la red local), site-local (un ambito administrativo, como puede ser un campus), o global (v lida y representativa en cualquier punto de Internet). Otras clasicaciones a diferencian entre preferidas y obsoletas (cuando caducan las direcciones conguradas autom ati camente en generacion sin estado), publicas y temporales (usadas en los primeros paquetes para ocultar la identidad del equipo durante la autonguracion [Narten01]), y, con los conceptos de movilidad, home address y care-of address. Si se tienen en cuenta las situaciones de multihoming es de esperar que un nodo tenga muchas m s direcciones. Incluido queda, adem s, el caso particular a a de equipos con pilas hbridas (dual stack), donde existen simult neamente direcciones IPv4. a Como se aprecia, las implementaciones IPv6 tendr n que resolver el problema de qu direcci n a e o elegir a la hora de establecer una comunicacion. Para poder mantener y desarrollar con IPv6 es necesario contar con un unico algoritmo, de forma que se pueda prever el comportamiento a priori. La utilidad de esta armaci n quedar patente en los ejemplos. o a Este algoritmo debe estar presente tanto para la seleccion de la direcci n de origen como para o la de destino, y as consiga resultados utiles por la dependencia de ambas. La importancia radica en saber elegir el alcance correcto para las direcciones, as como su estado (preferida u obsoleta, por ejemplo). El algoritmo propuesto en [Draves02] utiliza una serie de reglas de precedencia, y como m todo e de selecci n ultimo la mayor coincidencia de prejos, en los casos en los que sin mayor informao ci n se ha llegado a una situaci n de igualdad entre direcciones. o o M s concretamente, este algoritmo tiene capacidad de inclusion de polticas de funcionamiena to, permitiendo a los administradores optar por conguraciones diferentes a la inicial, util en situaciones dual stack y multihoming.
16
2.2.
Marco de trabajo
El algoritmo aqu presentado divide en dos el problema, intentando resolver por separado la selecci n de direcci n de origen de la de destino con sendos algoritmos. Sin embargo, est n dio o a se ados para obtener buenos resultados de manera conjunta, y comparten la misma informaci on n de administraci n. o En el uso habitual, a la hora de establecer una conexion se utilizan APIs como getaddrinfo(), cuyo resultado es una lista de direcciones en orden de preferencia, de entre las cuales la aplicaci on elegir una v lida, recorriendo de manera ordenada la lista as devuelta. El nivel de red no elige la a a direcci n de destino, unicamente lo hace la aplicaci n (aunque en muchos casos, si la aplicacion o o no dispone de m s informaci n, esta optar por utilizar la primera direcci n que haya sido recibida a o a o por getaddrinfo()). Es decir, el hecho de solicitar informacion sobre la direcci on no implica que esta ya haya sido seleccionada. Sin embargo, puede no estar indicada la direcci on de origen, en cuyo caso ser elegida por la capa de red, que ahora s aplica el algoritmo de selecci n de direcci n a o o por s misma, y tiene en cuenta la direcci n destino. o El algoritmo usa distintos criterios para ordenar las direcciones de las que se dispone antes de pasar la lista a la aplicaci n. Se utiliza la aplicaci n sucesiva de una lista de reglas (se ver con o o a m s profundidad en el caso particular de cada componente del algoritmo): a
1. Se preeren pares de direcciones (origen y destino) que coinciden en alcance o tipo, con el menor alcance posible para direcciones destino. 2. Se escogen las direcciones no obsoletas y publicas para las direcciones origen antes que las obsoletas o las temporales. 3. Se preeren las direcciones nativas sobre aquellas que resultan de mecanismos de transici on. Estos mecanismos son necesarios para que coexistan redes IPv4 e IPv6. Por ejemplo, direc ciones de este tipo son las 6to4, que se generan a partir de un prejo reservado y la direcci on IPv4 asignada a un interfaz, consiguiendo un prejo v lido IPv6, pudiendo tener toda una a red IPv6 a partir de conectividad IPv4. 4. En el caso de movilidad, las direcciones dom sticas son preferidas a las care-of, pero en el e caso que el equipo est en la red hogar, y alguna direccion sea a la vez care-of y dom stica, e e ser esta la preferida sobre cualquiera que unicamente sea dom stica. a e 5. Como ultima regla, se rompen los empates con la longitud de coincidencia entre prejos.
17
Captulo 2. El algoritmo DAS Para la aplicaci n de las reglas de decisi n, el algoritmo utiliza una tabla, donde se cotejan o o las direcciones candidatas en cada caso, y donde queda patente la ordenaci on de las direcciones. Por ello, es aqu donde los administradores pueden ajustar sus preferencias. La necesidad de tener reglas m s complejas (representadas por las entradas en la tabla), responde, como se coment o en la a secci n anterior, al uso de IPv6 en entornos que requieran mayor exibilidad que una conguraci on o habitual, como por ejemplo la existencia de varios ISP, seleccionables seg un el destino.
2.3.
Tabla de polticas
La parte administrativa del algoritmo se compone de una tabla de polticas, con los que se busca la mejor concordancia, a imagen de una tabla de encaminamiento. La tabla se compone de tres campos, el prejo, la precedencia y una etiqueta. Por tanto, la b squeda en la tabla a partir de una direccion dada produce dos valores: la precedencia y la etiqueta u asociadas a esa direcci n. o El valor de precedencia es utilizado para ordenar las direcciones de destino. Se corresponden con su valor num rico, es decir, si la precedencia de una direccion A es un n mero mayor que e u la correspondiente a una direcci n B, la direcci n A se encontrar antes que la B en la lista de o o a posibles direcciones de destino. El valor de la etiqueta se utiliza en polticas de administraci n para permitir la preferencia o de un prejo origen particular con un prejo destino concreto. El resultado es que se preere un origen O con una direcci n destino D si las etiquetas son iguales para ambas. La utilidad de esta o caracterstica quedar patente en los ejemplos, sobre todo en los casos de multihoming. a En la documentaci n referente a este algoritmo se recomienda una tabla por omision que se o reproduce aqu. Prejo ::1/128 ::/0 2002::/16 ::/96 ::ffff:0:0/96 Precedencia Etiqueta 50 0 40 1 30 2 20 3 10 4
Tabla 2.1: Tabla de polticas por omisi n o
18
Captulo 2. El algoritmo DAS Esta tabla consigue que se preeran direcciones nativas de origen cuando tambi n lo son de e destino, tambi n 6to4 de origen con direcciones 6to4 de destino, y la misma correspondencia con e direcciones compatibles IPv4. Tambi n se preere el uso de direcciones IPv6 sobre direcciones e IPv4, si est n disponibles para el origen. a
2.4.
Descripci n del algoritmo o
2.4.1. Funcionamiento del algoritmo de seleccion de direcci n origen o

Este m todo es el que el algoritmo utiliza en la capa de red para la seleccion autom tica de la e a direcci n origen a partir de una direcci n destino siempre que la aplicaci n no ha especicado una o o o direcci n origen. En este caso tiene que aceptarse la seleccion impuesta por la aplicaci n, incluso o o en caso de resultar inv lida. Esta asignaci n por parte de la aplicaci n sirve, por ejemplo, para a o o determinar el interfaz de salida. El algoritmo parte de un conjunto de posibles direcciones origen para la direcci on destino en cuesti n. El algoritmo recomienda [Bradner97] utilizar como conjunto de direcciones candio datas las direcciones unicast asociadas al interfaz que se utilizar para alcanzar el destino. Este a primer conjunto se puede reducir si se ha utilizado la opcion administrativa de la etiqueta zonal, manteni ndose, por tanto, unicamente las direcciones que coincidan en esta etiqueta con la coe rrespondiente a la direcci n destino. En cualquier caso, las direcciones multicast, anycast y las no o especicadas quedan excluidas del conjunto. Como es de esperar, al algoritmo devuelve una unica direcci n origen, y s lo es aplicable con o o direcciones destino IPv6. Para las direcciones IPv4 se toman soluciones de transici on (6to4, por ejemplo), que una vez resueltas, ser n traducidas seg n sea necesario (siguiendo el ejemplo, en a u gateways 6to4). As mismo, se determinan distintos alcances: las direcciones locales (loopback), y las de auto conguraci n IPv4 [Cheshire02] tienen ambito link-local, las de direccionamiento o privado [Rekhter96] se consideran site-local; el resto se considera de ambito global. El funcionamiento b sico es el uso de reglas de comparacion, de manera que el cotejo de dos a direcciones dentro del conjunto resulta en una mejor que otra. Por tanto, si al aplicar las reglas un candidato ha resultado perdedor, no es necesario que vuelva a ser tenido en consideraci on durante el resto del algoritmo, puesto que solo se elige al ganador.
19
Captulo 2. El algoritmo DAS La aplicaci n de reglas se realiza consecutivamente, cuando por necesidad en caso de empate o se toma la siguiente.
1. Se preere una direcci n origen si coincide con la de destino. o 2. Posteriormente, si la direcci n es distinta, se preere aqu lla cuyo ambito sea igual o mayor o e que el de destino. Esta es de vital importancia, puesto que un ambito menor imposibilitara la conexi n. o 3. De entre las que cumplan estas condiciones, se evitan las direcciones obsoletas, se preeren las direcciones home, y es preferible usar aqu llas que coincidan con el interfaz de salida e para la direcci n destino. o 4. Si aqu hay empate (pr cticamente hasta ahora las preferencias eran medidas para garantizar a la comunicaci n de manera eciente), el algoritmo utiliza los valores presentes en la tabla: o se preere aquella direcci n que le corresponde la misma etiqueta. o 5. Y por ultimo, se preere la mayor coincidencia en el prejo de las direcciones. Los valores de precedencia no se utilizan en este subalgoritmo.
2.4.2. Funcionamiento del algoritmo de seleccion de direcci n destino o

Esta parte del algoritmo toma una lista de direcciones destino y produce una lista ordenada en orden de preferencia. Aqu s se acepta el uso de direcciones IPv4 como candidatos v lidos, para a lo que el algoritmo requiere (por dise o) que est expresada como IPv4 mapped dentro de una n e direcci n IPv6. o Como subalgoritmo (y una de las garantas de compatibilidad para ambas secciones), se utiliza el algoritmo anteriormente descrito como valor intermedio, seleccionando la direcci on origen correspondiente a cada destino. En aras de la simplicidad, se denominar a esta direcci n DO en la a o posterior enumeraci n las reglas. De hecho, toda las reglas toman los valores correspondientes a o sus direcciones origen. En denitiva, el funcionamiento es similar, siendo la aplicacion consecutiva de reglas de com paraci n el m todo a seguir, siendo necesario en este caso la comparacion completa entre todas las o e direcciones, puesto que el resultado es una lista ordenada de direcciones, siendo m s complejo que a el algoritmo de selecci n de direcci n origen. o o
20
Captulo 2. El algoritmo DAS 1. Se evitan las direcciones inservibles, esto es, de las que se sabe que no se pueden alcanzar, o cuya DO no est denida. a 2. Despu s, se preere un ambito que coincida con el de su propia DO, para minimizar este e primero. Tambi n se evitan las direcciones DO obsoletas. e 3. Entre direcciones DO se preeren las que son, a la vez, dom sticas y care-of, y entre unas y e otras las dom sticas. e Hasta aqu se ha realizado una selecci n tal y como la hara la otra parte de la comunicaci n o o para elegir su direcci n origen. En este punto se aplican las entradas en la tabla. o 4. Se preeren las direcciones que tengan la misma etiqueta que su DO. 5. Posteriormente se toman aquellas con mayor preferencia y tambi n las que utilizan como e transporte un mecanismo nativo (por ejemplo, se preere una direcci on que no implique encapsulamiento como en 6to4). 6. Una vez conseguidos los par metros administrativos y una comunicacion eciente, se prea ere una direcci n con un ambito menor. o 7. Por ultimo, como en el caso de direcciones origen, se utiliza la mayor coincidencia de prejos.
Si aun as existe empate, se mantiene el orden en el que aparecieron en la lista original. Las implementaciones pueden preferir otras selecciones que consideren oportunas (por ejemplo, si puede saberse cu l tendr un mejor funcionamiento), y se situaran precediendo la coincia a dencia de prejos.
2.5.
Consideraciones sobre el algoritmo
2.5.1. Interacciones con routers

La especicaci n del algoritmo de [Draves02] asume que la seleccion de un interfaz de sao lida (encaminamiento) se realiza antes de la seleccion de la direcci n origen. Sin embargo, las o implementaciones pueden usar consideraciones asociadas a la selecci on de direcci n origen como o
21
Captulo 2. El algoritmo DAS desempate a la hora de elegir entre caminos equivalentes como, por ejemplo, la mejor correspondencia entre prejos de direcciones. Y tambi n a la inversa, dependiendo del interfaz de salida se puede preferir una direcci on e origen m s apropiada dentro de la red que se acceda a trav s del mismo. a e
2.5.2. Seguridad
Este algoritmo no tiene inuencia en la seguridad de la infraestructura IP. La unica implicaci n o dentro de temas de seguridad consiste en que cualquier terminal es sensible a un ataque que permita obtener sus direcciones de origen. El m todo, tal y como se describe en [Draves02], se reduce e a forzar al terminal a elegir entre sus direcciones mediante el envo de paquetes formados con diferentes direcciones origen (por ejemplo con direcciones anycast), y enviados desde el mismo nodo atacante. En otro orden de cosas, la seguridad a la hora de transmitir la informaci on que necesita este algoritmo ser tratada aparte en el captulo 4. a
2.6.
Ejemplos de funcionamiento del algortimo
Como ultimo apartado en este resumen, se tratar n algunos ejemplos que ayuden a comprobar a el funcionamiento, incluyendo casos especiales de IPv4 y multihoming, para demostrar la importancia de la tabla de polticas. Los primeros ejemplos usan la tabla por omision. Posteriormente se presentar n los cambios a para conseguir otros funcionamientos. Cada ejemplo muestra las diferentes direcciones con las que se cuenta, la elecci n y el por qu de esta. o e
2.6.1. Selecci n de la direcci n origen o o

Destino Resultado: 2001::1 3ffe::1 (se preere el ambito apropiado) 22
Candidatos: 3ffe::1, fe80::1
Destino Resultado: Destino Resultado: Destino
2001::1 fec0::1 (se preere el ambito apropiado) fec0::1 2001::1 (se preere el ambito apropiado) ff05::1
Candidatos: fec0:1, fe80::1
Candidatos: 2001::1, fe80::1
Candidatos: fec0::1, 2001::1, fe80::1 Resultado: fec0::1 (se preere el ambito apropiado) Destino Resultado: Destino 2001::1 2001::1 (se preere la misma direccion) fec0::1
Candidatos: 2002::1, 2001::1 (obsoleta)
Candidatos: fec0::2(obsoleta), 2001::1 Resultado: fec0::2 (se preere el ambito apropiado) Destino 2001::1
Candidatos: 3ffe::2, 2001::2 Resultado: 2001::2 (se toma la mayor coincidencia de prejos)
2.6.2. Selecci n de la direcci n destino o o

Conjunto candidato: Destinos: Resultado: 2001::2 o fe80::1 o 169.254.13.78 2001::1 o 131.107.65.121 2001::1 despu s 131.107.65.121 e 169.254.13.78) (se preere el mismo ambito) (origen 2001::2), (origen
23
Captulo 2. El algoritmo DAS Conjunto candidato: Destinos: Resultado: fe80::1 o 131.107.65.117 2001::1 o 131.107.65.121 131.107.65.121 (origen 131.107.65.117), despu s 2001::1 (origen e fe80::1) (se preere el mismo ambito) 2001::2 o fe80::1 o 10.1.2.4 2001::1 o 10.1.2.3 2001::1 (origen 2001::2), despu s 10.1.2.3 (origen 10.1.2.4) (se pree ere una mayor precedencia) Conjunto candidato: Destinos: Resultado: 2001::2 o fec0::2 o fe80::2 2001::1 o fec0::1 o fe80::1 () fe80::1 (origen fe80::2), despu s fec0::1 (origen fec0::2), despu s e e 2001::1 (origen 2001::2) (se preere un ambito menor) 2001::2 (care-of address) o 3ffe::1 (home address) o fec0::2 (care-of address) o fe80::2 (care-of address) 2001::1 o fec0::1 2001:1 (origen 3ffe::1), despu s fec0::1 (origen fec0::2) (se preere e home address) Conjunto candidato: Destinos: Resultado: 2001::2 o fec0::2 (obsoleta) o fe80::2 2001::1 o fec0::1 2001::1 (origen 2001::2), despu s fec0::1 (origen fec0::2) (se evitan e direcciones obsoletas) Conjunto candidato: Destinos: Resultado: 2001::2 o 3f44::2 o fe80::2 2001::1 o 3ffe::1 2001::1 (origen 2001::2), despu s 3ffe::1 (origen 3f44::2) (mayor e coincidencia de prejos) Conjunto candidato: Destinos: Resultado: 2002:836b:4179::2 o fe80::2 2002:836b:4179::1 o 2001::1 2002:836b:4179::1 (origen 2002:836b:4179::2), despu s 2001::1 e (origen 2002:836b:4179::2) (se preere coincidencia de etiquetas)
Conjunto candidato: Destinos: Resultado:
24
Captulo 2. El algoritmo DAS Conjunto candidato: Destinos: Resultado: 2002:836b:4179::2 o 2001::2 o fe80::2 2002:836b:4179::1 o 2001::1 2001::1 (origen 2001::2), despu s 2002:836b:4179::1 (origen e 2002:836b:4179::2) (se preere mayor precedencia)
2.6.3. Conguraciones de preferencia por IPv4

En esta primera muestra de cambios en la tabla permite mantener una preferencia por las direcciones IPv4 en detrimento de las IPv6. Para ello, el administrador ha de otorgar una mayor precedencia al prejo ::ffff:0:0/96. Prejo ::1/128 ::/0 2002::/16 ::/96 ::ffff:0:0/96 Precedencia Etiqueta 50 0 40 1 30 2 20 3 100 4
Tabla 2.2: Ejemplo de tabla de polticas para IPv4 Conjunto candidato: Destinos: Resultado: 2001::2 o fe80::1 o 169.254.13.78 (auto conguracion) 2001::1 o 131.107.65.121 2001::1 despu s 131.107.65.121 e 169.254.13.78) (se preere el mismo ambito) (origen 2001::2), (origen
fe80::1 o 131.107.65.117 2001::1 o 131.107.65.121 131.107.65.121 (origen 131.107.65.117), despu s 2001::1 (origen e fe80::1) (se preere el mismo ambito) 2001::2 o fe80::1 o 10.1.2.4 2001::1 o 10.1.2.3 10.1.2.3 (origen 10.1.2.4), despu s 2001::1 (origen 2001::2) (se pree ere una mayor precedencia)
25

ISP C Router de salida de empresa A Router de salida de empresa B
2001:aaaa:aaaa::/48
2001:bbbb:bbbb::/48
2007:0:aaaa::/48
2007:0:bbbb:/48
ISP A
2007:0:aaaa::/48
INTERNET
2007:0:bbbb::/48 ISP B
Figura 2.1: Esquema del ejemplo para el caso multihoming
2.6.4. Conguraciones de entornos multihoming

Para este caso, se va a realizar el ejemplo dentro de un supuesto entorno de funcionamiento. Se considera una empresa A con una relacion crtica con otra empresa B. Para poder suplir las necesidades de comunicaci n, ambas han contratado una conexion con QoS a un ISP de alto o rendimiento, as como su conexi n habitual a Internet, a trav s de otros ISP. Puesto que el ISP o e de alto rendimiento resulta m s caro que los otros, se requiere que solo en caso de establecer a comunicaciones entre ambas empresas se utilice este primero. Ya que cada ISP ofrece un prejo global para cada empresa, tanto A como B tienen dos prejos globales distintos y simult neos. a Prejo ISP de alto rendimiento Prejo ISP habitual 2001:aaaa:aaaa::/48 2007:0:aaaa::/48 2001:bbbb:bbbb::/48 2007:0:bbbb::/48 Tabla 2.3: Prejos de cada empresa por ISP Las rutas dentro de ambas empresas dirigen la mayora del tr co a trav s del ISP habitual, a e pero los routers encaminan hacia el ISP de alto rendimiento cuando el prejo de destino coincide con el que la otra empresa. Para evitar un mal uso de la conexion cara, ambas empresas ltran a la entrada de sus routers el tr co que no proviene de la otra empresa. Para tener m s claro el entorno a a del ejemplo, se puede ver la gura 2.1.
Empresa A Empresa B
26
Captulo 2. El algoritmo DAS Para la empresa A, el comportamiento que se obtiene con la tabla por omisi on a la hora de iniciar tr co con B es el siguiente: a Conjunto candidato: Destinos: Resultado: 2001:aaaa:aaaa::a o 2007:0:aaaa::a o fe80::a 2001:bbbb:bbbb::b o 2007:0:bbbb::b 2007:0:bbbb::b (origen 2007:0:aaaa::a), despu s 2001:bbbb:bbbb::b e (origen 2001:aaaa:aaaa::a) (se preere mayor coincidencia de prejos)
No se utiliza el ISP de alto rendimiento, por lo que no es el comportamiento deseado. Asimismo, al iniciar una comunicaci n con otra empresa C: o Conjunto candidato: Destinos: Resultado: 2001:aaaa:aaaa::a o 2007:0:aaaa::a o fe80::a 2001:cccc:cccc::c o 2006:cccc:cccc::c 2001:cccc:cccc::c (origen 2001:aaaa:aaaa::a), despu s e 2006:cccc:cccc::c (origen 2007:0:aaaa::a) (se preere mayor coincidencia de prejos)
Y por tanto, como se aprecia, el tr co puede volver por el ISP de alto rendimiento, cosa que a tampoco es deseada. Por tanto, se comprueba que la regla de mayor coincidencia de prejos es limitada, y da lugar a comportamientos no deseados en situaciones no tan habituales. Sin embargo, con un cambio en la tabla de polticas, se puede conseguir el comportamiento que se requiere, por ejemplo, usando la siguiente tabla: Prejo Precedencia Etiqueta ::1/128 50 0 2001:aaaa:aaaa::/48 45 5 2001:bbbb:bbbb::/48 45 5 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4 Tabla 2.4: Ejemplo de tabla de polticas para multihoming Y de esta manera se consiguen los resultados esperados para ambos problemas. Para el uso del ISP de alto rendimiento con la empresa B: Proyecto n de carrera - H ctor Cordob s de la Calle e e 27
Captulo 2. El algoritmo DAS Conjunto candidato: Destinos: Resultado: 2001:aaaa:aaaa::a o 2007:0:aaaa::a o fe80::a 2001:bbbb:bbbb::b o 2007:bbbb:bbbb::b 2001:bbbb:bbbb::b precedencia) (origen 2001:aaaa:aaaa::a), despu s e 2007:bbbb:bbbb::b (origen 2007:0:aaaa::a) (se preere mayor
Y para el caso de iniciar una comunicacion con otra empresa C: Conjunto candidato: Destinos: Resultado: 2001:aaaa:aaaa::a o 2007:0:aaaa::a o fe80::a 2001:cccc:cccc::c o 2006:cccc:cccc::c 2006:cccc:cccc::c (origen 2007:aaaa:aaaa::a), despu s e 2001:cccc:cccc::c (origen 2007:0:aaaa::a) (se preere mayor coincidencia de prejos)
Como es f cil de demostrar, por simetra, se cumple tambi n para la empresa B. Para una a e tratamiento m s orientado al QoS por este algoritmo, se puede consultar [Bagnulo01]. a
28
Parte II An lisis de los mecanismos candidatos a
29
Captulo 3 Caractersticas necesarias para el mecanismo de propagaci n de DAS o
El objetivo de las t cnicas analizadas en este trabajo es tener la capacidad de brindar toda la e informaci n necesaria para que un equipo que se conecta a la red pueda congurar su pila IPv6 en o cuanto a direcciones y capacidad de seleccion optima de entre ellas se reere. Entre las virtudes que debe poseer el mecanismo elegido, son importantes las siguientes:
Fiabilidad en la informaci n o La conguraci n de la pila IP es crtica para el buen funcionamiento no solo de la entidad o de red que est siendo congurada, sino de todo su entorno, puesto que un interfaz mal a congurado puede causar comportamientos indeseados en la red. Si, por ejemplo, se necesita mandar la informacion en distintas tandas o en distintos paque tes, es necesario que esta transmisi n se considere at mica, puesto que una conguracion o o incompleta puede dar lugar a funcionamientos anomalos. Si se considera que hay un unico paquete donde se enva la informaci n, o se utiliza un transporte able (como TCP), esta o consideraci n es superua. o Para comprender la importancia de esta caracterstica, imagnese la situaci n en la que la o tabla de polticas estuviera incompleta en una o m s las. Las implicaciones, en principio, a s lo afectan a una m quina, que elegira mal las direcciones destino y origen en sus comunio a 1 caciones. En el caso habitual no tiene m s implicaci n que la posibilidad de esta m quina a o a
Se tomar de aqu en adelante como situaci n habitual la descrita en [Draves02], es decir, el uso del algoritmo a o unicamente para la selecci n de direcci n origen, sin utilizarse para multihoming o QoS. o o
1
30
Captulo 3. Caractersticas necesarias para el mecanismo de propagacion de DAS de quedar sin servicio. Sin embargo, el uso para otros menesteres puede implicar, por ejemplo, enviar informaci n de baja prioridad a trav s de una ruta para la que se ha contratado o e QoS, signicando un comportamiento indeseable. Capacidad de distinci n entre clientes o Es util poder establecer diferencias administrativas por clientes y poder cambiar la conguraci n de todo este conjunto de una sola vez. o Sin embargo, como se comprobar en las consideraciones sobre seguridad, puede resultar a complejo mantener conguraciones individualizadas dentro de un entorno de manera segura. Capacidad de reacci n ante cambios de conguraci n o o Una vez que el cliente ha sido congurado correctamente, puede ocurrir que interese un cambio en las polticas a causa de un cambio de las necesidades de la red. Hay que prever, por tanto, como cambiar esta informacion por petici n externa, o analizar qu dicultades o e pueden aparecer.
Opcionalmente tambi n sera deseable: e
Capacidad de ordenaci n de la informaci n o o Es aconsejable utilizar protocolos que faciliten en la medida de lo posible la estructuraci on de la informaci n. LDAP y SNMP ya la incluyen por omision, y no hay necesidad de denir o una estructura de datos que viajar por la red simplicando la implementacion. a Funcionamiento transparente con el equipamiento actual Es preferible que el protocolo utilizado no necesite, por ejemplo, cambios en el programa interno de un router, ya que sera una soluci n cara frente a otra que s lo implicara una o o conguraci n de un servidor. Este es el caso del mecanismo por router advert. Tambi n es o e cierto, no obstante, que la funcionalidad necesaria puede ser conseguida mediante un servi dor. En otro orden de cosas, la implicacion (mnima) es que tendra una implantaci n m s o a lenta en el mercado. T ngase en cuenta que actualmente, al no estar completamente denida e la arquitectura nal de IPv6, no existen productos completos que no sean actualizables. Seguridad en la comunicaci n o Importa m s la autenticaci n que la condencialidad, ya que las direcciones viajar n en a o a limpio por la red. Una especial atencion ser requerida cuando la informaci n sea sensible a o (por ejemplo, situaciones donde se puede obtener un QoS mejor de manera ilcita). Adem s, a hay que tener en cuenta que los posibles ataques a este mecanismo seran presumiblemente Proyecto n de carrera - H ctor Cordob s de la Calle e e 31
Captulo 3. Caractersticas necesarias para el mecanismo de propagacion de DAS perpetrados desde la propia red. Si se quiere transmitir informacion con cifrado y/o autenticaci n ya existen soluciones como IPSec o TLS. o En esta situaci n prima la autenticaci n del servidor: todos los dem s equipos dependen de o o a el. Tambi n puede ser muy interesante la autenticacion de clientes: puede hacerse pasar un e equipo por otro de cara a realizar actividades maliciosas en la red y esquivar controles o responsabilidades. En el siguiente capitulo se ofrecer un an lisis m s detallado de los problemas de seguridad a a a que pudieran aparecer. Capacidad de auto conguraci n sin informaci n previa o o Esta funcionalidad puede ser conseguida de distintas maneras. Se proponen aqu dos posibles soluciones: Sera interesante el uso de direcciones normalizadas o especiales (multicast conocida, por ejemplo, tal y como ocurre en DHCPv6), de manera que no sea necesaria la incorporaci on de informaci n adicional por parte del administrador para que las m quinas a congurar o a descubran el servicio. Tambi n pueden utilizarse t cnicas de anuncio por difusi n si las conguraciones no son die e o ferenciadas entre equipos, o el uso de protocolos como DHCP para dar a conocer la direcci on de servidores, como ya se hace con las direcciones del equipo, gateway y DNS. Protocolo sencillo Para poder disponer de implementaciones f ciles y ligeras. a Ampliaci n de campos inmediata o Que no sea necesario especicar nuevas extensiones al protocolo para poder aceptar nuevos campos que pueden resultar utiles en otras implementaciones (por ejemplo deniciones m s a concretas de dominios administrativos). La ordenaci n jer rquica de SNMP y sobre todo la de LDAP son claras ventajas 2 , puesto que o a no es necesario realizar ning n cambio o ampliaci n al protocolo para poder implementar u o nuevas caractersticas o a adir m s informaci n a la tabla. En el caso de que se utilizara una n a o expansi n denida para DHCP no sera posible cambiarla, puesto que el tipo de datos ya o est jado y no sera est ndar para todas las implementaciones. a a
Hay que tener en cuenta que se pueden proponer soluciones combinadas. Pongamos el caso
Para SNMP hay que realizar cambios en la MIB tanto en el servidor como en el cliente para que se reconozcan las nuevas opciones. Sin embargo, para LDAP unicamente hay que a adir un nuevo schema en el servidor, pudi ndose n e utilizar inmediatamente esa ampliaci n. o
2
32
Captulo 3. Caractersticas necesarias para el mecanismo de propagacion de DAS de un mismo entorno en el que pueden coexistir dos tecnologas, por ejemplo DHCP para las direcciones y LDAP para la informaci n de gesti n de DAS. o o Tambi n se pueden explorar otras vas no habituales, como el protocolo SNMP realizando la e petici n a una direcci n anycast3 , que es algo completamente ajeno a SNMP. o o
El uso de direcciones anycast tiene ciertas implicaciones no resueltas por lo que ahora mismo se recomienda no usarlas [Hinden02].
33
Captulo 4 An lisis sobre seguridad a
En esta secci n se proceder al an lisis de los problemas de seguridad a los que puede eno a a frentarse un mecanismo de las caractersticas contempladas en este estudio. Primeramente se plan tear una situacion general, donde se analizar n los problemas de seguridad b sicos. Posteriora a a mente se comentar n las caractersticas propias para la informaci n que se desea transmitir en este a o caso. Y se comentar n dos casos, diferenciados en el entorno de aplicacion. a
4.1.
Los problemas de seguridad
B sicamente existen tres problemas de seguridad inherentes a una comunicaci on. Por una parte, a 1 el asegurar la integridad del mensaje, es decir, que este no ha sido alterado. Por otra, asegurar la privacidad. Y por ultimo, poder asegurar que el contenido recibido corresponde a quien se desea. Otros problemas m s avanzados, como el no repudio de recepciones, no se tendr n en cuenta aqu. a a Tampoco se tendr n en cuenta ataques a los propios servidores, como pueden ser los de tipo buffer a overow o cross-site scripting, ni las t cnicas para mantener la seguridad en cuanto a permiso e de usuarios dentro de un servidor. Para analizar los problemas mencionados anteriormente, es recomendable repasar los conceptos necesarios.
1
En criptologa suele llamarse mensaje el conjunto de datos a cifrar, comprobar o autenticar.
34
Captulo 4. An lisis sobre seguridad a
4.1.1. Funciones resumen (hash )

Las funciones resumen tienen ciertas caractersticas que las hacen muy apropiadas para los prop sitos de seguridad: o
El resultado tiene una longitud denida, es decir, el resultado no da idea de la longitud de la entrada, y adem s permite que los subsiguientes procesos se encuentren una entrada de a formato jo. Esto quiere decir que en la mayora de los casos se pierde informaci n. o No existe una funci n que permita conseguir el contenido original a partir del resumen. o Cualquier cambio, por peque o que sea, provoca cambios importantes en el resumen (idealn mente, un cambio de un bit en la entrada provoca un cambio aleatorio del 50 % de los bits a la salida). Dado un hash, idealmente no existe un m todo para encontrar otro conjunto origen que e 2 produzca la misma salida. En esta propiedad se apoyar n los sistemas de vericaci n de la a o integridad del mensaje.
Funciones conocidas y utilizadas son SSHA, HMAC-MD5. . .
4.1.2. Esquemas de clave sim trica vs. clave publica e

Un esquema de clave sim trica es aqu l donde ambas partes comparten un secreto en comun. e e De modo tal que a partir de un mensaje se genera un mensaje cifrado, que s olo podr ser descifrado a conociendo la clave. 3 Ejemplos de este esquema de cifrado son el cifrado C sar o el DES. e Una limitaci n de este esquema es que no se puede hacer una asignacion individual, es decir, o cualquiera que conozca la clave puede cifrar y descifrar. Esta situaci on se puede solucionar con los esquemas de cifrado de clave publica. En ellos, existen dos claves complementarias, donde lo cifrado por una de ellas s lo puede ser descifrado por la otra. Una de estas partes se hace p ublica o y la otra se guarda para uso propio. Esto asegura que un origen, y s olo uno, es el que ha cifrado
Existen ataques dependiendo del algoritmo, en las que se plantea el tiempo estimado para encontrar una colisi on (distinto mensaje, mismo resumen). Por ejemplo, para MD5 este tiempo es de 2 a nos, para un PC dom stico actual. e [Cooke02] 3 En las situaciones habituales, se estima que se pueden tardar muchos a nos (10 ) en descifrar el contenido con los medios actuales, siempre que se usen correctamente los mecanismos de cifrado. [Tanenbaum02]
35
Captulo 4. An lisis sobre seguridad a un mensaje en concreto, ya que solo poda haber sido cifrado con la clave privada. Asimismo sigue existiendo la privacidad: si el remitente cifra con la clave publica del destinatario, s lo este o puede descifrar el mensaje. La mayor contrapartida es que para conseguir un nivel equiparable de seguridad se necesitan claves mucho m s grandes, y un n mero mayor de operaciones: es un a u sistema computacionalmente muy costoso. Como es de esperar, es de vital importancia que las claves privadas permanezcan en el mayor de los secretos, pues es este hecho el que garantiza el funcionamiento correcto del sistema. Uno de los mecanismos m s usados para implementar la seguridad con clave publica es el RSA. a
4.2.
Soluciones a los problemas de seguridad
La privacidad puede conseguirse con el cifrado de la comunicaci on. Las partes que no conozcan la clave no podr n (o les costar mucho esfuerzo captar el contenido de la transmision). A lo largo a a del captulo, ser este y no otro el sentido de la palabra imposible. a Para la autenticaci n, se puede pensar que si se recibe un contenido cifrado con una clave coo nocida, la otra parte es de conanza, puesto que ha demostrado conocer la clave. Sin embargo, esta situaci n implica que ambas partes est n compartiendo la misma clave, por lo que no est identio a a cando inequvocamente a un origen en concreto. Particularmente, no se puede autenticar ante un tercero. Y en el caso de un esquema de clave publica, para garantizar la autenticidad no basta con saber que la clave p blica conocida es capaz de descifrar un mensaje. Hay que tener la seguridad de que, u adem s, el contenido no ha sido cambiado y que esta clave corresponde a su debido due no. a En el primero de los casos se utiliza la rma digital. Esquem ticamente puede verse el m todo a e en la gura 4.1. B sicamente, es obtener un hash del mensaje a enviar, donde la funci on hash a es conocida por ambas partes, esto es, ambas son capaces de calcular el hash del mensaje. Este resumen es cifrado con la clave privada del remitente. Sup ngase conanza en la clave publica que se posee, es decir, existe la certeza que la clave o p blica es de su due o legtimo. u n La comprobaci n de la rma consiste en aplicar los pasos inversos. Se separa el mensaje de su o resumen cifrado, que se descifra, puesto que se posee la clave p ublica del remitente. Si al calcular Proyecto n de carrera - H ctor Cordob s de la Calle e e 36
CLAVE PRIVADA
FUNCION HASH
HASH
Figura 4.1: Esquema del fucionamiento de la rma digital el resumen del mensaje recibido coincide con el resumen recibido, se pueden sacar las siguientes conclusiones:
Si se hubiera cambiado el mensaje o el resumen cifrado, se obtendran res menes diferentes, u por lo que se detectara. Si se hubiera cifrado con otra clave, no coincidiran los res menes, por lo que se detectara. u Si una tercera parte descifra el hash, ya que no posee la clave privada, por las propiedades de la funci n resumen no podr generar un mensaje con el mismo hash. o a Es decir, una coincidencia de los resumenes implica un cifrado con la clave correcta y la integridad de la informaci n, bas ndose en las buenas propiedades de la funcion resumen. o a
Por tanto, la rma implica autenticidad e integridad, pero necesita que se posea con seguridad anterior la clave p blica. u Para ello, existen los certicados de seguridad, documentos donde se ligan la identidad del emisor de la clave p blica, y su propia clave. Para que sea v lido, el certicado tiene que estar u a rmado digitalmente por una entidad en la que se tenga conanza (Certication Authority o CA), es decir de la que se posea su clave publica. Esto da lugar a las infraestructuras de clave publica (PKI), donde la conanza en una CA im plica la conanza en todas los certicados rmados por esta. Habitualmente, la clave publica de la CA se encuentra en un certicado propio autormado. Este certicado suele encontrarse habitualmente en los programas comerciales. Por poner un ejemplo, el navegador Mozilla (y tambi n e Proyecto n de carrera - H ctor Cordob s de la Calle e e 37
Captulo 4. An lisis sobre seguridad a Netscape o Explorer), incorpora los certicados de diversas autoridades, como Verisign, RSA Data Security Inc., con lo que no hace falta incorporarlo. Los PKI incorporan m s opciones, como revocar certicados y caducidad de estos, pero son a temas m s avanzados que no afectan a este trabajo. a As, cuando se reciba un nuevo certicado de cualquier origen, si est rmado por una autoridad a conable, ser seguro. Si la autoridad que lo rma (informacion que tambi n est presente en a e a el certicado) no fuera conocida, las aplicaciones instan al usuario a elegir si aceptar o no esta autoridad. Y en ese momento se podr establecer una comunicaci n donde se utilizar la clave a o a p blica del destinatario para enviar la informacion cifrada, y la clave privada propia para rmarla. u Resumiendo, la importancia de cada uno de estos problemas tendr relaci n, evidentemente, a o con el escenario de aplicaci n. Por ejemplo, el cifrado ser importante cuando por la raz n que o a o fuese, no se quiera que nadie pueda entender el mensaje si este es captado y la autenticaci n o ser importante cuando el funcionamiento correcto de la red dependa de la informaci on recibida, a y no deba ser alterada.
4.2.1. Problemas de seguridad en una red

Dentro de una red, los datos son trasmitidos a trav s de medios compartidos con otros equipos, e por lo que pueden ser vulnerables. Se supondr , adem s, que el usuario malicioso tiene la misma capacidad de acceso que los a a usuarios habituales, si es que no es uno de ellos. Esta suposicion se basa en que lo m s normal a es no permitir el acceso externo a informacion de gesti n interna (sea por un cortafuegos, por o ejemplo), de manera que en este an lisis se desestimar n ataques externos. Adem s, es razonable a a a imaginar que se utilizar n direcciones locales (tanto link-local como site-local) para transmitir esta a informaci n, siendo innecesario el ltrado al recaer el aislamiento en los routers externos. o Por ejemplo, una red local puede ser objeto de ataques man-in-the-middle, donde por medio de articios se provoca un funcionamiento diferente de los equipos de red, donde el contenido de una comunicaci n pasa por un tercer equipo, donde se pueden realizar cambios antes de llegar a o los destinatarios legtimos. Si se realiza correctamente, las partes originales de la comunicaci on no tienen constancia de la existencia del tercero que capta las transmisiones.
38
0101010101010 1100110100101 0101010101010 1100110100101
Figura 4.2: Esquema de man-in-the-middle Este tipo de ataques, junto a los DoS y a las intrusiones, suelen ser los m s graves, ya que a permite tanto captar la informaci n, como cambiarla en tr nsito y suplantar equipos. o a Para solventar estos problemas, en IPv6 se ha propuesto utilizar un esquema de cifrado y autenticaci n denominado IPSec, que siguiendo las especicaciones, las implementaciones estar n o a obligadas a incorporar. Hasta que estas ultimas presenten el soporte de IPSec, habr que considerar a otras situaciones, como SSL o TLS 4 , que obtienen pr cticamente los mismos resultados, si bien a se sit an en el plano de aplicaci n, mientras que IPSec se sit a en el de red. u o u La seguridad descansa en el intercambio de certicados al inicio de la comunicaci on, donde se comprueba la autenticidad de las partes, y posteriormente, transmitiendo informacion cifrada por el esquema de clave p blica se negocia una clave sim trica (que acarrea una menor carga u e computacional), para el resto de la comunicacion. Cualquiera de estas soluciones conseguiran tanto la privacidad como la garanta de autenti cidad en las trasmisiones, y el atacante solo captara informaci n cifrada sin sentido para el, que o tampoco podra cambiar.
SSL fue desarrollado por Netscape Corp., y posteriormente se ha generado una especicaci on m s abierta con a TLS, que es pr cticamente SSL3.0, si bien no son completamente compatibles. a
4

39
ERROR
Figura 4.3: Esquema de man-in-the-middle junto con IPSec, SSL o TLS
4.3.
Aplicaci n al caso presente o
La importancia de los tres problemas enumerados en la primera seccion tienen la siguiente importancia en la transmisi n de la tabla de polticas DAS. o
Autenticidad Cuando un equipo utiliza una informacion externa para congurar un mecanismo del que depende la conectividad del propio equipo, queda patente que ha de garantizarse que esta informaci n sea buena. Por tanto, si un atacante supliera el origen de esta informaci on, o de manera que fuese incorrecta, podra provocar un DoS. Por tanto, se aprecia que comprobar la autenticidad de la informaci n es clave. o Integridad Se pueden aplicar las mismas reexiones que a la autenticidad, ya que la informaci on no s lo ha de llegar correctamente (caso este comprobado en los campos correspondientes o de los PDU), sino que se vuelve importante saber que nadie ha cambiado la informaci on de la tabla. Privacidad En principio DAS es un algoritmo utilizado para conseguir un funcionamiento eciente de IPv6, gracias a la selecci n correcta de las direcciones a la hora de establecer una o comunicaci n. Por tanto, s lo es importante cuando se desea que exista una conguracion a o o la que no se acceda, por las razones que sean (QoS, por ejemplo).

40
Captulo 4. An lisis sobre seguridad a Por tanto, es muy deseable la autenticidad, tanto de equipos como de los contenidos, si bien la privacidad resulta menos grave. Se plantear n en paralelo dos situaciones representativas. La primera de ellas es la mnima a expresada en [Draves02], en la que se utiliza el algoritmo unicamente para conseguir un funcionamiento eciente en una red ajena al multihoming, y la segunda ser aqu lla que proponga a e conguraciones diferenciadas entre equipos y un uso adicional del algoritmo para conseguir QoS, por ejemplo.
4.3.1. Aplicaci n al caso habitual o

As, la privacidad en el caso m s general [Draves02] es un tema balad, ya que todos los usua a rios comparten la misma informaci n. De esta manera el usuario malicioso no puede esperar un o benecio para s mismo, pudiendo unicamente perjudicar falsicando la informacion que reciben los otros usuarios, incluso intentando realizar un ataque por suplantaci on, o incluso un ataque DoS. De esta manera se aprecia que son la autenticacion y la integridad de los mensajes los puntos fuertes a conseguir. Normalmente, aplicando marcas de tiempo (para evitar el almacenamiento y reenvo si fuera necesario) y rmas digitales, ambos objetivos se cumplen. No obstante, alguno de los protocolos objeto de estudio no permiten estas caractersticas per se. Se ver en el an lisis a a c mo es esta caracterstica en los protocolos a estudio. o Este problema se ver solucionado cuando exista la implementacion de IPSec. a
4.3.2. Aplicaci n a QoS multihoming o

Si se pretende realizar una conguracion personalizada de polticas, hay que tener en cuenta, qu diferencia puede existir si la informacion se hace p blica o no. El uso de este algoritmo para e u otra capacidad, como la aplicaci n de QoS de manera individualizada implica, para que los otros o usuarios no se vean inmerecidamente favorecidos, que la informaci on debe ser inaccesible para estos. Sin embargo, hay que pensar tambi n que toda esta informaci n se traduce, al nal, en el uso e o de ciertas direcciones que aparecer n en la cabecera IP, por lo que es f cilmente extrable si no a a se han tenido en cuenta todas las precauciones necesarias dentro de la red local, destacando usar Proyecto n de carrera - H ctor Cordob s de la Calle e e 41
Captulo 4. An lisis sobre seguridad a concentradores que no realicen inundacion, evitando que los paquetes de enlace lleguen a todos los equipos, medidas contra ataques ARP5 y falsos routers. Es decir, unicamente sobre condiciones muy concretas y seguras (y generalmente, en redes locales, de dudosa validez pr ctica), se puede garantizar que la informacion ser invisible para el a a resto de equipos presentes en la red, independientemente del mecanismo utilizado para la transmi si n a cada uno de los equipos, incluso por conguracion manual. Por lo tanto, en la mayora de los o casos dos cosas ser n inevitables: no se podr mantener la privacidad de la informacion referente a a al algoritmo, y por tanto no se pueden prestar servicios diferenciados dentro de una red evitando a la vez que el resto de los equipos puedan tener esos mismos servicios. Asimismo, aparte de esta facilidad intrnseca al uso de la informaci n (direcciones que apa o recer n en cabeceras IP), el uso de distintos mecanismos puede tener tambi n sus propias vulnea e rabilidades (por ejemplo, el uso de una tabla SNMP compartida por todos los equipos que fuese accedida en el plano del usuario). Luego parece complicado el caso de otorgar servicios diferenciados sin que alg un usuario pue da llegar a conocer intencionadamente como acceder por su cuenta a esa informacion privilegiada, implicando por tanto que dentro de una red todas las capacidades ser n comunes, tanto si existe a servicio de QoS como si no. Un caso especial en el que s puede resultar pr ctico el envo de distinta informaci n podra ser a o el siguiente. Una organizaci n, distribuida en distintos departamentos dotados de redes local indeo pendientes (y por tanto, protegidas de ataques al nivel de enlace dentro de la propia organizaci on), quiere establecer distintos perles de QoS entre estos departamentos. Sin embargo, quiere que unicamente se administren los perles de manera centralizada, para evitar cambios desde los propios departamentos. As, el uso de un servidor que requiera autenticacion de los clientes y cierre los accesos a las entradas que no les correspondan, as como no permitir su cambio, puede resultar una soluci n correcta. Para evitar la captaci n de la informaci n por el transcurso en la red se puede o o o utilizar cifrado.
5
Neighbor Discovery en el caso de IPv6
42
4.4.
Conclusiones sobre seguridad
Se han visto de manera muy general los problemas de seguridad que pueden afectar a las trasmisiones de datos en general, y trasladados al caso particular que ocupa esta memoria. Tambi n se ha comprobado c mo en algunas situaciones los problemas no son tales, puesto e o que no es necesario privacidad cuando todos los equipos van a recibir la misma informaci on o no van a poder mantenerla en secreto. De forma que, como se dijo al inicio de este estudio acerca de las necesidades a cubrir por los mecanismos, queda mostrado que lo importante en este caso es la autenticidad de la informaci on recibida, mucho m s que la privacidad. a
43
Captulo 5 An lisis de mecanismos a
5.1.
Router advert
Este protocolo, denido en [Narten98] y detallado en [Thomson98], es utilizado en la auto conguraci n sin estado dentro de IPv6. o B sicamente, cuando un ordenador se conecta a una red IPv6 realiza una serie de operaciones a sencillas para congurarse a s mismo. Dejando a un lado el mecanismo de control de direcciones duplicadas [Thomson98], y las conguraciones manuales, se genera una direcci on link-local por medio del prejo conocido junto con la direccion de enlace [Hinden02]. Para que un ordenador tenga conectividad completa en nivel de red, ya sea en su entorno de empresa o globalmente, ha de utilizar direcciones v lidas, bien site-local o global. a As, para este n, cada cierto tiempo o bajo peticion los routers mandan, a todos los interfaces conectados a una red, la informacion referente a los prejos con los que se pueden construir las direcciones anteriormente mencionadas. Los paquetes mandados se denominan router advert. Como es apreciable, no es necesario que el equipo sepa donde localizar al servidor. Lo interesante para el prop sito que ocupa a este estudio es que, adicionalmente, se puede o incluir otro tipo de informaci n en los mensajes de router advert. Una utilidad actual es marcar a o los equipos si deben tomar esos prejos, o por el contrario deben conseguir las direcciones desde un servidor DHCPv6.
44
Captulo 5. An lisis de mecanismos a Se propone utilizar los campos de extension de este protocolo para que los routers sean capaces de difundir los campos de gesti n de selecci n de direcciones IPv6. o o En principio, ya que es un mecanismo de difusion, la poltica emitida ser com n para todos a u los equipos que la escuchen. Pero adem s es compatible con servidores DHCP, por lo que el uso a de router advert resulta en exibilidad. Es m s, pueden existir distintos agentes (puesto que la a responsabilidad de la emisi n de este tipo de mensajes, si bien reside conceptualmente en los o routers, puede ser llevada a cabo por un agente cualquiera), y conseguir una mayor disponibilidad frente errores por replicaci n. o
5.1.1. Resumen de caractersticas

Fiabilidad Buena, no est orientada a estado. Adem s, puede coexistir funcionalmente con otros protoa a colos con estado, como DHCPv6 y la poltica puede ser servida por varios agentes distintos y conseguir mayor disponibilidad. Ordenaci n de datos o Ninguna, es un transporte sobre el cual disponer la informacion, hay que generar un formato de envo dentro de los campos de extension de los paquetes router advert. Seguridad No se autentican los servidores. Existen t cnicas [Thomson98] para evitar ataques DoS en e cuanto a tiempo de vida de direcciones, pero no de la informacion adicional, que es lo que interesa en este caso, ni tampoco del protocolo de deteccion de direcciones duplicadas. Identicaci n de clientes o Ninguna. Es una comunicaci n unilateral y no conrmada (si bien pueden hacerse peticiones o para la emisi n de un mensaje router advert). o Rapidez de implementaci n o Implica cambios leves del software en los routers (o agentes que enven los mensajes de router advert) y en la pila IP de los hosts (ampliacion de la recepci n de los router advert). o Sin embargo, es un protocolo incorporado a la pila TCP/IP.
45
Captulo 5. An lisis de mecanismos a
5.2.
DHCPv6
El uso del protocolo DHCP parte de la necesidad de conguracion autom tica de interfaces y a equipos, entendido esto como un mecanismo individual para cada una de ellas. Este protocolo es utilizado normalmente para dotar de informacion de diversa ndole para la conguraci n de la pila o IP, como puede ser la direcci n asignada, la m scara de red, la ruta por omisi n, el servidor DNS... o a o En la versi n 6 de IP este uso tiene algo menos de sentido ya que esta funcion est conseguida o a mediante la informaci n de router advert de manera gen rica por el ya conocido mecanismo de preo e jos. Sin embargo, los routers pueden indicar que la informacion ha de ser obtenida de un servidor DHCP, que permite, adem s, poder adjudicar informaci n diferente dependiendo del origen. a o Este protocolo sirve completamente a las necesidades comentadas en este estudio, ya que puede transmitir informaci n de manera diferenciada (en el sentido de distintos clientes). Adem s, no o a requiere ning n cambio en los routers para su implantacion. u
5.2.1. Resumen de caractersiticas

Fiabilidad Buena, uso de TCP para la comunicacion. Seguridad Posibilidad de usar IPSec o TLS. Capacidad de organizar los datos Existen distintos campos (extensiones) ya creados para distintos tipos de informaci on. Por tanto, es utilizar DHCP como un servicio de transporte (como ocurre tambi n en COPS, y e Router Advert), donde es el desarrollador el que especica como se enviar la informaci n a o a trav s de la red. e Identicaci n de clientes o En las implementaciones habituales del protocolo utilizado con IPv4, se suelen distinguir las peticiones distinguiendo por las direcciones de origen del nivel de enlace, siendo un m todo e que es f cilmente manipulable. En la versi n de IPv6, se utiliza un identicador que mezcla a o informaci n del interfaz e informaci n aleatoria denominado DUID. o o Por tanto, aqu sera necesario utilizar cualquier medio de autenticacion de los m todos de e seguridad previstos, adem s de identicar por la direcci n del nivel de enlace. a o Proyecto n de carrera - H ctor Cordob s de la Calle e e 46
Captulo 5. An lisis de mecanismos a Rapidez de implementaci n o El usar este mecanismo cumpliendo las caractersticas necesarias pasa por generacion de un servidor y un cliente DHCPv6 con las extensiones necesarias. No es necesario ning un cambio en el equipamiento de red, si bien DHCP no es un protocolo propio de la pila TCP/IP.
5.3.
SNMP
Este protocolo tiene unas caractersticas que lo hacen destacar. Primero, en su diseno fue pensa do para la gesti n de cualquier tipo de equipamiento, con lo que se insistio mucho en la simplicidad. o Segundo, funciona sobre UDP, por lo que se pueden usar equipos m s sencillos. a Funciona en un esquema tpico cliente-servidor, donde el servidor (agente) es el elemento a gestionar y el cliente (gestor) es aqu l que tiene la capacidad de gesti n. Esto responde a e o razones de dise o, donde se espera que los equipos gestionados tengan poca capacidad de c omputo, n mientras que el control centralizado se realiza en un equipo m s complejo, donde ya se pueden a analizar resultados y generar informes. Ambos elementos deben ser capaces de representar la informacion en unos formatos estable cidos, y deben organizar la informacion con la misma jerarqua. A este tipo de modelos se los denomina MIB. Es decir, la informaci n se trata tal y como se especica en la denicion de una o MIB. Cada representaci n de un objeto dentro de una MIB es denominada por una serie de n umeo ros llamada OID. Existen unos organismos que se encargan de mantener un arbol de informaci n universal, llao mado arbol de OIDs (OID-tree), como la CCITT (ITU-T) y la ISO. Universal implica que todos los elementos comparten el mismo arbol de identicaciones, y por lo tanto, no pueden existir dos objetos que tengan la misma representacion en dicho arbol. Dentro del arbol hay ramas espec cas para cada necesidad, no unicamente para la gesti n de dispositivos. Entre otras cosas, tambi n o e existen ramas privadas, para que las empresas puedan realizar sus desarrollos sin estar atadas a los organismos de normalizaci n, y ramas experimentales, dentro de la cual no existe ninguna asignao ci n v lida. Se pueden ver las primeras ramas en la gura 5.1. Por ejemplo, INTERNET recibira o a el OID 1.3.6.1. La interacci n entre los dos elementos se realiza con peticiones sencillas: o
47

TOP
CCITT (0)
ISO (1)
JOINT (2) IDENTIFIED ORG (3)
STANDARD (0)
REGISTRATION (1)
MEMBER BODY (2) DoD (6)
INTERNET (1)
DIRECTORY (1)
MGMT (2)
EXPERIMENTAL (3)
PRIVATE (4)
SECURITY (5)
SNMPv2 (6)
Figura 5.1: Esquema b sico del arbol de OIDs a GET El gestor enva este comando al agente, acompanado del OID cuyo valor se solicita. GET-NEXT El agente devuelve como resultado el elemento siguiente al especicado. RESPONSE El agente devuelve el valor solicitado, o un error (y su tipo) si no se pudo. Tambi n e responde con este mensaje cuando se ha realizado una asignaci on por medio de SET Este comando es el utilizado por el gestor para almacenar un valor en el equipo gestionado. En el mensaje se indican tanto el OID del objeto a cambiar, como el valor a asignar. TRAP Este es un mensaje no solicitado que enva el agente al gestor. Puede ser util, por ejemplo, en un router que informa al gestor de una sobrecarga en la red, para que tome las medidas oportunas.
En el caso de m ltiples entradas (tablas) como es el presente, es necesario realizar una petici on u por cada una de ellas (puesto que en principio no se conoce el tama no de la tabla). Para ellos se utiliza el comando get-next, donde al terminar la tabla se devuelve un elemento ajeno a ella, y por lo tanto, se puede saber que se ha llegado al nal. En versiones posteriores de SNMP se permiten transacciones m ltiples en una unica petici n, pero se analizar la primera versi n de SNMP por u o a o ser la m s extendida. a Se analizar n dos posibles aproximaciones a la solucion con SNMP, dependiendo de qu elea e mento haga el papel de servidor:
48
MIB
LAN
Figura 5.2: Equipos gestores, un agente con la informacion
5.3.1. Equipos actuando como gestores SNMP, un agente con la informaci on

En esta situaci n cada interfaz, al ser congurado, ha de acceder al servidor de polticas (el o agente SNMP) 1 , para conseguir la informaci n de DAS. Realmente en esta situaci n en servidor o o SNMP act a de servidor de informaci n (como NIS), por lo que es un uso no propuesto para este u o protocolo, aunque resulta en una implementacion sencilla. Por tanto, cada gestor tiene que saber a qu agente ha de acceder. Esta informacion puede ser e equivalente a la de conguraci n de direcciones: autom tica con router advert, DHCP, o manual. o a Existe el problema de distinguir entre gestores, para dar, si es necesario, una conguraci on distinta a cada uno. Una soluci n posible sera incluir un ndice en la tabla correspondiente a la o direcci n IPv6 (que el interfaz ya tiene asignada y congurada), y una por omisi on si el interfaz o no tiene una conguraci n especca. Claramente esto deja acceso a toda la informacion por parte o de todos los usuarios. Tambi n sera una soluci n, pero asimismo una implementacion especial de e o SNMP, la posibilidad de respuestas distintas dependiendo de la direcci on origen del gestor. En ambos aparece una supuesta brecha de seguridad, puesto que sera sencillo que cualquier
Aqu, con agente, s lo se quiere destacar que la informacion se encuentra centralizada en un punto para todos los o gestores, pero no se elimina la posibilidad de que existan varios agentes, para conseguir diversidad y redundancia.
1

49
TRAP
T GE SE ON SP RE
Captulo 5. An lisis de mecanismos a cliente tuviera acceso a la informaci n de polticas del resto de usuarios. Sin embargo, en una o situaci n convencional ( nico ISP) no es un problema, como ya se comento en el captulo 4. o u S es, sin embargo, una potencial fuente de problemas en el caso de entornos multihoming donde se aplique QoS mediante este algoritmo, puesto que capturando paquetes de la red podran identicarse accesos premium, por ejemplo, y disminuir las prestaciones a esos usuarios, o usar ilcitamente este acceso. Por tanto, en esta situacion no es recomendable el uso de SNMP. Como ultima caracterstica, tambi n hay que considerar el caso en que la informacion cam e bia din micamente. El m todo habitual de SNMP para generar alarmas o enviar informacion no a e solicitada es el uso de traps. De esta manera, el agente SNMP que en este caso hace de servidor de informaci n puede avisar a los elementos gestores para que actualicen su tabla, incluso de una o manera individualizada.
5.3.2. Equipos agentes, un gestor por unidad de administracion

En esta situaci n, los clientes tienen que esperar a que el administrador congure (autom tica o a o manualmente) la poltica de selecci n de direcciones en cada interfaz. o Con esta arquitectura el administrador ha de saber la direccion de cada uno de los hosts a con gurar. Esto es relativamente sencillo si los clientes han lanzado una petici on durante el arranque, como puede ser el lanzar un trap para llamar la atencion del gestor y conseguir as la conguraci n o necesaria. Otra soluci n, m s complicada, sera el analizar las peticiones DHCP, con la ventaja de o a poder mantener una contabilidad de los equipos conectados, necesitando una compartici on de datos entre aplicaciones. El problema de seguridad que se puede plantear aqu es que se pudiera acceder con intencion maliciosa a la conguraci n de los equipos. Dado que la version habitual de SNMP usa claves en o limpio, es relativamente sencillo atacar en este caso si no hay otro m todo de autenticaci n. De e o hecho, esta es la raz n por la que muchos fabricantes de dispositivos no incorporan el comando o SET a sus productos. A cambio, esta arquitectura permite el envo de la informaci n personali o zada sin necesidad de que sea cada equipo el que elija a informaci on que necesita. Para el cambio din mico de la informaci n no existe mayor problema, puesto que es el gestor a o el que realiza tal cambio cuando convenga, salvo la escalabilidad, ya que hay que cambiar, uno por uno, la informaci n de cada agente. o
50

MIB
DB
LAN MIB
ON SP RE
MIB
Figura 5.3: Equipos agentes, un gestor con la informacion
5.3.3. Consideraciones
En ambas situaciones puede ser pr ctico proponer el uso de IPSec para evitar problemas de a autenticaci n a partir de direcciones IP. De esta forma se evitaran los dos problemas de seguridad o planteados. Recordando el primero de ellos en el que un usuario malicioso intenta conseguir la informaci on de otro usuario, el servidor SNMP tiene que ser capaz no solo de autenticar el cliente y permitir el acceso a los datos, sino que, adem s, ha de evitar la lectura de la informacion de otros usuarios. a Por lo tanto, estamos fuera de la implementacion est ndar de SNMP. a En el segundo de los problemas, los equipos tienen que conocer cu l va a ser la direcci n del a o cliente que gestiona para aceptar el control unicamente de este autenticado. Tampoco se quita la posibilidad de que existan varios clientes gestores en pos de una mayor disponibilidad.

Fiabilidad Las transmisiones se realizan en UDP, sera interesante el uso de peticiones conrmadas para que la m quina tenga toda la conguraci n de manera segura. a o Proyecto n de carrera - H ctor Cordob s de la Calle e e 51

T SE SE
Captulo 5. An lisis de mecanismos a Organizaci n de la informaci n o o Capacidad intrnseca de organizar datos jer rquicamente dentro del marco de normalizacion a de la ITU. Necesidad de que ambas partes tengan la denicion previa de la organizaci n de o la informaci n. o Seguridad Existe una identicaci n simple por medio de un nombre de grupo a gestionar. Sin emo bargo, el prop sito de este identicador no es el de seguridad, y va en limpio dentro del o paquete SNMP. Las siguientes especicaciones s han tenido en cuenta la seguridad, pero se tomar como referente la primera versi n de SNMP, por ser la com nmente utilizada y para a o u la cual existe un mayor n mero de herramientas disponible. u Por tanto, ser necesario el uso de mecanismos adicionales, como IPSec. a Identicaci n de clientes o Aunque para este protocolo se han propuesto dos arquitecturas diferentes, existen en ambos casos ciertos problemas de identicacion. Las implementaciones est ndar de SNMPv1 no contemplan la identicacion de los clientes a (y los mecanismos de IPAuth no pasan m s all del nivel de red). Por lo que s se puede tener a a autenticaci n, pero no una conguraci n para cada equipo. o o Para el caso de un agente servidor (y donde la privacidad de la informaci on no sea un tema sensible), se puede proponer el uso de una tabla general, donde se encontrar la informaci n a o para cada equipo (donde cada equipo tendr un ndice concreto), y una conguracion por a omisi n, con la sencillez de que la distincion entre equipos se realiza en la propia peticion. o Quedara solucionado el tema de privacidad si se contase con implementaciones que sean capaces de servir informaci n distinta dependiendo de las credenciales del cliente. o En el caso de un gestor, s lo es necesaria una credencial por gestor en todos los equipos a o ser gestionados, con lo que se gana en escalabilidad. Rapidez de implementaci n o Generaci n de un agente SNMP y una herramienta administrativa. Implica tener capacidades o de agente en los clientes. Asimismo, es necesario incorporar un protocolo externo a la pila TCP/IP.
52
5.4.
COPS (Common Open Policy Service)
COPS es un protocolo dise ado especcamente para el intercambio y mantenimiento de poltin cas, por lo que ha sido dotado de ciertas caractersticas que lo hacen pr ctico en algunas ocasiones. a Se basa en un modelo cliente/servidor (llamados aqu PEP y PDP), y utiliza TCP como protoco lo de transporte, por lo que no necesita ningun mecanismo adicional para tener una comunicacion able. A la hora de utilizarlo, en principio el interfaz ha de estar congurado puesto que este protocolo utiliza TCP como transporte, si bien puede utilizarse una comunicacion con direcciones link-local. El equipo necesita, adem s, la direcci n del servidor o servidores a los que puede acceder. Es a o sencillo a adir una informaci n simple como esta a un servidor DHCP, por ejemplo, a los paquetes n o router advert, o a una conguracion manual. Es decir, es equiparable a la conguracion de la propia direcci n del interfaz, siendo recomendable el an lisis del uso de unos y otros en el siguiente o a captulo. Una vez conocida la direcci n del servidor, no hay m s que requerir la informaci n necesaria o a o para el protocolo. Como es de imaginar, para esta comunicacion la tabla de precedencia utilizada es aqu lla que garantiza la conexi n de manera m s sencilla, es decir, la tabla por omision, puesto e o a que todava no se tiene ninguna otra informacion. Adem s tiene comportamiento de protocolo orientado a estado, en el sentido que es capaz de a responder de manera distinta a las peticiones dependiendo de la historia anterior en la comunicaci n con el cliente. Para ello, el estado del PEP est constantemente replicado en el PDP. Incluso si o a lo considera necesario, dentro de la sesion puede enviar informaci n al PEP (modo push). Lo cual o hace a este protocolo un candidato muy interesante cuando haya necesidad de tener informaci on din mica. a El protocolo especica distintos tipos de clientes para administrar las polticas, por lo que un mismo cliente puede tener varas conexiones independientes con distintos PDP siempre y cuando no existan coincidencias de tipos de cliente entre varios PDP. Asimismo, cada PDP puede administrar distintos tipos de cliente. En cuanto a seguridad, implementa internamente la autenticidad y la integridad de los datos con HMAC-MD5-96 en su versi n mnima. No ocurre as con la privacidad, que como se vio en o la secci n correspondiente a SNMP, puede resultar importante en las situaciones de multihoming o
53
Captulo 5. An lisis de mecanismos a con QoS. Para los objetivos de privacidad se puede utilizar IPSec, o bien usar TLS. Es tolerante a fallos en el sentido que la comunicacion se reestablece cuando no se puede vericar la conexi n (mediante mensajes del tipo keep-alive propios de COPS), incluso con otros o PDPs distintos que puedan otorgar la informacion requerida.

Fiabilidad de los datos Usa TCP, con la posibilidad de recuperar sesiones con otros servidores en caso de indisponibilidad del que est en uso en ese momento. e Clasicaci n o Es capaz de diferenciar distintos tipos de clientes en cuanto a polticas se reere (un tipo para DAS, otro para QoS, por ejemplo), y dentro de estos, distintos paquetes de informacion (por ejemplo, ancho de banda mnimo, retardo m ximo). No implementa m s clasicaci n a a o de la informaci n, dej ndolo al desarrollador de cada tipo de cliente el como organizar los o a datos dentro de los paquetes y el a adir nuevos campos. n Identicaci n de clientes o En caso de necesitar identicar entre clientes, no existe una denicion del protocolo para esta necesidad. Si bien s se puede esperar que dentro de la implementacion se contemple este punto. Ver el siguiente apartado. Seguridad El protocolo incluye un mecanismo para asegurar la autenticidad y la integridad de los men sajes bas ndose en rmas digitales por comparticion de secretos. Para conseguir la privacia dad es necesario utilizar otros m todos, de entre los que se proponen en la documentacion e IPSec o TLS. Capacidad de auto conguraci n para encontrar el servidor o Requiere el conocimiento de la direccion del PDP (los PDPs) as como de la clave utilizada (si es necesario) para una comunicacion segura. Puede resultar sencillo a adir un nuevo n campo en la informaci n servida por el servidor DHCP, por ejemplo. o Sencillez y rapidez de implementaci n o Es un protocolo sencillo, si bien resulta muy general, por lo que puede resultar pesado y de una implementaci n m s elaborada de lo que sera necesario para el prop sito de este o a o Proyecto n de carrera - H ctor Cordob s de la Calle e e 54
Captulo 5. An lisis de mecanismos a estudio. T ngase en cuenta que obliga a tener una comunicacion TCP abierta continuamente, e con intercambio continuo de paquetes de aplicacion, cuando en el caso que ocupa a este estudio no es necesario un cambio frecuente de la poltica. En el caso de multihoming con QoS puede darse el caso de cambios din micos (se otorga a la informaci n de encaminamiento bajo demanda, por ejemplo), y s puede ser interesante o mantener un control de cambios como el que ofrece COPS. Es necesario incorporar a los clientes un protocolo externo a la pila TCP/IP.
5.5.
LDAP
LDAP es un protocolo que implementa servicios de directorio de manera ligera y permite una clasicaci n jer rquica sencilla de la informaci n por medio de nombres, sin utilizar estructuras o a o diferentes para cada tipo de datos. Hasta hace poco su ultima versi n util era la primera, puesto o que la tercera no est completamente denida y la segunda ha resultado tener problemas que la a hacen no recomendable. Sin embargo, a pesar de no tener toda la especicaci on terminada, las caractersticas de la tercera versi n la hacen muy interesante (SASL, por ejemplo), por lo que o ser utilizada en la implementaci n. a o Como caractersticas principales, es un protocolo orientado a sesion en su funcionamiento ha bitual, funcionando en una arquitectura tpica cliente-servidor con peticiones y respuestas que arrojan el resultado o error. Tambi n es capaz de mantener distintas peticiones dentro del mismo mensaje, as como rese ponder a estas peticiones en distinto orden del que fueron realizadas. La ordenaci n de las entradas se realiza de manera jer rquica, existiendo distintos tipos de o a entradas, que corresponden a clases ya denidas. No tiene por qu existir una relaci n concreta e o entre la jerarqua de objetos, aunque existen unas clases generales aptas para la clasicaci on, como pueden ser las unidades de organizacion(ou). Los objetos se referencian como nombres distingidos (distinguished names), de tal manera que a partir del nombrado de los valores en atributos se puede llegar a una entrada en particular. Por ejemplo, cn=default, ou=equipos, dc=uc3m, dc=es, donde, empezando por las hojas y terminando en la raz, se solicita la entrada cuyo atributo cn (o common name) es default, y cuyo padre es una entrada ou (organizational unit) llamada equipos. Proyecto n de carrera - H ctor Cordob s de la Calle e e 55

dc=uc3m.es, dc=es description=Universidad Carlos III de Madrid Location=28911 Leganes
dn="dc=uc3m, dc=es"
dn="ou=personal, dc=uc3m, dc=es"
dn="ou=empresas, dc=uc3m, dc=es"
dn="ou=equipos, dc=uc3m, dc=es"
ou=equipos, dc=uc3m, dc=es description=Equipos gestionables location=Ingenieria Telematica
cn=bacterio, ou=equipos, dc=uc3m, dc=es dn="cn=default, ou=equipos, dc=uc3m, dc=es" dn="cn=bacterio, ou=equipos, dc=uc3m, dc=es" description=Portatil location=Lab 4.1F04
Figura 5.4: Ejemplo de un arbol LDAP En la gura 5.4 se muestra un arbol LDAP de ejemplo. Se destacan tres entradas de las que se muestran algunos de sus atributos y valores de estos. Apr ciese tambi n la dependencia de las e e entradas de los equipos dentro de la unidad de organizacion equipos. El funcionamiento que se podra proponer es simplemente el acceso a un servidor con esta informaci n. La unica informaci n que debe residir en los clientes es como alcanzar al servidor o o del que obtener las polticas de administraci n. Al igual que en el caso de COPS, esta informacion o puede ser distribuida por los servidores DHCP o por router advert, o incluso mantenerse de forma manual. Adem s, como ventaja a adida al uso del protocolo, no es extrano contar con LDAP para a n substituir los servicios de NIS en muchas redes, con lo que su uso puede suponer poco o ning un esfuerzo para una tarea m s como es la de mantener la informacion para el DAS. Hay que tener en a cuenta que el uso de NIS para la informacion rebaja mucho el nivel de privacidad de los datos que se envan, y resulta muy difcil la autenticaci n. Por eso LDAP puede resultar una alternativa muy o util de cara a proteger la informaci n en la red. o Como problemas de seguridad se pueden plantear los mismos que aparecen con SNMP, con la salvedad de que se puede pasar por sistemas de autenticacion Kerberos, de manera independiente a la iniciativa IPAuth. En las nuevas versiones (en la pr ctica, LDAPv3), se puede contar con a otros esquemas mucho m s completos, de entre los que se puede destacar SSL y TLS, y ya m s a a incrustado en el mecanismo, SASL, que es una solucion muy gen rica para que ambas partes e negocien el mecanismo de seguridad (autenticacion y privacidad), que se utilizar posteriormente a durante la comunicaci n. o
56

Fiabilidad Usa TCP, por lo que se puede tener la seguridad de conseguir una tabla completa. Seguridad Autentiicaci n mediante Kerberos, DSA o Cifrado y autenticaci n SSL, TSL, SASL (LDAPv3) o Capacidad de ordenaci n de los datos o Capacidad intrnseca de organizar datos jer rquicamente. Asimismo una ampliacion uni a camente implica a adir un nuevo identicador en la base (y en la busqueda si el dato es n necesario). No es necesario que el cliente conozca los tipos de datos presentes en el servidor (el coste de la ampliaci n unicamente afecta al servidor). o Identicaci n de los clientes o Kerberos, claves en texto plano y hash SSL, TSL, SASL (LDAPv3) Rapidez de implementaci n o R pida, existen soluciones para usar LDAP como substituto de NIS. Implica instalar un a protocolo en el cliente externo al paquete TCP/IP.
57
Captulo 6 Relaciones entre los mecanismos de conguraci n de direcciones y los de gesti n o o de DAS
Como se ha visto hasta ahora, se han planteado distintos mecanismos posibles sobre protocolos ya existentes para realizar la gesti n del funcionamiento del algoritmo DAS. Sin embargo, hay que o tener en cuenta que la implementacion de cualquiera de ellos se har sobre una red ya existente, a la cual estar , presumiblemente, dotada de un mecanismo de auto conguraci on de direcciones a previo. Por tanto, es interesante comprobar como se pueden interrelacionar las implementaciones sobre cada una de estas situaciones posibles. Se realizar el estudio a partir de los mecanismos existena tes para la conguraci n autom tica de la direcci n IP. Por tanto, parece conveniente estudiar la o a o conveniencia de uno u otro mecanismo de auto conguracion para el algoritmo DAS a partir de la situaci n presente en una determinada red. o Las preferencias vendr n dadas por el mantenimiento de la losofa inicial del mecanismo de a auto conguraci n de la direcci n, y posteriormente por una mayor sencillez. Sin embargo, la o o decisi n nal no implica que el resto de soluciones sea inv lido, sino que existen razones para o a tener una preferencia. El estudio se centra en la situaci n inicial descrita en [Draves02]. No obstante, otros documeno tos, como [Bagnulo01], plantean la posibilidad de anadir nuevos campos para usar el algoritmo con
58
Captulo 6. Relaciones entre los mecanismos de conguracion otros objetivos adicionales, por lo que habr que recapacitar si esta ampliaci n implica preferencia a o de un mecanismo sobre otros.
6.1.
DHCP como mecanismo de conguracion autom tica a
Cuando se utiliza DHCP [Bound02] se hace por alguno de estos motivos: se requiere una con guraci n individual de los equipos, se requiere mandar informacion adicional que no est presente o a en otros m todos como router advert, o no se dispone de un agente que enve mensajes de router e advert. Por tanto, es interesante mantener estas propiedades en el mecanismo que se utilice para la gesti n de DAS. o La primera propuesta es, por reutilizacion inmediata del protocolo, usar DHCP. De esta manera se pueden mantener todas las propiedades que se requeran anteriormente con la informaci n de o DAS. La otra opci n es el uso de la informaci n de los mensajes router advert ignorando aquello o o que ya ha sido congurado por DHCP. Sin embargo, esta solucion no permite el uso de polticas individualizadas (de manera sencilla), ni asegurar la privacidad de la informaci on. Si bien, como se comprob en el captulo sobre seguridad, este ultimo punto no es f cil de conseguir. o a De estas dos maneras se evita el a adir un nuevo protocolo en los equipos, puesto que, en la n pr ctica, todas las implementaciones de IPv6 tienen que serson capaces de tratar con router advert. a Los otros mecanismos usan otros protocolos que no tienen por qu estar activos en el host, e por lo que son menos recomendables en aras de la sencillez, si bien ser n necesarios cuando se a requiera privacidad y no se use DHCP.
6.2.
Router advert como mecanismo de conguracion
Este mecanismo es la opci n por omisi n de la arquitectura IPv6 [Hinden02], de manera que o o si el router 1 est congurado a tal efecto, realiza una difusion de la informaci n necesaria para la a o conguraci n por prejos [Thomson98] as como la de encaminamiento. o
No es absolutamente necesario que esta funcion la lleve a cabo un router, bastara con un agente de red capaz de generar el tipo de mensajes de router advert.
1
59
Captulo 6. Relaciones entre los mecanismos de conguracion Ya que todos los equipos de la red van a tener administrativamente la misma poltica para la auto conguraci n de direcciones, es de imaginar que algo similar ocurra con la informaci on del o DAS. As, en tanto en cuanto la informaci n no haya de ser diferenciada (como ocurre con las direc o ciones IPv6 en esta situaci n), parece razonable pensar que de la misma forma no ser necesario o a diferenciar polticas entre distintos equipos, y se puede recomendar el uso de RA como meca nismo de transmisi n de la informaci n DAS. T ngase en cuenta que esta soluci n implica una o o e o actualizaci n en los routers y en los clientes para que esta informacion pueda ser tratada en ambas o partes. Sin embargo, en una situaci n en la que se exija una poltica individualizada, o no se puedan o cambiar los routers, esta soluci n no es v lida, y habr que elegir entre otras opciones. o a a En este caso no hay una propuesta recomendable clara. Es muy dependiente de los servicios presentes en la red (como por ejemplo, el uso de LDAP para NIS). Habr que tener en cuenta las a fortalezas y debilidades de cada una de las posibilidades, teniendo en cuenta las implicaciones de la respuesta f cilmente individualizada de DHCP, la exibilidad de SNMP y LDAP o la abilidad a de COPS.
6.3.
Conguraci n manual de las direcciones o
Por ultimo, se va a considerar la posibilidad de realizar una conguracion manual de las direcciones en los interfaces. Desde el punto de vista del administrador, es la opcion m s compleja, teniendo que denir a individualmente y a mano las conguraciones de cada uno de los equipos que tendr n esta caraca terstica. Los principales motivos por los que asignar una conguracion manual pueden ser, por ejemplo, pruebas r pidas, implantaciones nuevas o de pocos equipos, o necesidad de una conguraci on muy a concreta dentro de un entorno para el que no se desea o requiere un servidor que proporcione autom ticamente esta informaci n. a o Es de esperar que en esta situaci n tambi n se aplique manualmente la conguracion del DAS, o e ya que se ha evitado la instalaci n de un servidor. o Proyecto n de carrera - H ctor Cordob s de la Calle e e 60
Captulo 6. Relaciones entre los mecanismos de conguracion No obstante, as como se ha visto anteriormente, es posible que se requiera una informaci on actualizada o bajo demanda, por lo que s sera necesario entonces plantear la instalacion de un servidor de esta informaci n. o Cualquiera de los anteriormente vistos pueden suplir la carencia impuesta por la conguraci on manual, exceptuando router advert que realiza difusion de la informaci n, hecho que puede ser o poco recomendable cuando se requiere que la informacion no sea transparente dentro de la red. Por tanto, aqu parece recomendable el uso de otros mecanismos, de entre los que puede ser interesante usar LDAP o SNMP, ya que estos no requieren ninguna extension de los protocolos conocidos (ganando pues, en rapidez de implantacion, generalidad y compatibilidad a falta de implementaciones v lidas). Por otro lado, LDAP suele ser una alternativa muy presente como a a dep sito de informaci n general, siendo de esta manera una buena solucion f cil de implantar sin o o necesidad de muchos recursos adicionales.
61
Captulo 7 Conclusiones sobre los mecanismos analizados
De entre los mecanismos analizados se destacar n tres que resultan particularmente interesana tes.
Informaci n particular y aprovechamiento o Usar DHCPv6 es realizar una extensi n a un protocolo de conguracion autom tica ya exiso a tente, por lo que en entornos donde ya se utilice resulta muy interesante por necesitar cam bios mnimos en los equipos. Si un equipo ya utiliza DHCPv6 para una conguraci on indivi duaizada, es razonable imaginar que muy probablemente necesite una conguraci on propia para DAS, llegado el caso. Informaci n particular, seguridad y exibilidad o LDAP resulta muy interesante por ser muy utilizado en algunos entornos como sustituto de NIS, adem s de cumplir otros objetivos excepcionalmente, como es la seguridad y la a posibilidad de otorgar conguraciones distintas. Asimismo, permite una organizaci n de los datos inmediata e implcita (caracterstica de o la que los otros dos carecen), por lo que cualquier campo adicional que se pueda llegar a necesitar puede ser integrado inmediatamente, sin ninguna denici on adicional para el protocolo. Sencillez
62
Captulo 7. Conclusiones sobre los mecanismos analizados SNMP puede parecer un poco m s inapropiado por necesitar capacidades de gestion en los a clientes. Sin embargo, es razonable pensar que la complejidad del tratamiento de la informa ci n ser mnimo, ya que se utiliza SNMP como acceso a un directorio de informaci on, sin o a tener que llevar a cabo tratamiento de las respuestas: en este caso los gestores no gestionan. Por ello, lo vuelven muy interesante de cara a ser implementado en equipos de red, donde la capacidad de c mputo es sensiblemente inferior, y los otros protocolos supondran una o complejidad excesiva.
Para conguraciones generales ya se cuenta con los mensajes de router advert, que por contra, no permiten una conguraci n para equipos concretos. Por eso, no aporta ninguna capacidad nueva o sobre DHCPv6, que tambi n es capaz de otorgar conguraciones generales. e COPS parece una soluci n menos recomendable. Es un protocolo disenado para gesti n de o o polticas, pero requiere una conexi n continua y puede resultar muy pesado. Adem s resulta po o a co utilizado siendo el menos habitual de los cinco aqu comentados, aunque en situaciones muy concretas, donde existe un cambio din mico, puede resultar muy recomendable. a Para obtener una idea aproximada de cara a comparar cada uno de los mecanismos, se ha sintetizado una tabla que resume las caractersticas estos: RA M ltiples polticas u Facilidad de implementaci n o Sencillez en los equipos Autenticaci n o Organizaci n implcita o Redundancia de los servidores B squeda de los servidores u Respuesta din mica a * *** DHCPv6 LDAP SNMP COPS *** * * ** * *** ** * * * ** * ** * * *** ** * *** *** * * * 2 3 * ** ***
** *** ** 1
Tabla 7.1: Resumen de los mecanismos
Cambio de la informaci n presente en los mensajes router advert. Es de esperar que el equipo tome esa informao ci n nueva como la v lida para ulteriores comunicaciones. o a 2 Caducidad de las cesiones por DUID 3 Traps
63
Parte III Implementaci n de mecanismos o
64
Captulo 8 Introducci n a las implementaciones o
Esta parte de la memoria da comienzo a las implementaciones desarrolladas para plasmar algu no de los mecanismos comentados anteriormente. En los proximos captulos se har un comentario a exhaustivo de los desarrollos necesarios para implementar soluciones sobre los mecanismos anteriormente analizados. En cada uno de ellos se har una introducci n algo m s profunda al mecanismo en s, a las a o a herramientas disponibles, y a los nuevos conceptos implicados en el desarrollo cuando sea necesario. Posteriormente se comentar n las principales lneas de desarrollo seguidas, y qu motivos a e movieron a las decisiones de dise o tomadas. M s tarde, se ver n algunas pruebas concretas que n a a muestran el correcto funcionamiento de las implementaciones. Y nalmente, se concluir con los principales problemas encontrados durante el desarrollo, a y qu herramientas y conocimientos son necesarios para poder continuar el desarrollo por otras e lneas. Es importante rese ar que los posibles trabajos futuros se han reservado para las conclusio n nes generales.
8.1.
Sobre las implementaciones
Una vez analizados los distintos mecanismos, se propone la implementaci on pr ctica de alguno a de ellos, a saber: DHCPv6, LDAP y SNMP. Se han seleccionado estos mecanismos ya que cada uno de ellos puede ser representativo de una caracterstica en especial, que ser la explotada en a
65
Captulo 8. Introducci n a las implementaciones o este trabajo. Cada cual tendr sus puntos de partida y un trabajo a realizar distinto, en tanto en cuanto a cada uno es un protocolo m s desarrollado o en proceso, y existan herramientas a disposicion que a permitan una implantaci n m s r pida. o a a Asmismo, el escenario de apliaci n de cada mecanismo, tal y como se vio en la seccion de o an lisis, responde de distinta manera a distintas necesidades, por lo que tambi n se tendr en cuenta a e a en su desarrollo. Si bien no se ha actualizado la tabla en el kernel para el uso de la informaci on, se debe a que actualmente no est contemplado. Para FreeBSD existe una implementacion sobre a la versi n 4.5 realizada por J.F. Rodrguez [Rodrguez02], pero que necesita una compilacion del o Kernel especca, y por tanto no es una opci n que actualmente se pueda considerar como est ndar. o a Adem s, este proyecto versa sobre la transmision de la informaci n de la tabla y c mo consea o o guir que esta se haga de manera correcta. Aun as, los desarrollos llevados a cabo tendran un tarea pendiente que sera realizar llamadas al sistema por cada nueva entrada, por lo que usando el API correspondiente sera una unica lnea de c digo m s. o a
8.2.
Escenarios de los mecanismos
El desarrollo de los mecanismos aqu propuesto tiene en cuenta un modelo muy general, sin presuponer ning n escenario en especco. No obstante, tal y como se comento en la secci n de u o an lisis, cada mecanismo tiene unas caractersticas determinadas que lo hacen m s apropiado para a a unas situaciones sobre otras. Por ejemplo, DHCPv6 ser util cuando se desee otorgar una cona guraci n personalizada entre equipos distintos. Por contra, SNMP resulta m s aplicable cuando la o a necesidad es contar con implementaciones sencillas. Por tanto, los desarrollos aqu propuestos pueden utilizarse en cualquier situacion en general, pero se ha intentado sacar provecho de las caractersticas que pueden tener llegado el caso.
66
Captulo 9 DHCPv6
En este captulo se mostrar el proceso seguido para conseguir una implementacion completa a y funcional de la trasmisi n de la informaci n de la tabla de polticas DAS sobre DHCPv6. o o Primeramente se mostrar de qu material se parte a la hora del desarrollo. Se contar n brevea e a mente las caractersticas de una primera implementaci n que se est desarrollando por el consorcio o a KAME de un sistema completo cliente - servidor para DHCPv6. Posteriormente, se analizar esquem ticamente el funcionamiento de cada uno de los prograa a mas que toman parte en la comunicacion, y sobre todo, c mo han sido desarrollados o M s tarde, se analizar n los cambios planteados y el por qu de estos, con un enfasis en los a a e cambios que plantea al usuario administrador, y como afectan los cambios a la informacion que viaja por la red. Por ultimo, se mostrar un peque o resumen acerca de cada uno de los cheros que conforman a n el c digo fuente del programa, incidiendo en su funcion y qu cambios hay que realizar en ellos o e para conseguir los efectos deseados. Todo ello con la mirada puesta en servir como documentaci on a potenciales trabajos futuros sobre el mismo codigo fuente.
67
Captulo 9. DHCPv6
9.1.
Punto de partida
Los nuevos protocolos implementados de forma conjunta con IPv6 no tienen, generalmente, una implementaci n completa que sea conforme a las especicaciones, puesto que incluso en o la mayora de los casos estas no est n completamente perladas. En la situacion particular de a DHCPv6 ocurre as, por lo que es necesario partir de unos desarrollos incompletos, poco docu mentados y bastante monolticos. Por mantener una relativa seguridad de la estabilidad del resultado, se eligi o una de las mejores implementaciones actuales de la pila IPv6 y los protocolos adyacentes, la generada por KAME 1 , que funciona sobre FreeBSD. Adem s, el desarrollo bajo FreeBSD aporta la ventaja adicional de a ser una de las distribuciones UNIX que m s se utilizan en equipamiento de red. a Entre las caractersticas de la implementaci n KAME de DHCPv6 se cuenta con ser comple o tamente funcional en cuanto a informacion de prejos, servidores DNS, clasicacion por DUID entre equipos, atenci n a las direcciones multicast pertinentes y otras caractersticas, aunque no o cumple todas las especicaciones de [Bound02]. Es decir, no es del todo est ndar. a A pesar de lo completo de este desarrollo, la adicion de nuevas extensiones no resulta intuitiva, ya que no se ha tenido en cuenta la exibilidad a la hora de incluir nuevos campos. Sin embargo, ya que el estilo de c digo es correcto y se han utilizado otras herramientas para generaci on de o c digo (por ejemplo, para el analizador sem ntico para el chero de conguracion), la inclusi n o a o de la nueva extensi n fue posible de manera ciertamente dirigida, pero a todas luces no inmediata. o Para aprovechar el trabajo realizado en KAME en el servidor DHCPv6, se pens o que lo mejor era cambiar el c digo en las partes que fuera necesario, recreando las estructuras de datos que o fueran requeridas y reutilizando las ya existentes para mantener lo m s posible la generalidad a en el c digo. As, cualquier revisi n del nuevo c digo generado apreciar que se han mantenido o o o a el estilo y la losofa de programaci n originales. Esto puede ser interesante si hay posteriores o cambios importantes en el c digo propusto por KAME, ya que el estado actual del servidor se o puede considerar sin ning n tipo de dudas como en desarrollo. u
KAME (http://www.kame.net) es un consorcio entre empresas asi ticas que quieren desarrollar una implementaa ci n completa de IPv6, e impulsar este protocolo. o
1
68
Captulo 9. DHCPv6
Solicit (rapidcommit) Response

Solicit (inf
it e lic tis So dver A est qu e Re pons s Re
o only) Response
Figura 9.1: Esquema de funcionamiento de DHCPv6
9.2.
DHCPv6 dentro de la red
La estructura del servidor dentro de la red responde al esquema representado en la gura 9.1. Como puede verse, las interacciones entre el servidor y los clientes pueden suceder de distintos modos. Por omisi n, el servidor DHCPv6 escucha una direccion multicast conocida. El envo por o parte de un cliente de un mensaje solicit provoca el envio de los paquetes advert. Estos paquetes, en principio, incluir n informaci n sobre los identicadores unvocos (DUID) del ciente y el servidor, a o los identicadores de transacci n (XID), y la direcci n unicast de cada uno de los nodos. Se utiliza o o una direcci n multicast, para poder disponer de m s de un servidor en la red, por una parte, y para o a poder realizar la localizaci n del servidor sin conguraci n previa, por otra. o o Una vez que el cliente ha identicado el servidor, realiza una peticion (request), con las opciones especiales que requiere, y recibe una respuesta (reply), con las asignaciones pertinentes. Sin embargo, otros funcionamientos son posibles. Si el cliente aporta la opci on rapid commit en el mensaje solicit, el servidor, si lo permite, realizar una asignaci n completa, y tratar el a o a mensaje como si fuera una petici n (request). Es decir, la carga en la red se reduce a la mitad. o Hay que tener en cuenta que esta opcion no debe ser activada por defecto. Por ejemplo, si hubiera m s de un servidor en la red, la activacion de rapid commit provocara m ltiples asignaciones a u conjuntas por parte de servidores distintos, que no suele ser el comportamiento deseado. De modo tal que, para sacar provecho de la asignacion inmediata, el cliente aporta la opcion rapid commit, y el servidor debe haber sido congurado para aceptar la opcion. Proyecto n de carrera - H ctor Cordob s de la Calle e e 69
Captulo 9. DHCPv6 Ocurre lo mismo cuando se especica en la solicitud la opcion information only, traducible como informaci n general, donde no se realiza ninguna conguracion que requiera un estado, con o lo que se responde al cliente con la informacion general, o con la especca para el si la hay. En este caso no es necesario habilitar este tipo de transaccion, ya que no hay un gasto adicional de recursos. Para el caso que aqu se trata, se ha tomado la informaci n de la tabla de polticas DAS como o informaci n general. De esta forma, la informacion ser adjuntada en las respuestas del servidor o a (excepto advertise), reej ndose la conguraci n exclusiva del equipo si la hubiera. a o Cabe destacar que si bien las primeras llamadas se realizan a una direcci on multicast, las respuestas y llamadas posteriores (exceptuando los anuncios del servidor), utilizan direcciones uni cast, puesto que corresponden unicamente al cliente en cuesti n. Para que estas llamadas de clieno tes unicast sean tenidas en cuenta, han de aportar correctamente los identicadores asociados al servidor, al cliente y a la comunicacion.
9.3.
La implementaci n KAME o
9.3.1. El programa servidor

Por conveniencia, el esquema de ejecucion del servidor se representa de forma resumida en la gura 9.2. B sicamente, al iniciar el servidor, se realiza la lectura del chero de conguraci on, y si la a estructura es sint cticamente correcta, se analiza sem nticamente y se organiza en las estructuras a a de datos pertinentes en memoria si el contenido es correcto. Posteriormente se comprueba si existe un chero que contenga la identicacion unvoca del servidor, que se genera conjuntamente con la direcci n fsica y datos aleatorios. Si no es as, esta se genera. o Una vez que el servidor tiene preparados todos los datos que va a necesitar, inicializa una lista donde almacenar las asignaciones de prejos a los clientes, junto con el tiempo de caducidad. a A partir de aqu, entra en un bucle donde las llamadas son recogidas en una lista de eventos asociada al interfaz, donde se van procesando y respondiendo en orden de llegada. Durante la ge neraci n de las respuestas, se comprueba si existe una conguracion especca para el equipo que o Proyecto n de carrera - H ctor Cordob s de la Calle e e 70
Captulo 9. DHCPv6
INTERFAZ DE RED
Recepcion paquetes Temporizadores Generacion de respuestas
Configuracion General Interfaz Equipo
Fichero de configuracion
Cesion de prefijos DUID
Figura 9.2: Estructura del servidor la solicita, adem s de comprobar qu tipo de respuesta se requiere (por ejemplo, cuando se ha aca e tivado la opci n rapid commit). Una vez generada la respuesta, se enva al cliente correspondiente o y se vuelve al bucle principal. El servidor puede respoder a un unico interfaz por ejecuci n, aunque pueda aplicar una conguo raci n distinta a cada uno de ellos, con lo que se comparte el chero de conguraci on (permitiendo o lanzar en el mismo equipo varios servidores). As mismo, tambi n es capaz de otorgar una con e guraci n diferenciada entre equipos, dentro de las cuales pueden determinarse las opciones a las o que responde (por ejemplo, rapid commit). El chero de conguraci n para el servidor responde al siguiente esquema: o
Conguraci n general o Aqu se situa la informaci n que afectar a todos los clientes. Originalmente, aqu unica o a mente se especican los servidores DNS. Conguraci n por interfaz o Aqu se indica las opciones concernientes a interfaces completos. Cabe destacar que esta informaci n bien poda situarse en la mayora de los casos en una opci n general, ya que la o o ejecuci n del servidor se realiza unicamente sobre un interfaz. o Sin embargo, ofrece la posibilidad de mantener un unico archivo de conguraci n para varias o ejecuciones simult neas del servidor en distintos interfaces. a
71
Captulo 9. DHCPv6 Es en este apartado donde se conguran las opciones especiales aceptadas por el servidor (en este caso, unicamente se contempla rapid commit), y el valor de preferencia que indicar el a servidor en su anuncio. Conguraci n por equipo o En este apartado es obligatorio incluir el DUID del equipo. Este numero es un identicador unco que permitir identicar el equipo entre otros. a Originalmente s lo se puede incluir una delegaci n de prejo asociada al equipo, y su tiempo o o de caducidad. Conviene recordar que en IPv6 no suele utilizarse DHCP para la conguraci on de una direcci n IP, sino que todo equipo est dotado de una direcci n v lida en el momento o a o a del arranque.
Las opciones de conguraci n se aplican en el chero de conguracion con la siguiente sintao xis:
[option domain-name-servers <direccin IPv6>+ ;]* o [interface <nombre interfaz> { [allow <opciones>+;] [preference <nmero>;] } ;]* u [host <nombre host> { duid <DUID>; [prefix <prefijo> [<duracin> | infinity ] ;]* o };]
Para ser ledo, se ha generado un analizador sint ctico usando yacc, lo que en cierta medida a simplica la adici n de una nueva opci n a este chero, no as al servidor en general, que requiere o o una concepci n completa de su estructura y una integracion del nuevo c digo algo m s estudiada. o o a El contenido del chero de conguracion es est tico, y es ledo s lo una vez, durante la carga a o del servidor. Posteriormente, la informacion as tratada pasa a memoria de manera estructurada, y ser utilizada cuando convenga, segun las peticiones recibidas desde los clientes DHCPv6. a
72
Captulo 9. DHCPv6
INTERFAZ DE RED
Recepcion paquetes Temporizadores Generacion de respuestas Llamadas al sistema
Configuracion
Fichero de configuracion
DUID
PID
Figura 9.3: Estructura del cliente
9.3.2. El programa cliente

Para tener una visi n del funcionamiento del cliente dentro de la red, es completamente v lida o a la gura 9.1 que ya se present para el servidor en la p gina 69. o a Para apreciar la estructura en ejecuci n del cliente, se puede observar el esquema gr co que o a aparece en la gura 9.3. B sicamente, se procede a la carga de las conguraciones, y se situan en estructuras de memoria a m s pr cticas. Tambi n se crea un chero de PID, para evitar m s de una ejecuci n del cliente. Por a a e a o lo dem s, es una m quina de estados que realiza peticiones al servidor, y permanece a la espera a a hasta que recibe un paquete o naliza un temporizador que marca una nueva petici on. El chero de conguraci n del cliente, a diferencia del servidor, no es necesario para un funcioo namiento habitual. Sin embargo, es imprescindible cuando se requiera activar opciones especiales. Por ejemplo, se puede activar la opcion de asignaci n de prejos (prex delegation). o Esquem ticamente, la conguraci n para el cliente es como sigue: a o
Conguraci n por interfaz o Aqu se especican las opciones que se enviar n y se solicitar n al servidor. Actualmen a a te s lo se puede enviar la opci n rapid commit, y s lo puede solicitarse prex delegation. o o o As mismo, tambi n se puede indicar que no se requiere una conguracion con estado, por e Proyecto n de carrera - H ctor Cordob s de la Calle e e 73
Captulo 9. DHCPv6 lo que s lo se necesita la informacion general. o Conguraci n de interfaces por prejos o Aqu se establecen las conguraciones para interfaces locales cuyos prejos se derivan de los prejos asignados por el servidor DHCPv6. Los par metros que se determinan son la a longitud y el identicador del SLA (site-level aggregator), para un interfaz determinado. B sicamente, se trata de continuar el prejo asignado con el SLA, de manera que, por ejema plo, si se ha recibido la asignaci n del prejo 3ffe:ffff::/48, y el identicador del o SLA es 1, el prejo asignado al interfaz es 3ffe:ffff:0:1::/64. T ngase en cuenta e que a no ser que se especique otro valor, la longitud del SLA es de 16 bits.
El chero de conguraci n responde a la siguiente sintaxis: o
[interface <interfaz> { [send <opciones>;]* [request <opciones>;]* [information-only;] };] [prefix-interface <interfaz> { sla-id <nmero decimal>; u [sla-len <nmero decimal>;] u };]
Como puede verse, este tipo de conguracion no afecta al envo de la extensi n DAS, puesto o que ha sido considerada como informacion general, y ser enviada a n sin solicitud previa (como a u ocurre con los servidores DNS).
9.4.
Cambios realizados
En esta secci n se mostrar n los cambios que hubo que realizar as como las nuevas denicioo a nes y el por qu de ellas. Particularmente, se comenzar explicando las razones que han movido e a para plantear un modelo de dise o en concreto, posteriormente se mostrar la estructura de la nueva n a opci n, y m s tarde se enumerar n los distintos cambios que se han realizado sobre el codigo. o a a Proyecto n de carrera - H ctor Cordob s de la Calle e e 74
Captulo 9. DHCPv6
9.4.1. Funcionamiento propuesto para la gestion de la tabla de polticas

El objetivo que se persigue es la completa y correcta transmision de la tabla de polticas que necesita el algoritmo DAS. Se cuenta tambi n con que el cliente ya dispone de una conguracion e b sica por omisi n, en la que ya existe la tabla DAS b sica. a o a Puesto que el servidor DHCPv6 no puede negociar valores, es decir, no puede asignar cambios a no ser que mantenga una copia local como ocurre con la asignaci on de prejos, el funcionamiento debe basarse en la reconstrucci n completa en cada comunicacion, sin posibilidad de cambios. o Es decir, el mecanismo ha de proveer con todas las entradas de la tabla, siendo especicadas tanto en la conguraci n general, como en la particular de cada cliente. o El envo se realizar en una extensi n DHCP, que a falta de una asignacion por parte de IANA, a o se ha tomado un valor alto (200), que actualmente no est en uso para DHCPv6. El envo se a realizar en una unica opci n, de tama o variable, con las distintas entradas que se enven. a o n Ya en el cliente, puesto que el tama o ocupado por cada opci n es conocido, se pueden separar n o cada una de las entradas. S lo resta realizar las llamadas al sistema, donde se actualizar por o a completo la tabla presente en ese momento con la informacion recibida.
9.4.2. La extensi n DHCPv6 DAS o

La denici n b sica e imprescindible necesaria es la estructura que contendr los datos en su o a a transcurso por la red. Se ha querido mantener un tamano m ltiplo de 4 bytes para mantener el u alineamiento a 32 bits. El comienzo es comun a todas las dem s opciones de DHCPv6: dos bytes a que identican de qu opci n se trata, y dos bytes que indican la longitud en bytes de la opci on. e o El rango de los valores a enviar delimita las caractersticas de la opci n. Como es preferible o un modelo general, el prejo se enviar como una combinaci n de direcci n IPv6 y la longitud en a o o bits. La direcci n IPv6 ocupa 128 bits (16 bytes). Como la longitud debe indicar un valor entre 0 o y 128, ocupar otro byte. Esto resta 3 bytes hasta el siguiente multiplo de 4 bytes. a El valor de etiqueta puede ser usado perfectamente con valores bajos, ya que smplemente tie nen que ser distintos, pues resulta poco probable que se encuentren tablas mayores a una decena de entradas. Asignando unicamente un byte restan 2 bytes que ser n asignados a la precedencia. a Proyecto n de carrera - H ctor Cordob s de la Calle e e 75
Captulo 9. DHCPv6 Adem s, es conveniente tener libertad en los valores de la precedencia, puesto que adminsitrativaa mente es com n utilizar valores altos, en vistas a intercalar posteriormente valores intermedios, o u asegurar que una entrada ha de tener una alta preferencia. Todos los valores son enteros sin signo, en orden de red. Por tanto, existe una limitaci on (que se comprueba al cargar la conguracion en el servidor) de los valores, siendo la precedencia inferior a 65536, y la longitud del prejo y la etiqueta inferiores a 256. Adem s, con correci n sem ntica, a o a el valor del prejo no puede ser superior a 128. Para el valor de la opci n se ha elegido el valor temporal 200, que es muy superior a la ultima o asignaci n realizada por IANA, pero que puede ser solicitado y en ese caso, asignado. o Ya que se especica la longitud total de la opcion, y por dise o se conoce el tama o de la n n estructura de cada una de las entradas individuales, estas se pueden separar, y adem s se puede a realizar una comprobaci n de que el tama o de la opci n recibida es correcto. o n o
4 bytes (32 bits)
Opcion (200)
Longitud de la opcion
20 bytes
Direccion IPv6
Precedencia
Prefijo
Etiqueta
Figura 9.4: Estructura de la opci n DAS dentro del paquete DHCPv6 o
9.4.3. Cambios en el servidor

El inter s en el desarrollo aqu seguido se limitan a activar distintas extensiones en las rese puestas DHCPv6. Dado el dise o del servidor, las estructuras en memoria son distintas para las n conguraciones por interfaz y por equipos, teniendo que replicar el trabajo en m s de una ocasi n, a o aunque sint cticamente responde al mismo tipo de descripcion. a
76
Captulo 9. DHCPv6 Por tanto, resumiendo, las etapas seguidas en el desarrollo fueron:
Creaci n de las estructuras l xicas y sint cticas para la correcta lectura de la conguracion o e a relativa al algoritmo DAS. Paralelamente, la creaci n de las estructuras de datos que contendr n la informaci n relativa o a o al algoritmo. En primera instancia solo se implementaron aqu llas necesarias para el funcioe namiento, es decir: prejo, precedencia y etiqueta. Tambi n se ha tenido esta consideraci n e o en la creaci n de la estructura dentro de la red. En este caso se ha preferido mantener un o n mero de bytes m ltiplo de 4 para intentar mantener dentro de lo posible el alineamiento u u a 32 bits para facilitar el uso dentro de lo posible a procesadores de este tama no de palabra, tal y como se recomienda en la losofa de IPv6. Adaptaci n de las funciones de incorporacion a la memoria de la conguraci n propuesta, o o para que identicara los nuevos tipos de datos reci n creados. Cabe destacar que se utilizan e las funciones referentes a colas TAIL QUEUE para administrar todos los datos de manera eciente en cuanto a uso de memoria. a Creaci n de un tipo de extensi n DHCPv6 que pueda contener la informacion b sica del o o algoritmo. Como nota, se ha optado por utilizar un envo que agrupe todas las entradas para la tabla DAS propuestas en una unica extensi n, e intentar mantener as una ejecuci n de los cambios o o en la tabla lo mas at mica posible, para que no existan comportamientos espureos en el o funcionamiento de la pila IPv6. Adaptaci n de las funciones de generaci n y recepci n de mensajes de opciones DHCPv6, o o o y todas las auxiliares, para que tengan en cuenta la nueva opcion. Finalmente, dada la recepci n correcta de un mensaje de DHCPv6 referente a opciones que o incluya a la nueva aqu creada, pasar al S.O. la informaci n para que se utilice en posteriores o comunicaciones.
De cara al usuario, los cambios introducidos se reejan en los archivos de conguraci on de esta manera:
[option [ domain-name-servers <direccin IPv6>+ | o dasentry <entrada DAS>+ ] ;]*
77
Captulo 9. DHCPv6 [interface <nombre interfaz> { [allow <opciones>+;] [preference <nmero>;] u } ;]* [host <nombre host> { duid <DUID>; [prefix <prefijo> [<duracin> | infinity ] ;]* o [hostdasentry <entrada DAS>+ ;]* };]
u Se ha propuesto como expresi n de la entrada en la tabla el formato direccion IPv6 / n meo ro de bits / precedencia / etiqueta , expresado en el modo habitual (direcci on en el formato normalizado, y los otros datos en base decimal). Por ejemplo, una entrada v lida en este formato a sera 2001:ed00::/32/45/10. Como se puede comprobar, resulta una extension a la expre si n com n de un prejo. La validez de los valores aqu contenidos se comprueba tambi n durante o u e el an lisis de los cheros de conguraci n. a o

9.4.4. Cambios en el cliente

Gracias a que gran parte del c digo est compartida entre ambos programas, la adaptacion del o a servidor, si se realiza completamente, consigue que el cliente reconozca la nueva extensi on sin ning n cambio adicional. Sin embargo, hay que completar el programa para que realice la llamada u al sistema una vez que ha recibido la informacion de la tabla de polticas del servidor. Cabe rese ar que por omisi n el kernel de FreeBSD no contempla los cambios en la tabla de n o polticas. Para ello, se puede utilizar el trabajo [Rodrguez02] 2 .
9.4.5. Resumen de los cambios en los cheros

Seguidamente se ofrece un ndice de los cheros en los que es necesario realizar los cambios para futuros trabajos. En todos ellos se han realizado marcas identicativas para conocer cu l es a
Este trabajo incorpora tanto los cambios en el nucleo del sistema operativo como codigo de usuario que es capaz de realizar las llamadas y actualizar la tabla.
2
78
Captulo 9. DHCPv6 el nuevo c digo que ha sido insertado. As mismo, se destaca que ha sido incorporado tambi n el o e c digo de depuraci n suciente como para poder observar qu est ocurriendo a cada momento. o o e a
dhcp6.h Fichero donde se incluyen todas las deniciones b sicas y comunes del marco DHCPv6. a Es aqu donde se especican los valores de los campos en el protocolo, las estructuras b sicas a (tanto las que se almacenan en memoria como las que circulan por la red), y las deniciones de listas que se utilizar n masivamente tanto en el cliente como en el servidor. a cftoken.l Fichero principal del analizador l xico. Aqu es necesario denir cualquier nuevo smboe lo terminal, como la palabra clave dasentry, por ejemplo. cfparser.y Fichero principal del analizador sint ctico. Aqu hay que denir la nueva estructura a sint ctica que da capacidad de reconocer la extension al servidor. As mismo, hay que ina cluir el c digo que se ejecutar al analizar las estructuras del chero de conguracion y o a que crear n las estructuras b sicas de conguraci n que posteriormente ser n analizadas y a a o a transformadas en otras m s pr cticas para el uso tanto del servidor como del cliente. a a Aqu es necesario especicar las estructuras sem nticas que ser n v lidas y las instrucciones a a a a ejecutar para cargar las conguraciones en memoria. cong.c En este archivo se realiza el paso de las estructuras analizadas en cfparser.y a las que uti lizar la funci n principal del servidor. En algunos casos existe cierta repeticion de c digo, a o o por similitud entre las posibles conguraciones de los interfaces y los equipos, que son tra tadas independientemente. Adem s, este chero incluye la transformacion de las estructuras a tanto para el cliente como para el servidor. Es en este chero donde hay que incluir el an lisis de las conguraciones ledas en cfparser.y a y transformarlas en estructura de memoria v lidas, dentro de la clasicaci n impuesta en el a o servidor y en el cliente: general, por interfaz, por equipo... common.c y common.h Aqu se encuentran todas las funciones que son compartidas tanto por el cliente como por el servidor durante el funcionamiento continuo. Es decir, las transfor maciones de datos de memoria a red y viceversa, la gestion de listas y eventos, y funciones auxiliares. Aqu es imprescindible a adir el soporte a las nuevas opciones, teniendo en cuenta cu ndo n a se trata de datos generales y cu ndo hay que incluir c digo especco para la extensi n a o o propuesta. dhcp6s.c Fichero principal del servidor. Realiza la escucha de la direcci on multicast asociada y responde consecuentemente a las peticiones del cliente. Lleva a cabo tambi n la temporizae ci n de las asignaciones de prejos y de los anuncios. o Proyecto n de carrera - H ctor Cordob s de la Calle e e 79
Captulo 9. DHCPv6 Aqu hay que incorporar las nuevas opciones, haciendo especial hincapi en que hay que e comprobar qu tipo de opci n se requiere en cada momento, as como qu informaci n e o e o corresponde, dependiendo de si se debe aportar una conguraci on general o una especca para un equipo. dhcp6c.c Fichero principal del cliente. Realiza las peticiones al servidor, cuidando de las temporizaciones para las nuevas peticiones, y realiza las llamadas al sistema para que se contemple la conguraci n recibida en el funcionamiento de IPv6. o Aqu unicamente hay que incorporar el codigo que trata de manera especca la nueva in formaci n recibida. No es necesario cambiar este chero para que el cliente reconozca la o opci n reci n incorporada: esto ya ha sido conseguido en common.c. o e El nuevo c digo debe, por una parte, comprobar la validez de las entradas recibidas (puede o haber existido alg n fallo durante la transmisi n), y ejecutar la llamada al n cleo necesaria u o u para actualizar la tabla.
9.5.
Pruebas
Para comprobar el correcto funcionamiento de los programas generados en esta implentaci on se ha incluido suciente c digo de depuraci n. Adem s, los programas est n dotados de secciones o o a a destinadas a analizar la correci n de los datos suministrados en todo momento, tando por parte del o administrador como los recibidos de la red. En los volcados siguientes, por economa de espacio y de esfuerzo en su lectura, se ha omitido la depuraci n de los cheros de conguraci n. o o
9.5.1. Conguraci n general o

En este caso unicamente existen conguraciones generales (option ...), es decir, no se iden ticar al cliente como propietario de una conguracion concreta. Este ejemplo ser el m s largo a a a de los aqu presentes, ya que en los siguientes se obviar n los eventos comunes. a Al arrancar el servidor, se comprueba que existe un chero donde se encuentra un DUID para el servidor generado anteriormente.
80
Captulo 9. DHCPv6
avispa# ./dhcp6s -f -D rl0 2003/00/08 19:09:25 get_duid: extracted an existing DUID from /etc/dhcp6s_duid: 00:01:00:01:05:1b:84:1e:00:c0:26:a0:20:32
Al arrancar el cliente, primero se consigue el DUID, que ya estaba generado en un chero con anterioridad. Despu s se inicializa la lista de eventos para el interfaz, y se espera un tiempo e aleatorio antes de lanzar el mensaje de solicit. Se prepara el mensaje, con el identicador del cliente y el de transacci n (XID), y se enva a la direcci n link-local multicast conocida para los o o servidores DHCPv6, y se ajusta el estado del interfaz para esperar una respuesta.
avispa# ./dhcp6c -f -D rl0 2003/00/08 19:10:21 get_duid: extracted an existing DUID from /etc/dhcp6c_duid: 00:01:00:01:05:af:0e:f8:00:c0:26:a0:20:32 2003/00/08 19:10:21 dhcp6_reset_timer: reset a timer on rl0, state=INIT, timeo=, retrans=2383 2003/00/08 19:10:24 client6_send: a new XID (139ccd) is generated 2003/00/08 19:10:24 dhcp6_set_options: set client ID 2003/00/08 19:10:24 client6_send: send solicit to ff02::1:2 2003/00/08 19:10:24 dhcp6_reset_timer: reset a timer on rl0, state=SOLICIT, timeo=0, retrans=544
Aqu se ve c mo el servidor ha recibido una peticion desde una direcci n link-local. Extrae o o el identicador del cliente, y empieza a generar un mensaje de anuncio, en el que incluir su a propio identicador, y la preferencia del servidor. Posteriormente, enva este mensaje a la direcci n o unicast desde la que se recibi la petici n. o o
2003/00/08 19:10:24 server6_recv: received solicit from fe80::2c0:26ff:fea0:2032 2003/00/08 19:10:24 dhcp6_get_options: get DHCP option client ID, len 14 2003/00/08 19:10:24 DUID: 00:01:00:01:05:af:0e:f8:00:c0:26:a0:20:32 2003/00/08 19:10:24 server6_react_solicit: client ID 00:01:00:01:05:af:0e:f8:00:c0:26:a0:20:32 2003/00/08 19:10:24 server6_react_solicit: Entering analysis of client ID 2003/00/08 19:10:24 dhcp6_set_options: set client ID 2003/00/08 19:10:24 dhcp6_set_options: set server ID 2003/00/08 19:10:24 dhcp6_set_options: set preference 2003/00/08 19:10:24 server6_send: transmit advertise to fe80::2c0:26ff:fea0:2032
81
Captulo 9. DHCPv6 El cliente recibe el anuncio, y extrae los identicadores presentes, comprobando que el mensaje es suyo y tomando nota del servidor y de su nivel de preferencia. Ajusta la lista de eventos del interfaz puesto que ya ha recibido la respuesta, y de entre todas las respuestas (en este caso, s olo una) elige un servidor. Adem s, genera un identicador de transaccion (XID). Con este ultimo, a genera un mensaje de petici n (request), y lo enva a la direcci n multicast, al que unicamente o o responder el servidor cuya DUID haya sido incorporada al mensaje. a
2003/00/08 19:10:24 client6_recv: receive advertise from fe80::2c0:26ff:fea0:2032 on rl0 2003/00/08 19:10:24 dhcp6_get_options: get DHCP option client ID, len 14 2003/00/08 19:10:24 2003/00/08 19:10:24 DUID: 00:01:00:01:05:af:0e:f8:00:c0:26:a0:20:32 DUID: 00:01:00:01:05:1b:84:1e:00:c0:26:a0:20:32 2003/00/08 19:10:24 dhcp6_get_options: get DHCP option server ID, len 14 2003/00/08 19:10:24 dhcp6_get_options: get DHCP option preference, len 1 2003/00/08 19:10:24 client6_recvadvert: server ID: 00:01:00:01:05:1b:84:1e:00:c0:26:a0:20:32, pref=0 2003/00/08 19:10:24 client6_recvadvert: reset timer for rl0 to 0.497569 2003/00/08 19:10:24 select_server: picked a server (ID: 00:01:00:01:05:1b:84:1e:00:c0:26:a0:20:32) 2003/00/08 19:10:24 client6_send: a new XID (b8a50d) is generated 2003/00/08 19:10:24 dhcp6_set_options: set client ID 2003/00/08 19:10:24 dhcp6_set_options: set server ID 2003/00/08 19:10:24 client6_send: send request to ff02::1:2 2003/00/08 19:10:24 dhcp6_reset_timer: reset a timer on rl0, state=REQUEST, time o=0, retrans=244
El servidor recibe el mensaje de petici n, comprueba que es v lido, y genera un mensaje de o a respuesta, donde se incluye la informacion general, que en este caso es una tabla DAS. No es el caso, pero se podran a adir servidores DNS, por ejemplo. n
2003/00/08 19:10:24 server6_recv: received request from fe80::2c0:26ff:fea0:2032 2003/00/08 19:10:24 dhcp6_get_options: get DHCP option client ID, len 14 2003/00/08 19:10:24 2003/00/08 19:10:24 DUID: 00:01:00:01:05:af:0e:f8:00:c0:26:a0:20:32 DUID: 00:01:00:01:05:1b:84:1e:00:c0:26:a0:20:32 2003/00/08 19:10:24 dhcp6_get_options: get DHCP option server ID, len 14 2003/00/08 19:10:24 server6_react_request: Entering analysis of client ID 2003/00/08 19:10:24 dhcp6_set_options: set client ID 2003/00/08 19:10:24 dhcp6_set_options: set server ID
82
Captulo 9. DHCPv6
2003/00/08 19:10:24 dhcp6_set_options: set das entry 2003/00/08 19:10:24 server6_send: transmit reply to fe80::2c0:26ff:fea0:2032
El cliente recibe la respuesta desde el servidor. Se analiza la opcion DAS recibida, y se comprueba que los valores sean v lidos. Finalmente, se eliminan los estados de espera del interfaz y se a duerme el proceso hasta que el contador interno obligue a renovar la informaci on.
2003/00/08 19:10:24 client6_recv: receive reply from fe80::2c0:26ff:fea0:2032 on rl0 2003/00/08 19:10:24 dhcp6_get_options: get DHCP option client ID, len 14 2003/00/08 19:10:24 2003/00/08 19:10:24 DUID: 00:01:00:01:05:af:0e:f8:00:c0:26:a0:20:32 DUID: 00:01:00:01:05:1b:84:1e:00:c0:26:a0:20:32 2003/00/08 19:10:24 dhcp6_get_options: get DHCP option server ID, len 14 2003/00/08 19:10:24 dhcp6_get_options: get DHCP option das entry, len 40 2003/00/08 19:10:24 dhcp6_get_options: Extracting DAS option 2003/00/08 19:10:24 dhcp6_get_options: DAS received: 2001:aa1:: 32 10 2 2003/00/08 19:10:24 dhcp6_get_options: DAS received: 0:0:0:ffff:: 96 100 8 2003/00/08 19:10:24 client6_recvreply: sysctl DAS entry[0] 2001:aa1:: 2003/00/08 19:10:24 client6_recvreply: sysctl DAS entry[1] 0:0:0:ffff:: 2003/00/08 19:10:24 dhcp6_remove_event: removing an event on rl0, state=3 2003/00/08 19:10:24 client6_recvreply: got an expected reply, sleeping.
9.5.2. Conguraci n general y de cliente o

En este caso se cuenta con una conguracion general, que presenta los mismos valores que el caso anterior: 2001:aa1::/32/10/2 y 0:0:0:ffff::/96/100/8. Asimismo, existe una conguraci n especca para el cliente, del que se conoce su DUID, cuyo contenido es una entrada o de la tabla DAS: 2001:aa2::/32/10/2. El comportamiento esperado es que, ya que existe una conguraci on especca, se enve uni camente esta al cliente. En el arranque se comprueba que se hay una conguracion especca para un cliente, cuyo nombre es kame (este identicador tiene sentido unicamente en la conguraci n del servidor o para facilidad adminsitrativa), y tiene un DUID asociado.
83
Captulo 9. DHCPv6
2003/00/08 18:54:21 configure_host: configure DUID for kame: 00:01:00:01:05:af:0e:f8:00:c0:26:a0:20:32 2003/00/08 18:54:21 get_duid: extracted an existing DUID from /etc/dhcp6s_duid: 00:01:00:01:05:1b:84:1e:00:c0:26:a0:20:32
En principio, el cliente realiza exactamente la misma peticion que en el caso anterior (aunque cambia la XID, que se genera aleatoriamente en cada mensaje). As, el mensaje solicit es enviado al servidor, donde se comprueba la DUID del cliente, y se encuentra la conguracion especca bajo el nombre asociado:
2003/00/08 18:55:41 server6_recv: received solicit from fe80::2c0:26ff:fea0:2032 2003/00/08 18:55:41 dhcp6_get_options: get DHCP option client ID, len 14 2003/00/08 18:55:41 DUID: 00:01:00:01:05:af:0e:f8:00:c0:26:a0:20:32 2003/00/08 18:55:41 server6_react_solicit: client ID 00:01:00:01:05:af:0e:f8:00:c0:26:a0:20:32 2003/00/08 18:55:41 server6_react_solicit: Entering analysis of client ID 2003/00/08 18:55:41 server6_react_solicit: found a host configuration for kame 2003/00/08 18:55:41 dhcp6_set_options: set client ID 2003/00/08 18:55:41 dhcp6_set_options: set server ID 2003/00/08 18:55:41 dhcp6_set_options: set preference 2003/00/08 18:55:41 server6_send: transmit advertise to fe80::2c0:26ff:fea0:2032
En este caso no se ha mandado ninguna opcion especial, puesto que en el mensaje de advertise el servidor no ha encontrado informacion que tuviera que mandar en ese momento. As, de nuevo, el cliente se comporta de la misma manera que en el caso anterior. A lo que el servidor responde.
2003/00/08 18:55:41 server6_recv: received request from fe80::2c0:26ff:fea0:2032 2003/00/08 18:55:41 dhcp6_get_options: get DHCP option client ID, len 14 2003/00/08 18:55:41 2003/00/08 18:55:41 DUID: 00:01:00:01:05:af:0e:f8:00:c0:26:a0:20:32 DUID: 00:01:00:01:05:1b:84:1e:00:c0:26:a0:20:32 2003/00/08 18:55:41 dhcp6_get_options: get DHCP option server ID, len 14 2003/00/08 18:55:41 server6_react_request: Entering analysis of client ID 2003/00/08 18:55:41 server6_react_request: found a host configuration named kame 2003/00/08 18:55:41 dhcp6_set_options: set client ID 2003/00/08 18:55:41 dhcp6_set_options: set server ID
84
Captulo 9. DHCPv6
2003/00/08 18:55:41 dhcp6_set_options: set das entry 2003/00/08 18:55:41 server6_send: transmit reply to fe80::2c0:26ff:fea0:2032
Aqu s se ha respondido de manera diferente. No se puede apreciar la diferencia de la respuesta en la salida del servidor, puesto que unicamente se ha a adido una opci n DAS. Sin embargo, si se comprueba la salida n o del cliente:
2003/00/08 18:55:41 client6_recv: receive reply from fe80::2c0:26ff:fea0:2032 on 2003/00/08 18:55:41 2003/00/08 18:55:41 rl0 2003/00/08 18:55:41 dhcp6_get_options: get DHCP option client ID, len 14 DUID: 00:01:00:01:05:af:0e:f8:00:c0:26:a0:20:32 DUID: 00:01:00:01:05:1b:84:1e:00:c0:26:a0:20:32 2003/00/08 18:55:41 dhcp6_get_options: get DHCP option server ID, len 14 2003/00/08 18:55:41 dhcp6_get_options: get DHCP option das entry, len 20 2003/00/08 18:55:41 dhcp6_get_options: Extracting DAS option 2003/00/08 18:55:41 dhcp6_get_options: DAS received: 2001:aa2:: 32 10 2 2003/00/08 19:10:24 client6_recvreply: sysctl DAS entry[0] 2001:aa2:: 2003/00/08 18:55:41 dhcp6_remove_event: removing an event on rl0, state=3 2003/00/08 18:55:41 client6_recvreply: got an expected reply, sleeping.
Y se comprueba que unicamente se ha recibido una entrada, correspondiente al valor esperado, por lo que el servidor est funcionando correctamente. a
9.5.3. Uso de rapid commit

En este caso, hay que realizar cambios en la conguracion tanto del cliente como del servidor. En el caso del cliente, se indica que se desea utilizar la opcion rapid commit. En el servidor, que se puede aceptar en el interfaz correspondiente. As, cambia la petici n inicial del cliente, donde se solicita una asignacion inmediata: o
2003/00/16 14:18:41 dhcp6_set_options: set rapid commit 2003/00/16 14:18:41 client6_send: send solicit to ff02::1:2
El servidor recibe la solicitud, de donde extrae la opcion rapid commit. Adem s, comprueba que existe a una conguraci n especca para el cliente, por lo que genera una respuesta (y no un anuncio), donde enva o la tabla DAS.
85
Captulo 9. DHCPv6
2003/00/16 14:18:41 server6_recv: received solicit from fe80::2c0:26ff:fea0:2032 2003/00/16 14:18:41 dhcp6_get_options: get DHCP option client ID, len 14 2003/00/16 14:18:41 DUID: 00:01:00:01:05:af:0e:f8:00:c0:26:a0:20:32 2003/00/16 14:18:41 dhcp6_get_options: get DHCP option rapid commit, len 0 2003/00/16 14:18:41 server6_react_solicit: client ID 00:01:00:01:05:af:0e:f8:00:c0:26:a0:20:32 2003/00/16 14:18:41 server6_react_solicit: Entering analysis of client ID 2003/00/16 14:18:41 server6_react_solicit: found a host configuration for kame 2003/00/16 14:18:41 dhcp6_set_options: set client ID 2003/00/16 14:18:41 dhcp6_set_options: set server ID 2003/00/16 14:18:41 dhcp6_set_options: set rapid commit 2003/00/16 14:18:41 dhcp6_set_options: set das entry 2003/00/16 14:18:41 server6_send: transmit reply to fe80::2c0:26ff:fea0:2032
El cliente recibe la respuesta, de donde recoge la informacion referente a DAS. Se puede comprobar que, adem s, es la informaci n del cliente, no la general. a o
2003/00/16 14:18:41 client6_recv: receive reply from fe80::2c0:26ff:fea0:2032 on rl0 2003/00/16 14:18:41 dhcp6_get_options: get DHCP option client ID, len 14 2003/00/16 14:18:41 2003/00/16 14:18:41 DUID: 00:01:00:01:05:af:0e:f8:00:c0:26:a0:20:32 DUID: 00:01:00:01:05:1b:84:1e:00:c0:26:a0:20:32 2003/00/16 14:18:41 dhcp6_get_options: get DHCP option server ID, len 14 2003/00/16 14:18:41 dhcp6_get_options: get DHCP option rapid commit, len 0 2003/00/16 14:18:41 dhcp6_get_options: get DHCP option das entry, len 20 2003/00/16 14:18:41 dhcp6_get_options: Extracting DAS option 2003/00/16 14:18:41 dhcp6_get_options: DAS received: 2001:aa2:: 32 10 2 2003/00/08 19:10:24 client6_recvreply: sysctl DAS entry[0] 2001:aa2:: 2003/00/16 14:18:41 dhcp6_remove_event: removing an event on rl0, state=1 2003/00/16 14:18:41 client6_recvreply: got an expected reply, sleeping.
Para el caso de una petici n de informaci n general (information only), el funcionamiento es pr cticao o a mente el mismo que el aqu expuesto, ya que en los ejemplos mostrados no se ha solicitado la cesi on de prejos.
86
Captulo 9. DHCPv6
9.5.4. Envio de datos incorrectos

Para este ultimo caso, se ha de prestar atenci n a la gura 9.4, donde se muestra la estructura de la opcion o DAS. Seg n las deniciones propuestas, todos los valores son v lidos, excepto la longitud del prejo, que u a est limitada a 128. Por tanto, se prueba a enviar una entrada con este valor alterado (provocado, por ejemplo, a por un fallo en un router). El cliente responde:
2003/00/08 19:26:19 dhcp6_get_options: Extracting DAS option 2003/00/08 19:26:19 dhcp6_get_options: DAS received: 2001:aa1:: 32 10 2 2003/00/08 19:26:19 dhcp6_get_options: DAS received: 0:0:0:ffff:: 200 255 8 2003/00/08 19:26:19 dhcp6_get_options: Invalid DAS option received, ignoring all DAS entries.
Y descarta toda la opci n DAS, ya que no hay seguridad de que el funcionamiento de la red sea correcto o sin esa entrada. Tambi n resulta importante resaltar que tanto el cliente como el servidor realizan pruebas e de coherencia en la recepci n de los paquetes, como longitud de las opciones y validez de la estructura, y o est n preparados para ignorar las recepciones erroneas y continuar. a
9.6.
Conclusiones sobre DHCPv6
Se ha mostrado en este captulo c mo implementar de forma completa, hasta el paso nal, del envo de o la informaci n en DHCPv6. o Durante el desarrollo de las extensiones a DHCPv6 se conto con varias dicultades:
C digo indocumentado o o o En el SNAP3 no se incluye documentaci n acerca del c digo, es decir, no existe una referencia para saber c mo est planteada la implementaci n m s que estudiando detenidamente el c digo. o a o a o Sin duda, una documentaci n funcional en este sentido hubiera sido una gran ayuda durante el desao rrollo. Esta raz n ha sido un catalizador para plantear el an lisis por cheros anteriormente descrito o a y facilitar as posteriores desarrollos sobre el c digo. o
3
Denominaci n de KAME al volcado completeo de su desarrollo en un momento dado. o
87
Captulo 9. DHCPv6
Herramientas Asimismo, el uso de herramientas para generar codigo (que es conveniente tanto para desarrollar de manera r pida as como para cometer menos errores), obliga a aprender el manejo en todas ellas. As, a fue necesario un estudio de un analizador l xico (lex) y un analizador sint ctico (yacc), as como e a de las funciones especcas para listas enlazadas (queue.h). Si bien es cierto que una vez que estas herramientas se manejan correctamente, son una gran ayuda a la hora de programar. Fallos en algunas funciones Como cualquier proyecto conjunto entre varios programadores, es posible que no haya completa compatibilidad entre todas las llamadas a funciones, con lo que a veces, en situaciones no comunes, ocurran fallos que no se tuvieron en cuenta en un primer momento. Durante la implementaci n de la lectura de las conguraciones, se encontraron algunas funciones de o depuraci n que a pesar de ser correctamente llamadas provocaban un error de segmento. Este tipo o de situaci n provoca retrasos a causa del tiempo perdido en depurar las llamadas a funciones que se o supona probadas. Tambi n se apreciaron errores en el c digo original, que presumiblemente estar n subsanados en e o a posteriores versiones del servidor. Estos errores, no conceptuales, son debidos muy posiblemente a fallos de edici n. Aquellos que se encontraron fueron debidamente subsanados, para conseguir una o implementaci n lo m s correcta y funcional posible. o a
Finalmente, se adjunta una lista de conocimientos b sicos requeridos por aquel que quisiera trabajar a sobre este desarrollo para incorporar nuevas funcionalidades:
Entornos FreeBSD: http://www.freebsd.org Direccionamiento y arquitectura IPv6: [Hinden02] Funcionamiento y extensiones DHCPv6: [Bound02] Programaci n en C, estructuras de datos y programacion en red o Yacc y Lex [Levine95] Funciones de gesti n de colas: /usr/include/sys/queue.h o
88
Captulo 10 SNMP
En el presente captulo se mostrar n los pasos seguidos para generar una implementacion en SNMP que a permita la transmisi n de la informaci n DAS. En este caso, tal y como se comentaba en el an lisis, prima o o a la sencillez. Se comenzar con la presentaci n de la situaci n inicial, en cuanto a herramientas y posibilidades disa o o ponibles al comienzo. Posteriormente se tomar la decisi n de qu dise o de los dos posibles se realiza. a o e n Posteriormente se comentar el dise o de la base de informaci n (MIB), atendiendo a ciertas consideraa n o ciones. Se propondr un dise o que tenga cabida conjunta para dos posibilidades diferentes y compatibles. a n Este ser el contenido principal de este captulo. a M s tarde, se ver n los desarrollos realizados en cuanto a programas gestores y agentes de ejemplo de a a uso de la MIB. Finalmente, se enumerar n las dicultades encontradas, y los conocimientos necesarios para llevar a a cabo el desarrollo y las mejoras tanto de la MIB como de las aplicaciones.
10.1.
Punto de partida
Para SNMP se cuenta con muchas implementaciones funcionales, ya que es un protocolo muy extendido de cara a la gesti n de dispositivos. o
89
Captulo 10. SNMP

En GNU/Linux se cuenta con la herramienta scotty, que permite la generaci on de agentes SNMP, as co mo la incorporaci n de nuevas MIB. Scotty es parte de una ampliacion a Tcl, un lenguaje de programaci n o o de scripts muy sencillo, que resulta pr ctico para el encadenamiento de llamadas a otros programas y el a tratamiento de la informaci n devuelta por estos. o De esta forma, se partir de un marco de trabajo apto para el desarrollo del agente SNMP, y se genea rar un sistema completo para el envo de la informaci n DAS. a o De las dos posibilidades que se planteaban en el an lisis, se realizar la que presenta una mayor sencillez a a (p gina 49), es decir, la que presenta un unico agente que contiene la informacion para todos los clientes a (gestores). As, no es necesario que se genere una lista a gestionar dependiendo de la actividad de cada equipo de la red como en la opci n alternativa (p gina 50). Adem s, esta arquitectura permite el envo de o a a traps, con lo que se puede tener una actualizacion din mica de las tablas si es necesario. a As, unicamente es necesario que los equipos conozcan la direccion del agente, que puede ser incorpo rada a mano, o incluso dentro de una extension DHCP. Cabe resaltar que esta opci n, a pesar de ser m s o a pr ctica, no responde del todo al espritu de SNMP, puesto que se est utilizando como mero directorio a a de informaci n, y no como una monitorizaci n de equipos. Sin embargo, es mucho menos vulnerable que o o la opci n alternativa, puesto que habra que implementar el comando SET, y podra provocar fallos de o seguridad graves.
10.2.
Desarrollo
El desarrollo de SNMP requiere tres elementos: la MIB con la descripci on de los nuevos elementos a gestionar, el agente, y el gestor.
10.2.1. Generaci n de la MIB o

La intenci n en este proyecto, en general, es generar mecanismos que sean utiles y compatibles, am n o e de mantener cierto orden de coexistencia con las opciones ya existentes. En este apartado en particular, se intentar generar una base de informaci n que sea compatible con la jerarqua ya existente. a o A falta de una denici n completa para la gesti n de IPv6 con SNMPv1, la elecci n de una rama del o o o arbol de gesti n recae sobre la experimental, para que una vez se haya concretado pueda ser incorporado o consecuentemente en su secci n. No obstante, se ha desarrollado una MIB v lida para SNMPv2 y escrita en o a SMIv2, que acepta scotty.
90
Captulo 10. SNMP

EXPERIMENTAL.DAS (1.3.6.1.3.200)
SNMP(1)
LDAP(2)
dasMIBObjects(1)
dasMIBConformance(3)
ATRIBUTOS (1)
CLASES (2)
dasMIBGroups(2)
dasTable(1) dasEntry(1) dasNumber(2) dasMultiple(3)
dasMultipleTable(4) dasMultipleEntry(1)
dasIndex(1) dasPrefixAddress(2) dasPrefixLength(3) dasPrecedence(4) dasLabel(5) dsaHost(6)
dasMultipleIndex(1) dasMultipleName(2)
Figura 10.1: Estructura de la MIB planteada

La implementaci n realizada contempla una tabla (dasTable) con las entradas generales para el ambito o administrativo, es decir, los mismos valores para todos los equipos que accedan al agente SNMP. Sin embargo, se ha pensado en incluir un campo adicional, donde se podr indicar el equipo al que pertenece la a entrada. Tambi n se incluye un objeto (dasNumber), que almacena la longitud de la tabla (en n umero de ene tradas). Se ha credo conveniente, ya que a alg n equipo m s simple puede serle de utilidad conocer de u a antemano la cantidad de datos que ha de recibir. La intenci n ha sido generar una soluci n lo m s sencilla posible, de cara a ser implementada en equipos o o a de red. Una MIB de conguraciones m ltiples implicara un proceso m s complejo, ya que SNMP tiene u a problemas para las tablas que deban comportarse como entradas de otras tablas. De esta forma se han propuestos dos funcionamientos compatibles entre s con una unica MIB. Por una parte, se tiene un acceso sencillo, donde unicamente hay que leer tantas entradas como indique dasNumber, desde el comienzo de la lista de dasTable. Esas ser n las entradas por omisi n, para todos los equipos. a o Por otra, la tabla tiene un campo adicional (que no es necesario leer en el proceso anterior), identicando qu equipo debe recibir la informaci n presente en esa entrada. De tal manera, que en la tabla puede haber e o m s entradas de las indicadas por dasNumber, pero estas ser n de una conguraci n diferente. a a o
91
Captulo 10. SNMP

Para poder conocer a qu equipo se reere el identicador, existe otra tabla donde se encuentran relacioe a nados el nombre del equipo 1 con el ndice asociado. Para esto sirve dasMultipleTable. Adem s, se ha credo conveniente incluir un objeto adicional, donde se contabilizan el numero de polticas diferentes presentes en la tabla. As, si este contador es cero, no habr que lanzar la b squeda de nombres, ya que no existir n a u a conguraciones propias. Por tanto, para un equipo muy simple, el funcionamiento sera el siguiente:
1. 2.
Se comprueba el valor de dasNumber. Se toman tantas entradas de la tabla dasTable como haya indicado la lectura anterior. Como en SNMP cada lectura se realiza sobre un campo y una entrada de la tabla, no es necesario saber realmente si existe o no un campo adicional (el identicador de conguraciones), que en este caso se puede ignorar.
Sin embargo, para una situaci n m s compleja, donde los equipos tengan cierta capacidad de tratamiento o a de datos, y se requiera conguraciones diferentes, la situacion pasa a ser:
1.
Se comprueba el valor de dasMultiple, que tiene que ser mayor que cero para que la tabla presente conguraciones m ltiples. u
2. 3. 4. 5.
Si es cero, se aplica el m todo anterior para conguraci n unica. e o Se toma el nombre del equipo (bien de /etc/hostname, o bien por asignaci on directa). Se recorre la tabla dasMultipleTable para encontrar el identicador asociado al nombre del equipo. Una vez encontrado, se consulta la tabla en donde solo se utilizan las entradas que corresponden al equipo.
6.
Si el equipo no fue encontrado, se utilizara el m todo de la conguraci n unica. e o
S lo se implementar el comando GET para evitar problemas de seguridad derivados de la escritura o a indebida o maliciosa. Se ha implementado, sin embargo, la denici on de una trap para poder indicar que el equipo debe solicitar la tabla contenida en el agente. Esta es dasChange, que depende del grupo de noticaciones de la MIB. Durante el envo de esta trap podra pensarse la conveniencia o no de enviar informaci n adicional, como la direcci n del agente. Motivos de seguridad indican que es mejor no aportar o o tal informaci n, puesto que podra ser utilizado para provocar la lectura de la informacion en otro equipo o distinto, y se cae en el mismo problema que presentaba la segunda de las opciones analizadas para SNMP. Por tanto, la denici n de la trap no contendr ning n campo de informaci n. o a u o
Si bien en esta discusi n se est tomando una conguraci n por equipo, este identicador puede ser compartido o a o por m ltiples equipos que recibir n la conguraci n asociada. u a o
1
92
Captulo 10. SNMP

Cabe insistir en el hecho que cualquier nueva extension a la tabla puede realizarse sin ning n tipo de u problemas, simplemente indicando en DasEntry el tipo de dato a incluir, y una posterior asignaci on a un valor en concreto de OID para esa nueva extension. La unica condici n es que los nuevos OID no intereran o con los anteriores. Por su extensi n mediana, la MIB se adjunta en los ap ndices, p gina 123. o e a
10.2.2. El agente SNMP

La generaci n de un agente con scotty se consigue mediante la asignacion de variables Tcl a valores o entradas en el arbol jer rquico SNMP. a B sicamente el agente consta de la generacion de una sesi n SNMP. Recordemos que SNMP no tiene a o orientaci n a conexi n, es m s, funciona sobre UDP. Sin embargo, de cara a generar aplicaciones con scotty, o o a resulta conveniente generar una abstraccion funcional que trate todas las interacciones del agente como una unica sesi n. A esta sesi n se le incluir la opci n especca para que se comporte como un agente. o o a o Posteriormente, se realiza la carga de la conguracion pertinente, presente en un archivo especco (cong.das), que contendr la informaci n de la tabla de polticas DAS. Como ya se coment , lo que se a o o realiza posteriormente es la asignacion de variables de Tcl a entradas en la MIB. La unica dicultad en este caso es cuidar el mantenimiento de la tabla, y la correcta inclusi on de los ndices seg n el contenido del u chero de conguraci n, para que se mantenga la coherencia de la informacion. o Una vez calculados los valores para las entradas, y hechas las asignaciones e instancias de los objetos de la MIB, el agente quedar a la escucha de las peticiones en el puerto habitual de SNMP. Se ha utilizado un a puerto superior a 1024 (2000) para poder ejecutar el agente como usuario. Sin embargo, se puede cambiar en la lnea de comandos. Puede ser interesante que funcione como usuario y no como root, puesto que el int rprete Tcl no est probado, y podra dar lugar a ataques del tipo buffer overow que pusieran en peligro e a la integridad del equipo servidor.
10.2.3. El gestor SNMP

Para el caso del gestor, el script realizar la petici n al agente en una direcci n conocida, y recibir los a o o a contenidos de la tabla, con la que podr actualizar su propia tabla DAS. a El funcionamiento es el propuesto en el apartado de generacion de la MIB, para lo que se utilizan los
93
Captulo 10. SNMP

comandos habituales de SNMP. Para comprobar los inicios de las tablas se utiliza el comando GET-NEXT, cuyo comportamiento es util: la primera entrada de una tabla tiene un OID posterior al de la propia tabla (que no es accesible). Por tanto, si se realiza un GET-NEXT, se devolver el primer objeto accesible, que a en este caso, si existe alg n elemento en la tabla, sera este. Si no, se puede comprobar con el OID del objeto u devuelto que no corresponde a la tabla (puesto que se habr pasado al siguiente objeto en la jerarqua de a OIDs). Este mismo m todo se puede aplicar a las lecturas de tablas de tamano desconocido, smplemente e leyendo secuencialmente hasta que el siguiente objeto no pertenezca a la tabla. Posteriormente s lo restara realizar la llamada al sistema para cada una de las entradas de la tabla. o
10.3.
Pruebas
La unica dicultad que puede aparecer aqu es la lectura completa y correcta de las tablas. El programa gestor que accede a la informaci n incorpora escritura en la salida est ndar para poder depurar los resultados. o a Un ejemplo de ejecuci n es el siguiente. La salida del agente muestra la inicializacion, con la carga de la o conguraci n acerca de la tabla DAS. Posteriormente realiza la asignacion de valores y queda a la espera de o recibir peticiones. Como no se le ha indicado, el agente ha tomado un puerto que se le ha jado en dise no, para posibilitar el arranque por parte de usuarios.
hector@bacterio:/proyecto/codigo/snmp$ ./agente.sct Iniciando agente SNMPv1 DAS en el puerto 2000. Equipo 1: default Entrada leda: Prefijo: Longitud: Etiqueta: Entrada leda: Prefijo: Longitud: Etiqueta: Equipo 2: kame Entrada leda: Prefijo: Longitud: ::aaaa:0:0:0:0 96 ::ffff:0:0:0:0 96 1 2001:aaaa:: 32 2
Precedencia: 10
Precedencia: 20
Precedencia: 10
94
Captulo 10. SNMP

Etiqueta: 1
Agente iniciado, esperando peticiones!
Como puede verse, se han cargado tanto la conguracion general, como la correspondiente al equipo kame. Para el caso del gestor, se ver primero el caso m s habitual: una conguraci n com n y acceso sencillo. a a o u
hector@bacterio:/proyecto/codigo/snmp$ ./gestor.sct localhost 2000 Agente solicitado en la lnea de comandos: localhost:2000 Configuraciones alternativas: 1 o o No se ha especificado nombre de equipo. Se usar la configuracin por omisin a o Nmero de entradas por omisin en la lista: 2 u Solicitando las entradas DAS. Recibida entrada n.1: Prefijo: ::ffff:0:0:0:0/96 Prec: Prec: Se ha(n) recibido 2 entrada(s). 10 Label: 1 20 Label: 2 Recibida entrada n.2: Prefijo: 2001:aaaa::/32
Para el caso de una conguraci n en particular, el gestor tendr que ser convenientemente instruido en o a la lnea de comandos:
hector@bacterio:/proyecto/codigo/snmp$ ./gestor.sct localhost 2000 kame Agente solicitado en la lnea de comandos: localhost:2000 Configuraciones alternativas: 1 Nombre del equipo especificado: kame. Buscando en tabla. Encontrado nombre: kame Indice : 2 Recibida entrada n.1: Prefijo: ::aaaa:0:0:0:0/96 Prec: Se ha(n) recibido 1 entrada(s). 10 Label: 1 Se ha llegado al final de la tabla.
De esta forma, el gestor ha sido capaz de tomar unicamente las entradas que le correspoden.
95
Captulo 10. SNMP
10.4.
Conclusiones
El desarrollo de SNMP tal y como se ha realizado aqu sufre de los problemas que ya se comentaron en el an lisis (p g. 51). Sin embargo, para el caso de una red sin usuarios maliciosos, resulta razonablemente a a correcta. El uso de SNMPv3 o IPSec cuando la especicacion est terminada puede suponer un fuerte empuje a e esta opci n, ya que se contemplar en mucha mayor profundidad el cifrado y la autenticacion, con lo que o a aumentar la seguridad y la posibilidad de impedir al resto de los usuarios el acceso a tablas de polticas que a no les correspoden. Las principales dicultades para el desarrollo SNMP fueron las siguientes:
Las especicaciones de las MIBs se encuentran repartidas en multitud de RFCs. Adem s, las corresa podientes a fabricantes no suelen estar documentadas y son complejas de encontrar. La documentaci n de scotty no incorpora informaci n acerca de la gesti n de tablas din micas, auno o o a que los problemas son menores cuando s lo se permite el comando GET (ya que las tablas permao necer n jas). a Asimismo, la documentaci n de scotty resulta limitada en la mayora de las situaciones, y es parca en o ejemplos generales.
Para poder trabajar con los resultados aqu conseguidos, es conveniente tener aanzados los conceptos acerca de:
SNMP, SMIv1, SMIv2, MIB-2: [Perkins97], [Mauro01] Tcl y Scotty: http://wwwhome.cs.utwente.nl/ schoenw/scotty/
96
Captulo 11 LDAP
En este captulo se mostrar n los pasos seguidos para la implementacion de LDAP como mecanismo a para la transmisi n de la tabla de polticas DAS. o En esta primera implementaci n no se tendr en cuenta la posibilidad de generar una implementacion o a que sea accesible como base de informacion de red. LDAP es un buen substituto a NIS, como ya se coment en el an lisis. Sin embargo, los clientes actuales de LDAP para este tipo de servicios, que usan PAM o a y NSS 1 , no incorporan facilidades para a adir nuevos tipos de entradas. n Lo que s se va a generar es una implementaci n donde se van a poner de maniesto las consideraciones o sobre seguridad ya mencionadas en el an lisis. Se va a autenticar el servidor y cifrar las conexiones por a medio de TLS. Adem s, para poder asegurar que son los clientes correspondientes los que acceden a la a informaci n, asmismo se va a comprobar la autenticidad de las credenciales, por medio de claves para los o clientes. Estas claves podran mantenerse en texto plano, puesto que la capa TLS aporta el cifrado suciente como para evitar la captaci n. A n as, se ha preferido almacenar las claves como hash. o u Adem s, el servidor LDAP permite ocultar ciertos atributos dependiendo de las credenciales, por lo que a se puede conseguir un buen nivel de autenticacion y privacidad a los efectos ya comentados en el captulo 4. Esta caracterstica servir para evitar el acceso a las claves de los otros usuarios. a En este captulo, pues, existir una secci n donde se mostrar , de manera pr ctica y completa, c mo ge a o a a o nerar los certicados necesarios para poder garantizar la seguridad en las peticiones LDAP. Cuando existan implementaciones completas de IPv6 que incluyan IPSec, no ser necesaria la autenticaci n por certicados a o en el nivel de aplicaci n, ya que se realizar en el de red. Sin embargo, se ha credo interesante mostrar o a
Pluggable Authentication Modules y Name Service Switch. Para m s informaci n, a o http://www.rz.uni-augsburg.de/ zahn/pam nss dce/
1
97
Captulo 11. LDAP

c mo conseguir un buen nivel de seguridad con las herramientas disponibles actualmente. o
11.1.
Punto de partida
Existen multitud de soluciones para LDAP, como los servidores de Netscape, o la Universidad de Mi chigan. Bas ndose en esta ultima, hay un proyecto de software libre que resulta muy potente y completo, a OpenLDAP. Esta implementaci n contempla no s lo LDAPv2 y LDAPv3, sino que implementa de manera funcional o o las nuevas caractersticas como por ejemplo SASL. Adem s de ser de libre distribuci n y modicaci n, entre a o o otras de sus ventajas se incluye la de ser f cilmente congurable, tanto en la inclusion de nuevos esquemas a (la descripci n de los datos que es capaz de manejar), como en las instrucciones sobre seguridad y nivel de o acceso a los clientes. Para las pruebas de acceso se utiliz un cliente caracterizado tambi n por ser software libre llamado o e Gq. Si bien su fucionamiento es completamente correcto, tambi n por comodidad se utiliz LBE v2.8.2 e o (LDAP Browser/Editor), que incluye cierta facilidad para la inclusi on de nuevas entradas y es visualmente m s claro. a El primer cliente nombrado tiene caractersticas como SASL, TSL, distintos tipos de cifrado en las claves de usuario, y es capaz de recuperar el schema original a la hora de incorporar datos, capacidad carente en el segundo, que necesita incluir la descripcion de los objetos que se van a a adir. n Este otro cliente sigue elmente las especicaciones de LDAPv2 y LDAPv3, con las que puede funcionar indistintamente a voluntad del usuario. De entre otras caractersticas se puede destacar que puede funcionar en m ltiples S.S.O.O., ya que est desarrollado en Java, entre ellos GNU/Linux, MAC OS X y u a Windows. Por supuesto, la facilidad de uso en este caso requiere un esfuerzo adicional, que es especicar el tipo de objetos que se quieren a adir, para que esta operaci n pueda realizarse inmediatamente. n o En esta implementaci n se utilizar la versi n 3 de LDAP para poder sacar partido a todas las opciones o a o de seguridad disponibles, para otorgar al resultado nal de una mayor exibilidad a la hora de activar otras opciones, como el uso de mecanismos de seguridad como TLS. Adem s, se va a generar un nuevo tipo de clase estructural (object class) LDAP, para contener la infora maci n referente a un equipo IPv6 con la informacion pertinente. o No obstante, puede resultar m s pr ctica la generaci n de una clase auxiliar (como se ver m s adelante, a a o a a
98
Captulo 11. LDAP

son aquellas que se pueden a adir a una entrada que pertenezca a una clase estructural consiguiendo a nadir a n la entrada sus atributos). De esta forma, cuando exista una denici on completa de equipos IPv6 para LDAP, unicamente habra que a adir esta clase a la ya existente dentro de cada entrada. As, se ha generado tambi n n e una clase auxiliar, que no se usar , pero que puede ser util cuando la especicaci n est completa. a o e
11.2.
Generaci n de un schema LDAP o
B sicamente, un schema es una denicion que contiene tanto los atributos como el tipo de objetos que a estar n disponibles en el directorio LDAP. a En LDAP, cada entrada est determinada por clases. En la denicion de cada una de las clases se espea cican tanto los tipos de atributos que deben incluirse, como aquellos que pueden ser aportados. Es decir, se especica completamente qu puede tener un objeto, y sobre todo, qu debe tener obligatoriamente el e e objeto para pertenecer a una clase. De esta manera, se tiene control sobre el tipo de objetos que se insertan en el directorio. Adem s, existen varios tipos de clases. A destacar la distincion entre clases estrucurales y auxiliares. a Una entrada puede pertenecer unicamente a una clase estructural, mientras que no tiene lmite en el n mero u de clases auxiliares. La utilidad de esta distinci n quedar m s clara con un ejemplo. Una clase auxiliar es simpleSecuo a a rityObject. Esta clase otorga la posibilidad de aportar un atributo llamado userPassword, que como su nombre indica, es capaz de contener una clave. De esta manera, si se tiene un objeto de una clase cualquiera, basta con a nadir al atributo objectClass que tiene toda entrada del directorio, el valor simpleSecurityObject, de tal manera que a partir de entonces se puede disponer del atributo userPassword. La autenticaci n de los clientes es sencilla. El identicador que se otorga durante la conexi on es el o distinguished name de una entrada que contiene un atributo userPassword. Y la clave ha de coincidir, ya sea en limpio, ya sea con algoritmos hash, con la almacenada en esa entrada. En este caso, se ha optado por utilizar hash de claves, para evitar posibles fallos de seguridad. Tanto las clases como los atributos est n completamente determinados en el schema, tanto en depena dencias como en asignaciones al arbol OID. Por ello en este trabajo se ha tomado la rama experimental para incluir las entradas.
99
Captulo 11. LDAP

Por mantener cierta hoomogeneidad con las anteriores implementaciones, se tomar el segmento 200 a dentro de la rama experimental. As mismo, se separar n las deniciones de atributos de las de clases, a asignando 200.1 a los atributos, y 200.2, a las clases. No est de mas recordar en este punto, que la jerarqua del arbol de OIDs no tiene nada que ver con a la organizaci n del directorio. La clasicaci n en OIDs unicamente afecta a la denici n de las clases o o o y los atributos, no a los objetos, que estar n distribuidos en la jerarqua del directorio LDAP como m s a a conveniente le parezca al administrador. En otro orden de cosas, la informaci n que se va a incluir ser unicamente la correspondiente a la tabla o a DAS. Se utilizar un formato ya conocido, generado por el grupo responsable de LDAPv3, para mandar a cadenas, v lido para direcciones. LDAP tiene otra particularidad consistente en que un mismo atributo puede a contener m s de un valor, con lo que se convierte en una gran facilidad a la hora de implementar listas de a datos para una misma entrada. De esta manera, un unico atributo contendr toda la tabla das correspondiente a a esa entrada. El atributo ser de tipo IA5String, que permite almacenar una cadena de texto. El formato que se utilia zar es el mismo que el utilizado para expresar la entrada de la tabla DAS en la implementaci on DHCPv6: a direcci n IPv6 / n mero de bits / precedencia / etiqueta . o u La decisi n de almacenar la informaci n de esta manera se ha tomado pensando en el administrador. o o Para un humano es mucho m s sencillo ver la informaci n expresada en este modo que en una larga cadena a o de dgitos hexadecimales. Adem s, es mucho m s c modo insertar la informaci n de manera seguida que a a o o en m ltiples casillas, m s a n cuando el n mero de entradas a insertar es grande. Por tanto, aunque sea u a u u ligeramente m s ineciente a la hora de tratar la informacion por una m quina, el esfuerzo y tiempo que se a a ahorra durante la administraci n justican esta decisi n. o o Hubiera sido muy interesante que el servidor permitiera la denici on de una nueva sintaxis para el atributo, de tal manera que forzase a las entradas a respetar el formato para las entradas. Este tipo de facilidades est previsto para attributos como n mero OID o n meros de T lex, donde el servidor s lo acepta las a u u e o entradas si estas se ajustan a un formato concreto. Para realizar una implementaci n activa, se ha creado una clase que contiene una descripcion del equipo, o as como un identicador habitual (cn, o common name). De cara a la autenticaci on, se tomar la clase a no estructural (auxiliar) anteriormente comentada para poder incluir autenticaci on a partir de las nuevas entradas propuestas. As, la visi n del arbol de OIDs correspondiente a la implementacion de LDAP puede verse en la gura o 11.1. La descripci n en el formato de OpenLDAP (formato LDAPv3) es: o

100
Captulo 11. LDAP

EXPERIMENTAL.DAS (1.3.6.1.3.200)
SNMP(1)
LDAP(2)
ATRIBUTOS (1)
CLASES (2)
dasMIBObjects(1)
dasMIBGroups(2)
dasMIBConformance(3)
dasTableEntry (1)
equipoIP6 (1)
dasObject (1)
Figura 11.1: Arbol OID correspondiente a LDAP

# Atributos # # dasTableEntry: Una entrada DAS en el formato expresado en DHCP: # <dirIP>/<longitud del prefijo>/<precedencia>/<etiqueta>
attributetype ( 1.3.6.1.3.200.2.1.1 NAME dasTableEntry EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} ) # Clases # Clase estructural para realizar las pruebas objectclass ( 1.3.6.1.3.200.2.2.1 NAME equipoIP6 SUP top DESC A class defining an IPv6 capable node MUST ( cn ) MAY ( description $ dasTableEntry ) STRUCTURAL ) # Clase auxiliar para la implementacin futura o objectclass ( 1.3.6.1.3.200.2.2.2 NAME dasObject SUP top DESC A non-structural class including a DAS entry MAY ( dasTableEntry ) AUXILIAR )
Cabe destacar que el espacio de LDAP para DAS empieza en (experimental.200.2) , puesto que la rama (experimental.200.1) es la usada en el desarrollo SNMP. Con esta inclusi n ya se pueden disponer de objetos capaces de mantener la informaci on correspono diente a DAS. De cara a utilizar estas clases en el servidor, para el desarrollo aqu comentado se utilizar n a equipoIP6 y simpleSecurityObject. Esta ultima est denida en la especicaci n de LDAPv3, y aporta a o
101
Captulo 11. LDAP

dc=uc3m.es, dc=es dn="dc=uc3m, dc=es" description=Universidad Carlos III de Madrid Location=28911 Leganes
ou=equipos, dc=uc3m, dc=es dn="ou=personal, dc=uc3m, dc=es" dn="ou=empresas, dc=uc3m, dc=es" dn="ou=equipos, dc=uc3m, dc=es" description=Equipos gestionables location=Ingenieria Telematica
dn="cn=default, ou=equipos, dc=uc3m, dc=es"
dn="cn=bacterio, ou=equipos, dc=uc3m, dc=es"
cn=bacterio, ou=equipos, dc=uc3m, dc=es description=Portatil dasTableEntry=2001::/20/30/3
Figura 11.2: Organizaci n LDAP propuesta o

el atributo userPassword.
11.3.
Organizaci n del espacio LDAP o
LDAP ofrece mucha exibilidad a la hora de organizar la informacion dentro del servidor, de manera que pueden realizarse multitud de clasicaciones distintas. Por ejemplo, entre departamentos, entre localizaciones. . . Para el trabajo aqu presentado se propone una clasicacion sencilla, que no tiene por qu ser la utilizada e en otra implementaci n. Se supondr una situaci n habitual, como es una universidad. Por sencillez se too a o mar una separaci n entre personal y equipos, que estar n representados por sus correspondientes unidades a o a de organizaci n. o Dentro de la unidad equipos, s lo existir un nivel inferior, donde se encuentran los objetos que o a representan a los equipos. En el desarrollo aqu propuesto, unicamente se tendr n en cuenta los atributos a mnimos, es decir, los correspondientes a DAS y a la autenticacion. Sin embargo, cualquier administrador puede a adir una clase auxiliar a los objetos, y permitir que tengan mayor informaci on (localizaci n, sistema n o operativo, memoria. . . ). Como ejemplo de la organizaci n propuesta, se adjunta la gura 11.2. o
102
Captulo 11. LDAP
11.4.
Conguraci n de los niveles de acceso o
Una vez que se tiene preparada la estructura de la informacion a almacenar en el directorio LDAP, hay que designar los niveles de acceso para poder plantear un sistema con cierto grado de seguridad. En la siguiente lista se enumeran las caractersticas organizativas y de seguridad que se plantean para la implementaci n LDAP. Se omitir n las entradas superiores (nodos padre) por encima de las que afectan a la o a implementaci n, puesto que en cada caso corresponder n a una organizaci n del directorio diferente. o a o
1.
Todos los equipos depender n de una unidad de organizaci n denominada equipos. Si bien esta a o clasicaci n es puramente un ejemplo, puede servir tal y como est aplicada a una organizaci n o a o sencilla.
2.
Existir una conguraci n por omisi n a la que todos los equipos tendr n acceso. Esta aparecer dena o o a a tro de la unidad equipos bajo el nombre com n default. Es decir, su nombre distinguido ser cn=default, u a ou=equipos, . . . .
3.
Asimismo, opcionalmente puede existir una conguracion especca, a la que s lo podr acceder el o a equipo que debe recibirla. Esta se identicar con la entrada cuyo nombre com n sea el nombre del a u equipo. Por ejemplo, para el equipo llamado proyecto, la conguraci on se encontrar en aquella a entrada con el nombre distinguido cn=proyecto, ou=equipos, . . . .
4.
Los equipos tendr n que autenticarse al acceder al directorio como la entrada a la que tienen que a acceder. Es decir, el equipo cuyo nombre sea kame, se autenticar con el nombre distinguido a cn=kame,ou=equipos, . . . . La clave que deben aportar se encontrar en la entrada propia, bajo a el atributo userPassword.
5. 6.
Los equipos no pueden acceder al atributo userPassword que no les pertenezca. S lo el administrador puede realizar cambios en las entradas de los equipos. o
La lista anterior puede resumirse en la siguiente tabla: Estos distintos objetivos se consiguen mediante las directivas de acceso, conguradas en el servidor OpenLDAP. El ejecutable principal, slapd, requiere un chero de conguraci on donde se especican todos los par metros necesarios. Por ejemplo, localizaciones de los cheros de datos, formatos, cu l es el nombre a a distinguido del administrador. . . Entre estos par metros se encuentran los ajustes de los accesos. La traduccion al formato de slapd es: a
103
Captulo 11. LDAP Tipo de usuario Informaci n o Administrador Toda Equipos Tabla DAS por omisi n o Tabla DAS propia Tabla DAS ajena Clave propia Clave ajena An nimo o Tabla DAS por omisi n o Tabla DAS de equipos Clave de usuario Acceso Escritura Lectura Lectura No autorizado Escritura No autorizado Lectura No autorizado No autorizado
Tabla 11.1: Niveles de acceso por clientes y zonas al servidor LDAP

# The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below access to attribute=userPassword by dn="cn=admin,o=Universidad Carlos III de Madrid,c=34" write by anonymous auth by self write by * none # Configuracin para DAS o access to dn="cn=default,ou=equipos,o=Universidad Carlos III de Madrid,c=34" by * read access to attribute=dasTableEntry by dn="cn=admin,o=Universidad Carlos III de Madrid,c=34" write by self read by * none # The admin dn has full write access access to * by dn="cn=admin,o=Universidad Carlos III de Madrid,c=34" write by * read
Los par metros aqu especicados se aplican en orden de aparicion, es decir, si la solicitud encuentra a correspondencia en alguno de los par metros, se aplica lo que en el aparece, y no se ignoran los restantes. a Como puede verse, la implementaci n que se ha generado, supone una estructura jer rquica sencilla, o a dependiendo unicamente de la organizaci n Universidad Carlos III de Madrid, en Espana (c 34). Sin o
104
Captulo 11. LDAP

embargo, esto depende de cada servidor de directorio. De esta manera ya existe un servidor completamente funcional que es capaz de otorgar las entradas de la tabla DAS, y mantener ciertos criterios de privacidad.
11.5.
Uso de la capa TLS
Hasta este punto se ha conseguido mantener un nivel de seguridad b sico, permitiendo que los equipos a accedan s lamente a la informaci n que les corresponde. o o Sin embargo, estas consideraciones de seguridad no han tenido en cuenta dos posibilidades:
1. 2.
C mo asegurarse de la autenticidad del servidor o C mo prevenir ataques que se basen en interceptacion de paquetes o
Es decir, como asegurar la autenticacion y la privacidad cuando el atacante tiene acceso a la red. Para ello, LDAP cuenta con distintas opciones que implementan ambas consideraciones. Para este caso, se tomar TLS, ya que es una tecnologa muy probada (pr cticamente equivalente a SSL 3.0, al que puede a a rebajarse si alguna de las partes no soporta TLS), y existe documentaci on completa acerca de ella. No se tomar SASL, que siendo m s atractiva por su exibilidad, no acaba de estar f cilmente accesible. Adem s, a a a a es la opci n utilizada cuando LDAP realiza el papel de NIS. o TLS se sit a entre la capa de red y la de transporte, de manera casi transparente, para conseguir minimiu zar los cambios en las aplicaciones que lo usen. El protocolo se basa en el intercambio de certicados y la negociaci n de algoritmos de cifrado y claves de sesion (normalmente sim tricas), que se utilizar n en la coo e a municaci n. Como es de esperar en todo mecanismo de clave publica, aparece el concepto de conanza. En o denitiva, esto se traduce que todo certicado que se proponga al cliente y est rmado digitalmente por una e autoridad que el cliente reconozca como able, ser asimismo reconocido como able, y se aceptar para la a a comunicaci n. o Los pasos a seguir son los siguientes:
1.
Contar con una autoridad certicadora (CA). Es necesario que el certicado del servidor est rmado por una autoridad certicadora que reconozca e el cliente. Puesto que no se va a contar en principio con la colaboraci on de ninguna autoridad, se ha
105
Captulo 11. LDAP

optado por generar una clave privada y generar los certicados necesarios, rmados por la autoridad generada. Esto implica que habr que copiar en los clientes los certicados de la CA reci n creada. a e 2. Generar el certicado del servidor Adem s, este certicado ha de estar rmado por la CA que sea conocida y tenida en conanza por a los clientes. 3. Copiar el certicado en cada cliente que utilice LDAP, o permitir que se acepte el certicado propues to la primera vez que se acceda. Esta ultima opci n no est disponible en todos los clientes LDAP, o a y es necesario tener una copia de la rma para que al usarla se pueda aceptar el certicado como correcto. 4. Opcionalmente, generar certicados para los clientes. Este paso no es necesario, puesto que los clientes ya se est n autenticando por medio de las ena tradas userPassword que permanecen ocultas para el resto de los equipos. Pero puede signicar una protecci n adicional. o 5. Congurar el servidor LDAP para que utilice los certicados. No hay m s que indicar en el chero de conguracion cu les son los cheros que contienen el certia a cado del servidor y de la CA, as como el chero que contiene la clave privada del servidor.
Para generar todos los cheros necesarios se conto con las herramientas de las que dispone el proyecto OpenSSL. Principalmente se utiliz el script CA.pl que simplica en gran medida las operaciones a seguir, o que no los resultados. Esta aplicacion Perl es realmente una mera coleccion de llamadas con par metros al a ejecutable principal openssl. Para una muestra completa de la puesta a punto de la capa TLS, se ha realizado un ap ndice que se e encuentra en la p gina 135. a
11.6.
Pruebas
Seguidamente se muestran distintas pantallas conseguidas durante las pruebas. Se mostrar n las corresa pondientes al programa LBE, por ser m s claras que las correspondientes a Gq. Si bien se utiliza SSL en a vez de TLS, el resultado es pr cticamente el mismo, ya que TLS es capaz de detectar que el otro extremo es a SSL, y comportarse como tal. Se partir de la siguiente situaci n: a o
106
Captulo 11. LDAP

El directorio LDAP tiene como DN base a o=Universidad Carlos III de Madrid,c=34. El administrador ya ha incluido las entradas necesarias para que los equipos puedan identicarse. El equipo que se va a usar como ejemplo es el equipo bacterio. Este equipo requiere una conguraci n especca, que buscar en la entrada correspondiente. o a Este equipo tiene asignada, tambi n, una clave que el administrador ha prejado, y que es conocida. e Esta puede ser modicada posteriormente por el equipo.
La pantalla principal de conexiones de LBE aparece en la gura 11.3. Se muestra c omo pueden existir distintas conguraciones guardadas para cada ocasion. Se realizar el acceso tal y como lo hara un equipo normal, es decir, identic ndose como una entrada a a perteneciente a la unidad organizacional equipos. Puede observarse que se ha seleccionado la versi on 3 de LDAP, y que se utiliza SSL. Al aceptar la conexi n con estos par metros, el cliente muestra, como se ve en la gura 11.5, que se ha o a recibido un certicado cuya CA no reconoce. Por tanto, antes de continuar, se ofrecen varias posibilidades para el uso del certicado. Por supuesto, se muestra a la autoridad certicadora, de cuya conanza dependen todos los certicados rmados por ella. Lamentablemente este cliente no muestra la rma digital que permita saber, compar ndola con la prea sente en el certicado, la autenticidad de la otra parte de la comunicaci on. As, dependiendo del nivel de seguridad requerido, es conveniente haber traspasado manualmente el u certicado a los clientes, para evitar posibles ataques man-in-the-middle, ya que en esta situaci on a n no se tiene seguridad de qui n es la autoridad. e La comunicaci n ya establecida mediante una capa de seguridad, y la entrada al directorio ya est gao a rantizada, pudiendo acceder a las entradas de la manera habitual. En la gura 11.6 se puede ver el arbol en su primer nivel, con la clasicacion en People y equipos. Existen dos entradas m s, para distintos a administradores, admin y gestor. B sicamente el equipo ha de acceder a su entrada correspondiente, donde podr obtener la informaci n a a o requerida para la tabla de polticas DAS. En la gura 11.7 se puede observar que el equipo tiene asignada una tabla de dos entradas, y tambi n puede acceder a su clave. e Adem s, como es de esperar, el equipo tambi n puede acceder a la conguraci n est ndar para todos a e o a los equipos (gura 11.8), es decir, a la que se encuentra dentro del objeto cn=default, ou=equipos, . . . . Estas son las unicas dos entradas de las que el equipo puede obtener informacion relativa a la tabla DAS.
107
Captulo 11. LDAP

Como comprobaci n, se intenta acceder a las entradas del equipo mortadelo. No se puede ver ning un o valor del atributo dasTableEntry en la gura 11.9, ya que ha sido desautorizado por el administrador. Por tanto, aqu se ha conseguido mantener la privacidad de la informacion de la tabla DAS. Por supuesto, tambi n se va a comprobar que las entradas est n protegidas contra escritura. Para ello, e a se intenta a adir un nuevo valor al atributo dasTableEntry, con el esperado resultado de la gura 11.10. n Luego se est evitando que el usuario pueda realizar cambios que provoquen funcionamientos de la red a inapropiados.
11.7.
Conclusiones
a Se ha mostrado c mo implementar, desde cero, una solucion v lida para la transmisi n de la informaci n o o o de la tabla DAS. Las principales dicultades que se encontraron fueron:
B squeda de schemas para IPv6, ya que se intento compatibilizar lo m s posible con los desarrollos u a existentes. Sin embargo, el haber desarrollado una clase auxiliar permite que sea a nadida en cuanto esta schema sea normalizada. Falta de documentaci n precisa acerca de la generaci n de certicados TLS/SSL para OpenLDAP, ya o o que algunos detalles, como la coincidencia del common name con la direcci on del servidor no est n a especicados. Dicultad de encontrar una aplicacion que permita ampliar los servicios de nss ldap, para permitir el uso de la clase auxiliar dentro del servidor de informacion de una red.
Los principales conocimientos que se necesitan para seguir trabajando con esta implementaci on son:
Organizaci n LDAP: c mo se ordenan los datos, clasicaciones habituales de objetos LDAP: [Howes99]. o o Organizaci n del arbol de OIDs, para saber c mo organizar las clases y los atributos generados: o o [Howes99], [Perkins97]. Formato de especicaci n de los atributos y las clases (dependiente de la aplicacion): [Howes99]. o Funcionamiento de los esquemas de clave publica y certicados. Funcionamiento de OpenLDAP como administrador (lnea de comandos, opciones, . . . ) y el uso de certicados: [vanMeer01], [Frediksson01], [Brown01]
108
Captulo 11. LDAP

Uso de las aplicaciones de la biblioteca OpenSSL, en particular las herramientas de gesti on de certicados: man openssl Uso de alguna herramienta cliente de LDAP
109
Captulo 11. LDAP
Figura 11.3: Men de conexiones de LBE u
Figura 11.4: Opciones de conexion para un equipo
Figura 11.5: Opciones para una nueva CA no reconocida
110
Captulo 11. LDAP
Figura 11.6: Visi n general del arbol LDAP o
Figura 11.7: Atributos disponibles para el equipo bacterio
111
Captulo 11. LDAP
Figura 11.8: Atributos de la entrada default
Figura 11.9: Atributos de la entrada mortadelo
Figura 11.10: Informe de errores del programa LBE Proyecto n de carrera - H ctor Cordob s de la Calle e e 112
Parte IV Conclusiones nales
113
Captulo 12 Conclusiones nales
En el captulo nal se intentar n mostrar algunas reexiones y concluiones sobre el trabajo realizado. a Para ello se contar con los objetivos planteados al comienzo de la memoria, como punto de referencia. a Posteriormente, se propondr n futuras lneas de trabajo, tanto para continuacion de lo hasta ahora exa puesto, como otras posibilidades.
12.1.
Sobre los resultados
Recordando los objetivos marcados al comienzo, con este proyecto se pretenda principalmente realizar una base s lida para el entendimiento y el trabajo con la informacion referente al algoritmo DAS. Incidiendo, o claro est , en la demostraci n de las implicaciones mostradas en un an lisis que aportara la mayor cantidad a o a posible de informaci n util. o Sobre lo completo del an lisis hay que decir que se ha intentado tener la mayor cantidad posible de a puntos de vista: entorno, seguridad, en distintos protocolos que fueran utiles como mecanismo buscado. Para ello, se ha incidido especialmente en los temas importantes, como el funcionamiento del algoritmo, y sus implicaciones dependiendo del marco de funcionamiento. Otro tema, como el de seguridad, por su importancia aqu y en muchas otras situaciones, fue considerado lo bastante importante como para incluir un breve pero completo resumen de los sistemas actuales de seguridad en redes. Sobre las implementaciones, que si bien no son completas hasta el ultimo extremo (en el que se actua liza la tabla de la pila IPv6), esto no es importante. La transmisi on del mecanismo que se buscaba se ha conseguido, y cada uno de los prop sitos para cada implementaci n ha sido logrado. o o
114
Captulo 12. Conclusiones nales

Con DHCPv6 se buscaba una soluci n capaz de aportar informaci n diferenciada entre clientes, o o adem s de compartir servidor y mecanismo con otro tipo de informacion de autoconguraci n. a o Se plante SNMP para otro objetivo muy distinto: la mayor sencillez posible manteniendo alg un o criterio extra, como la capacidad de cambio de la informacion bajo demanda. En LDAP se buscaba la exibilidad de su esquema de ordenacion de datos y la seguridad que se consigue con la capa TLS.
Adem s, pensando tanto en el posible adminsitrador que usara estas soluciones, como en el desarroa llador que tuviera que mantenerlas o ampliarlas, se han incluido ejemplos pr cticos de funcionamiento, de a conguraci n, de instalaci n, y un listado de conocimientos y referencias b sicos para que se disponga de o o a todo lo necesario para trabajar con las m ximas garantas de comprensi n del contenido. a o Por ello, puede decirse que los objetivos han sido plenamente alcanzados.
12.2.
Trabajos futuros
El trabajo aqu presente no es m s que el comienzo de posibles mejoras, que dependen en gran medida a de la evoluci n de la implementaci n del est ndar IPv6, y de los desarrollos de otros protocolos. o o a Para DHCPv6, sin duda, una tarea pendiente es incorporar la extensi on a las versiones nales del proyecto KAME, donde posiblemente las opciones disponibles se hayan expandido para dar cabida a m s partes a de la especicaci n, que actualmente no sigue totalmente. o Otra tarea immportante sera conseguir autenticaci n por parte del servidor y de los clientes, para ase o gurar un buen uso del protocolo en redes m s hostiles de lo habitual. Sin embargo, este trabajo sera vano a una vez se implementara IPSec. De ah considerar m s importante la tarea anterior. a Para SNMP, la posibilidad de mantener distintas polticas dentro de la MIB con un uso est ndar, per a mitiendo incorporar las entradas DAS a la IPV6-MIB, la denicion actual de gesti n IPv6, que todava no o est terminada. Asimismo, la posibilidad de autenticacion de equipos, dependiente de IPv6. Sin embargo, a esto le restara utilidad, ya que el punto fuerte de SNMP es la sencillez. Para LDAP, hay una posibilidad muy ambiciosa. La integracion de las entradas LDAP en la subtitucion de NIS. De esta forma, sin necesidad de utilizar IPSec podran existir ahora mismo soluciones seguras, y a n as el trabajo no sera en vano. Los principales esfuerzos seran, por una parte, denir las clases estrucu turales mnimas que contendr n la informaci n. Las auxiliares ya est n conseguidas. Por otra, el cambio a o a
115
Captulo 12. Conclusiones nales

del c digo fuente del m dulo nss ldap, 1 donde se realiza la comunicaci n segura y la actualizaci n de los o o o o contenidos en los equipos. Tambi n sera importante realizar el mismo cambio en la utilidad nscd2 , para e que la informaci n se mantuviera actualizada de manera eciente. o En todas ellas ahora mismo hay que realizar las llamadas al sistema para cambiar los contenidos de la tabla. Sin embargo, actualmente no hay ninguna implementacion ocial que permita esta posibilidad, por lo que ser necesario esperar a futuros desarrollos (o implementarlo en el kernel de sistemas libres). a No obstante, existe una versi n experimental [Rodrguez02] para el kernel FreeBSD 4.5 que es capaz de o actualizar esa informaci n. o Tambi n puede ser interesante el desarrollo para otros mecanismos, como Router Advertisment, y evitar e as el uso de un protocolo adicional para congurar los equipos. No obstante, como ya se ha comentado, s lo sirve para otorgar una conguracion com n a todos los equipos, lo que no es obice a que coexista con o u otros mecanismos.
Este m dulo se encarga de el acceso al servidor LDAP, a unas unidades de organizaci on especcas [Howard98], o donde encuentra entradas de clases que corresponden a datos del tipo NIS. 2 Este programa se encarga de mantener una cach local para evitar tener que acceder contnuamente al servidor e LDAP.
116
Captulo 13 Bibliografa y referencias
[Draves02]
R. Draves. Default Address Selection. Internet Draft, IETF, August 2002. Work in progress.
[Deering98]
S. Deering, R. Hinden. Internet Protocol, Version 6 (IPv6) Specication, RFC 2460, December 1998
[Bound02]
J. Bound, M. Carney, C. Perkins, R. Droms. Dynamic Host Conguration Protocol for IPv6 (DHCPv6). Internet Draft, IETF, November 2002. Work in progress.
[Yeong95]
W. Yeong, T. Howes, S. Kille. Lightweight Directory Access Protocol, March 1995. RFC 1777.
[Thomson98]
S. Thomson, T. Narten. IPv6 Stateless Address Autoconguration, December 1998. RFC 2462
[Hinden02] [Narten98]
R. Hinden, E. Deering. IPv6 Addressing Architecture. RFC 2373, July 1998 T. Narten, E. Nordmark, W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). December 1998, RFC 2461
[Narten01]
T. Narten, R. Draves, Privacy Extensions for Stateless Address Autoconguration in IPv6, January 2001, RFC 3041
[Dierks99] [Atkinson95] [Tanenbaum02] [Kent98a]
T. Dierks, C. Allen, The TLS Protocol, Version 1.0, RCF 2246, January 1999 R. Atkinson. IP Authentication Header, RFC 1826, July 1995. A. Tanenbaum, Computer Networks, Prentice Hall Publishing, 4th Ed. August 2002 S. Kent, R. Atkinson. Security Architecture for the Internet Protocol. RFC 2401, November 1998.
117
Bibliografa y referencias
[Kent98b] [Kent98c] S. Kent, R. Atkinson. IP Authentication Header. RFC 2402, November 1998. S. Kent, R. Atkinson. IP Encapsulating Security Payload (ESP). RFC 2406, November 1998. [Bradner97] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997, RFC 2119 [Reynolds94] J. Reynolds, J. Postel. Assigned numbers, STD 2, RFC 1700, October 1994. As como: http://www.iana.org/numbers.html [Durham00] [Cheshire02] D. Durham, J. Boyle, R. Cohen. The COPS protocol. January 2000, RFC 2748 S. Chesire, B. Aboba, Dynamic Conguration of IPv4 Link-local Addresses. Internet Draft, IETF, August 2002, Work in progress [Rekhter96] [Bagnulo01] Y. Rekhter et. Al, Address Allocation for Private Internets, February 1996, RFC 1918 M. Bagnulo, A. Garca-Martnez, D. Larrabeiti, A. Azcorra, A QoS-Driven ISP Selection Mechanism for IPv6 Multi-Homed Sites, IST-1999-20393 [Mauro01] [Perkins97] D. Mauro, K. Schmidt. Essential SNMP, OReilly, 1.a Ed, 2001 D. Perkins, E. McGinnis,Understanding SNMP MIBs, Upper Saddle River : PrenticeHall , 1997 [Howes99] T. Howes, M. Smith, G. Good,Understanding and deploying LDAP directory services, McMillan Technical Publishing, 1.a Ed, 1999 [Howard98] L. Howard, An approach for using LDAP as a Network Information Service. March 1998, RFC 2307 [Levine95] [Rodrguez02] J. Levine, T. Mason, D. Brown. Lex and yacc, OReilly, 1995, 2.a Ed J.F. Rodrguez Hervella. Implementaci n de una soluci n Multi-Homing para IPv6, o o Estudio Tecnol gico, Ingeniera Telem tica, Universidad Carlos III de Madrid, 2002 o a [vanMeer01] R. van Meer, G. Lo Biondo, LDAP ImplementationHOWTO,
http://www.tldp.org/HOWTO/LDAP-Implementation-HOWTO/index.html, March 2001 [Brown01] [Frediksson01] P. Brown, Secure LDAP for Solaris, www.bolthole.com/solaris/LDAP.html , 2001 T. Fredriksson, OpenLDAP, OpenSSL, SASL and KerberosV,
http://www.bayour.com/LDAPv3-HOWTO.html, 2001 [Cooke02] J.L. Cooke A call for an Attack on MD5, http://www.certainkey.com/dnet/ , 2002
118
Parte V Ap ndices e
119
Ap ndice A e Glosario
ARP Address Resolution Protocol Protocolo utilizado para poder resolver la correspondencia de las direcciones de enlace y de red de un determinado interfaz. Ya que este protocolo funciona sin ningun tipo de autenticaci n, y las o direcciones tanto de interfaz como de red son f cilmente manipulables, en muchas ocasiones resula ta en una posible vulnerabilidad dentro de una red, donde se puede dar, entre otros, un ataque de man-in-the-middle (suplantaci n de cada una de las partes de la comunicacion por un tercero que, o conceptualmente, se encuentra entre ambas). Actualmente, en IPv6, su misi n la desarrolla otro mecanismo, el Neighbor Discovery. o ASN.1 Abstract Syntax Notation (version 1) Reglas sint cticas a partir de las cuales se genero el formato de descripci n de las MIB, junto con a o SMI. COPS Common Open Policy Service Protocolo dise ado para realizar gesti n de polticas, con alta abilidad y capacidad de replicacion n o de servidores, y que es, adem s, muy general. a DAS Default Address Selection Algoritmo para realizar la selecci n optima de las direcciones de origen y destino en una comunicao ci n IPv6. o DoS Denial of Service Tipo de ataque malicioso para conseguir la negacion del servicio a un equipo o a una red. DHCP Dynamic Host Conguration Protocol
120
Ap ndice A. Glosario e
Protocolo para la conguraci n autom tica de la informaci n de red necesaria para los equipos. Puede o a o incluir direcciones IP, nombres, dotar de informacion dependiente del origen y usarse como recopilatorio de otro tipo de informaci n. o DNS Domain Name Service Con DNS se denominan a los servidores y al protocolo que solucionan la vinculaci on entre nombres para un servicio (como los que parecen en una URL), y una posible direcci on IP para ese servicio. Hash Algoritmo usado com nmente en seguridad que se utiliza para realizar un ?resumen? a partir de un u cierto conjunto de datos. El inter s radica que estos algoritmos son disenados, en principio, para que e no se pueda hallar una relaci n entre la salida (el resumen) y la entrada, con el n de poder realizar o una autenticaci n de la informaci n (rma digital), o evitar el almacenamiento y/o transmision en o o limpio de la informaci n de autenticaci n sensible (por ejemplo, las claves en la red). o o IPSec Internet Protocol SECurity Conjunto de mecanismos y algoritmos para garantizar tanto la autenticaci on de los integrantes de la comunicaci n como de la privacidad de los datos en ella trasmitidos. o IPv4 mapped Dentro de las soluciones de transicion para poder conectar redes IP de distintas versiones, las direcciones IPv4 mapped son una representacion las direcciones IPv4 como direcciones v lidas a IPv6. ISO International Standarization Organization Organismo estadounidense que se encarga de la generacion de normas. Ver ITU. ISP Internet Service Provider El proveedor de acceso es el organismo o entidad que se encarga de otorgar conectividad a una red, ya sea entre redes de una empresa o a Internet. ITU International Telecommunications Union Organismo de normalizaci n (uni n del CCIR y CCITT) que, dentro del tema de inter s de este o o e trabajo, junto con ISO regula el uso de los OID utilizados en SNMP. LDAP Lightweight Directory Access Protocol Protocolo de acceso a un directorio de informacion en el que prima la simplicidad, basado en X.500. Est muy extendido, y actualmente llega a sustituir en algunos entornos a las yellow pages (un servicio a de informaci n de red) de UNIX. o MIB Management Information Base Descripci n del conjunto de datos propios de la gestion, ya sea para el agente a gestionar como el o gestor. Se suelen describir por ASN y SMI. No corresponde a la informaci on que se gestiona.
121
Ap ndice A. Glosario e
Multihoming Caso especial de pertenecer a varias redes simult neamente. Puede implicar varias posibilia dades de encaminar un paquete a trav s de distintos ISP, por ejemplo. En un caso pr ctico, uno de los e a ISP puede dar un tr co best effort, mientras que el otro se utiliza para tr co con calidad de servicio, a a y se utiliza cada uno seg n las necesidades del momento. u NIS Network Information Service Es el uso de un directorio de informacion de utilidad para una determinada red, como por ejemplo, las correspondencias entre nombre de usuario y el hash de la clave dentro de esa red. OID Object IDentier Valor unvoco (y por tanto identicador) de un elemento dentro del arbol de organizaci n obtenido o a trav s de un organismo de normalizaci n. Asimismo, se aplica a los elementos gestionados dene o tro de la descripci n de una MIB, que est n organizados jer rquicamente y contenidos en el arbol o a a anteriormente comentado. QoS Quality of Service Calidad de servicio. Por esto suele entenderse el mantener un sistema capaz de garantizar ciertas capacidades (cierto ancho de banda mnimo, por ejemplo), y normalmente se pretende poder otorgar a usuarios especcos, y tambi n a aplicaciones concretas. e SNMP Simple Network Management Protocol Protocolo de gesti n remota sencillo, que utiliza una organizacion jer rquica de la informaci n por o a o medio de identicadores unvocos asignados por la ITU y la ISO. TLS Transport Layer Security Mecanismo de seguridad que se integra de forma transparente encima del nivel de transporte, proporcionando tanto autenticaci n como privacidad e integridad. o
122
Ap ndice B e SNMP MIB para DAS
Contenido del fichero das.mib DASMIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, experimental, NOTIFICATION-TYPE, OBJECT-IDENTITY FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION FROM SNMPv2-TC Ipv6Address FROM IPV6-TC; dasMIB MODULE-IDENTITY LAST-UPDATED "10000000" ORGANIZATION "Universidad Carlos III de Madrid" CONTACT-INFO " Hctor Cordobs e e hcordobes@airtel.net" DESCRIPTION "The MIB module for DAS management" ::= { experimental 200 }
dasMIBObjects OBJECT IDENTIFIER ::= { dasMIB 1 }
123
Ap ndice B. SNMP MIB para DAS e
-- textual conventions DisplayString ::= OCTET STRING -- This data type is used to model textual information taken -- from the NVT ASCII character set. ---SIZE (0..255) OCTET STRING For many --Ipv6Address ::= -- This data type is used to model IPv6 addresses. By convention, objects -- with this syntax are declared as having
-- types of media, this will be in a binary representation. -- For example, an ethernet address would be represented as -- a string of 6 octets. -- Definitions start hre dasTable OBJECT-TYPE SYNTAX SEQUENCE OF DasEntry ACCESS not-accessible STATUS current DESCRIPTION "A list of DAS entries. The number of entries is given by the value of dasNumber." ::= { dasMIBObjects 1 } dasNumber OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "An integer number equal to the number of entries for de DAS policy table." ::= { dasMIBObjects 2 } dasEntry OBJECT-TYPE
124

SYNTAX DasEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A DAS entry containing objects at the DAS management table." INDEX { dasIndex } ::= { dasTable 1 } DasEntry ::= SEQUENCE { dasIndex INTEGER, dasPrefixAddress Ipv6Address, dasPrefixLength INTEGER, dasPrecedence INTEGER, dasLabel INTEGER } dasIndex OBJECT-TYPE SYNTAX STATUS INTEGER read-only current "An unique value for each entry. Its value ranges from 1 and the value of dasNumber." ::= { dasEntry 1 } dasPrefixAddress OBJECT-TYPE SYNTAX STATUS Ipv6Address read-only current "An IPv6 address expressed as OCTET STRING." MAX-ACCESS DESCRIPTION MAX-ACCESS DESCRIPTION
125
::= { dasEntry 2 }
dasPrefixLength OBJECT-TYPE SYNTAX STATUS INTEGER(0..128) read-only current "The lenght in bits of the net mask." ::= { dasEntry 3 } dasPrecedence OBJECT-TYPE SYNTAX STATUS INTEGER read-only current "The precedence level." ::= { dasEntry 4 } dasLabel OBJECT-TYPE SYNTAX STATUS INTEGER read-only current "An optional label." ::= { dasEntry 5 } --Notifications dasNotifications OBJECT IDENTIFIER ::= { dasMIB 2 } dasNotificationsPrefix OBJECT IDENTIFIER ::= { dasNotifications 0} dasChange NOTIFICATION-TYPE --OBJECTS { -dasDescr MAX-ACCESS DESCRIPTION MAX-ACCESS DESCRIPTION MAX-ACCESS DESCRIPTION
126

-}
STATUS current DESCRIPTION "This notification implies that there has been a change in the policy table that must be followed by the host." ::= {dasNotificationsPrefix 1 } --conformance information dasConformance OBJECT IDENTIFIER ::= { dasMIB 3 } dasCompliances OBJECT IDENTIFIER ::= { dasConformance 1 } dasGroups OBJECT IDENTIFIER ::= { dasConformance 2 }
--compliance statements dasCompliance MODULE-COMPLIANCE status current DESCRIPTION "The compliance statement for SNMPv2 entities which implement DAS MIB." MODULE MANDATORY-GROUPS { dasGeneralGroup, dasNotificationGroup } ::= { dasCompliances 1 } dasGeneralGroup OBJECT-GROUP OBJECTS { dasNumber, dasTable, dasEntry, dasIndex, dasPrefixAddress, dasPrefixLength, dasPrecedence, dasLabel} STATUS current DESCRIPTION
127

"The DAS group of objects providing for basic management of IPv6 entities." ::= { dasGroups 1 } dasNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { dasChange } STATUS current DESCRIPTION "The notification an entity is required to implement." ::= { dasGroups 2 } END
128
Ap ndice C e Manuales de instalaci n, conguraci n y o o uso
En este ap ndice se documentar el funcionamiento de los desarrollos aqu propuestos, para que puedan e a ser utilizados por cualquier usuario, administrador o desarrollador. Cuando sea correspondiente, se mostrar tambi n el proceso de instalaci n de utilidades adicionales o a e o herramientas que sean necesarias para el funcionamiento.
C.1.
Implementaci n de DHCPv6 o
Esta implementaci n es un par de programas (servidor y cliente), que funcionan bajo FreeBSD 4.4 o o superior. El sistema est generado ntegramente en C. No obstante, se han utilizado herramientas de an lisis l xico a a e - sint ctico auxiliares para generar analizadores en C que ser n posteriormente compilados y a adidos al a a n programa. Todas las herramientas necesarias, el compilador de C gcc (GNU C Compiler), el analizador l xico lex, e y el analizador sint ctico yacc, (Yet Another Compiler-Compiler) se encuentran disponibles en cualquier a instalaci n est ndar de FreeBSD en la que se haya optado por la instalacion de los paquetes de desarrollo. o a
129
Ap ndice C. Manuales de instalaci n, conguraci n y uso e o o
C.1.1. Compilaci n e instalaci n de los programas o o

A partir de la situaci n en la que el directorio contiene todos los archivos fuente descomprimidos, casi o todos los programas que se distribuyen bajo licencias libres incorporan una serie de scripts que facilitan la compilaci n. o En el caso del proyecto KAME ocurre as, siendo necesario ejecutar primeramente la comprobacion del software disponible: avispa:kame/kame/dhcp6# ./configure Se generar n entonces los cheros correspondientes, especcos para el equipo en el que se est compia e lando. Posteriormente, solo hace falta aplicar: avispa:/kame/kame/dhcp6# make As, si todo ha transcurrido correctamente, se habr n generado dos ejecutables, dhcp6s y dhcp6c, es a decir, el servidor y el cliente para DHCPv6. Para instalar los programas en el sistema, habr que ejecutar, como root: a avispa:/kame/kame/dhcp6# make install De esta manera, estar n disponibles tantos los ejecutables como los manuales de uso y conguraci on de a los programas anteriores, con el a adido de que los cheros han sido copiados con los permisos de acceso n correspondientes. Las p ginas del manual corresponden a dhcp6s, dhcp6c, dhcp6s.conf y dhcp6c.conf. a
C.1.2. Conguraci n de los programas o

Ambos programas sit an sus cheros de conguraci n bajo el directorio /usr/local/v6/etc/. Esta locau o lizaci n se especica en el c digo fuente. Sin embargo, se puede especicar un chero distinto para cada o o ejecuci n. o Los formatos de conguraci n fueron especicados en las p ginas 77 y 74 para el servidor y el cliente, o a respectivamente, por lo que no se repetir n aqu. a
130
C.1.3. Ejecuci n de los programas o

Los dos programas funcionan como utilidades residentes, de tal manera que la informaci on de avisos y errores es dirigida a la salida de error est ndar (STDERR). Sin embargo este par metro es modicable. a a Las llamadas a los ejecutables utilizan tres opciones y un par metro obligatorio: a
-f Esta opci n consigue que la salida de depuracion se dirija a la salida est ndar. Adem s, el programa o a a no pasar a ejecutarse de fondo. a -d Esta opci n implica que se ver informaci n de depuraci n. o a o o -D Con esta opci n se indica que los mensajes de depuracion ser exhaustiva (con -d s lo aparecen los o a o avisos y los errores). <nombre del interfaz> Este es el unico par metro obligatorio. A diferencia de GNU / Linux, el nombre de cada interfaz es a dependiente del controlador del dispositivo: por ejemplo, para una tarjeta Realtek, rl0.
La lnea de ejecuci n mnima y habitual para el servidor sera: o avispa# dhcp6s rl0 Y para el cliente: avispa# dhcp6c rl0
C.2.
Implementaci n de SNMP o
C.2.1. Instalaci n o
Para el desarrollo de esta implementacion se ha contado con la versi n 2.1.10 de scotty, ya que pese a o no ser la ultima versi n, los programas son ligeramente m s sencillos. Se puede obtener el paquete Debian o a con todo lo necesario en http://matrix.it.uc3m.es/ cjbc/software.html.
131

Las llamadas a los programas en scotty se realizan por medio de la ejecuci on del int rprete, indicando e el nombre del script y las opciones correspondientes. Por ejemplo, para ejecutar un programa ejemplo.sct: bacterio:# scotty ejemplo.sct opcion1 Sin embargo, la shell permite realizar llamadas a int rpretes si existe el comando al inicio del script, de e forma que se puede realizar la llamada directamente al script, siempre que tenga los permisos adecuados y el comando est correctamente escrito (y corresponda a la localizacion exacta de este). e Por ejemplo, si el int rprete est situado en /usr/bin/scotty, y el chero comienza con e a #!/usr/bin/scotty entonces basta con escribir bacterio# ./ejemplo.sct opcion1 En las aplicaciones provistas se pueden utilizar ambos m todos. e La aplicaci n est formada por los cheros: agente.sct,gestor.sct, cong.das y das.mib. Smplemente o a es necesario contar con los cuatro cheros en un mismo directorio.
C.2.2. Conguraci n o
Existe un unico chero de conguraci n, cong.das. En el se especican las entradas por omision y por o equipo. Las entradas de un nuevo equipo est n indicadas por un signo de suma (+), que indica el nombre a de un equipo. La primera entrada puede tener cualquier nombre, y ser considerada la entrada por omisi n a o (por lo que se recomiendan nombres como omision o default). Un ejemplo sera el siguiente:
default ::ffff:0:0:0:0 96 10 1 2001:aaaa:: 32 20 2 +kame ::aaaa:0:0:0:0 96 10 1
132

Y as se habr n especicado dos entradas para default y una para el equipo kame. a
C.2.3. Ejecuci n o
Unicamente es necesario lanzar los scripts con las opciones adecuadas. Para el agente, se puede indicar un puerto o tomar el n mero 2000, que est incorporado en el c digo. Por ejemplo, para arrancar en el a u a o puerto 1200: bacterio:# ./agente.sct 1200 Para el caso del gestor se fuerza a especicar tanto el equipo agente como el puerto correspondiente. Si no se indica nada m s, se localiza la conguraci n por omisi n. Por ejemplo, si el equipo es snmp.uc3m.es, a o o y el agente estuviera ligado al puerto 1200: bacterio:# ./gestor.sct snmp.uc3m.es 1200 Si adem s, se desea la conguraci n de un equipo en concreto, por ejemplo avispa, el comando sera: a o bacterio:# ./gestor.sct snmp.uc3m.es 1200 avispa Si no se encontrara una conguraci n para este equipo, se tomara la conguraci n com n. o o u
C.3.
Implementaci n del servidor LDAP o
El caso del servidor LDAP es muy dependiente de la arquitectura donde se instale, ya que cada servidor, incluso cada versi n del servidor, puede ser congurada e instalada en cheros distintos. Por tanto, aqu se o va a presentar la puesta en marcha con un servidor y una estructura concretos. Particularmente, se ha elegido el servidor OpenLDAP en un sistema Debian Woody GNU / Linux, por ser la ultima versi n estable de la o distribuci n que se caracteriza por estar basada unicamente en programas libres. o Se partir de la situaci n en que el sistema ya est congurado en cuanto a red, m dulos de n cleo. . . , a o a o u de manera que es completamente funcional. Para el cliente, unicamente es necesario tener una instalacion correcta del int rprete Perl, junto con sus e biblitecas correspondientes para LDAP y SSL.
133
C.3.1. Instalaci n o
La implementaci n contempla dos elementos, el propio servidor y el uso de una capa de seguridad. En o Debian, estas dos herramientas se instalan con facilidad gracias al uso de paquetes completos y la aplicaci on de instalaci n y pre-conguraci n caracterstica de Debian apt-get. o o Siendo root, el comando a ejecutar es: bacterio:# apt-get install slapd Por s solo instalar todos los dem s paquetes asociados que incluyan funciones biblioteca o utilidades a a que sean necesarias o muy recomendables para el uso de OpenLDAP, como el uso de TSL y gesti on de entradas. Tambi n se instalar n los cheros de conguraci n bajo el directorio /etc/ldap/, y solicitar los e a o a nombres b sicos para iniciar el servicio de directorio: el nombre distinguido base (por ejemplo, dn=it, a dn=uc3m, dn=es, as como la entrada que ser el administrador y su clave correspondiente. a Para la generaci n de los certicados y las claves RSA, se utiliza en paquete openSSL, que incluye las o herramientas necesarias. bacterio:# apt-get install openssl A partir de este punto, s lo resta realizar el enlace simb lico del script CA.pl para que se pueda utilizar o o desde cualquier directorio. bacterio:# ln /usr/lib/ssl/misc/CA.pl /usr/sbin/CA.pl De esta forma estar instalado todo el software necesario para poder usar el servidor de LDAP. a Para el cliente: bacterio:# apt-get install perl libnet-ldap-perl libio-socket-ssl-perl
Y no se necesitar m s que el script proporcionado. a a
134
C.3.2. Conguraci n o
La conguraci n de OpenLDAP se puede dividir en dos apartados, la conguracion del schema LDAP o permitido en el servidor, y los par metros de funcionamiento (acceso, cheros, identicador del administraa dor. . . ). Para a adir una nueva especicaci n del schema, no hay m s que a adir el chero con la informaci n n o a n o o n correspondiente, escrito en el formato LDAPv3 1 , al directorio /etc/ldap/schema/. S lo es necesario a adir una entrada con la localizaci n de este chero a la conguraci n de funcionamiento. Para ello, no hay m s o o a que a adir la siguiente lnea al comienzo de slapd.conf: n include /etc/ldap/schema/das.schema
Como ya se vi en el desarrollo de LDAP (p gina 103), s lo resta aplicar los niveles de acceso (ACL), o a o que son una mera enumeraci n de objetos y capacidades de acceso por parte de usuarios. o La conguraci n del cliente de muestra es sencilla. No hay m s que editar el propio script, y en el area o a indicada aportar los datos correspondientes, cuidando respetar las comillas. Por ejemplo:
####### Configuracin de acceso al servidor LDAP ################ o # # Donde estn almacenados los objetos para DAS a $bdn = "ou=equipos, o=Universidad Carlos III de Madrid, c=34";
# Equipo donde conectar $hostname="ldap.proyecto"; # Puerto del equipo (ldaps:/// suele ser el 636) $port=636; ####### Fin de la configuracin ################################# o
C.3.3. Generaci n de una CA y su certicado o

El script CA.pl aporta una serie de conguraciones por defecto, como caducidad de un a no y los nombres por omisi n de los cheros que se generar n. Adem s, se puede aplicar un chero de conguracion, con una o a a
1
Para una especicaci n completa de este formato, es muy util la descripci n de [Howes99] o o
135

mayor exibilidad y potencia, pero en principio los resultados obtenidos con el script son buenos. Para este desarrollo se han tomado los siguientes par metros: a
La caducidad ser de 356 das. a El algoritmo para realizar res menes ser SHA1. u a La clave privada RSA tendr 1024 bits. a Se utilizar una frase clave para almacenar la clave privada a
Para generar el certicado raz como autoridad certicadora, se siguio la siguiente secuencia. Cabe notar que la frase clave no se visualiza.
bacterio:/var/ssl# CA.pl -newca CA certificate filename (or enter to create) Making CA certificate ... Using configuration from /etc/openssl.cnf Generating a 1024 bit RSA private key ......++++++ .......++++++ writing new private key to /var/ssl/private/cakey.pem Enter PEM pass phrase: Verifying password - Enter PEM pass phrase: ----You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ., the field will be left blank. ----Country Name (2 letter code) [FJ]:ES State or Province Name (full name) [Fiji]:Madrid Locality Name (eg, city) [Suva]:Legans e Organization Name (eg, company) [SOPAC]:Proyecto Fin de Carrera DAS Organizational Unit Name (eg, section) [ITU]:Autoridad Certificadora Common Name (eg, YOUR name) []:Hctor Cordobs de la Calle e e Email Address []:hcordobes@airtel.net
136

Esta operaci n ha generado tanto la clave privada para la entidad certicador como el certicado o de la autoridad certicadora. Estos cheros se encuentran en el directorio ./demoCA, bajo los nombres private/cakey.pem y cacert.pem, respectivamente. Ambos son cheros binarios que se han codicado en base64 para no tener problemas con el uso, envo y almacenamiento en sistemas con distintos codicaciones de idioma.
C.3.4. Generaci n de un certicado para el servidor o

Esta parte es m s delicada que la anterior, pues hay algunos elementos de este certicado que tomar el a a cliente para comprobar la autenticidad del servidor. En esta ocasi n se emplear el ejecutable principal de OpenSSL sin pasar por el script. o a Primero hay que generar una petici n de certicado que tedr que rmar la CA. Esto se hace en la o a siguiente secuencia. Por supuesto, la frase clave es la que el solicitante del certicado quiere, cuya clave privada no tiene que ser conocida por la CA. A veces se imponen requerimientos en las entradas del nuevo certicado, como la coincidencia del campo correspondiente al pas con el correspondiente a la CA, pero todo esto es congurable.
bacterio:/var/ssl/certificados# openssl req -new > newreq.pem Using configuration from /usr/lib/ssl/openssl.cnf Generating a 1024 bit RSA private key ...................++++++ .............................................++++++ writing new private key to privkey.pem Enter PEM pass phrase: Verifying password - Enter PEM pass phrase: ----You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ., the field will be left blank. ----Country Name (2 letter code) [AU]:ES State or Province Name (full name) [Some-State]:Madrid Locality Name (eg, city) []:Legans e
137

Organization Name (eg, company) [Internet Widgits Pty Ltd]:Proyecto DAS Organizational Unit Name (eg, section) []:El certificado Common Name (eg, YOUR name) []:ldap.proyecto Email Address []:hcordobes@airtel.net
Esto genera una solicitud y una clave privada, en las mismas condiciones que se gener o el certicado raz de la CA. Los cheros son llamados newreq.pem y privkey.pem. En este punto es muy importante subrayar una entrada en particular de este certicado. El atributo Common Name ser la entrada que utilizar el cliente para identicar al servidor, por lo que debe coincidir a a con el nombre en la red. Es decir, si por ejemplo el cliente intenta conectarse a ldap.uc3m.es, esta entrada tendra que ser ldap.uc3m.es. El nombre utilizado en este ejemplo no es el m s correcto, pero como a a muestra es perfectamente v lido 2 . Si esta entrada no coincide, la mayora de los clientes rehusar n la a conexi n. o Ahora s lo es necesario que alguien realice la rma. Eso es sencillo puesto que ya se es una autoridad o certicadora. Para ello, el script toma por defecto el archivo newreq.pem:
bacterio:/var/ssl/certificados# CA.pl -signreq Using configuration from /etc/openssl.cnf Enter PEM pass phrase: Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryName stateOrProvinceName localityName organizationName commonName emailAddress :PRINTABLE:ES :PRINTABLE:Madrid :T61STRING:Legan\0xFFFFFFE9s :PRINTABLE:Proyecto DAS :PRINTABLE:ldap.proyecto :IA5STRING:hcordobes@airtel.net
organizationalUnitName:PRINTABLE:El certificado
Certificate is to be certified until Jan 14 23:47:05 2004 GMT (365 days) Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries
En el caso de no contar con un servidor DNS, para que pueda ser utilizado no hay m s que incorporar la entrada a correspondiente en el chero /etc/hosts.
2
138

Data Base Updated Signed certificate is in newcert.pem
As, ya se ha conseguido el certicado con la rma de la CA, disponible para ser usado en cualquier aplicaci n que implemente SSL o TLS. Como cuestion aparte, se toma nota de los certicados expedidos, o para que puedan ser revocados si es necesario, aunque este tema excede de las intenciones de esta memoria. Como ultimo paso, la mayora de las apliaciones, desgraciadamente, requieren que la clave privada no est cifrada cuando va a ser usada por el servidor. Para tener una versi on limpia de la clave, simplemente se e realiza:
$ openssl rsa -in privkey.pem -out server.key read RSA key Enter PEM pass phrase: writing RSA key
Por supuesto, la frase clave aqu es la que corresponde a la solicitud del certicado. Y el chero ser ver.key es el que ser necesario posteriormente. a
C.3.5. Implantaci n del certicado en LDAP o

Ya s lo resta incorporar el certicado al servidor, y el certicado raz al servidor y los clientes. o Para activar la opci n TLS en el servidor OpenLDAP, no hay m s que a adir las entradas correspono a n dientes al chero de conguraci n del ejecutable principal, /etc/ldap/slapd.conf: o
TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /etc/ldap/newcert.pem TLSCertificateKeyFile /etc/ldap/server.key TLSCACertificateFile /etc/ldap/CA/cacert.pem TLSVerifyClient 0
En los directorios mostrados hay que a adir los cheros indicados. La primera lnea indica qu tipo de n e seguridad se va a negociar en primer lugar, y como se pueden negociar otras posteriormente. La ultima opci n indica que no se va a requerir un certicado a los clientes. Activar esta opci on implica o que los clientes han de aceptar el envo de certicados, caracterstica que en principio no todos contemplan.
139
C.3.6. Fichero de conguraci n nal o

El aspecto nal del chero de conguracion puede ser como este. Se han recuadrado aquellas entradas que han sido necesarias para el desarrollo de DAS sobre LDAP.
# This is the main ldapd configuration file. See slapd.conf(5) for more # info on the configuration options. # Schema and objectClass definitions include include include include /etc/ldap/schema/core.schema /etc/ldap/schema/cosine.schema /etc/ldap/schema/nis.schema /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/das.schema
# Schema check allows for forcing entries to # match schemas for their objectClassess schemacheck on
# Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd.pid
# List of arguments that were passed to the server argsfile /var/run/slapd.args
# Where to store the replica logs replogfile /var/lib/ldap/replog
# Read slapd.conf(5) for possible values loglevel 0
140

# Entradas para la capa TLS# # TLS ENTRIES TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /etc/ldap/server.cert TLSCertificateKeyFile /etc/ldap/server.key TLSCACertificateFile /etc/ldap/CA/cacert.pem TLSVerifyClient 0 # No se autenticarn clientes con TLS a
####################################################################### # ldbm database definitions ####################################################################### # The backend type, ldbm, is the default standard database ldbm
# The base of your directory suffix "o=Universidad Carlos III de Madrid,c=34" rootdn "cn=admin,o=Universidad Carlos III de Madrid,c=34" rootpw {SSHA}7JgB+ZTUtqCkECpj2G45fccHWN9/eJLy # Where the database file are physically stored directory "/var/lib/ldap" # Indexing options index objectClass eq # Save the time that the entry gets modified lastmod on # The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below access to attribute=userPassword by dn="cn=admin,o=Universidad Carlos III de Madrid,c=34" write by anonymous auth by self write by * none
141

Configuracin de los niveles de acceso para DAS o access to dn="cn=default,ou=equipos,o=Universidad Carlos III de Madrid,c=34" by * read\\ access to attribute=dasTableEntry by dn=cn=admin,o=Universidad Carlos III de Madrid,c=34" write by anonymous auth by self read by * none
# The admin dn has full write access access to * by dn="cn=admin,o=Universidad Carlos III de Madrid,c=34" write by * read # For Netscape Roaming support, each user gets a roaming # profile for which they have write access to access to dn=".*,ou=Roaming,o=morsnet" by dn="cn=admin,o=Universidad Carlos III de Madrid,c=34" write by dnattr=owner write
C.3.7. Ejecuci n o
Ya s lo es necesario lanzar el servidor indicando que se desea usar una capa de seguridad: o bacterio:/var/ssl/certificados# slapd -h "ldaps:///" Como ultimo consejo con el servidor, ya que la clave privada se alojar en limpio, es correspondiente a otorgar los permisos pertinentes a los cheros sensibles, para evitar la lectura por parte de todos los usuarios excepto el administrador, y si es necesario por cuestiones de ejecuci on en alguans conguraciones, al usuario bajo el que se ejecute el servidor LAPD. Para usar el cliente de muestra que acompana el desarrollo, no hay m s que indicarle el equipo cuya a conguraci n se quiere conseguir, y en caso de ser distinto de default, la clave correspondiente. Por o ejemplo, para solicitar la conguracion mortadelo, con clave mortadelo, bastara con
hector@bacterio:$ ./clienteLDAP.pl mortadelo mortadelo
142

Cliente especificado: mortadelo. Realizando conexin a ldap.proyecto:636. o Activado TLS, certificado reconocido. Subject DN: /C=ES/ST=Madrid/L=Legan\xE9s/O=Proyecto DAS certificado/ OU=El certificado/CN=ldap.proyecto/Email=hcordobes@airtel.net Cifrado utilizado: DES-CBC3-SHA Realizando autorizacin (bind). o Recibida entrada: 2001::/16/10/2 Recibida entrada: ::ffff:0:0/96/40/4
C.4.
Generador de archivos de conguracion
Como complemento a las aplicaciones desarrolladas, se ha credo interesante la creaci n de una utilidad o que genere la informaci n necesaria para poder utilizar de manera sencilla las aplicaciones. o Para ello, se cuenta con el script en Perl congurador.pl, el cual, a partir de un archivo de conguraci on sencillo, consigue congurar el resto de aplicaciones. Para ello, se parte del archivo inicial, cong.das, en el cual se mantiene la conguraci on en el formato expresado para el agente SNMP. Esto es, varios bloques separados por un smbolo de suma, en los que la primera lnea especica el nombre del equipo, y las siguientes son las entradas de la tabla DAS. Por ejemplo:
default :: 0 50 5 +kame 2001:: 16 20 2 ::ffff:0:0 96 10 1
El script ha de ser congurado para su uso con LDAP. Ya que el servidor LDAP puede estar funcionando con otra implementaci n diferente a la aqu utilizada, se ha pensado que es mejor optar por una solucion o m s general, e implementar llamadas al servidor para la conguraci on. Para ello, hay que incorporar al a script la informaci n correspondiente: credenciales del administrador, DN base, as como la localizaci n o o del servidor. Todo ello est correctamente especicado al inicio del chero. a Una vez se tienen los dos archivos preparados como se necesita, solo resta ejecutar el script, indican do para qu protocolo se desea generar la informacion. Para SNMP y DHCPv6 se crear un archivo que e a
143

deber ser situado en el directorio apropiado. Para LDAP, se crear n las entradas correspondientes en el a a servidor, y estar listo para ser usado. a
144
Ap ndice D e Licencias y marcas
D.1.
Sobre las marcas registradas
En esta memoria de proyecto han aparecido distintas marcas. El hecho de que al lado de ellas aparezca bajo el registro de la propietario correspondiente. Por tanto en esta memoria se reconocen todas las marcas presentes en ella.
D.2.
Sobre el software utilizado
Para la elaboraci n de este trabajo se ha contado con distinitos programas y sistemas operativos, que o est n sujetos a distintas licencias. Como puede verse, se ha intentado mantener tanto como ha sido posible a el uso de programas libres, entendiendo libre por libertad de distribuci on y modicaci n, no la gratuidad o o la apertura del c digo. En cualquier caso, aquellos programas que no son imprescindibles para el desarrollo, o sino unicamente para las pruebas, si bien no son libres, son gratuitos, con lo que se puede mejorar muchsmo el coste nal del proyecto. En determinados informes, sobre todo aqu llos que provienen de empresas con claros intereses en la e venta de exclusivamente los derechos de uso de los programas que produce, se asegura que a largo plazo el uso del software libre resulta m s caro que el propietario. En este proyecto se intentar mostrar c mo esta a a o armaci n resulta falsa, siendo adem s, un claro benecio no unicamente para la instituci n o empresa que o a o utilice estos programas, sino en general para toda la sociedad, puesto que podr utilizar e incluso mejorar a
o no la indicaci n de marca registrada ( o
) no implica ni niega que estas marcas est n protegidas e
145
Ap ndice D. Licencias y marcas e

los logros aqu conseguidos. Claramente, el desarrollo de servidores implica que el sistema que les d apoyo ha de resultar estable. e El tiempo ha demostrado que las soluciones basadas en BSD y GNU/Linux han resultado ser mucho m s a estables que las correspondientes en entornos Windows de Microsoft,
1
sobre todo aquellos que requieren
un funcionamiento continuado y una alta carga. Por mostrar un ejemplo, los sistemas de cheros ReiserFS y algo menos los ExtX (usados ampliamente en GNU / Linux) han resultado ser mucho m s estables, cona ables y r pidos que el equivalente en el entorno profesional de Windows, el NTFS. Esto es, por supuesto, a un punto m s a favor de este tipo de soluciones. a Y un punto m s, puesto que, aparte de la reputacion que tienen tanto BSD como OpenLDAP en t rminos a e de exibilidad y estabilidad, se cuenta con todas las ventajas que aporta el modelo de software libre. Resumiendo, los programas utilizados est n protegidos por las licencias siguientes: a
GNU General Public License (GPL) 1. 2. 3. 4. S. O. GNU / Linux Scotty
A LTEX 2
Gq
FreeBSD License 1. S. O. FreeBSD 4.4
Licencias propias libres 1. 2. KAME (WIDE project) OpenLDAP
Licencias de libre uso acad mico e 1. LBE v2.8.2
D.3.
Sobre esta memoria
Esta memoria, incluyendo los gr cos presentes en ella, salvo los correspondientes a las capturas de a pantalla del programa LBE, puede ser distribuida en los t rminos de la FDL (Free Documentation License) e
1
http://www.computerpro-usa.com/linux.html
146

donde sea apropiado aplicarla. Copyright (c) 2003 H ctor Cordob s de la Calle e e Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.
D.4.
Descripci n de las licencias o
D.4.1. GNU General Public License

GNU GENERAL PUBLIC LICENSE
Version 2, June 1991 Copyright c 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free softwareto make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundations software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
147

To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each authors protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modied by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reect on the original authorsreputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyones free use or not licensed at all. The precise terms and conditions for copying, distribution and modication follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
1.
This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The Program, below, refers to any such program or work, and a work based on the Programmeans either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modications and/or translated into another language. (Hereinafter, translation is included without limitation in the term modication.) Each licensee is addressed as you. Activities other than copying, distribution and modication are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
148

2. You may copy and distribute verbatim copies of the Programs source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 3. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modied les to carry prominent notices stating that you changed the les and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modied program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modied work as a whole. If identiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 4. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the
149

following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface denition les, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 5. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 6. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 7. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients xercise e
150

of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 8. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 9. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 10. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program species a version number of this License which applies to it and any later version, you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 11. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this.
151

Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 12. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND / OR OTHER PARTIES PROVIDE THE PROGRAM AS ISWITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 13. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
D.4.2. FreeBSD
Copyright 1994-2002 FreeBSD, Inc. All rights reserved. Redistribution and use in source and binary forms, with or without modication, are permitted provided that the following conditions are met:
1.
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE FREEBSD PROJECT AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
152

MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD PROJECT OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The views and conclusions contained in the software and documentation are those of the authors and should not be interpreted as representing ofcial policies, either expressed or implied, of the FreeBSD Project or FreeBSD, Inc.
D.4.3. KAME
Copyright c 1998 and 1999 WIDE Project. All rights reserved. Redistribution and use in source and binary forms, with or without modication, are permitted provided that the following conditions are met:
1.
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3.
Neither the name of the project nor the names of its contributors may be used to endorse or promote products derived from this software without specic prior written permission.
THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
153
D.4.4. GNU Free Documentation License

GNU Free Documentation License Version 1.2, November 2002 Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
PREAMBLE
The purpose of this License is to make a manual, textbook, or other functional and useful document freein the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modications made by others. This License is a kind of copyleft, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The Document, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as you. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law. A Modied Version.of the Document means any work containing the Document or a portion of it, either
154

copied verbatim, or with modications and/or translated into another language. A Secondary Sectionis a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Documents overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The Invariant Sections.are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not t the above denition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The Cover Texts.are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A Transparentcopy of the Document means a machine-readable copy, represented in a format whose specication is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent le format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modication by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not Transparentis called Opaque. Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modication. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The Title Pagemeans, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, Title Pagemeans the text near the most prominent appearance of the works title, preceding the beginning of the body of the text.
155

A section Entitled XYZmeans a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specic section name mentioned below, such as Acknowledgements, Dedications, Endorsements, or History.) To Preserve the Title.of such a section when you modify the Document means that it remains a section Entitled XYZ.according to this denition. The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.
VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies.
COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Documents license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to t legibly, you should put the rst ones listed (as many as t reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either
156

include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
MODIFICATIONS
You may copy and distribute a Modied Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modied Version under precisely this License, with the Modied Version lling the role of the Document, thus licensing distribution and modication of the Modied Version to whoever possesses a copy of it. In addition, you must do these things in the Modied Version:
1.
Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.
2.
List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modications in the Modied Version, together with at least ve of the principal authors of the Document (all of its principal authors, if it has fewer than ve), unless they release you from this requirement.
3. 4. 5. 6.
State on the Title page the name of the publisher of the Modied Version, as the publisher. Preserve all the copyright notices of the Document. Add an appropriate copyright notice for your modications adjacent to the other copyright notices. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modied Version under the terms of this License, in the form shown in the Addendum below.
7.
Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Documents license notice.
8.
Include an unaltered copy of this License.
157

9. Preserve the section Entitled History, Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modied Version as given on the Title Page. If there is no section Entitled Historyin the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modied Version as stated in the previous sentence. 10. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the Historysection. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. 11. For any section Entitled Acknowledgements.or Dedications, Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. 12. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. 13. Delete any section Entitled Endorsements. Such a section may not be included in the Modied Version. 14. Do not retitle any existing section to be Entitled Endorsements.or to conict in title with any Invariant Section. 15. Preserve any Warranty Disclaimers.
If the Modied Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modied Versions license notice. These titles must be distinct from any other section titles. You may add a section Entitled Endorsements, provided it contains nothing but endorsements of your Modied Version by various partiesfor example, statements of peer review or that the text has been approved by an organization as the authoritative denition of a standard. You may add a passage of up to ve words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modied Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
158

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modied Version.
COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms dened in section 4 above for modied versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodied, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections Entitled Historyin the various original documents, forming one section Entitled History; likewise combine any sections Entitled Acknowledgements, and any sections Entitled Dedications. You must delete all sections Entitled Endorsements.
COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an aggregateif the copyright
159

resulting from the compilation is not used to limit the legal rights of the compilations users beyond what the individual works permit. When the Document is included an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Documents Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
TRANSLATION
Translation is considered a kind of modication, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warrany Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail. If a section in the Document is Entitled Acknowledgements, Dedications, or History, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
160
Ap ndice E e Contenido del CD

Memoria /memoria/ Implementaci n DHCPv6 o Fuentes compilables: /codigo/dhcp6/ Implementaci n SNMP o Scripts, cheros de conguraci n y MIB: /codigo/snmp/ o Implementaci n LDAP o Schema: /codigo/ldap/schema/ Ejemplo de slapd.conf: /codigo/ldap/cong/ Cliente: /codigo/ldap/cliente/ Congurador /codigo/congurador/
161
Parte VI Presupuesto
162
Presupuesto
Para el presente presupuesto se tomar n los datos aportados por el Colegio Ocial de Ingenieros de a Telecomunicaci n, donde se estipulan los honorarios de trabajo para un ingeniero como 60/h en horario o habitual, y 66/h en horario extraordinario. Para la contabilidad mensual, se tomar n meses de 20 das a h biles, y un horario de 7 horas por da. a
Coste de Recursos Humanos

Documentaci n y formaci n previa o o
Concepto B squeda de informaci n u o Formaci n en herramientas o Subtotal: Cantidad 40h 40h Valor unitario 60 60 Total 2400 2400 4800
Estructuraci n del proyecto o

Concepto An lisis de entorno a Subtotal: Cantidad 10h Valor unitario 60 Total 600 600
163
Programaci n de software o
Concepto DHCPv6, horario habitual DHCPv6, horario extraordinario SNMP, horario habitual LDAP, horario habitual LDAP, horario extraordinario Subtotal: Cantidad 3m (60d, 420h) 100h 1m (20d, 140h) 1m (20d, 140h) 10h Valor unitario 60 66 60 60 66 Total 25200 6600 8400 8400 660 49260
Generaci n de memoria de proyecto o

Concepto Estructura Escritura Subtotal: Cantidad 10h 100h Valor unitario 60 60 Total 600 6000 6600
Total de Recursos Humanos

Concepto Documentaci n y formaci n o o Estructuraci n o Programaci n o Memoria Total RRHH Total 4800 600 49260 6600 61260
164
Material
Concepto Hardware PC gama media Software SO Debian GNU/Linux SO FreeBSD Tlc/Scotty OpenLDAP Gq SNAP KAME Subtotal:
Cantidad 2 1 1 1 1 1 1 1
Valor unitario 800 0 0 0 0 0 0 0
Total 1600 0 0 0 0 0 0 0 1600
A LTEX 2
Ejecuci n material o
Concepto Recursos Humanos Material Total ejecuci n material o Total 61260 1600 62860
165
Total
Los honarios del ingeniero proyectista se calcular n sobre el total de ejecuci n material. Como excede a o de 30000, se aplicar un factor de correcci n de 0,6 sobre el 7 % correspondiente. a o Concepto Ejecuci n material o Honorarios Total presupuesto de contrata I.V.A. 16 % Total Total 62860 2640 65500 10480 75980
El presupuesto asciende a SETENTA Y CINCO MIL NOVECIENTOS OCHENTA EUROS.
El ingeniero proyectista
H ctor Cordob s de la Calle e e Legan s, 23 de Enero de 2003 e
166

Analisis e Implementacion de Mecanismos para La Gestion Del Algoritmo Selector de Direcciones Por Omision en IPv6

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Analisis e Implementacion de Mecanismos para La Gestion Del Algoritmo Selector de Direcciones Por Omision en IPv6

Uploaded by

Copyright:

Available Formats

Proyecto Fin de Carrera An lisis e Implementaci n de Mecanismos a o para la Gesti n del Algoritmo Selector de Direcciones o por Omisi n en IPv6 o

Proyecto n de carrera - H ctor Cordob s de la Calle e e

1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

II An lisis de los mecanismos candidatos a

4.1. Los problemas de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1.1. Funciones resumen (hash ) . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4

III Implementaci n de mecanismos o

8.1. Sobre las implementaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 8.2. Escenarios de los mecanismos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 9. DHCPv6 67

12. Conclusiones nales

12.1. Sobre los resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Proyecto n de carrera - H ctor Cordob s de la Calle e e

A. Glosario B. SNMP MIB para DAS C. Manuales de instalaci n, conguraci n y uso o o

Proyecto n de carrera - H ctor Cordob s de la Calle e e

Indice general E. Contenido del CD 161

Proyecto n de carrera - H ctor Cordob s de la Calle e e

Captulo 1 Introducci n al proyecto o

Proyecto n de carrera - H ctor Cordob s de la Calle e e

Captulo 2 El algoritmo DAS

Captulo 2. El algoritmo DAS

Proyecto n de carrera - H ctor Cordob s de la Calle e e

Captulo 2. El algoritmo DAS

Proyecto n de carrera - H ctor Cordob s de la Calle e e

Tabla 2.1: Tabla de polticas por omisi n o

Proyecto n de carrera - H ctor Cordob s de la Calle e e

Descripci n del algoritmo o

2.4.1. Funcionamiento del algoritmo de seleccion de direcci n origen o

Proyecto n de carrera - H ctor Cordob s de la Calle e e

2.4.2. Funcionamiento del algoritmo de seleccion de direcci n destino o

Proyecto n de carrera - H ctor Cordob s de la Calle e e

Consideraciones sobre el algoritmo

2.5.1. Interacciones con routers

Proyecto n de carrera - H ctor Cordob s de la Calle e e

Ejemplos de funcionamiento del algortimo

2.6.1. Selecci n de la direcci n origen o o

Candidatos: 3ffe::1, fe80::1

Proyecto n de carrera - H ctor Cordob s de la Calle e e

Captulo 2. El algoritmo DAS

Destino Resultado: Destino Resultado: Destino

Candidatos: fec0:1, fe80::1

Candidatos: 2001::1, fe80::1

Candidatos: 2002::1, 2001::1 (obsoleta)

2.6.2. Selecci n de la direcci n destino o o

Proyecto n de carrera - H ctor Cordob s de la Calle e e

Conjunto candidato: Destinos: Resultado:

Conjunto candidato: Destinos: Resultado:

Proyecto n de carrera - H ctor Cordob s de la Calle e e

2.6.3. Conguraciones de preferencia por IPv4

Conjunto candidato: Destinos: Resultado:

Conjunto candidato: Destinos: Resultado:

Proyecto n de carrera - H ctor Cordob s de la Calle e e

Captulo 2. El algoritmo DAS

Figura 2.1: Esquema del ejemplo para el caso multihoming

2.6.4. Conguraciones de entornos multihoming

Proyecto n de carrera - H ctor Cordob s de la Calle e e

Proyecto n de carrera - H ctor Cordob s de la Calle e e

Parte II An lisis de los mecanismos candidatos a

Captulo 3 Caractersticas necesarias para el mecanismo de propagaci n de DAS o

Opcionalmente tambi n sera deseable: e

Proyecto n de carrera - H ctor Cordob s de la Calle e e

Proyecto n de carrera - H ctor Cordob s de la Calle e e

Captulo 4 An lisis sobre seguridad a

Los problemas de seguridad

En criptologa suele llamarse mensaje el conjunto de datos a cifrar, comprobar o autenticar.

Captulo 4. An lisis sobre seguridad a