IPsec

В вычислении , Internet Protocol Security ( IPsec ) представляет собой безопасный сетевой набор протоколов , который аутентифицирует и шифрует в пакет , направленные данные , чтобы обеспечить безопасный обмен данными между зашифрованными двумя компьютерами над Internet Protocol сетью. Он используется в виртуальных частных сетях (VPN).

IPsec включает протоколы для установления взаимной аутентификации между агентами в начале сеанса и согласования криптографических ключей для использования во время сеанса. IPsec может защищать потоки данных между парой хостов ( хост-хост ), между парой шлюзов безопасности ( сеть-сеть ) или между шлюзом безопасности и хостом ( сеть-хост ). ^[1] IPsec использует службы криптографической безопасности для защиты связи по сетям Интернет-протокола (IP). Он поддерживает аутентификацию однорангового узла на уровне сети, аутентификацию источника данных, целостность данных, конфиденциальность данных (шифрование) и защиту от воспроизведения.

Первоначальный пакет IPv4 был разработан с некоторыми мерами безопасности. Как часть усовершенствования IPv4, IPsec представляет собой модель OSI уровня 3 или схему сквозной безопасности интернет-уровня . Напротив, в то время как некоторые другие широко используемые системы безопасности в Интернете работают над уровнем 3, например, безопасность транспортного уровня (TLS), которая работает на транспортном уровне, и Secure Shell (SSH), которая работает на уровне приложений, IPsec может автоматически защищать приложения на уровень IP.

История [ править ]

Начиная с начала 1970-х, Агентство перспективных исследовательских проектов спонсировало серию экспериментальных устройств шифрования ARPANET , сначала для собственного шифрования пакетов ARPANET, а затем для шифрования пакетов TCP / IP; некоторые из них были сертифицированы и выставлены на вооружение. С 1986 по 1991 год АНБ спонсировало разработку протоколов безопасности для Интернета в рамках своей программы Secure Data Network Systems (SDNS). ^[2] Это объединило различных поставщиков, включая Motorola, которая произвела устройство сетевого шифрования в 1988 году. Работа была открыто опубликована примерно с 1988 года NIST и, в частности, Security Protocol at Layer 3.(SP3) в конечном итоге трансформируется в стандартный протокол безопасности сетевого уровня (NLSP) ISO. ^[3]

С 1992 по 1995 годы различные группы проводили исследования в области шифрования на уровне IP.

• 1. В 1992 году Лаборатория военно-морских исследований США (NRL) начала проект Simple Internet Protocol Plus (SIPP) по исследованию и внедрению IP-шифрования.
• 2. В 1993 году в Колумбийском университете и в AT&T Bell Labs Джон Иоаннидис и другие исследовали экспериментальный программный протокол IP Encryption Protocol (swIPe) на SunOS .
• 3. В 1993 году Спонсор проекта интернет - услуг Уайтхаус, Вэй Сюй на Доверенные информационные системы (ТИС) дополнительно исследовал Программное обеспечение IP Протоколы безопасности и разработала аппаратную поддержку для тройного DES Data Encryption Standard , ^[4] , который был закодирован в BSD 4.1 и поддерживает архитектуры x86 и SUNOS. К декабрю 1994 года TIS выпустила свой продукт Gauntlet Firewall с открытым исходным кодом, спонсируемый DARPA, со встроенным аппаратным шифрованием 3DES на скоростях выше T1 . Это был первый случай использования IPSec VPN-соединений между восточным и западным побережьем Штатов, известный как первый коммерческий продукт IPSec VPN.
• 4. В рамках исследовательских усилий NRL, финансируемых DARPA , NRL разработала спецификации IETF для отслеживания стандартов (RFC 1825 - RFC 1827) для IPsec, которые были закодированы в ядре BSD 4.4 и поддерживали архитектуры процессоров x86 и SPARC. ^[5] Реализация IPsec в NRL была описана в их статье в протоколе конференции USENIX 1996 года. ^[6] Реализация IPsec с открытым исходным кодом NRL была сделана доступной в сети MIT и стала основой для большинства первоначальных коммерческих реализаций. ^[7]

Engineering Task Force Интернет (IETF) сформировала рабочую группу IP - безопасности в 1992 году ^[8] стандартизировать открыто указанные расширения безопасности для IP, называется IPsec . ^[9] В 1995 году рабочая группа организовала несколько семинаров с участием представителей пяти компаний (TIS, CISCO, FTP, Checkpoint и т. Д.). Во время семинаров по IPSec стандарты NRL и программное обеспечение Cisco и TIS стандартизируются в виде общедоступных ссылок, публикуемых как RFC-1825 - RFC-1827. ^[10]

Архитектура безопасности [ править ]

IPsec - это открытый стандарт как часть пакета IPv4. IPsec использует следующие протоколы для выполнения различных функций: ^{[11] [12]}

• Заголовки аутентификации (AH) обеспечивают целостность данных без установления соединения и аутентификацию источника данных для дейтаграмм IP и обеспечивают защиту от атак повторного воспроизведения . ^{[13] [14]}
• Инкапсуляция полезной нагрузки безопасности (ESP) обеспечивает конфиденциальность , целостность данных без установления соединения, аутентификацию источника данных , службу защиты от повторного воспроизведения (форма частичной целостности последовательности) и ограниченную конфиденциальность потока трафика. ^[1]
• Протокол Internet Security Association and Key Management Protocol (ISAKMP) обеспечивает основу для аутентификации и обмена ключами ^[15] с фактическими аутентифицированными материалами для ключей , предоставляемыми либо путем ручной настройки с предварительными общими ключами , Internet Key Exchange (IKE и IKEv2), либо с помощью Kerberized Internet Negotiation ключей (KINK) или записей DNS IPSECKEY . ^{[16] [17] [18] [19]} Цель состоит в том, чтобы сгенерировать ассоциации безопасности (SA) с набором алгоритмов и параметров, необходимых для операций AH и / или ESP.

Заголовок аутентификации [ править ]

Заголовок проверки подлинности безопасности ( AH ) был разработан в Лаборатории военно-морских исследований США в начале 1990-х годов и частично является производным от предыдущих стандартов IETF для проверки подлинности протокола SNMP версии 2. Заголовок проверки подлинности (AH) является член набора протоколов IPsec. AH обеспечивает целостность без установления соединения с помощью хэш-функции и секретного общего ключа в алгоритме AH. AH также гарантирует происхождение данных путем аутентификации IP- пакетов . Необязательно порядковый номер может защитить содержимое пакета IPsec против атак воспроизведения , ^[20] с помощью скользящего окна техника и отбрасывание старых пакетов.

• В IPv4 AH предотвращает атаки с вставкой опций. В IPv6 AH защищает как от атак вставки заголовков, так и от атак вставки опций.
• В IPv4 AH защищает полезную нагрузку IP и все поля заголовка дейтаграммы IP, за исключением изменяемых полей (т. Е. Тех, которые могут быть изменены при передаче), а также параметры IP, такие как параметр безопасности IP (RFC 1108). Изменяемые (и, следовательно, не прошедшие аутентификацию) поля заголовка IPv4 - это DSCP / ToS , ECN , флаги, смещение фрагмента , TTL и контрольная сумма заголовка . ^[14]
• В IPv6 AH защищает большую часть базового заголовка IPv6, сам AH, неизменяемые заголовки расширения после AH и полезную нагрузку IP. Защита заголовка IPv6 исключает изменяемые поля: DSCP , ECN , Flow Label и Hop Limit. ^[14]

AH работает непосредственно поверх IP, используя IP-протокол номер 51 . ^[21]

Следующая диаграмма пакета AH показывает, как создается и интерпретируется пакет AH: ^{[13] [14]}

Следующий заголовок (8 бит)

Тип следующего заголовка, указывающий, какой протокол верхнего уровня был защищен. Значение берется из списка номеров IP-протоколов .

Длина полезной нагрузки (8 бит)

Длина этого заголовка аутентификации в 4-октетных единицах минус 2. Например, значение AH, равное 4, равно 3 × (32-битные поля AH фиксированной длины) + 3 × (32-битные поля ICV) - 2 и, следовательно, значение AH, равное 4, означает 24 октета. Хотя размер измеряется в 4-октетных единицах, длина этого заголовка должна быть кратной 8 октетам, если он передается в пакете IPv6. Это ограничение не применяется к заголовку аутентификации, передаваемому в пакете IPv4.

Зарезервировано (16 бит)

Зарезервировано для использования в будущем (до этого момента все нули).

Индекс параметров безопасности (32 бита)

Произвольное значение, которое используется (вместе с IP-адресом назначения) для идентификации ассоциации безопасности принимающей стороны.

Порядковый номер (32 бита)

Монотонна строго возрастает порядковый номер (увеличивается на 1 для каждого отправленного пакета) для предотвращения повторных атак . Когда включено обнаружение воспроизведения, порядковые номера никогда не используются повторно, потому что новое сопоставление безопасности должно быть повторно согласовано перед попыткой увеличить порядковый номер сверх его максимального значения. ^[14]

Значение проверки целостности (кратное 32 битам)

Контрольное значение переменной длины. Он может содержать заполнение для выравнивания поля по 8-октетной границе для IPv6 или 4-октетной границе для IPv4 .

Инкапсуляция полезной нагрузки безопасности [ править ]

Полезная нагрузка IP Encapsulating Security Payload (ESP) ^[22] была разработана в Военно-морской исследовательской лаборатории, начиная с 1992 года как часть исследовательского проекта, спонсируемого DARPA , и была открыто опубликована рабочей группой IETF SIPP ^[23], созданной в декабре 1993 года в качестве безопасности. расширение для SIPP. Этот ESP был первоначально получен из протокола SP3D Министерства обороны США , а не на основе протокола безопасности сетевого уровня (NLSP) ISO. Спецификация протокола SP3D была опубликована NIST.в конце 1980-х, но спроектирован в рамках проекта Secure Data Network System Министерства обороны США. Инкапсуляция полезной нагрузки безопасности (ESP) является членом набора протоколов IPsec. Она обеспечивает происхождения подлинность через источник аутентификации , целостности данных с помощью хэш - функций и конфиденциальности с помощью шифрования защиты IP - пакетов . ESP также поддерживает шифрование -только и аутентификации -Только конфигурации, но с использованием шифрования без проверки подлинности настоятельно не рекомендуется , потому что это небезопасно. ^{[24] [25] [26]}

В отличие от заголовка аутентификации (AH) , ESP в транспортном режиме не обеспечивает целостность и аутентификацию для всего IP-пакета . Однако в туннельном режиме , когда весь исходный IP-пакет инкапсулируется с добавленным новым заголовком пакета, защита ESP предоставляется для всего внутреннего IP-пакета (включая внутренний заголовок), в то время как внешний заголовок (включая любые внешние параметры IPv4 или расширение IPv6 заголовки) остается незащищенным. ESP работает непосредственно поверх IP, используя IP-протокол номер 50. ^[21]

На следующей диаграмме пакетов ESP показано, как создается и интерпретируется пакет ESP: ^{[1] [27]}

Индекс параметров безопасности (32 бита)

Произвольное значение, используемое (вместе с IP-адресом назначения) для идентификации ассоциации безопасности принимающей стороны.

Порядковый номер (32 бита)

Монотонно возрастает порядковый номер (увеличивается на 1 для каждого отправленного пакета) для защиты от атак воспроизведения . Для каждой ассоциации безопасности ведется отдельный счетчик.

Данные полезной нагрузки (переменная)

Защищенное содержимое исходного IP-пакета, включая любые данные, используемые для защиты содержимого (например, вектор инициализации для криптографического алгоритма). Тип защищенного содержимого указывается в поле « Следующий заголовок» .

Заполнение (0–255 октетов)

Padding для шифрования, чтобы расширить полезные данные до размера , который соответствует шифрованию в шифре размера блока, а также для выравнивания следующего поля.

Длина контактной площадки (8 бит)

Размер заполнения (в октетах).

Следующий заголовок (8 бит)

Тип следующего заголовка. Значение берется из списка номеров IP-протоколов .

Значение проверки целостности (кратное 32 битам)

Контрольное значение переменной длины. Он может содержать заполнение для выравнивания поля по 8-октетной границе для IPv6 или 4-октетной границе для IPv4 .

Связь безопасности [ править ]

Протоколы IPsec используют ассоциацию безопасности , при которой взаимодействующие стороны устанавливают общие атрибуты безопасности, такие как алгоритмы и ключи. Таким образом, IPsec предоставляет ряд опций после того, как было определено, используется ли AH или ESP. Перед обменом данными два хоста согласовывают, какой алгоритм используется для шифрования IP-пакета, например DES или IDEA , и какая хеш-функция используется для обеспечения целостности данных, например MD5 или SHA . Эти параметры согласованы для конкретного сеанса, для которого необходимо согласовать время жизни и сеансовый ключ . ^[28]

Алгоритм аутентификации также согласовывается до передачи данных, и IPsec поддерживает ряд методов. Аутентификация возможна через предварительный общий ключ , когда симметричный ключ уже находится во владении обоих хостов, и хосты отправляют друг другу хэши общего ключа, чтобы доказать, что они обладают одним и тем же ключом. IPsec также поддерживает шифрование с открытым ключом , где каждый хост имеет открытый и закрытый ключи, они обмениваются своими открытыми ключами, и каждый узел отправляет другому одноразовый номер, зашифрованный открытым ключом другого узла. В качестве альтернативы, если оба хоста имеют сертификат открытого ключа от центра сертификации , его можно использовать для аутентификации IPsec.^[29]

Связи безопасности IPsec устанавливаются с использованием протокола сопоставления безопасности Интернета и управления ключами (ISAKMP). ISAKMP реализуется путем ручной настройки с использованием предварительно общих секретов, обмена ключами в Интернете (IKE и IKEv2), согласования ключей в Интернете по протоколу Kerberized (KINK) и использования записей DNS IPSECKEY . ^{[19] [30] [31]} RFC 5386 определяет безопасность лучше, чем ничего (BTNS) как неаутентифицированный режим IPsec с использованием расширенного протокола IKE. К. Медоуз, К. Кремерс и другие использовали формальные методы для выявления различных аномалий, существующих в IKEv1, а также в IKEv2. ^[32]

Чтобы решить, какая защита должна быть обеспечена для исходящего пакета, IPsec использует индекс параметров безопасности (SPI), индекс базы данных сопоставлений безопасности (SADB), а также адрес назначения в заголовке пакета, который вместе однозначно определяет ассоциация безопасности для этого пакета. Аналогичная процедура выполняется для входящего пакета, когда IPsec собирает ключи дешифрования и проверки из базы данных сопоставлений безопасности.

Для многоадресной IP-рассылки для группы предоставляется ассоциация безопасности, которая дублируется для всех авторизованных получателей группы. Для группы может быть несколько ассоциаций безопасности, использующих разные SPI, что позволяет использовать несколько уровней и наборов безопасности внутри группы. Действительно, у каждого отправителя может быть несколько ассоциаций безопасности, позволяющих аутентификацию, поскольку получатель может знать только то, что кто-то, знающий ключи, отправил данные. Обратите внимание, что соответствующий стандарт не описывает, как ассоциация выбирается и дублируется в группе; предполагается, что выбор сделает ответственная сторона.

Режимы работы [ править ]

Протоколы IPsec AH и ESP могут быть реализованы в транспортном режиме от хоста к хосту, а также в режиме сетевого туннелирования.

Транспортный режим [ править ]

В транспортном режиме обычно шифруется или аутентифицируется только полезная нагрузка IP-пакета . Маршрутизация остается неизменной, поскольку заголовок IP не изменяется и не зашифрован; однако, когда используется заголовок аутентификации , IP-адреса не могут быть изменены преобразованием сетевых адресов , так как это всегда делает недействительным значение хеш-функции . На транспортные и прикладные слои всегда обеспечены хэша, так что они не могут быть изменены каким - либо образом, например , путем перевода на порт номера.

Средства инкапсуляции сообщений IPsec для прохождения NAT были определены в документах RFC, описывающих механизм NAT-T .

Туннельный режим [ править ]

В туннельном режиме весь IP-пакет зашифрован и аутентифицирован. Затем он инкапсулируется в новый IP-пакет с новым IP-заголовком. Туннельный режим используется для создания виртуальных частных сетей для связи между сетями (например, между маршрутизаторами для связывания сайтов), обмена данными между хостами (например, удаленный доступ пользователей) и обмена данными между хостами (например, частный чат). ^[33]

Туннельный режим поддерживает обход NAT.

Алгоритмы [ править ]

Алгоритмы симметричного шифрования [ править ]

Криптографические алгоритмы, определенные для использования с IPsec, включают:

• HMAC - SHA1 / SHA2 для защиты целостности и аутентичности.
• TripleDES - CBC для конфиденциальности
• AES- CBC и AES-CTR для конфиденциальности.
• AES - GCM и ChaCha20 - Poly1305 обеспечения конфиденциальности и аутентификации вместе эффективно.

Подробную информацию см. В RFC 8221.

Алгоритмы обмена ключами [ править ]

• Диффи – Хеллмана (RFC 3526)
• ECDH (RFC 4753)

Алгоритмы аутентификации [ править ]

• ЮАР
• ECDSA (RFC 4754)
• PSK (RFC 6617)

Реализации [ править ]

IPsec может быть реализован в стеке IP операционной системы , что требует модификации исходного кода. Этот метод реализации предназначен для хостов и шлюзов безопасности. Различные IP-стеки с поддержкой IPsec доступны от таких компаний, как HP или IBM. ^[34] Альтернативой является так называемая реализация Bump-in-the-stack (BITS), при которой не нужно изменять исходный код операционной системы. Здесь IPsec устанавливается между стеком IP и сетевыми драйверами . Таким образом операционные системы могут быть дооснащены IPsec. Этот метод реализации также используется как для хостов, так и для шлюзов. Однако при модернизации IPsec инкапсуляция IP-пакетов может вызвать проблемы для автоматическогообнаружение MTU пути , при котором устанавливается максимальный размер блока передачи (MTU) на сетевом пути между двумя IP-узлами. Если у хоста или шлюза есть отдельный криптопроцессор , который широко используется в вооруженных силах, а также может быть найден в коммерческих системах, возможна так называемая реализация IPsec с технологией Bump-in-the-Wire (BITW). ^[35]

Когда IPsec реализован в ядре , управление ключами и согласование ISAKMP / IKE осуществляется из пользовательского пространства. Разработанный NRL и открыто указанный "API управления ключами PF_KEY, версия 2" часто используется, чтобы позволить приложению управления ключами пространства приложений обновлять сопоставления безопасности IPsec, хранящиеся в реализации IPsec пространства ядра. ^[36] Существующие реализации IPsec обычно включают ESP, AH и IKE версии 2. Существующие реализации IPsec в UNIX-подобных операционных системах, например, Solaris или Linux, обычно включают PF_KEY версии 2.

Встроенный IPsec может использоваться для обеспечения безопасной связи между приложениями, работающими в системах с ограниченными ресурсами, с небольшими накладными расходами. ^[37]

Статус стандартов [ править ]

IPsec был разработан вместе с IPv6 и изначально должен был поддерживаться всеми совместимыми со стандартами реализациями IPv6, прежде чем RFC 6434 сделал это только рекомендацией. ^[38] IPsec также является необязательным для реализаций IPv4 . IPsec чаще всего используется для защиты трафика IPv4. ^{[ необходима цитата ]}

Протоколы IPsec были первоначально определены в RFC 1825 - RFC 1829, которые были опубликованы в 1995 году. В 1998 году эти документы были заменены RFC 2401 и RFC 2412 с некоторыми несовместимыми инженерными деталями, хотя они были концептуально идентичны. Кроме того, был определен протокол взаимной аутентификации и обмена ключами Internet Key Exchange (IKE) для создания ассоциаций безопасности и управления ими. В декабре 2005 г. новые стандарты были определены в RFC 4301 и RFC 4309, которые в значительной степени представляют собой надмножество предыдущих редакций со второй версией стандарта Internet Key Exchange IKEv2 . Эти документы третьего поколения стандартизировали сокращение IPsec до прописных «IP» и строчных «sec». «ESP» обычно относится к RFC 4303, который является самой последней версией спецификации.

С середины 2008 г. в IETF действует рабочая группа по обслуживанию и расширению IPsec (ipsecme). ^{[39] [40]}

Предполагаемое вмешательство АНБ [ править ]

В 2013 годе , как часть утечек Snowden , было выявлено , что США Агентство национальной безопасности было активно работает «Вставка уязвимостей в коммерческие системы шифрования, информационные системы, сети и устройства связи конечных точек , используемых целями» в рамках Bullrun программы . ^[41] Есть утверждения, что IPsec был целевой системой шифрования. ^[42]

Стек OpenBSD IPsec появился позже и также был широко скопирован. В письме, которое ведущий разработчик OpenBSD Тео де Раадт получил 11 декабря 2010 года от Грегори Перри, утверждается, что Джейсон Райт и другие, работающие на ФБР, вставили «ряд бэкдоров и механизмов утечки ключей побочного канала » в криптографию OpenBSD. код. В переадресованном электронном письме от 2010 года Тео де Раадт сначала не выразил официальной позиции по обоснованности претензий, за исключением неявного подтверждения от пересылки электронного письма. ^[43]Ответ Джейсона Райта на обвинения: «Каждая городская легенда становится более реальной благодаря включению реальных имен, дат и времени. Электронная почта Грегори Перри попадает в эту категорию… Я четко заявляю, что я не добавлял бэкдоры в операционную систему OpenBSD. системе или криптографической платформе OpenBSD (OCF) ». ^[44] Несколько дней спустя де Раадт прокомментировал: «Я считаю, что NETSEC, вероятно, заключила контракт на написание бэкдоров, как якобы… Если бы они были написаны, я не думаю, что они вошли в наше дерево». ^[45] Это было опубликовано до утечки информации о Сноудене.

Альтернативное объяснение, выдвинутое авторами атаки Logjam, предполагает, что АНБ взломало IPsec VPN, подорвав алгоритм Диффи-Хеллмана , используемый при обмене ключами. В своей статье ^[46] они утверждают, что АНБ специально построило вычислительный кластер для предварительного вычисления мультипликативных подгрупп для определенных простых чисел и генераторов, например, для второй группы Oakley, определенной в RFC 2409. По состоянию на май 2015 года 90% адресных IPsec VPN поддерживали вторая группа Oakley в составе IKE. Если организация должна предварительно вычислить эту группу, она могла бы получить ключи, которыми обмениваются, и расшифровать трафик, не вставляя никаких программных бэкдоров.

Второе альтернативное объяснение, которое было выдвинуто, заключалось в том, что Equation Group использовала эксплойты нулевого дня против VPN-оборудования нескольких производителей, которые были проверены « Лабораторией Касперского» как привязанные к Equation Group ^[47] и подтвержденные этими производителями как реальные эксплойты. некоторые из них были эксплойтами нулевого дня на момент их раскрытия. ^{[48] [49] [50]} Cisco PIX и ASA брандмауэры были слабые места, которые были использованы для прослушки АНБ ^{[ править ]} .

Более того, IPsec VPN, использующие настройки «Агрессивного режима», отправляют хэш PSK в открытом виде. Это может быть и, по-видимому, является целью NSA, использующего автономные словарные атаки. ^{[51] [52] [53]}

Документация IETF [ править ]

Трек стандартов [ править ]

• RFC 1829: преобразование ESP DES-CBC
• RFC 2403: Использование HMAC-MD5-96 в ESP и AH
• RFC 2404: Использование HMAC-SHA-1-96 в ESP и AH
• RFC 2405: алгоритм шифрования ESP DES-CBC с явным IV
• RFC 2410: алгоритм шифрования NULL и его использование с IPsec
• RFC 2451: алгоритмы шифрования ESP в режиме CBC
• RFC 2857: Использование HMAC-RIPEMD-160-96 в ESP и AH
• RFC 3526: больше модульных экспоненциальных (MODP) групп Диффи-Хеллмана для обмена ключами в Интернете (IKE)
• RFC 3602: алгоритм шифрования AES-CBC и его использование с IPsec
• RFC 3686: Использование режима счетчика Advanced Encryption Standard (AES) с IPsec Encapsulating Security Payload (ESP)
• RFC 3947: Согласование прохождения NAT в IKE
• RFC 3948: UDP-инкапсуляция пакетов IPsec ESP
• RFC 4106: Использование режима Галуа / счетчика (GCM) в IPsec Encapsulating Security Payload (ESP)
• RFC 4301: Архитектура безопасности для Интернет-протокола
• RFC 4302: заголовок аутентификации IP
• RFC 4303: полезная нагрузка IP-инкапсуляции безопасности
• RFC 4304: Дополнение с расширенным порядковым номером (ESN) к домену интерпретации IPsec (DOI) для протокола ассоциации безопасности Интернета и протокола управления ключами (ISAKMP)
• RFC 4307: криптографические алгоритмы для использования в Internet Key Exchange версии 2 ( IKEv2 )
• RFC 4308: криптографические пакеты для IPsec
• RFC 4309: Использование режима CCM Advanced Encryption Standard (AES) с IPsec Encapsulating Security Payload (ESP)
• RFC 4543: Использование кода аутентификации сообщений Галуа (GMAC) в IPsec ESP и AH
• RFC 4555: протокол мобильности и множественной адресации IKEv2 (MOBIKE)
• RFC 4806: Расширения протокола состояния онлайн-сертификатов (OCSP) для IKEv2
• RFC 4868: Использование HMAC-SHA-256, HMAC-SHA-384 и HMAC-SHA-512 с IPsec
• RFC 4945: Профиль PKI безопасности IP в Интернете для IKEv1 / ISAKMP, IKEv2 и PKIX
• RFC 5280: Сертификат инфраструктуры открытого ключа Internet X.509 и профиль отзыва сертификатов (CRL)
• RFC 5282: Использование аутентифицированных алгоритмов шифрования с зашифрованной полезной нагрузкой протокола Internet Key Exchange версии 2 (IKEv2)
• RFC 5386: Безопасность лучше, чем ничего: режим IPsec без аутентификации
• RFC 5529: Режимы работы Camellia для использования с IPsec
• RFC 5685: механизм перенаправления для протокола обмена ключами в Интернете версии 2 (IKEv2)
• RFC 5723: возобновление сеанса протокола обмена ключами Интернета версии 2 (IKEv2)
• RFC 5857: расширения IKEv2 для поддержки надежного сжатия заголовков через IPsec
• RFC 5858: расширения IPsec для поддержки надежного сжатия заголовков по IPsec
• RFC 7296: протокол обмена ключами в Интернете версии 2 (IKEv2)
• RFC 7321: Требования к реализации криптографического алгоритма и руководство по использованию для инкапсуляции полезной нагрузки безопасности (ESP) и заголовка аутентификации (AH)
• RFC 7383: фрагментация сообщений протокола обмена ключами в Интернете версии 2 (IKEv2)
• RFC 7427: Аутентификация подписи в Internet Key Exchange версии 2 (IKEv2)
• RFC 7634: ChaCha20, Poly1305 и их использование в протоколе обмена ключами в Интернете (IKE) и IPsec

Экспериментальные RFC [ править ]

• RFC 4478: повторная проверка подлинности в протоколе обмена ключами в Интернете (IKEv2)

Информационные RFC [ править ]

• RFC 2367: интерфейс PF_KEY
• RFC 2412: протокол определения ключа OAKLEY
• RFC 3706: основанный на трафике метод обнаружения неработающих узлов обмена ключами в Интернете (IKE)
• RFC 3715: Требования совместимости IPsec с трансляцией сетевых адресов (NAT)
• RFC 4621: Разработка протокола мобильности и множественной адресации IKEv2 (MOBIKE)
• RFC 4809: Требования к профилю управления сертификатом IPsec
• RFC 5387: Заявление о проблеме и применимости для безопасности Better-Than-Nothing (BTNS)
• RFC 5856: интеграция надежного сжатия заголовков через ассоциации безопасности IPsec
• RFC 5930: Использование стандартного режима счетчика расширенного шифрования (AES-CTR) с протоколом Internet Key Exchange версии 02 (IKEv2)
• RFC 6027: Описание проблемы кластера IPsec
• RFC 6071: план разработки документов IPsec и IKE
• RFC 6379: криптографические наборы Suite B для IPsec
• RFC 6380: профиль Suite B для защиты интернет-протокола (IPsec)
• RFC 6467: Secure Password Framework для Internet Key Exchange версии 2 (IKEv2)

RFC с лучшими текущими практиками [ править ]

• RFC 5406: Рекомендации по определению использования IPsec версии 2

Устаревшие / исторические RFC [ править ]

• RFC 1825: Архитектура безопасности для Интернет-протокола (устарела RFC 2401)
• RFC 1826: заголовок аутентификации IP (устарел RFC 2402)
• RFC 1827: IP Encapsulating Security Payload (ESP) (устарело в соответствии с RFC 2406)
• RFC 1828: IP-аутентификация с использованием ключа MD5 (исторический)
• RFC 2401: Архитектура безопасности для Интернет-протокола (обзор IPsec) (устарело в соответствии с RFC 4301)
• RFC 2406: IP Encapsulating Security Payload (ESP) (устарело в соответствии с RFC 4303 и RFC 4305)
• RFC 2407: Internet IP Security Domain of Interpretation for ISAKMP (устарело RFC 4306)
• RFC 2409: Интернет-обмен ключами (устарело в соответствии с RFC 4306)
• RFC 4305: Требования к реализации криптографического алгоритма для инкапсуляции полезной нагрузки безопасности (ESP) и заголовка аутентификации (AH) (устарело в соответствии с RFC 4835)
• RFC 4306: протокол обмена ключами в Интернете (IKEv2) (устарел RFC 5996)
• RFC 4718: Разъяснения и рекомендации по реализации IKEv2 (устарело RFC 7296)
• RFC 4835: Требования к реализации криптографического алгоритма для инкапсуляции полезной нагрузки безопасности (ESP) и заголовка аутентификации (AH) (устарело в соответствии с RFC 7321)
• RFC 5996: протокол обмена ключами в Интернете версии 2 (IKEv2) (устарел RFC 7296)

См. Также [ править ]

• Динамическая многоточечная виртуальная частная сеть
• Информационная безопасность
• Обход NAT
• Оппортунистическое шифрование
• tcpcrypt

Ссылки [ править ]

Внешние ссылки [ править ]

• Компьютерная безопасность в Curlie
• Все рабочие группы IETF по активной безопасности
  • IETF ipsecme WG (Рабочая группа по поддержке и расширению IP-безопасности)
  • IETF btns WG (рабочая группа «Безопасность лучше, чем ничего») (уполномочена работать с IPsec без аутентификации, API IPsec, фиксацией соединений)]
• Защита данных при передаче с помощью IPsec Статья Деб Шиндер на WindowsSecurity.com
• IPsec в Microsoft TechNet
  • Средство диагностики Microsoft IPsec в Центре загрузки Майкрософт
• Иллюстрированное руководство по IPsec Стива Фридла
• Архитектура безопасности для передачи данных IP (IPsec) Лекции Манфреда Линднера Часть IPsec
• Создание виртуальных частных сетей с использованием IPsec и SSL / TLS Статья в Linux Journal Рами Розена