stringtranslate.com

IPsec

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

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

История

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

В 1992 году Лаборатория военно-морских исследований США (NRL) получила финансирование от DARPA CSTO для внедрения IPv6 и исследования и внедрения IP-шифрования в 4.4 BSD , поддерживающей архитектуры как SPARC, так и x86. DARPA предоставила свою реализацию в свободном доступе через MIT. В рамках финансируемых DARPA исследовательских усилий NRL, NRL разработала спецификации IETF standards-track (RFC 1825 по RFC 1827) для IPsec. [4] Реализация IPsec от NRL была описана в их статье в материалах конференции USENIX 1996 года . [5] Реализация IPsec с открытым исходным кодом от NRL была размещена в Интернете MIT и стала основой для большинства первоначальных коммерческих реализаций. [4]

Целевая группа по инжинирингу Интернета ( IETF ) сформировала рабочую группу по безопасности IP в 1992 году [6] для стандартизации открыто указанных расширений безопасности IP, называемых IPsec . [7] Разработанные NRL стандарты были опубликованы IETF как RFC 1825 — RFC 1827. [8]

Архитектура безопасности

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

IPsec — это открытый стандарт , входящий в пакет IPv4, который использует следующие протоколы для выполнения различных функций: [9] [10]

Заголовок аутентификации

Использование формата заголовка аутентификации IPsec в туннельном и транспортном режимах

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

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

Следующая диаграмма AH-пакета показывает, как создается и интерпретируется AH-пакет: [11] [12]

Следующий заголовок (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 для каждого отправленного пакета) для предотвращения атак повторного воспроизведения . Когда включено обнаружение повторного воспроизведения, порядковые номера никогда не используются повторно, поскольку необходимо повторно согласовать новую ассоциацию безопасности перед попыткой увеличения порядкового номера сверх его максимального значения. [ 12]
Значение проверки целостности (кратно 32 битам)
Значение проверки переменной длины. Может содержать заполнение для выравнивания поля по 8-октетной границе для IPv6 или 4-октетной границе для IPv4 .

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

Использование IPsec Encapsulating Security Payload (ESP) в туннельном и транспортном режимах

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

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

ESP работает непосредственно поверх IP, используя IP-протокол номер 50. [20]

Следующая диаграмма пакета ESP показывает, как создается и интерпретируется пакет ESP: [1] [26]

Индекс параметров безопасности (32 бита)
Произвольное значение, используемое (вместе с IP-адресом назначения) для идентификации ассоциации безопасности принимающей стороны.
Порядковый номер (32 бита)
Монотонно увеличивающийся порядковый номер (увеличивается на 1 для каждого отправленного пакета) для защиты от атак повторного воспроизведения . Для каждой ассоциации безопасности ведется отдельный счетчик.
Данные полезной нагрузки (переменные)
Защищенное содержимое исходного IP-пакета, включая любые данные, используемые для защиты содержимого (например, вектор инициализации для криптографического алгоритма). Тип защищенного содержимого указывается в поле Next Header .
Заполнение (0-255 октетов)
Заполнение для шифрования, чтобы расширить данные полезной нагрузки до размера, соответствующего размеру блока шифрования , и выровнять следующее поле.
Длина пэда (8 бит)
Размер заполнения (в октетах).
Следующий заголовок (8 бит)
Тип следующего заголовка. Значение берется из списка номеров IP-протокола .
Значение проверки целостности (переменная)
Значение проверки переменной длины. Может содержать заполнение для выравнивания поля по 8-октетной границе для IPv6 или 4-октетной границе для IPv4 .

Ассоциация безопасности

Протоколы IPsec используют ассоциацию безопасности , где взаимодействующие стороны устанавливают общие атрибуты безопасности, такие как алгоритмы и ключи. Таким образом, IPsec предоставляет ряд опций после того, как было определено, используется ли AH или ESP. Перед обменом данными два хоста договариваются о том, какой алгоритм симметричного шифрования используется для шифрования IP-пакета, например AES или ChaCha20 , и какая хэш-функция используется для обеспечения целостности данных, например BLAKE2 или SHA256 . Эти параметры согласовываются для конкретного сеанса, для которого должно быть согласовано время жизни и ключ сеанса . [27]

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

Ассоциации безопасности IPsec устанавливаются с использованием протокола ISAKMP (Internet Security Association and Key Management Protocol ). ISAKMP реализуется путем ручной настройки с предварительно общими секретами, обменом ключами в Интернете (IKE и IKEv2), согласованием ключей в Интернете с использованием Kerberos (KINK) и использованием записей DNS IPSECKEY . [17] [1] : §1  [29] RFC 5386 определяет Better-Than-Nothing Security (BTNS) как неаутентифицированный режим IPsec, использующий расширенный протокол IKE. C. Meadows, C. Cremers и другие использовали формальные методы для выявления различных аномалий, которые существуют в IKEv1, а также в IKEv2. [30]

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

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

Сообщения Keepalives

Чтобы гарантировать, что соединение между двумя конечными точками не будет прервано, конечные точки через регулярные интервалы обмениваются сообщениями keepalive , которые также можно использовать для автоматического восстановления туннеля, потерянного из-за прерывания соединения.

Dead Peer Detection (DPD) — это метод обнаружения неработающего однорангового узла Internet Key Exchange (IKE). Метод использует шаблоны трафика IPsec для минимизации количества сообщений, необходимых для подтверждения доступности однорангового узла. DPD используется для возврата потерянных ресурсов в случае, если одноранговый узел оказывается неработающим, а также для выполнения аварийного переключения однорангового узла IKE.

UDP keepalive является альтернативой DPD.

Режимы работы

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

Режимы IPsec

Вид транспорта

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

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

Туннельный режим

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

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

Алгоритмы

Симметричные алгоритмы шифрования

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

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

Алгоритмы обмена ключами

Алгоритмы аутентификации

Реализации

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

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

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

Статус стандартов

IPsec был разработан совместно с IPv6 и изначально должен был поддерживаться всеми соответствующими стандартам реализациями IPv6, прежде чем RFC 6434 сделал его только рекомендацией. [36] 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). [37] [38]

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

В 2013 году в результате утечек Сноудена выяснилось, что Агентство национальной безопасности США активно работало над «внедрением уязвимостей в коммерческие системы шифрования, ИТ-системы, сети и конечные коммуникационные устройства, используемые целями» в рамках программы Bullrun . [39] Существуют утверждения, что IPsec был целевой системой шифрования. [40]

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

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

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

Кроме того, IPsec VPN, использующие настройки "Aggressive Mode", отправляют хэш PSK в открытом виде. Это может быть и, по-видимому, является целью АНБ, использующего офлайновые атаки по словарю . [44] [49] [50]

Смотрите также

Ссылки

  1. ^ abcd D. Harkins; R. Atkinson (ноябрь 1998 г.). IP Encapsulating Security Payload (ESP). Сетевая рабочая группа. doi : 10.17487/RFC2406 . RFC 2406. Устарело. Устарело из-за RFC 4303, 4305. Устаревший RFC 1827.
  2. ^ Дхалл, Хитеш; Дхалл, Долли; Батра, Соня; Рани, Пуджа (2012). «Внедрение протокола IPSec». Вторая международная конференция по передовым вычислительным и коммуникационным технологиям 2012 г. IEEE . стр. 176–181. doi :10.1109/ACCT.2012.64. ISBN 978-1-4673-0471-9. S2CID  16526652.
  3. ^ Гилмор, Джон. "Сетевое шифрование – история и патенты". Архивировано из оригинала 2014-09-03 . Получено 2014-02-18 .
  4. ^ ab «Страница распространения IPv6 + IPSEC + ISAKMP» . web.mit.edu .
  5. ^ "ЕЖЕГОДНАЯ ТЕХНИЧЕСКАЯ КОНФЕРЕНЦИЯ USENIX 1996". www.usenix.org .
  6. ^ "Протокол безопасности IP (ipsec) -". datatracker.ietf.org .
  7. ^ S. Kent ; K. Seo (декабрь 2005 г.). Архитектура безопасности для интернет-протокола. Сетевая рабочая группа. doi : 10.17487/RFC4301 . RFC 4301. Предложенный стандарт. стр. 4. Устаревший RFC 2401. Обновлен RFC 6040 и 7619. Написание "IPsec" является предпочтительным и используется в этом и всех связанных стандартах IPsec. Все другие заглавные буквы в IPsec [...] устарели.
  8. ^ "Достижения NRL ITD - IPSec и IPv6" (PDF) . Военно-морские исследовательские лаборатории США . Архивировано (PDF) из оригинала 2015-09-15.
  9. ^ Тейер, Р.; Дорасвами, Н.; Гленн, Р. (ноябрь 1998 г.). Дорожная карта документов по безопасности IP. IETF . doi : 10.17487/RFC2411 . RFC 2411.
  10. ^ Хоффман, П. (декабрь 2005 г.). Криптографические наборы для IPsec. IETF . doi : 10.17487/RFC4308 . RFC 4308.
  11. ^ ab Кент, С.; Аткинсон, Р. (ноябрь 1998 г.). Заголовок аутентификации IP. IETF . doi : 10.17487/RFC2402 . RFC 2402.
  12. ^ abcde Кент, С. (декабрь 2005 г.). Заголовок аутентификации IP. IETF . doi : 10.17487/RFC4302 . RFC 4302.
  13. ^ Обмен ключами в Интернете (IKE), RFC 2409, §1 Аннотация
  14. ^ S. Kent ; D. Carrel (ноябрь 1998 г.). Internet Key Exchange (IKE). Сетевая рабочая группа. doi : 10.17487/RFC2409 . RFC 2409. Устарело. Устарело по RFC 4306. Обновлено по RFC 4109.
  15. ^ C. Kaufman (декабрь 2005 г.). Протокол обмена ключами в Интернете (IKEv2). Сетевая рабочая группа. doi : 10.17487/RFC4306 . RFC 4306. Устарело. Устарело в соответствии с RFC 5996. Обновлено в соответствии с RFC 5282. Устаревшие RFC 2407, 2409 и 2408.
  16. ^ S. Sakane; K. Kamada; M. Thomas; J. Vilhuber (март 2006 г.). Kerberized Internet Negotiation of Keys (KINK). Сетевая рабочая группа. doi : 10.17487/RFC4430 . RFC 4430. Предлагаемый стандарт.
  17. ^ ab M. Richardson (март 2005 г.). Метод хранения ключевого материала IPsec в DNS. Сетевая рабочая группа. doi : 10.17487/RFC4025 . RFC 4025. Предлагаемый стандарт.
  18. ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация сетей Интернета . IET. стр. 270. ISBN 9780852969823.
  19. ^ Р. Ширей (август 2007 г.). Глоссарий безопасности Интернета, версия 2. Сетевая рабочая группа. doi : 10.17487/RFC4949 . RFC 4949. Информационный.
  20. ^ ab "Protocol Numbers". IANA . 2010-05-27. Архивировано из оригинала 2010-05-29.
  21. ^ "SIPP Encapsulating Security Payload". Рабочая группа IETF SIPP. 1993. Архивировано из оригинала 2016-09-09 . Получено 2013-08-07 .
  22. ^ Диринг, Стив Э. (1993). «Проект спецификации SIPP». IETF. стр. 21.
  23. ^ Белловин, Стивен М. (1996). "Проблемные области протоколов безопасности IP" ( PostScript ) . Труды шестого симпозиума по безопасности Usenix Unix . Сан-Хосе, Калифорния. С. 1–16 . Получено 09.07.2007 .
  24. ^ Патерсон, Кеннет Г.; Яу, Арнольд К. Л. (2006-04-24). «Криптография в теории и на практике: случай шифрования в IPsec» (PDF) . Eurocrypt 2006, Lecture Notes in Computer Science Vol. 4004. Берлин. стр. 12–29 . Получено 13 августа 2007 г.
  25. ^ Дегабриэль, Жан Поль; Патерсон, Кеннет Г. (2007-08-09). «Атака стандартов IPsec в конфигурациях только с шифрованием» (PDF) . Симпозиум IEEE по безопасности и конфиденциальности, IEEE Computer Society . Окленд, Калифорния. стр. 335–349 . Получено 13 августа 2007 г.
  26. ^ S. Kent (декабрь 2005 г.). IP-инкапсуляция безопасной полезной нагрузки. Сетевая рабочая группа. doi : 10.17487/RFC4303 . RFC 4303. Предложенный стандарт. Отменяет RFC 2406.
  27. ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация сетей Интернета . IET. стр. 271. ISBN 9780852969823.
  28. ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация сетей Интернета . IET. стр. 272–3. ISBN 9780852969823.
  29. ^ М. Томас (июнь 2001 г.). Требования к согласованию ключей в Интернете с использованием Kerberos. Сетевая рабочая группа. doi : 10.17487/RFC3129 . RFC 3129. Информационный.
  30. ^ C. Cremers (2011). Key Exchange in IPsec Revisited: Formal Analysis of IKEv1 and IKEv2, ESORICS 2011. Lecture Notes in Computer Science. Springer. стр. 315–334. doi :10.1007/978-3-642-23822-2_18. hdl :20.500.11850/69608. ISBN 9783642238222. S2CID  18222662.
  31. ^ Уильям, С. и Столлингс, В. (2006). Криптография и сетевая безопасность, 4/E. Pearson Education India. стр. 492-493
  32. ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация сетей Интернета . IET. стр. 266. ISBN 9780852969823.
  33. ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация сетей Интернета . IET. стр. 267. ISBN 9780852969823.
  34. ↑ RFC 2367, API управления ключами PF_KEYv2 , Дэн Макдональд, Бао Фан и Крейг Метц (июль 1998 г.)
  35. ^ Хамад, Мохаммад; Превелакис, Василис (2015). «Внедрение и оценка производительности встроенного IPsec в микроядерной ОС». Всемирный симпозиум по компьютерным сетям и информационной безопасности 2015 г. (WSCNIS). IEEE. стр. 1–7. doi :10.1109/wscnis.2015.7368294. ISBN 9781479999064. S2CID  16935000.
  36. ^ RFC 6434, «Требования к узлу IPv6», Э. Янкевич, Дж. Лоуни, Т. Нартен (декабрь 2011 г.)
  37. ^ "ipsecme charter" . Получено 2015-10-26 .
  38. ^ "статус ipsecme" . Получено 2015-10-26 .
  39. ^ «Секретные документы раскрывают кампанию АНБ против шифрования». New York Times .
  40. ^ Джон Гилмор. «Re: [Криптография] Вступительное обсуждение: размышления о «BULLRUN»».
  41. ^ Тео де Раадт. «Обвинения относительно OpenBSD IPSEC».
  42. ^ Джейсон Райт. «Обвинения относительно OpenBSD IPSEC».
  43. ^ Тео де Раадт. «Обновленная информация по обвинению в бэкдоре OpenBSD IPSEC».
  44. ^ ab Адриан, Дэвид; Бхаргаван, Картикеян; Дурумерик, Закир; Годри, Пьеррик; Грин, Мэтью; Хальдерман, Дж. Алекс; Хенингер, Надя; Спринголл, Дрю; Томе, Эммануэль; Валента, Люк; Вандерслут, Бенджамин; Вустров, Эрик; Занелла-Бегелин, Сантьяго; Циммерман, Пол (2015). «Несовершенная прямая секретность». Труды 22-й конференции ACM SIGSAC по компьютерной и коммуникационной безопасности . стр. 5–17. doi :10.1145/2810103.2813707. ISBN 9781450338325. S2CID  347988.
  45. ↑ Гудин, Дэн (16 августа 2016 г.). «Подтверждено: утечка хакерского инструмента произошла от «всемогущей» группы, связанной с АНБ». Ars Technica . Получено 19 августа 2016 г.
  46. ^ Томсон, Иэн (17 августа 2016 г.). «Cisco подтверждает, что две уязвимости „АНБ“ от Shadow Brokers реальны». The Register . Получено 16 сентября 2016 г.
  47. ^ Паули, Даррен (24 августа 2016 г.). «Эксплойт Equation Group поражает новые Cisco ASA, Juniper Netscreen». The Register . Получено 16 сентября 2016 г.
  48. ^ Чиргвин, Ричард (18 августа 2016 г.). «Fortinet следует примеру Cisco в подтверждении уязвимости Shadow Broker». The Register . Получено 16 сентября 2016 г.
  49. ^ "обмен ключами - Каковы проблемы агрессивного режима IKEv1 (по сравнению с основным режимом IKEv1 или IKEv2)?". Cryptography Stack Exchange .
  50. ^ "Не прекращайте пока использовать IPsec". No Hats . 29 декабря 2014 г.

Дальнейшее чтение

Стандарты трек

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

Информационные RFC

Лучшие текущие практики RFC

Устаревшие/исторические RFC

Внешние ссылки