Protocolo IPv6.

Envia tus archivos, resúmenes, monografías, etc.

INTRODUCCION, OBJETIVOS DE DISEÑO, MECANISMOS DE SEGURIDAD DE IPv6, ADMINISTRACION DE CLAVES, USO, CONSIDERACIONES DE SEGURIDAD.

Agregado: 29 de AGOSTO de 2000 (Por ) | Palabras: 4118 | Votar | Sin Votos | Sin comentarios | Agregar Comentario
Categoría: Apuntes y Monografías > Computación > Varios >
Material educativo de Alipso relacionado con Protocolo IPv6

Protocolo para desarrollo de evaluacion ecologica rapida (EER): Permite la establecer los pasos metodologicos generales para el desarrollo y objetivos de la evaluacion ecologica rapida, en particular de las areas protegidas salvadoreñas.

Los protocolos de comunicación.: Sintesis de los niveles, equipo informatico.

Protocolo IPv6.: INTRODUCCION, OBJETIVOS DE DISEÑO, MECANISMOS DE SEGURIDAD DE IPv6, ADMINISTRACION DE CLAVES, USO, CONSIDERACIONES DE SEGURIDAD.

Enlaces externos relacionados con Protocolo IPv6

Nuevo Protocolo IPv6. -=- N3wk3rs -=-

1. INTRODUCCION

Esta parte describe los mecanismos de seguridad integrados en la versión 6 del Protocolo de Internet (IPv6) y los servicios que los proporcionan. También se describe la administración de claves para los mecanismos de seguridad de IPv6. Para más información, ver el draft draft-ietf-ipngwg-sec-00

1.1 Definiciones

Esta sección contiene algunas definiciones básicas aplicables para este documento.

Autenticidad Propiedad de conocer que la información recibida sea la misma que la información enviada y que el emisor es realmente quien asegura.

Integridad Propiedad de asegurar que la información es transmitida desde el emisor al destino sin detectarse alteraciones.

Confidencialidad Propiedad de mantener comunicaciones confidenciales de modo que los participantes involucrados puedan establecer comunicación sin que otros elementos ajenos a ellos sepan quiénes son.

Cifrado Mecanismo utilizado comunmente para proveer confidencialidad.

No repudio Propiedad de que un receptor sea capaz de probar que el emisor de alguna información realmente la envió, aun cuando el emisor pudiera negar posteriormente haber enviado dichaa información.

SAID Acrónimo de "Identificador de Asociación de Seguridad"

Asociación de Seguridad Conjunto de información de seguridad referente a una conexión de red dada (o conjunto de conexiones). Ésta incluye generalmente la clave criptográfica, tiempo de vida de la clave, algoritmo, forma del algoritmo, nivel de sensibilidad (p.e. No clasificada, Secreto, Propietario), qué clase de servicio de seguridad se proporciona (solamente autenticidad, modo de transporte de cifrado, Modo IP de Cifrado, o alguna combinación), y posiblemente alguna otra información.

Análisis de tráfico Una clase de ataque de red es aquél en el cual atacante es capaz de hacer deducciones acerca de la misma analizando sólo los patrones de tráfico de red (como frecuencia de transmisión, con quién se habla, tamaño de paquetes, Identificador de Flujo utilizado, etc).

2. OBJETIVOS DE DISEÑO

Esta sección describe parte de los objetivos de diseño de la arquitectura de seguridad y los mecanismos que los componen.

El objetivo principal de este trabajo es garantizar que IPv6 tenga mecanismos de seguridad sólidos disponibles para usuarios que deseen seguridad. Estos mecanismos estan diseñados de tal manera que los usuarios de Internet no los empleen no se vean afectados de forma adversa.
Se pretende que estos mecanismos sean algoritmos independientes de forma que los algoritmos de cifrado puedan ser alterados sin afectar otras partes de la implementación.

Los algoritmos estándar por defecto (p.e: MD5 con clave, DES CBC) han sido seleccionados para garantizar interoperabilidad en la Internet global.
Los algoritmos seleccionados son los mismos que los algoritmos estándar por defecto utilizados en SNMPV2. Los mecanismos de Seguridad de IPv6 deberían ser así útiles al imponer una variedad de políticas de seguridad.

3. MECANISMOS DE SEGURIDAD DE IPv6

Hay dos mecanismos de seguridad en IPV6.
La Cabecera de Autenticidad, que proporciona integridad y autenticidad sin confidencialidad.

El Encapsulating Security Payload, que, dependiendo del algoritmo y modo, podría proporcionar integridad, autenticidad, y siempre confidencialidad.

Los mecanismos de IPv6 no proveen seguridad contra un número de ataques de análisis de tráfico. Sin embargo, hay varias técnicas que no están en esta especificación (p.e.. bulk link encryption) que podrían ser utilizadas para proporcionar protección contra el análisis de tráfico.
Los dos mecanismos de seguridad de IPV6 pueden ser combinados.

3.1 CABECERA DE AUTENTICACIóN

La Cabecera de Autenticación de IPV6 busca proporcionar integridad y autenticidad para los datagramas IPv6. Esto se hace computando una función de autenticidad criptografica sobre el datagrama IPv6 y empleando una clave de autenticidad secreta en el cálculo.
El emisor computa la información de autenticidad exactamente antes de enviar el paquete IPV6 autenticado y el receptor verifica la información autenticada con la recibida. Hay ciertos campos que son omitidos en el cálculo de autenticidad debido a que cambian durante el tránsito como el campo Hop Limit, decrementando en cada paso. Sin embargo, la omisión del campo Hop Limit no afecta a la seguridad. Algunos algoritmos de autenticación podría proporcionar no repudio (p.e. algoritmos asimétricos en los que tanto las claves del emisor como del receptor se utilizan en el cálculo de la autenticidad) utilizados con la Cabecera de Autenticidad, pero no es necesariamente suministrado por todos los algoritmos de autenticidad que pueden utilizarse con la Cabecera de Autenticación.

El algoritmo de autenticación por defecto es el MD5 con clave, que se ajusta a todos los algoritmos simétricos que no proporcionan no repudio.
La protección del análisis de tráfico y la confidencialidad no son suministradas por la Cabecera de Autenticación.

La Cabecera de Autenticación de IPv6 mantiene información de autenticación para su datagrama IPv6. Esta información de autenticación se calcula utilizando todos los campos del datagrama IPv6 que no van a cambiar durante el tránsito desde el emisor al receptor. Todas las cabeceras de IPv6, payloads y la información de usuario están incluidas en este cálculo. La única excepción es que esos campos que deben cambiar en el tránsito (p.e. La Cabecera de IPv6 "Hop Count" o la Cabecera de Encaminamiento de IPv6 "Next Address") son omitidos cuando se calcula la información de autenticación.

El uso de la Cabecera de Autenticación aumentará los costes de procesamiento de protocolo de IPv6 en los sistemas que lo utilicen, así como la latencia de las comunicaciones. El aumento de latencia es principalmente debido al cálculo de la información de autenticación por parte del emisor y el cálculo y comparación de la información de autenticación por el receptor de cada datagrama IPv6 contenido en una Cabecera de Autenticación (AH).

La Cabecera de Autenticación proporciona una seguridad más fuerte que la existente en la mayoría de la actual Internet y no debería afectar a la exportabilidad ni aumentar significativamente el coste de implementación. Aunque la Cabecera de Autenticación puede ser instrumentada como una medida de seguridad empleando los nombres exactos de las máquinas de una red, este modo de operación no es seguro. En lugar de eso, la Cabecera de Autenticación debería ser utilizada también desde el origen al destino final.

Todas las máquinas que soporten IPv6 TIENEN que implementar la Cabecera de Autenticación de IPv6 con al menos el algoritmo de MD5 con unas claves de 128 bits. Se PUEDE implementar otros algoritmos de autenticación además del MD5 con clave.

3.2 ENCAPSULATING SECURITY PAYLOAD

El Encapsulating Security Payload (ESP) de IPv6 trata de dar integridad , autenticación y confidencialidad a los datagramas IPv6. Esto se hace por encapsulamiento, ya sea de un datagrama IPv6 completo o solamente información de protocolo de la capa superior dentro del ESP, cifrando la mayor parte del contenido del ESP, para concatenar después una nueva cabecera IPv6 sin cifrar al ya cifrado ESP. Esta cabecera IPv6 no cifrada se utiliza para llevar los datos protegidos a través de la red. El receptor del datagrama no cifrado retira y descarta la cabecera IPv6 y sus opciones no cifradas, descifra el ESP, procesa y después elimina las cabeceras de ESP, trata el (ahora descifrado) datagrama original IPv6 o los datos de un protocolo de nivel superior, como se indica en las especificaciones del protocolo IPv6.

3.2.1 Descripción de los Modos de ESP

Hay dos modos dentro de ESP :
El primer modo, conocido como IP-mode, encapsula y completa el datagrama IP dentro de la cabecera de ESP.
El segundo modo, conocido como Transport-mode, generalmente encapsula un UDP o TCP enmarcándolos dentro de IP.

3.2.2 Uso de ESP

ESP trabaja entre máquinas, entre una máquina y una entrada de seguridad, o entre entradas de seguridad. El soporte para entradas de seguridad permite que haya redes fiables detrás de una entrada de seguridad para omitir el cifrado y de ese modo evitar el trabajo y costes monetarios del cifrado, mientras que ofrece confidencialidad para tráfico transitando por segmentos de red no fiables. Cuando ambas máquinas implementan directamente ESP y no intervienen entradas de seguridad, entonces se puede emplear el Transport-mode (donde sólo es cifrada la información de protocolo de la capa superior (e.g. TCP o UDP), no la cabecera de IPv6). Este modo reduce tanto el ancho de banda consumido como los costes de procesamiento de protocolo para usuarios que no necesiten mantener la confidencialidad del datagrama IPv6 al completo. ESP trabaja tanto con tráfico unicast como multicast.

3.2.3 Impactos de la Función de ESP

El enfoque dado al encapsulamiento de seguridad utilizado por ESP puede impactar notablemente la función de la red en sistemas participantes, pero no debería influir negativamente en encamiadores u otros sistemas intermedios que no participen en la asociación de ESP particular.
El procesamiento de protocolo en sistemas participantes será más complejo cuando se utilice el encapsulamiento de seguridad, ambos requieren más tiempo y más potencia de procesamiento.
El uso del cifrado tambien aumentará la latencia de las comunicaciones. La latencia aumentada es principalmente debida al cifrado y descifrado requerido por cada datagrama IPv6 contenido en un ESP.
El coste preciso de ESP variará con las especificaciones de la implementación, incluyendo el algoritmo de cifrado, tamaño de clave y otros factores.

Las implementaciones hardware de los algoritmos de cifrado son recomendables cuando se desee una gran productividad. Debido al impacto de las funciones, los usuarios que no requieran confidencialidad preferirán probablemente utilizar la cabecera de Autenticación de IPv6 en lugar de ESP.
Para interoperar a través de la Internet a nivel mundial, todas las implentaciones de Encapsulting Security Payload de IPv6 soportan el uso del Data Encryptión Standard (DES) en Cipher-Block Chining (CBC) Mode.
Otros algoritmos de confidencialidad y modos pueden ser implementados además de este algoritmo y modo (obligatorios).
La exportación de métodos de cifrado y uso de los mismos está regulado en algunos países.

3.3 COMBINANDO MECANISMOS DE SEGURIDAD

En algunos casos la Cabecera de Autenticación de IPv6 puede combinarse con el IPv6 Encapsulating Security Protocol para obtener las propiedades de seguridad deseadas.
La Cabecera de Autenticación proporciona siempre integridad y autenticación y puede incluir no repudio si se usa con ciertos algoritmos de autenticación (p.e. RSA).
La Encapsulating Security Payload proporciona siempre integridad y confidencialidad y puede proveer autenticación si utiliza ciertos algoritmos de autenticación y cifrado.
Añadiendo la Cabecera de Autenticación a un primer datagrama IPv6 para encapsular aquel datagrama mediante el Encapsulating Security Protocol podría ser aconsejable para usuarios que deseen tener una integridad más fuerte, autenticación, confidencialidad, y quizás también no repudio. Cuando se combinan los dos mecanismos, la colocación de la Cabecera de Autenticación de IPV6 aclara que parte de la información está siendo autenticada. Detalles acerca de combinar los dos mecanismos vienen en las especificaciones del IPv6 Encapsulating Segurity Payload.

3.4 OTROS MECANISMOS DE SEGURIDAD

La protección del análisis de tráfico no es facilitada por ninguno de los mecanismos de seguridad descritos anteriormente. No está claro que la protección significativa contra el análisis de tráfico pueda ser proporcionada económicamente en la Capa de Internet y parece que pocos usuarios de Internet son conscientes acerca del análisis de tráfico.
Un método tradicional de protección contra el análisis de tráfico es el uso del cifrado bulk-link.
Otra técnica es enviar tráfico falso para aumentar el ruido en la información para el análisis de tráfico.
En la Referencia se discuten temas de análisis de tráfico más en detalle.

4. ADMINISTRACION DE CLAVES

El protocolo de Administración de Claves que se utilizará en IPv6 no está especificado en este documento.

IPv6 pretende sostener la llamada administración de claves "in-band", donde la información de administración de claves se lleva en una cabecera de IPv6 distinta.
En lugar de eso se utilizará principalmente la llamada administración de claves "out-of-band", donde la información de administración de claves la llevará un protocolo de capas superiores (como UDP o TCP) en algún numero de puerto especificado.
Esto permite aclarar el desacople del mecanismo de administración de claves de otros mecanismos de seguridad, y de ese modo se permite una nueva y mejorada sustitución de métodos de administración sin tener que modificar las implementaciones de los otros mecanismos de seguridad. Esto es de sobra conocido, dada la larga historia de sutiles 'grietas' en protocolos de administración de claves publicados.

Lo que sigue en esta sección es una discusión breve de algunos enfoques alternativos para la administración de claves.

4.1 Distribución Manual de Claves

La forma más simple de administración de claves es la administración de claves manual, donde una persona configura manualmente cada sistema con su propia clave y con las claves de otros sistemas de comunicación.
Esto es práctica habitual en entornos estáticos, pequeños pero no de gran escala.
No es un enfoque viable a medio o largo plazo, pero podría ser apropiado y útil en muchos entornos a corto plazo.

Por ejemplo, dentro de una LAN pequeña es totalmente práctico configurar manualmente claves para cada si;stema. Dentro de un único dominio administrativo es útil configurar claves para cada encaminador de modo que la información de encaminamiento quede protegida y para reducir el riesgo de que un intruso asalte un encaminador.

Otro caso podría ser una organización que tenga un firewall de cifrado entre la red interna y la Internet en cada una de sus plantas y se conecten dos o más plantas a través de la Internet.
En este caso, el firewall de cifrado podría selectivamente cifrar tráfico por otras plantas dentro de la organización utilizando una clave configurada manualmente, siempre y cuando no cifre tráfico con otros destinos. Tambien podría ser apropiado cuando solamente se necesita garantizar ciertas comunicaciones seleccionadas.

4.2 Algunas Técnicas de Administración de Claves Existentes

Hay varios algoritmos de administración de claves descritos en literarura de tipo público.

Needham y Schroeder han propuesto un algoritmo de administración de claves que confía en un sistema de distribución de claves centralizado. Este algoritmo es utilizado en el Sistema de Autenticación de Kerberos desarrollado en MIT bajo el Proyecto Athena.

Más recientemente, Diffie y Hellman han ideado un algoritmo que no requiere de un sistema de distribución de claves centralizado.
Lamentablemente, la técnica original de Diffie-Hellman es vulnerable a un activo ataque "man in the middle". Sin embargo, esta vulnerabilidad puede ser mitigada usando la firma de claves (firma digital) para la autenticación de bootstrap en el intercambio Diffie-Hellman.

4.3 Distribución automatizada de claves

La distribución y uso extendido de seguridad de IPV6 requerirá un protocolo de distribución de claves acoplable a la Internet estándar. Idealmente, tal protocolo sostendría un número de protocolos en la pila de protocolos de Internet, no sólo en la seguridad de IPv6.

Hay trabajo en camino dentro del IETF para añadir claves de máquinas asignadas al Sistema de Nombres de Dominio (DNS).
Las claves de DNS permiten que la parte original pueda autenticar mensajes de administración de claves con la otra parte de administración de claves utilizando un algoritmo asimétrico. Entonces, las dos partes tendrían un canal de comunicaciones autenticable que podría emplearse para crear una clave de sesión compartida utilizando Diffie-Hellman u otros medios.

Hay dos enfoques de claves para IPv6:
El primer enfoque, llamado clave host-to-host, tiene a todos los usuarios que comparten la misma clave en la máquina 1 para el uso en tráfico destinado a todos los usuarios en la máquina 2.
El segundo enfoque, llamado clave user-to-user, permite al usuario A en la máquina 1 tener una clave de sesión única con el usuaruio B en la máquina 2 que no está compartida con otros usuarios en host 1.

En muchos casos, un sistema de computación único tendrá al menos dos usuarios A y B mutuamente desconfiados (que no confían el uno en el otro). Cuando se utiliza la clave host-to-host y existen usuarios mutuamente desconfiados, es posible por parte del usuario A averiguar la clave host-to-host por medios bien conocidos, como un ataque Chosen Plaintext. Una vez el usuario A ha obtenido impropiamente la clave en uso, el usuario A puede entonces o bien leer el tráfico cifrado del usuario B o bien falsificar tráfico del usuario B. Cuando se utiliza una clave host-to-host, este tipo de ataques de un usuario al tráfico de otro usuario no es posible. Por tanto, se deduce que las claves host-to-host deberían estar presentes en todas las instrumentaciones de IPv6, como está descrito más adelante en "IPv6 Key Management Requirements".

4.4 Distribución de Claves de Multicast

La Distribución de Claves de Multicast es un área de investigación activa en la literatura. Para grupos de multicast que tienen relativamente pocos miembros, la distribución manual de claves o el uso de múltiples algoritmos de distribución de claves unicast existentes, como los Diffie-Hellman modificados, parecen posibles. Para muchos grupos, las nuevas técnicas de adaptación son necesarias. El uso de Core-Based Trees (CBT) para proporcionar administración de claves de sesión así como encaminamiento multicast sería un enfoque posible en el futuro.

4.5 Requisitos de Administración de claves de IPv6

Esta sección define requisitos de administración de claves para todas las instrumentaciones de IPv6. Esto se aplica igualmente a la Cabecera de Autenticación de IPv6 y al Encapsulating Security Payload de IPv6.

Todas las implementaciones de IPv6 TIENEN que soportar una administración de claves manual.
Todas las implentaciones de IPv6 DEBERíAN soportar un protocolo de administración de claves estándar de Internet una vez que este último sea definido.
Todas las implementaciones de IPv6 TIENEN que permitir la configuración y uso de claves user-to-user para el tráfico originado en el mismo sistema y PODER permitir adicionalmente la configuración de claves host-to- host para el tráfico originado en ese sistema como una característica añadida para hacer la distribución manual de claves más facil y dar al administrador del sistema más flexibilidad.
Un dispositivo que cifre o autentique paquetes de IPv6 originados en otros sistemas, como por ejemplo un cifrador IP dedicado o un gateway cifrador, por lo general no puede proporcionar claves user-to-user para el tráfico originado en otros sistemas. Por tanto, tales sistemas TIENEN que implementar claves host-to-host para tráfico originado en otros sistemas y PODER implementar claves user-to-user para el tráfico originado en otros sistemas.
El método por medio del cual las claves son configuradas en un sistema particular quedará definido en la implementación. Un archivo 'plano' que incluya identificadores de asociación de seguridad y los parámetros de seguridad, incluyendo la(s) clave(s), es un ejemplo de un posible método para la distribución manual de claves.
Un sistema IPv6 TIENE que dar pasos razonables para proteger las claves y otra información de seguridad, ya que toda la seguridad radica en las claves.

5. USO

Esta sección describe el uso de los posibles mecanismos de seguridad suministrados por IPv6 en diferentes entornos y aplicaciones para dar al implementador y al usuario una mejor idea de cómo estos mecanismos pueden utilizarse para reducir riesgos de seguridad.

5.1 USO CON FIREWALLS

Los firewalls son habituales en la actual Internet. Los dos mecanismos de IPv6 pueden utilizarse para aumentar la seguridad suministrada por los firewalls.
Los firewalls usados con IPv6 deberán poder analizar la cabecera daisy-chain para determinar el protocolo de transporte (p.e. UDP o TCP) en uso y el número de puerto para esos protocolos. La función de Firewall no debería verse afectada significativamente por el uso de IPv6, debido a que las reglas de formato de cabecera de IPv6 hacen un análisis fácil y rápido.
Los firewalls pueden utilizar la Cabecera de Autenticación para asegurarse de que la información (p.e. emisor, destino, protocolo de transporte, número de puerto) que se utiliza para decisiones de control de acceso es correcta y auténtica. La autenticación podría estar desempeñada no solamente dentro de una organización o campus sino también con sistemas remotos a traves de Internet mediante conexiones "end to end". Este uso de la Cabecera de Autenticación con IPv6 proporciona mucha más seguridad que la que facilita IPv4.

Organizaciones con dos o más plantas que se interconectan utilizando un servicio de IP comercial podrían desear utilizar un firewall para el cifrado selectivo. Si entre cada planta de una determinada empresa y su proveedor de servicios IP se situase un firewall de cifrado, este podría proporcionar un túnel de IP de cifrado entre todas las plantas de la empresa; podría también cifrar tráfico entre dicha empresa y sus suministradores, clientes y otros afiliados. El tráfico con el NIC, con el archivo público de Internet, o alguna otra organización no podría ser cifrado debido a la no disponibilidad de un protocolo de administración de claves estándar o al deseo de facilitar unas mejores comunicaciones, unas funciones mejoradas de red, y aumento de la conectividad. Tal práctica puede proteger fácilmente el tráfico sensible de la organización de posibles caídas y modificaciones.

Algunas organizaciones (como gobiernos) podrían desear utilizar completamente un firewall de cifrado para dar lugar a una red virtual protegida sobre el servicio comercial de IP. La diferencia entre esto y un dispositivo de cifrado de IPv6 es que un firewall dedicado al cifrado proveería filtraciones del tráfico descifrado así como ofrecería cifrado de paquetes de IP.

5.2 USO CON IPV6 MULTICAST

En los últimos años, la Multicast Backbone (MBONE) ha crecido rápidamente. Las reuniones de IETF y otras conferencias son ahora regularmente de tipo multicast con audio en tiempo-real, video, y whiteboards. Mucha gente está utilizando ahora aplicaciones de teleconferencia basadas en IP MULTICAST en la Internet o en redes internas privadas. Por tanto, es importante que los mecanismos de seguridad en IPv6 sean apropiados para su uso en un entorno donde el tipo multicast es el caso general.

Los Security Association Identifiers (SAIDS), utilizados en mecanismos de seguridad de IPv6 están orientados al receptor, haciéndolos apropiados para uso en multicast IP. Lamentablemente, los protocolos de distribución de claves multicast actualmente publicados no se adaptan bien. Sin embargo, hay una investigación activa en este área. Como paso interno, un grupo multicast podría utilizar repetidamente un protocolo seguro de distribución de claves unicast para distribuir la clave a todos los miembros, o el grupo podría prearrancar claves utilizando una distribución de claves manual.

5.3 USO PARA PROPORCIONAR PROTECCION QOS

El IAB Security Workshop identifica la protección de Quality of Service como un área de interés significativo. Los dos mecanismos de seguridad de IPv6 están buscando proporcionar un buen soporte para servicios en tiempo real así como de multicast. Esta sección describe un posible enfoque para ofrecer dicha protección.
La Cabecera de Autenticación puede utilizarse, con una administración de claves apropiada, para proveer autenticación de paquetes. Esta autenticación es potencialmente importante para la clasificación de paquetes dentro de routers.
El IPv6 Flow Identifier puede actuar como Low-Level Identifier (LLID).
Usados los dos conjuntamente, la clasificación de paquetes dentro de encaminadores se convierte en algo inmediato si el encaminador contiene el material de claves apropiado. Por razones de eficiencia, los encaminadores podrían autenticar solamente cada n paquetes (en lugar de autenticar cada paquete), pero ésta es una mejora aún más significativa sobre las características de la actual Internet. El QOS es apropiado también para utilizar el Flow ID conjuntamente con un protocolo para reservar recursos, como podría ser RSVP. Así, la clasificación del paquete autenticado puede utilizarse para ayudar a garantizar que cada paquete reciba una manipulación apropiada dentro de los encaminadores.

6. CONSIDERACIONES DE SEGURIDAD

Toda esta página discute la Arquitectura de Seguridad de IPv6.
Los usuarios deben entender que la calidad de la seguridad suministrada por los mecanismos de IPv6 depende completamente de la fortaleza de los algoritmos criptográficos implementados, la robustez de la clave que se utiliza, la implementación correcta de los algoritmos criptograficos, la seguridad del protocolo de administración de claves y la implementación correcta de IPv6 y los distintos mecanismos de seguridad de todos los sistemas que intervienen.

La seguridad de la implementación está en parte relacionada con la seguridad del sistema operativo que encarna las implementaciones de seguridad. Por ejemplo, si el sistema operativo no mantiene la confidencialidad de las claves cifradas privadas, entonces el tráfico que utilice dichas claves no va a ser seguro. Si cualquiera de éstas fuera incorrecta o insuficientemente segura, poca o ninguna seguridad real tendría el usuario. Debido a que diferentes usuarios del mismo sistema podrían no confiar unos en otros, cada usuario o cada sesión debería trabajar generalmente con claves separadas. Esto también tenderá a aumentar el trabajo requerido para criptoanalizar el tráfico, ya que no todo tráfico utilizará la misma clave.

Ciertas propiedades de seguridad (como protección del análisis de tráfico) no las pueden aportar estos mecanismos. Un enfoque posible para la protección contra el análisis de tráfico es un uso adecuado del cifrado de enlace. Los usuarios tienen que considerar cuidadosamente qué propiedades de seguridad quieren y tomar pasos activos para garantizar que sus necesidades se encuentran en estos u otros mecanismos.

Ciertas aplicaciones (como correo electrónico) necesitan probablemente mecanismos de seguridad específicos para cada aplicación. Estos mecanismos están fuera del alcance de la Arquitectura de Seguridad de IPv6. Los usuarios interesados en mecanismos de seguridad de correo electrónico específicos de una aplicación pueden consultar RFCs que los describan.

===========================================================

Sr-Ice (1998)