IPsec

IPsec(abreviatura deInternet Protocol security) es un conjunto de protocolos cuya función es asegurar las comunicaciones sobre elProtocolo de Internet(IP)autenticandoy/ocifrandocadapaquete IPen un flujo de datos. IPsec también incluye protocolos para elestablecimiento de claves de cifrado.^[1]

Resumen

Los protocolos deIPsecactúan en la capa de red, la capa 3 delmodelo OSI.Otros protocolos de seguridad para Internet de uso extendido, comoSSL,TLSySSHoperan de la capa de aplicación (capa 7 del modelo OSI). Esto hace que IPsec sea más flexible, ya que puede ser utilizado para proteger protocolos de la capa 4, incluyendoTCPyUDP.

Arquitectura de seguridad

IPsecestá implementado por un conjunto deprotocolos criptográficospara:

asegurar el flujo de paquetes,
garantizar laautenticación mutua,
establecer parámetros criptográficos.

La arquitectura de seguridad IP utiliza el concepto deasociación de seguridad(SA) como base para construir funciones de seguridad enIP.Una asociación de seguridad es simplemente el paquete de algoritmos y parámetros (tales como las claves) que se está usando para cifrar y autenticar un flujo particular en una dirección. Por lo tanto, en el tráfico normal bidireccional, los flujos son asegurados por un par de asociaciones de seguridad. La decisión final de los algoritmos de cifrado y autenticación (de una lista definida) le corresponde al administrador de IPsec.

Para decidir qué protección se va a proporcionar a un paquete saliente, IPsec utiliza el índice de parámetro de seguridad (SPI), un índice a la base de datos de asociaciones de seguridad (SADB), junto con la dirección de destino de la cabecera del paquete, que juntos identifican de forma única una asociación de seguridad para dicho paquete. Para un paquete entrante se realiza un procedimiento similar; en este caso IPsec toma las claves de verificación y descifrado de la base de datos de asociaciones de seguridad.

En el caso de multicast, se proporciona una asociación de seguridad al grupo, y se duplica para todos los receptores autorizados del grupo. Puede haber más de una asociación de seguridad para un grupo, utilizando diferentes SPIs, y por ello permitiendo múltiples niveles y conjuntos de seguridad dentro de un grupo. De hecho, cada remitente puede tener múltiples asociaciones de seguridad, permitiendo autenticación, ya que un receptor solo puede saber que alguien que conoce las claves ha enviado los datos. Hay que observar que el estándar pertinente no describe cómo se elige y duplica la asociación a través del grupo; se asume que un interesado responsable habrá hecho la elección..

Estado actual del estándar

IPsec fue una parte obligatoria deIPv6con base en la definición delRFC 4294,no obstante, en el año 2011, este RFC fue obsoleto por elRFC 6434el cual indica que IPsec es recomendado y no obligatorio para IPv6. ParaIPv4,su uso es opcional. Aunque el estándar está diseñado para ser indiferente a las versiones de IP, el despliegue y experiencia hasta 2007 atañe a las implementaciones deIPv4.

Los protocolos de IPsec se definieron originalmente en lasRFCs1825 y 1829, publicadas en 1995. En 1998 estos documentos fueron sustituidos por lasRFCs2401 y 2412, que no son compatibles con la 1825 y 1829, aunque son conceptualmente idénticas. En diciembre de 2005 se produjo la tercera generación de documentos,RFCs4301 y 4309. Son en gran parte un superconjunto de la 2401 y 2412, pero proporcionan un segundo estándar deInternet Key Exchange.Esta tercera generación de documentos estandarizó la abreviatura de IPsec como "IP" en mayúsculas y "sec" en minúsculas.

Es raro ver un producto que ofrezca soporte de RFC1825 y 1829. "ESP" se refiere generalmente a 2406, mientras que ESPbis se refiere a 4303.

Propósito de diseño

IPsec fue proyectado para proporcionar seguridad enmodo transporte(extremo a extremo) del tráfico de paquetes, en el que los ordenadores de los extremos finales realizan el procesado de seguridad, o enmodo túnel(puerta a puerta) en el que la seguridad del tráfico de paquetes es proporcionada a varias máquinas (incluso a toda lared de área local) por un único nodo.

IPsec puede utilizarse para crearVPNsen los dos modos, y este es su uso principal. Hay que tener en cuenta, sin embargo, que las implicaciones de seguridad son bastante diferentes entre los dos modos de operación.

La seguridad de comunicaciones extremo a extremo a escala Internet se ha desarrollado más lentamente de lo esperado. Parte de la razón a esto es que no ha surgidoinfraestructura de clave públicauniversal o universalmente de confianza (DNSSECfue originalmente previsto para esto); otra parte es que muchos usuarios no comprenden lo suficientemente bien ni sus necesidades ni las opciones disponibles como para promover su inclusión en los productos de los vendedores.

Como elProtocolo de Internetno provee intrínsecamente de ninguna capacidad de seguridad, IPsec se introdujo para proporcionar servicios de seguridad tales como:

Cifrar el tráfico (de forma que no pueda ser leído por nadie más que las partes a las que está dirigido)
Validación de integridad (asegurar que el tráfico no ha sido modificado a lo largo de su trayecto)
Autenticar a los extremos (asegurar que el tráfico proviene de un extremo de confianza)
Anti-repetición (proteger contra la repetición de la sesión segura).

Modos

Así pues y dependiendo del nivel sobre el que se actúe, podemos establecer dos modos básicos de operación deIPsec:modo transporteymodo túnel.

Modo transporte

Enmodo transporte,solo lacarga útil(los datos que se transfieren) del paquete IP escifradao autenticada. El enrutamiento permanece intacto, ya que no se modifica ni se cifra la cabecera IP; sin embargo, cuando se utiliza lacabecera de autenticación(AH), las direcciones IP no pueden sertraducidas,ya que eso invalidaría elhash.Las capas detransportey aplicación están siempre aseguradas por un hash, de forma que no pueden ser modificadas de ninguna manera (por ejemplotraduciendolos números depuertoTCP y UDP). Elmodo transportese utiliza para comunicaciones ordenador a ordenador.

Una forma de encapsular mensajes IPsec para atravesar NAT ha sido definido porRFCsque describen el mecanismo deNAT transversal.

Modo túnel

En elmodo túnel,todo el paquete IP (datos más cabeceras del mensaje) es cifrado o autenticado. Debe ser entonces encapsulado en un nuevo paquete IP para que funcione el enrutamiento. Elmodo túnelse utiliza para comunicaciones red a red (túneles seguros entre routers, p.e. paraVPNs) o comunicaciones ordenador a red u ordenador a ordenador sobreInternet.

Protocolos

IPsecconsta de tres protocolos que han sido desarrollados para proporcionar seguridad a nivel de paquete, tanto paraIPv4como paraIPv6:

Authentication Header(AH) proporciona integridad, autenticación y no repudio si se eligen los algoritmos criptográficos apropiados.
Encapsulating Security Payload(ESP) proporciona confidencialidad y la opción -altamente recomendable- de autenticación y protección de integridad.
Internet key exchange(IKE) emplea un intercambio secreto de claves de tipoDiffie-Hellmanpara establecer elsecreto compartido de la sesión.Se suelen usar sistemas deCriptografía de clave públicao clave pre-compartida.

Los algoritmos criptográficos definidos para usar con IPsec incluyenHMAC-SHA-1para protección de integridad, yTriple DES-CBCyAES-CBC para confidencialidad. Más detalles en laRFC 4305.

Authentication Header (AH)

AH está dirigido a garantizar integridad, sin conexión y autenticación de los datos de origen de los datagramas IP. Para ello, calcula un Hash Message Authentication Code (HMAC) a través de algún algoritmohashoperando sobre una clave secreta, el contenido del paquete IP y las partes inmutables del datagrama. Este proceso restringe la posibilidad de emplearNAT,que puede ser implementada conNAT transversal.Por otro lado, AH puede proteger opcionalmente contra ataques de repetición utilizando la técnica deventana deslizantey descartando paquetes viejos. AH protege la carga útil IP y todos los campos de la cabecera de un datagrama IP excepto los campos mutantes, es decir, aquellos que pueden ser alterados en el tránsito. En IPv4, los campos de la cabecera IP mutantes (y por lo tanto no autenticados) incluyenTOS,Flags, Offset de fragmentos,TTLysuma de verificaciónde la cabecera. AH opera directamente por encima de IP, utilizando el protocolo IP número 51. UnacabeceraAH mide 32 bits, he aquí un diagrama de cómo se organizan:

0 - 7 bit	8 - 15 bit	16 - 23 bit
Next header	Payload length	RESERVED
Security parameters index (SPI)
Sequence number
Hash Message Authentication Code (variable)

Significado de los campos:

Next header: Identifica el protocolo de los datos transferidos.
Payload length: Tamaño del paquete AH.
RESERVED: Reservado para uso futuro (hasta entonces todo ceros).
Security parameters index (SPI): Indica los parámetros de seguridad que, en combinación con la dirección IP, identifican la asociación de seguridad implementada con este paquete.
Sequence number: Un número siempre creciente, utilizado para evitar ataques de repetición.
HMAC: Contiene el valor de verificación de integridad (ICV) necesario para autenticar el paquete; puede contener relleno.

Encapsulating Security Payload (ESP)

El protocolo ESP proporciona autenticidad de origen, integridad y protección de confidencialidad de un paquete. ESP también soporta configuraciones de solo cifrado y solo autenticación, pero utilizar cifrado sin autenticación está altamente desaconsejado porque es inseguro^[2]^[3] .^[4] Al contrario que con AH, la cabecera del paquete IP no está protegida por ESP (aunque en ESP en modo túnel, la protección es proporcionada a todo el paquete IP interno, incluyendo la cabecera interna; la cabecera externa permanece sin proteger). ESP opera directamente sobre IP, utilizando el protocolo IP número 50.

Un diagrama de paquete ESP:

0 - 7 bit	8 - 15 bit	16 - 23 bit	24 - 31 bit
Security parameters index (SPI)
Sequence number
Payload data (variable)
	Padding (0-255 bytes)
		Pad Length	Next Header
Authentication Data (variable)

Significado de los campos

Security parameters index (SPI): Identifica los parámetros de seguridad en combinación con la dirección IP.
Sequence number: Un número siempre creciente, utilizado para evitar ataques de repetición.
Payload data: Los datos a transferir.
Padding: Usado por algunos algoritmos criptográficos para rellenar por completo los bloques.
Pad length: Tamaño del relleno en bytes.
Next header: Identifica el protocolo de los datos transferidos.
Authentication data: Contiene los datos utilizados para autenticar el paquete.

Implementaciones

El soporte de IPsec está normalmente implementado en elnúcleocon la gestión de claves y negociación deISAKMP/IKErealizada en espacio de usuario. Las implementaciones de IPsec existentes suelen incluir ambas funcionalidades. Sin embargo, como hay una interfaz estándar para la gestión de claves, es posible controlar una pila IPsec de núcleo utilizando las herramientas de gestión de claves de una implementación distinta.

Por esta razón, hay confusión en los orígenes de la implementación de IPsec que se encuentra en el núcleoLinux.El proyectoFreeS/WANrealizó la primera implementación completa y decódigo abiertode IPsec paraLinux.Consiste en una pila IPsec de núcleoKLIPS,junto con undemonio(pluto) y muchos scripts deshell.El proyecto FreeS/WAN fue desmantelado en marzo de 2004.OpenswanystrongSwanson continuaciones de FreeS/WAN. Elproyecto KAMEtambién implementó soporte IPsec completo paraNetBSDyFreeBSD.Su demonio de gestión de claves se llamaracoon.OpenBSDhizo su propio demonio ISAKMP/IKE, llamado simplemente isakmpd (y ha sido portado a otros sistemas, incluyendoLinux).

Sin embargo, ninguna de estas pilas IPsec de núcleo estaba integrada en Linux.Alexey KuznetsovyDavid S. Millerescribieron desde cero una implementación de IPsec de núcleo para Linux alrededor de finales de 2002. Esta pila fue posteriormente lanzada como parte de Linux 2.6, y es llamada por varios "nativa" o "NETKEY".

Por lo tanto, contrariamente a la creencia popular, la pila IPsec de Linux no se originó en el proyecto KAME. Como soporta el protocolo estándarPF KEY(RFC 2367) y el intefaz nativoXFRMpara gestión de claves, la pila IPsec de Linux puede utilizarse junto conplutodeOpenswan/strongSwan,isakmpddel proyectoOpenBSD,racoondelproyecto KAMEo sin ningún demonio ISAKMP/IKE (utilizando claves manuales).

Las nuevas arquitecturas de procesadores de red, incluyendo procesadores multinúcleo con motores de cifrado integrados, han cambiado la forma en que las pilas IPsec son diseñadas. Un Fast Path dedicado es utilizado para descargar el procesado de las tareas de IPsec (SA, búsquedas SP, cifrado, etc). Estas pilas Fast Path deben estar cointegradas en núcleos dedicados con Linux o RTOS corriendo en otros núcleos. Estos SO son el plano de control que ejecuta ISAKMP/IKE de la pila IPsec Fast Path.

Hay bastantes implementaciones de los protocolosIPsece ISAKMP/IKE. Entre otras:

6WINDGate,pila IPsec Fast Path para procesador de red multinúcleo
NRL[1]Archivadoel 8 de agosto de 2007 enWayback Machine.IPsec, una de las fuentes originales de código IPsec[2]
OpenBSD,con su propio código derivado de NRL IPsec
La pila deKAME,que está incluida enMac OS X,NetBSDyFreeBSD
"IPsec" en elsoftware IOS de Cisco [3]
"IPsec" enMicrosoft Windows,incluyendo Windows XP[4][5],Windows 2000[6],y Windows 2003[7]
Las herramientas QuickSec de SafeNet[8]
IPsec enSolaris [9]
El sistema operativoAIXdeIBM
z/OSdeIBM
IPsec e IKE enHP-UX(HP-UX IPSec)
"IPsec e IKE" enVxWorks[10](enlace rotodisponible enInternet Archive;véase elhistorial,laprimera versióny laúltima).

Lista de RFCs relacionados con IPsec

RFC 2327:PF_KEY Interface
RFC 2367:PF_KEY Interface
RFC 2401(sustituye aRFC 1825y fue sustituida porRFC 4301): Security Architecture for the Internet Protocol
RFC 2402(sustituida porRFC 4302yRFC 4305): Authentication Header
RFC 2403:The Use of HMAC-MD5-96 within ESP and AH
RFC 2404:The Use of HMAC-SHA-1-96 within ESP and AH
RFC 2405:The ESP DES-CBC Cipher Algorithm With Explicit IV
RFC 2406(sustituida porRFC 4303yRFC 4305): Encapsulating Security Payload
RFC 2407(sustituida porRFC 4306): IPsec Domain of Interpretation for ISAKMP (IPsec DoI)
RFC 2408(sustituida porRFC 4306): Internet Security Association and Key Management Protocol (ISAKMP)
RFC 2409(sustituida porRFC 4306): Internet Key Exchange (IKE)
RFC 2410:The NULL Encryption Algorithm and Its Use With IPsec
RFC 2411:IP Security Document Roadmap
RFC 2412:(sustituye aRFC 1829) The OAKLEY Key Determination Protocol
RFC 2451:The ESP CBC-Mode Cipher Algorithms
RFC 2857:The Use of HMAC-RIPEMD-160-96 within ESP and AH
RFC 3526:More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
RFC 3706:A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
RFC 3715:IPsec-Network Address Translation (NAT) Compatibility Requirements
RFC 3947:Negotiation of NAT-Traversal in the IKE
RFC 3948:UDP Encapsulation of IPsec ESP Packets
RFC 4106:The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
RFC 4301(sustituye aRFC 2401): Security Architecture for the Internet Protocol
RFC 4302(sustituye aRFC 2402): IP Authentication Header
RFC 4303(sustituye aRFC 2406): IP Encapsulating Security Payload (ESP)
RFC 4304:Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
RFC 4305(sustituida porRFC 4835): Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
RFC 4306(sustituye aRFC 2407,RFC 2408,andRFC 2409): Internet Key Exchange (IKEv2) Protocol
RFC 4307:Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
RFC 4308:Cryptographic Suites for IPsec
RFC 4309:Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
RFC 4478:Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
RFC 4543:The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
RFC 4555:IKEv2 Mobility and Multihoming Protocol (MOBIKE)
RFC 4621:Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
RFC 4718:IKEv2 Clarifications and Implementation Guidelines
RFC 4806:Online Certificate Status Protocol (OCSP) Extensions to IKEv2
RFC 4809:Requirements for an IPsec Certificate Management Profile
RFC 4835(sustituye aRFC 4305): Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
RFC 4945:The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX

Referencias

↑Marqués, Guillermo (12 de enero de 2016).IPsec y redes privadas virtuales.Lulu.com.ISBN 978-1-329-82419-5.Consultado el 3 de octubre de 2021.
↑Bellovin, Steven M. (1996).«Problem Areas for the IP Security Protocols».Proceedings of the Sixth Usenix Unix Security Symposium.San Jose, CA. pp. 1-16.Consultado el 13 de noviembre de 2007.
↑K.G. Paterson y A. Yau (2006).«Cryptography in theory and practice: The case of encryption in IPsec».Eurocrypt 2006, Lecture Notes in Computer Science Vol. 4004.pp. 12-29.Consultado el 13 de noviembre de 2007.Texto « Berlin » ignorado (ayuda)
↑J.P. Degabriele y K.G. Paterson (2007).«Attacking the IPsec Standards in Encryption-only Configurations».IEEE Symposium on Security and Privacy, IEEE Computer Society.pp. 335-349.Consultado el 13 de noviembre de 2007.Texto « Oakland, CA » ignorado (ayuda)

Datos:Q210214
Multimedia:IPsec/Q210214

[1] Marqués, Guillermo (12 de enero de 2016).IPsec y redes privadas virtuales.Lulu.com.ISBN 978-1-329-82419-5.Consultado el 3 de octubre de 2021.

[2] Bellovin, Steven M. (1996).«Problem Areas for the IP Security Protocols».Proceedings of the Sixth Usenix Unix Security Symposium.San Jose, CA. pp. 1-16.Consultado el 13 de noviembre de 2007.

[3] K.G. Paterson y A. Yau (2006).«Cryptography in theory and practice: The case of encryption in IPsec».Eurocrypt 2006, Lecture Notes in Computer Science Vol. 4004.pp. 12-29.Consultado el 13 de noviembre de 2007.Texto « Berlin » ignorado (ayuda)

[4] J.P. Degabriele y K.G. Paterson (2007).«Attacking the IPsec Standards in Encryption-only Configurations».IEEE Symposium on Security and Privacy, IEEE Computer Society.pp. 335-349.Consultado el 13 de noviembre de 2007.Texto « Oakland, CA » ignorado (ayuda)

[1]

[2]

[3]

[4]