Alternativa de Infraestructura de Seguridad Basada en
IPsec y DNSsec
Rolando Chaparro Fox FLIP6 Lima, Perú
Junio 2005
universidad nacional de asunción
[ Experiencia en la UNA ]
→ Modelo de infraestructura seguridad escalable
→ Uso combinado de IPsec y DNSsec
→ Trabajo experimental: alteraciones mínimas sobre implementaciones.
→ No requiere de cambios en el diseño de estos protocolos
→ Relativamente simple
→ Alternativa al tradicional esquema de certificados y CAs
→ Servicios de seguridad pueden sustentarse en la infraestructura de red y en sus organizaciones
[ De qué se trata ]
→ DNSsec
Distribución segura de claves públicas de entidades de red (típicamente hosts)
→ IPsec
Interación con DNSsec para localizar, recuperar y comprobar la autenticidad de estas claves públicas
[ Orígenes de IPsec ]
→ RFC1636 (1994)
Autenticación y cifrado como requerimiento para la siguiente generación del protocolo IP (IPv6)
→ IPsec
Extensión al Protocolo IP
Seguridad en la capa de interconexión de redes
IPv6 e IPv4
1998: IPv6 (RFC2460) IPsec (RFC2401)
[ IPsec Seguridad IP ]
→ Extensiones de seguridad para IPv6 e IPv4
→ Capa de interconexión de redes (protección para el tráfico TCP, UDP, ICMP, etc.)
→ Criptografía simétrica
→ Asociaciones de Seguridad o SAs (canales unidireccionales)
→ Tres protocolos: AH, ESP, IKE
→ Dos modos de transmisión segura:
Transporte y Túnel
[ IPsec Los Protocolos ]
→ AH (Authentication Header)
Autenticación (HMACMD5, HMACSHA1, etc.)
→ ESP (Encapsulating Security Payload)
Cifrado (3DES, AES, etc.)
→ IKE (Internet Key Exchange)
Intercambio dinámico de claves secretas (DH)
Autenticación de las partes
+ PSK (claves secretas predefinidas)
+ Firmas Digitales (RSA, DSA)
[ ]
E kuB
mensaje mensaje
cifrado
D
kpB
mensaje descifrado
A B
Clave Pública de B
Clave Privada de B
c
m m
Caracterización del Problema
→ A: ¿ Es esta realmente la clave pública de B ?
→ A: De hecho, ¿ cómo obtengo la clave pública de cualquier usuario o entidad ?
[ Caracterización del Problema ]
→ El uso de la criptografía asimétrica plantea un nuevo conjunto de problemas.
→ De forma concreta:
Cómo reconocer que una clave pública pertenece a un usuario o host en particular y no a otro que aparenta ser éste.
Cómo poner las claves públicas a disposición de todos, brindando mecanismos simples de localización y
recuperación
[ Caracterización del Problema ]
→ Estos dos cuestionamientos dan pie a la formulación del concepto de PKI
→ En la práctica una las PKIs son imprescindibles para el comercio electrónico y para determinadas aplicaciones de seguridad
→ El concepto de PKI se ha establecido en los últimos años y se ha usado como punto de referencia
[ ]
E kuB
mensaje mensaje
cifrado
D
kpB
mensaje descifrado
A B
Clave Pública de B
Clave Privada de B
c
m m
Caracterización del Problema
→ A: ¿ Es esta realmente la clave pública de B ?
[ ]
E kuB
mensaje mensaje
cifrado
D
kpB
mensaje descifrado
A B
Clave Pública de B
Clave Privada de B
c
m m
Caracterización del Problema
→ A: ¿ Es esta realmente la clave pública de B ?
Datos de Id. de B Firma Digital ....
Certificado
F6A2...
CA
[ Caracterización del Problema ]
→ Las actuales PKIs presentan aún estimables desafíos
Cuando se pretende extender sus soluciones a una gran cantidad de usuarios (escalabilidad)
Cuando se busca la interacción entre usuarios de PKIs diferentes (interoperabilidad)
→ El reto consiste consiste en solucionar estos problemas sin incrementar la complejidad del sistema al punto de que se torne difícil de manejar para los usuarios finales
[ DNS Domain Name System ]
→ Espacio de nombres de la infraestructura de red
HTTP SMTP FTP SSH
TCP UDP
LDAP
IP
AplicaciónTransporteRed
DNS (Domain Name System) Pro
tocolos de Infraestructura
[ DNS Domain Name System ]
→ Servicio de directorio simple y eficaz
→ Escalable,
→ Naturaleza distribuida,
→ Alta disponibilidad
→ Balance de carga
→ Espacio de nombres de la infraestructura de red
→ Las propias CAs han planteado usar al DNS para facilitar la localización de sus repositorios RLS: Repository Locator Service (indirección)
[ DNSsec Las extensiones de Seguridad ]
→ Inclusión de firmas digitales en las respuestas a las consultas DNS
→ Los resolvers DNSsec realizan verificaciones criptográficas para comprobar la validez de las respuestas recibidas
Autenticación del origen de los datos
Integridad de los datos transmitidos
→ Define su propia jerarquía de autenticación denominada authenticationchain
[ Definición del Modelo ]
Nuevo RR APPKEY
→ Clave pública asociada a un host u otra entidad
→ RFC3445 (2002): Limiting the Scope of the KEY RR
→ RFC4025 (2005): A Method for Storing IPsec Keying in DNS
www.cnc.una.py 3600 IN APPKEY 256 1 2 AQPdWbrGbV[...]xB1qTmA6bI8B
Clave Pública Aplicación o Protocolo
(ssh, email, web, IPsec, ...)
Algoritmo (RSA, DSA,...) Flags: Uso (cifrado, firma,...)
RDATA
[ IPsec Componentes ]
→ Esquema básico de componentes de IPsec
Otros RIPEMD160
Otros
IKE
IPv4 / IPv6 Protocolos de Aplicación
TCP / UDP
IPsec API Socket
Frontera del Kernel
AF_INET PF_KEY
SPD SAD
ESP
PF_KEY
AH
HMACSHA1 HMACMD5
Cast128 BlowfishCBC 3DESCBC
Administrador
Claves Negociadas con la otra parte
[ IKE Internet Key Exchange ]
→ Esquema básico de interacción
IKE
IPv4 / IPv6 IPsec Protocolos de Aplicación
TCP / UDP
IP UDP API Socket
Frontera del Kernel
AF_INET PF_KEY AF_INET
IKE Protocolos
de Aplicación
TCP / UDP IP
UDP
AF_INET PF_KEY
AF_INET UDP 500
IPsec
(AH/ESP/IPcomp)
Host A Host B
SPD
SAD IPv4 / IPv6
IPsec
SPD SAD
[ Definición del Modelo ]
Interacción IPsec/IKE/DNS
→ Equema básico de interrelación entre IPsec, IKE y DNSsec
Protocolos de Aplicación
TCP / UDP UDP
AF_INET PF_KEY
AF_INET
Host B IKE
IKE
IPv4 / IPv6 IPsec Protocolos de Aplicación
TCP / UDP
IP UDP API Socket
Frontera del Kernel
AF_INET PF_KEY AF_INET
Host A
SPD SAD
Sistema DNS
Servidor DNS Local
de Host A
Servidor Autoritatvo
de Host B
Servidor DNS Local
de Host B Servidor
Autoritatvo de Host A
Obtención de APPKEY de A
(UDP 53) Obtención de
APPKEY de B (UDP 53)
Negociación de las claves simétricas, autenticación de
las partes, establecimiento de asociaciones de seguridad
(UDP 500)
[ Definición del Modelo ]
Consultas DNSsec desde IKE
→ Interacción con DNSsec al final de la Fase 1
IKE (Host A) Servidor
DNS local
Servidores DNS
IKE (Host B)
Parámetros IKE (algoritmos de cifrado y hash, método de autenticación, grupos DH)
Negociación de Claves (generación de valores DH y nonces,
cómputo de shared secret) Autenticación de las Partes (obtención de PKs, intercambio y comprobación de identidades)
Fase 1Fase 2
Query: HOSTB IN APPKEY Resp: HOSTB IN APPKEY (mensaje DNS de respuesta, incluyendo clave pública de Host B) Resolución
Recursiva
Establecimiento SAs de IPsec (negociación de parámetros IPsec, SPI,
intercambio de nonces para derivar claves de sesión a partir del shared secret
de IKE, opcionalmente intercambio de valores DH para generar nuevas claves)
[ Definición del Modelo ]
Consultas DNSsec desde IKE
→ Interacción con DNSsec al final de la Fase 1
IKE (Host A) Servidor
DNS local
Servidores DNS
IKE (Host B)
Parámetros IKE (algoritmos de cifrado y hash, método de autenticación, grupos DH)
Negociación de Claves (generación de valores DH y nonces,
cómputo de shared secret) Autenticación de las Partes (obtención de PKs, intercambio y comprobación de identidades)
Fase 1Fase 2
Query: HOSTB IN APPKEY Resp: HOSTB IN APPKEY (mensaje DNS de respuesta, incluyendo clave pública de Host B) Resolución
Recursiva
Establecimiento SAs de IPsec (negociación de parámetros IPsec, SPI,
intercambio de nonces para derivar claves de sesión a partir del shared secret
de IKE, opcionalmente intercambio de valores DH para generar nuevas claves)
[ Implementación del Modelo ]
Interacción IPsec/IKE/DNS
→ Prueba de concepto del Modelo de Infraestructura de Seguridad basado en IPsec y DNSsec
→ Una adaptación de IPsec sobre Linux, en la que se incorporan mecanismos para:
Enviar la consulta al servidor DNS local
Recibir la respuesta como una ED tipo RR APPKEY
Extraer el material criptográfico que conforma la clave pública
Convertirla a la representación interna apropiada
Usarla en los procedimientos de autenticación para establecer la asociación de seguridad ISAKMP SA.
[ Implementación del Modelo ]
Implementación de IKE
→ Ultimo
intercambio, durante la Fase 1
ident_i1send Propuesta de Parámetros IKE ident_i2recv Selección de
Parámetros IKE
ident_r1recv ident_r1send
Host Initiator Host Responder
ident_i2send Negociación de Claves (DH, Nonce) ident_i3recv Negociación de Claves
(DH, Nonce)
ident_r2recv
ident_r2send
ident_i3send Autenticación ID, Firma ident_i4recv Autenticación
ID, Firma
ident_r3recv
ident_r3send
Fase 1
[ Implementación del Modelo ]
Implementación de IKE
→ Ultimo
intercambio durante la Fase 1
ident_i3send Autenticación ID, Firma ident_i4recv Autenticación
ID, Firma
ident_r3recv ident_r3send
oakley_validate_auth
auth_method autenticación
presharedkey preshared
key Firma Digital
getcert_method payload ...
DNS local ...
cert_type X.509 dns_getcert Registro
APPKEY
dnssec_getappkey Obtención del APPKEY autenticado vía DNSsec
[ Implementación del Modelo ]
Implementación de IKE
→ Ultimo
intercambio durante la Fase 1
ident_i3send Autenticación ID, Firma ident_i4recv Autenticación
ID, Firma
ident_r3recv ident_r3send
oakley_validate_auth
auth_method autenticación
presharedkey preshared
key Firma Digital
getcert_method payload ...
DNS local ...
cert_type X.509 dns_getcert Registro
APPKEY
dnssec_getappkey Obtención del APPKEY autenticado vía DNSsec
auth_method autenticación presharedkey
preshared key Firma Digital
getcert_method payload ...
DNS local ...
cert_type X.509
Registro APPKEY
dnssec_getappkey
oakley_ph1hash_common Cómputo del valor hash
Obtención del APPKEY autenticado vía DNSsec
getappkeysbyname Resolver
DNSsec dns_getcert
getrrsetbyname
eay_check_appkeysign Error: Firma no válida
[ Análisis del Modelo ]
Servicios de seguridad en la IR
→ Cualquier organización que requiera servicios de seguridad, no necesita recurrir a una CA
comercial para garantizar a los usuarios la legitimidad de las claves públicas
→ Para asegurar la autenticidad de las
mencionadas claves, basta con publicarlas en el sistema DNS, con la misma facilidad con la que se publican sus direcciones IP
→ En consecuencia se tiene un modelo más simple
[ Análisis del Modelo ]
Servicios de seguridad en la IR
→ Un modelo más simple
Configuración de Certificado Cache
Cliente
Internet
HandShake Cert y Negociación HTTP/SSL Cons/Resp IP de www
Serv. DNS Autoritativo
Servidor www
Publicación de nombre DNS e IP Serv. DNS
Local
Consultas Recursivas
Consultas Recursivas
Solicitud de Certificado Envío de PK, nombre DNS y otros datos Distribución outoftheband de Certificados Raíz Certificado
Raíz
Certificado Autoridad de
Certificación Subsidiaria
de Registro
[ Análisis del Modelo ]
Los servicios y la infraestructura
→ Un modelo más simple
Subsidiaria de Registro
Configuración de Certificado HandShake Cert y Negociación
Certificado Raíz
Distribución outoftheband de Certificados Raíz
Solicitud de Certificado Envío de PK, nombre DNS y otros datos
Certificado Autoridad de
Certificación Cache
Cliente
Internet
HTTP/IPsec Cons/Resp IP de www
Serv. DNS Autoritativo
Publicación de APPKEY, nombre DNS e IP Serv. DNS
Local
Consultas Recursivas
Consultas Recursivas Cons/Resp APPKEY de www
[ Análisis del Modelo ]
Aprovechamiento del cache
→ Consulta de la dirección IP (mensajes 1 10 en el ejemplo)
→ Siguientes peticiones APPKEY
8: Consulta: IP de www.cnc.una.py 9: Resp: IP de www.cnc.una.py 2: Consulta: IP de www.cnc.una.py 3: Resp: consultar a NS py
6: Consulta: IP de www.cnc.una.py 7: Resp: consultar a NS cnc.una.py 4: Consulta: IP de www.cnc.una.py 5: Resp: consultar a NS una.py
12: Consulta: APPKEY de www.cnc.una.py 13: Resp: APPKEYde www.cnc.una.py 1: Consulta: IP de www.cnc.una.py
10: Resp: IP de www.cnc.una.py
11: Consulta: APPKEY de www.cnc.una.py 14: Resp: APPKEYde www.cnc.una.py
NS Raíz
NS py
NS una.py
NS cnc.una.py Mensajes DNS propiciados
por la Aplicación Mensajes DNS propiciados
por IKE (APPKEY) Cache
Servidor DNS Local Cliente
[ Análisis del Modelo ]
Aprovechamiento del cache
→ Cache hits de varios servidores DNS en función a la cantidad de clientes
Aquellas claves más requeridas serán recuperadas localmente
Mejor aprovechamiento del ancho de banda y una importante ventaja sobre SSL y TLS
Aciertos (%)
Cantidad de Clientes
MIT 2000-01 MIT 2000-12 KAIST 2001-05
[ Análisis del Modelo ]
Los nombres
→ PKIs basadas en CAs
Los DNs no reflejan ninguna organización jerárquica (no existen requerimientos operacionales para ello)
C=Paraguay Raíz
Inconsistencias C=Paraguay
O=Gobierno Central
OU=Secretaría de Economía
....
O=Gobierno Central O=Gobierno Nacional O=Poder Ejecutivo
C=Paraguay
O=Gobierno Nacional OU=Secretaría de Educación
....
C=Paraguay O=Poder Ejecutivo
OU=Secretaría de Educación
....
C=Paraguay Raíz
O=Empresa XYZ
CA 1 CA 2
[ Análisis del Modelo ]
Los nombres
→ Esto no ocurre con el DNS
La operación del DNS y la responsabilidad de asignación de los nombres de dominio se distribuye y delega
efectivamente de manera jerárquica.
El DNS es una verdadera estructura de árbol en la que se asegura la unicidad de los nombres
Existe una clara dependencia por parte de las CAs hacia el DNS, dado que éste es el espacio de nombres de la infraestructura de red en la que se pretende
desplegar los servicios de seguridad (En SSL se usa el FQDN en el DN del certificado)
[ Análisis del Modelo ]
Confianza y autoridad
→ Confianza (trust) y Autoridad (authority)
Las CAs son TTPs
+ La confianza es en sí misma una relación compleja, no transitiva, de carácter relativo, no cuantificable y culturalmente influenciada
+ Consecuencias para la interoperabilidad de los procedimientos de autenticación
En cambio, si una entidad es autoritativa sobre un determinado espacio de nombres, la difusa y elusiva noción de confiabilidad se vuelve irrelevante
[ Análisis del Modelo ]
Confianza y autoridad
→ Confianza (trust) y Autoridad (authority)
Uno no se cuestiona :
+ Si se deposita o no confianza en una determinada empresa para entregar carnés de identificación a sus propios empleados,
+ Si un determinado país está autorizado a expedir pasaportes a sus ciudadanos
En estos ejemplos, cada entidad emisora es autoritativa sobre el espacio de nombres en el que estas credenciales son emitidas, de modo que la confianza es intrínseca
[ Análisis del Modelo ]
Confianza y autoridad
→ Confianza (trust) y Autoridad (authority)
En Internet, cada organización tiene autoridad sobre su segmento del espacio de nombres de dominio
+ Autoridad respecto a las denominaciones
+ Autoridad respecto a los datos asociados a los nombres
+ Autoridad para delegar en una nueva zona subordinada
+ Autoridad para firmar y publicar las claves de sus entidades, empleando para ello el RR APPKEY
[ Análisis del Modelo ]
El rol de las organizaciones
→ Acaso las CAs no tiene un importante rol ?
→ Las ccTLD Authorities con orgs. de soporte
Gran similitud entre ops. registro de nombres de dominio bajo un ccTLD y las solicitudes de certificados a una CA (en la práctica es un prerequisito tener un nombre DNS)
Las ccTLD Authorities de cada país tienen un vínculo más cercano con las empresas y organizaciones
nacionales (mayor autoridad para las verificaciones)
Las CAs recurren a las bases de datos de las
ccTLD Authorities como práctica normal para validar
[ Análisis del Modelo ]
El rol de las organizaciones
→ Las ccTLD Authorities con orgs. de soporte
Las ccTLD Authorities son las entidades autoritativas para la delegación de los nombres DNS a las empresas y organizaciones con presencia en Internet en cada país.
Considérese que el DNS es el espacio de nombres de la infraestructura de red sobre la que se pretende desplegar los servicios de seguridad
[ Análisis del Modelo ]
El rol de las organizaciones
→ Las ccTLD Authorities con orgs. de soporte
Son organizaciones ampliamente reconocidas y que tienen el respaldo de la Comunidad Internet local de cada país.
Por lo general están conformadas por asociaciones de ISPs y usuarios, o Universidades, o comités multi
sectoriales, en algunos casos con la participación de agencias gubernamentales.
[ Análisis del Modelo ]
El rol de las organizaciones
→ En resumen
El modelo propuesto no sólo se plantea el uso de protocolos base de la arquitectura TCP/IP,
Además defiende el principio de que los servicios de seguridad deben apoyarse en aquellos que están más estrechamente vinculados a la infraestructura de red de Internet
+ ccTLD Authorities,
+ ISPs
+ Las mismas organizaciones usuarias
[ Análisis del Modelo ]
Cambio y revocación de claves
→ Ante una situación de clave comprometida:
La CA debe desplegar procedimientos adicionales de seguridad que pueden demorar, aumentando la latencia entre el reporte de revocación y la distribución efectiva de la información a todas las partes
En el modelo propuesto, en cambio, es más sencilla y natural esta tarea de verificación, así como la
comprobación del origen de la nueva clave
+ Estas operaciones se realizan en el ámbito interno de la misma organización
[ Análisis del Modelo ]
Cambio y revocación de claves
→ Ante una situación de clave comprometida:
Los mecanismos de remoción y de publicación y
distribución segura de la nueva clave a los usuarios,
están implícitos en el DNS y en las extensiones DNSsec, y no dependen de la intervención de una tercera parte
[ Análisis del Modelo ]
Cambio y revocación de claves
→ Ante una situación de clave comprometida:
El TTL del RR APPKEY en los caches juega un papel importante.
Es razonable pensar que éste parámetro no tiene porqué ser más prolongado que el tiempo de espera que
transcurre en una situación de reporte de revocación remitido a una CA
→ La frecuencia de renovación de las claves y el TTL en los caches son controlados por la propia organización, sin
depender de políticas particulares de las CAs
[ Análisis del Modelo ]
Bytes transmitidos
→ Handshake de SSL
[ Análisis del Modelo ]
Bytes transmitidos
→ Mensajes de la Fase 1 (modo principal) de IKE
[ Análisis del Modelo ]
Bytes transmitidos
→ Mensajes DNSsec propiciados por IKE
[ Análisis del Modelo ]
Bytes transmitidos
→ Comparación de IKE (Fase 1) y HS de SSL
Handshake de SSL 3.857
IKE F1 (principal) + DNS 2.488 (1.232 + 1.256)
Diferencia 1.369
[ Análisis del Modelo ]
Roundtrips
→ Comparación de IKE (Fase1) y HS de SSL
Handshake SSL IKE Fase 1 M.Principal IKE Fase 1 M.Agresivo 0
1 2 3 4 5 6 7 8 9 10 11 12
TCP (ACK) TCP (SSL) UDP (IKE) UDP (DNSsec)
Cantidad de Paquetes
[ Análisis del Modelo ]
Carga computacional
→ Carga computacional de la verificación
criptográfica de autenticidad de las claves públicas (y de los caminos de autenticación)
El resolver DNSsec, no la aplicación
Bueno para dispositivos móviles
Las verificaciones no se realizan siempre (caching)
→ La sobrecarga computacional teórica es apenas de 0.2% dominios de tercer nivel.
[ Implementación en base
al modelo propuesto ]
( Capítulo 7 )
[ Conclusiones ]
→ Modelo alternativo de infraestructura de seguridad
Uso de protocolos base de Internet,
Reduce la complejidad inherente al esquema de relaciones de confianza en terceras partes
→ Existen muchos usuarios y aplicaciones que precisan
Un menor grado de complejidad
Mayor versatilidad
[ Conclusiones ]
→ Nuevo registro DNS (APPKEY)
Publicar las claves asociadas a las entidades de una Org.
Las aplicaciones obtienen a través de DNSSEC las claves públicas legítimas de cada host,
Para luego establecer los servicios de seguridad
→ El modelo se completa con IPsec
Mecanismo de interacción con DNSsec para recuperar los registros APPKEY
Autenticar a las partes durante el establecimiento de una comunicación IP segura
[ Conclusiones ]
→ El modelo propuesto es
relativamente sencillo
cubre los requerimientos de un importante número de aplicaciones de seguridad,
No recurre para a certificados digitales de las CAs
→ Esto se debe a que las claves públicas son autenticadas por las propias organizaciones autoritativas sobre el
espacio de nombres de la infraestructura de red en la que se despliegan los servicios de seguridad
[ Conclusiones ]
→ Las claves públicas son localizadas y recuperadas con la misma facilidad con la que se obtienen las direcciones IP
→ Se confiere autenticación a estas claves y se otorga a las organizaciones responsables de los servicios de red, el
control de los criterios de seguridad a ser aplicados, sin depender para ello de políticas internas de las
denominadas CAs
[ Conclusiones ]
→ Una PKI que pretenda un emplazamiento extendido en toda la red Internet debe cumplir además con otros
requerimientos (servicio de directorio simple y eficaz,
escalabilidad, naturaleza distribuida, alta disponibilidad y balance de carga).
→ El DNS tiene todas estas características y el modelo propuesto las aprovecha al máximo, sin agregar una sobrecarga significativa al sistema bajo las actuales condiciones
[ Conclusiones ]
→ Ventajas respecto a aplicaciones como SSL, desde el
punto de vista de la latencia en la comunicación, medida en roundtrips, y del tamaño de los mensajes
intercambiados
→ El aprovechamiento de caching del DNS, es un importante factor que posibilita un mejor
aprovechamiento del ancho de banda, así como
un mejor desempeño computacional a nivel colectivo
[ Conclusiones ]
→ La factibilidad técnica del Modelo de Infraestructura de Seguridad basado en IPsec y DNSsec ha quedado
demostrada mediante el trabajo de desarrollo presentado
→ Se ha visto cómo, a partir de alteraciones mínimas sobre las actuales implementaciones de software de estos dos protocolos, es posible proveer servicios de seguridad
como la autenticación y la confidencialidad, sin la
necesidad de recurrir a mecanismos de certificación que dependan de agentes externos
[ Trabajos Futuros ]
→ Explorar viabilidad del modelo para la transmisión segura de mensajes de voz sobre redes IP
→ Evaluar el impacto del modelo propuesto sobre dispositivos móviles y equipos de bajo poder computacional
→ Proponer y desarrollar componentes de software que
permitan a los MUA, recuperar las claves APPKEY para brindar servicios de cifrado de mensajes y firmas digitales
[ Trabajos Futuros ]
→ Proponer extensiones al API o interfaz de programación de aplicaciones de red, con la finalidad de que éstas
dispongan de métodos capaces de dar a conocer a las capas superiores los estados de seguridad vinculados a cada flujo de información que se va recibiendo, y luego poder asociarlos a los datos reensamblados en las
aplicaciones.
[ Muchas Gracias ]
Rolando Chaparro Fox
Centro Nacional de Computación Universidad Nacional de Asunción