Requisitos de Prueba para IPv6 SEND

Requisitos de Prueba para
IPv6 SEND (SEcure Neighbor Discovery)
César Olvera Morales y Miguel A. Díaz Fernández
{cesar.olvera, miguelangel.diaz}@consulintel.es
Estudiantes Doctorado UPM
Consulintel
Complejo Empresarial IMCE, Joaquín Turina, 2
E-28224 Pozuelo de Alarcón, Madrid España
Tel. (+34) 911518199
RESUMEN: El mecanismo SEND (SEcure
Neighbor Discovery) se diseñó para proporcionar
seguridad al protocolo de IPv6 NDP (Neighbor
Discovery Protocol) en ambientes como en el de
las redes inalámbricas, donde la seguridad en el
nivel físico esta comprometida.
Las implementaciones de SEND están
surgiendo y es necesario contar con herramientas
de pruebas para certificar su correcto
funcionamiento. Entre otros esfuerzos, se está
preparando un evento internacional de
interoperabilidad
para
probar
las
implementaciones SEND existentes.
El presente trabajo se basa en el marco
general para el desarrollo de pruebas IPv6
desarrollado por ETSI y extrae los requisitos de
prueba1 del principal documento descriptivo de
SEND, el RFC3971.
Con los requisitos obtenidos para SEND se
puede especificar posteriormente qué probar y
cómo probarlo durante el evento de
interoperabilidad en preparación.
1. Introducción
La IETF desarrollo el mecanismo SEND
(SEcure Neighbor Discovery) [1] para agregar
seguridad al NDP (Neighbor Discovery Protocol)
[2] de IPv6. SEND esta pensado para aplicarse
principalmente en ambientes donde la seguridad
en el nivel físico esta comprometida (como en las
redes inalámbricas) y donde se puedan dar
ataques a NDP [3].
Los desarrolladores y fabricantes están
produciendo implementaciones de SEND, y es
necesario
contar
con
programas
y
procedimientos de pruebas de conformidad2,
interoperabilidad3, prestaciones4, etc. para
certificar el correcto funcionamiento de tales
implementaciones. Entre otros esfuerzos
internacionales, se planea organizar un evento de
interoperabilidad
para
probar
las
implementaciones SEND disponibles a la fecha.
Es un hecho que el protocolo IPv6 se esta
instalando en redes en todo el mundo, y por ello
es necesario probar los equipos y programas
IPv6 para asegurar que sean interoperables entre
sí y con los equipos IPv4 ya instalados; además
es necesario verificar que brindan el mejor
rendimiento y cumplen ampliamente con los
servicios demandados por los usuarios.
Existen varias herramientas que facilitan las
pruebas de IPv6. Distintas instituciones
académicas, de investigación, de estandarización
y compañías comerciales han desarrollado
herramientas, llámense dispositivos, programas,
especificaciones y suites de prueba, para realizar
pruebas enfocadas a IPv6 en general. La
referencia [4] muestra las herramientas de prueba
IPv6 más comunes existentes a mediados del
2005, a las cuales ya se han sumado otras al día
de hoy.
Aun
así,
actualmente
no
existen
prácticamente herramientas para probar el
mecanismo SEND (debido en parte también a
que sus implementaciones son escasas).
Por lo que el evento de interoperabilidad en
preparación busca probar las implementaciones
existentes y fomentar el desarrollo de otras
nuevas. Y los requisitos de prueba para SEND
obtenidos en este trabajo se podrán usar para
definir posteriormente qué probar y cómo
3
1
Un requisito de prueba es una descripción de cómo
un dispositivo o sistema se debe de comportar bajo
ciertas circunstancias.
2 Las pruebas de conformidad determinan si un
dispositivo, o parte de él, satisface o no los criterios
dados en un documento de especificaciones creado y
controlado por algún organismo de estandarización
reconocido como ITU, ISO, IEEE, ETSI, IETF, etc.
Las pruebas de interoperabilidad evalúan la habilidad
de los dispositivos para proveer servicios hacia o
aceptar servicios desde otros dispositivos, y usar esos
servicios intercambiados de manera directa y
satisfactoria para operar en común efectivamente.
4 Las pruebas de prestación buscan caracterizar los
dispositivos a través de encontrar los valores
numéricos de parámetros tales como retardo (delay),
variación del retardo (jitter), caudal eficaz
(throughput), pérdida de paquetes, tiempo promedio
entre fallas, etc.
probarlo durante el evento de interoperabilidad
mencionado.
2. Herramientas de pruebas IPv6 de ETSI
ETSI esta involucrada en un novedoso
proyecto para producir un marco general para el
desarrollo de pruebas IPv6 [5] [6] [7], y ofrecer
sin costo los procedimientos, librerías y suites de
pruebas escritos en el lenguaje TTCN-3 (Testing
and Test Control Notation version 3) [8] [9].
El objetivo principal de ETSI es apoyar y
fortalecer el liderazgo de Europa en la
producción de herramientas que faciliten y hagan
más comunes las pruebas IPv6, y lo hace a través
de este marco que también busca convertirse en
un estándar de referencia mundial.
El lenguaje de programación TTCN-3 es un
estándar de ITU diseñado por ETSI
específicamente para pruebas y certificación.
TTCN-3 se utiliza para especificar las pruebas e
indicar el orden de ejecución de las mismas.
ETSI primero definió ([5] sección 7) siete
áreas de interés de IPv6, las cuales incluyen los
principales RFCs de la IETF relevantes a cada
una de las áreas: Protocolos de Núcleo IPv6,
Movilidad, Seguridad, Transición, Calidad de
Servicio, Encaminamiento y Multicast. ETSI
después definió [6] todos los componentes
necesarios para producir pruebas IPv6 escritas en
TTCN-3.
El proceso de desarrollo de las pruebas IPv6
definido por ETSI tienes varias etapas ([6]
sección 5), y cada una de ellas es necesaria para
las subsiguientes. La Figura 1 esquematiza las
etapas que componen el proceso.
RFCs
3G
IPv6
Forum
Conformidad
Recolección
de
Requisitos
Catálogo
de Requisitos
Casos
de Prueba
Suites
de Pruebas de
Conformidad
Interoperabilidad
Propósitos
de Prueba
Propósitos
de Prueba
Funciones
de Propósitos
de Prueba
Prácticas
Industriales
Biblioteca
en TTCN-3
Repositorio
de Suites de
Pruebas IPv6
Descripción
de Prueba de
Interoperabilidad
Casos
de Prueba
Suites
de Pruebas de
Interoperabilidad
Figura 1. Proceso de desarrollo de pruebas
IPv6 según el marco de ETSI.
La descripción de las etapas es como sigue:
 Recolección de requisitos de prueba a partir
de las distintas especificaciones de IPv6
(RFCs, 3GPP, IPv6 Forum, prácticas
industriales, etc.).
 Confección del catálogo de requisitos,
presentado como un árbol jerarquizado
donde cada nodo es un requisito o una
función IPv6.
 Para las Pruebas de Conformidad el proceso
consiste en: escritura de los propósitos de
prueba de conformidad a partir de los
requisitos, escritura de las funciones de
tales propósitos, escritura de los casos de
prueba, y finalmente producción de las
suites de pruebas en TTCN 3.
 Para las Pruebas de Interoperabilidad el
proceso consiste en: escritura de los
propósitos de prueba de interoperabilidad a
partir de los requisitos, escritura de las
descripciones de prueba, escritura de los
casos de prueba, y finalmente producción
de las suites de pruebas en TTCN 3.
Utilizando el marco descrito, a la fecha ETSI
ya ha desarrollado la suite de prueba para los
Protocolos de núcleo, y esta desarrollado las
suites de Movilidad y Seguridad. Pero en ellas no
ha incluido el mecanismo SEND, de allí la
novedad e importancia del presente trabajo que
se basa en el marco de pruebas IPv6 y extrae los
requisitos de prueba del principal documento
descriptivo de SEND: RFC3971 [1].
3. SEND (SEcure Neighbor Discovery)
Los nodos (encaminadores y hosts) IPv6 usan
el protocolo NDP (Neighbor Discovery Protocol)
[2] para descubrir a otros nodos en la misma red
local, determinar su dirección de nivel de enlace,
encontrar
encaminadores
y
mantener
información del camino hacia otros nodos
activos.
NDP es vulnerable a varios ataques [3] sí no
se utilizan las herramientas de seguridad
adecuadas. Según las especificaciones de IPv6,
los mensajes de ND (Neighbor Discovery) se
pueden proteger con la cabecera de autenticación
(AH - Authentication Header) de IPsec, sin
embargo existen limitaciones prácticas en el uso
de la gestión automática de llaves (entre ellas
problemas de bootstrapping al usar IKE).
Por ello el mecanismo SEND (SEcure
Neighbor Discovery) [1] se diseñó para
proporcionar seguridad a los mensajes de ND
(Neighbor Discovery) [2].
SEND define: un nuevo conjunto de opciones
para los mensajes ND, un proceso de
descubrimiento de autorización en la delegación,
un mecanismo de prueba de propiedad y los
requisitos para aplicar todos estos componentes
en el NDP.
Las cuatro opciones definidas para los
mensajes ND son:
 CGA
(Cryptographically
Generated
Addresses [10]) option. Las direcciones
CGA se usan para asegurar que el
transmisor del ND es efectivamente el
“dueño” de tal dirección. La CGA option se
usa para transportar la llave pública
necesaria así como los parámetros
asociados.
 RSA Signature option. Se usa para asociar
al mensaje ND la firma basada en llaves.
 Timestamp and Nonce options. Ambas se
utilizan para prevenir ataques de
retransmisión.
Con todos estos componentes, SEND se
pensó para aplicarse principalmente en
ambientes donde la seguridad en el nivel físico
esta comprometida, como en las redes públicas
inalámbricas.
4. Requisitos de prueba para SEND IPv6
Como se mencionó antes, el presente trabajo
se basa en el marco de desarrollo de pruebas
IPv6 de ETSI para producir los requisitos de
prueba del RFC3971 que especifica los
componentes de SEND. Este método se ha
aplicado exitosamente también para RFCs de
Transición IPv4-IPv6 [11].
 Usando como guía el marco de ETSI ([6]
sección 6 y anexo D), se obtienen todos los
requisitos de prueba del RFC3971.
 De acuerdo al trabajo realizado, se observa
que el tiempo promedio necesario para
obtener ‘a mano’ todos los requisitos de un
RFC de 50 páginas es de 70 horas/hombre.
Aunque podría ser deseable, hasta ahora no
existen
herramientas
para
obtener
‘automáticamente’ los requisitos de prueba
desde un RFC.
 Se obtienen finalmente más de 230
requisitos de prueba en inglés reunidos en
un catálogo en formato texto que serviría
como base de datos para tratamientos
futuros. El idioma usado es el inglés debido
al carácter internacional del evento de
interoperabilidad de SEND.
A modo de ejemplo, la Figura 2 muestra uno
de los requisitos de prueba obtenidos. El
requisito tomado del RFC3971, sección 5.2,
párrafo 1, es válido para un nodo (encaminador o
host). Es sobre los componentes de SEND y
específicamente sobre la opción RSA Signature,
Es de tipo [MUST] (‘DEBE‘ pero calificado por
la persona que escribe el requisito y por eso
marcado con [ ]), el campo “RqmtTxt” muestra
el texto exacto del RFC de donde se obtiene el
requisito. Los otros campos sirven para
relacionar el requisito con los posibles propósitos
de prueba (TP), los casos de prueba (TC), etc.
definidos posteriormente a partir del requisito.
RqmtID: RQ_SEND_0456
RqmtSubject: Node
ParentFncNode: SEND Components
ParentFncType:
ParentFncRef:
Function_node: RSA Signature Option
FunctionType: [MUST]
FunctionRef: RFC 3971
RqmtContext: The implementation uses IPv6 SEND to
protect all messages relating to Neighbour and Router
discovery. The implementation needs to attach the
public key-based signatures into NDP messages.
Rqmt: The implementation uses the RSA Signature
option.
RqmtTupleList: {RFC 3971, §5.2 ¶1}
RqmtTxt: <span style="color: #FF0000">The RSA
Signature option allows public key-based signatures to
be attached to NDP messages</span>.
Conf_TP_ID:
Conf_TC_ID:
Interop_TP_ID:
Interop_TC_ID:
Link_2srce:
Link_2rqmt:
Link_2ConfTP:
Link_2InteropTP:
Link_2ConfTC:
Link_2InteropTC:
Figura 2. Requisito de prueba para SEND.
5. Conclusiones
Se ha explicado que ETSI ha producido un
novedoso marco general estándar para el
desarrollo de pruebas para IPv6, y que ofrece sin
costo los procedimientos, librerías y suites de
pruebas escritos en el lenguaje estándar TTCN-3.
Se puede considerar que el marco de ETSI se
definió de tal forma que esta abierto para poder
recibir contribuciones que ayuden a la
elaboración de las suites de pruebas de IPv6 ya
definidas en el marco, o aún otras distintas, como
en este caso se ha hecho con el mecanismo de
seguridad SEND.
Así se generan más de 230 requisitos de
prueba de IPv6 SEND que servirán para
especificar las pruebas a realizar durante el
evento de interoperabilidad mencionado.
Por otro lado y empleando otras etapas del
marco de desarrollo de ETSI, los requisitos
obtenidos además podrían servir para la creación
de los de las suites de prueba en TTCN 3 para
SEND.
Referencias
[1] Arkko, J., Kempf, J., Zill, B., and P.
Nikander, “SEcure Neighbor Discovery
(SEND)”, RFC3971, Marzo 2005.
[2] Narten, T., Nordmark, E., and W. Simpson,
“Neighbor Discovery for IP Version 6
(IPv6)”, RFC2461, Diciembre 1998.
[3] Nikander, P., Kempf, J., and E. Nordmark,
“IPv6 Neighbor Discovery (ND) Trust
Models and Threats”, RFC3756, Mayo
2004.
[4] Olvera, C. “Pruebas en Dispositivos IPv6 Aspectos Técnicos”, Seminario sobre el
Protocolo IPv6 y Políticas Públicas en la
Distribución de Servicios de Internet,
Caracas Venezuela, Mayo 2005.
[5] “Pre-normative Study for IPv6 Testing”,
ETSI TR 102 235 V1.1.1, Julio 2003.
[6] “IPv6
Testing:
Methodology
and
Framework”, ETSI TS 102 351 V2.1.1,
Agosto 2005.
[7] “ETSI IPv6 Testing Project”. Consultado
en: http://www.ipt.etsi.org/ 30-01-2007.
[8] “The testing and test control notation
version 3: TTCN-3 core language”, ITU-T
Z.140, Julio 2001.
[9] “ETSI
TTCN-3”.
Consultado
en:
http://www.ttcn-3.org/ 30-01-2007.
[10] Aura, T., “Cryptographically Generated
Addresses (CGA)”, RFC3972, March 2005.
[11] Olvera C., “Catálogo de Requisitos de
Prueba para la Transición de IPv6”,
Jornadas Técnicas RedIRIS 2006, Granada
España, Noviembre 2006.
RESEÑA CURRICULAR
César Olvera Morales es Físico por la
Universidad Nacional Autónoma de México UNAM. De 1998 a 2001 trabajó en DGSCAUNAM, coordinando el Laboratorio de
Interoperabilidad, donde realizó investigaciones
y pruebas de IPv6, QoS, Multicast, VoIP, MPLS,
etc.; además de organizar conferencias y
seminarios sobre estas tecnologías, y ser
conferencista en eventos nacionales e
internacionales. Desde 2002 trabaja en
Consulintel donde participa en varios proyectos
de I+D de IST y PROFIT, y centrando sus tareas
en consultorías, pruebas e instalación de IPv6
sobre
temas
como
direccionamiento,
encaminamiento,
PLC,
QoS,
Multicast,
Movilidad, etc. Además colabora con ETSI, IPv6
Forum, Spirent, Agilent, Ixia, Telelogic, Testing
Tech, etc., en el diseño y conducción de pruebas
de interoperabilidad, conformidad y prestaciones
en dispositivos IPv6. También ha colaborado con
el grupo de trabajo de v6ops de la IETF.
Actualmente es estudiante de doctorado en la
Universidad Politécnica de Madrid
Miguel Angel Díaz Fernández Miguel Ángel
Díaz Fernández posee las titulaciones de
Ingeniero Técnico Electrónico e Ingeniero
Superior de Telecomunicación, ambas otorgadas
por la Universidad Politécnica de Madrid. Su
experiencia incluye programación en diferentes
lenguajes orientados a objeto como C/C++ y
Java, así como lenguajes de modelación como
UML. Desde 2.001 ha estado involucrado en
diferentes proyectos de I+D relacionados con
streaming de audio y video, voz sobre IP (VoIP),
QoS, Movilidad, etc. En la actualidad desarrolla
su actividad profesional en la empresa
Consulintel como consultor en el diseño y
despliegue de redes IP, principalmente IPv6,
dando soporte a clientes tales como ISPs y
grandes empresas. Así mismo participa en
diferentes proyectos IST y PROFIT de I+D,
siendo sus áreas de interés aquellas que se
centran en el protocolo IPv6, tales como
despliegue de red, gestión, evaluación, QoS,
transición etc.