✖
~~~~~~~~~~~~~~~~~~~~ Arc.Ask3.Ru ~~~~~~~~~~~~~~~~~~~~~ 
Номер скриншота №:
✰ 889705D9A405D9C263D2CF0AE5DA440F__1715422140 ✰
Заголовок документа оригинал.:
✰ IPsec - Wikipedia ✰
Заголовок документа перевод.:
✰ IPsec — Википедия ✰
Снимок документа находящегося по адресу (URL):
✰ https://en.wikipedia.org/wiki/IPsec ✰
Адрес хранения снимка оригинал (URL):
✰ https://arc.ask3.ru/arc/aa/88/0f/889705d9a405d9c263d2cf0ae5da440f.html ✰
Адрес хранения снимка перевод (URL):
✰ https://arc.ask3.ru/arc/aa/88/0f/889705d9a405d9c263d2cf0ae5da440f__translat.html ✰
Дата и время сохранения документа:
✰ 21.06.2024 05:09:42 (GMT+3, MSK) ✰
Дата и время изменения документа (по данным источника):
✰ 11 May 2024, at 13:09 (UTC). ✰ 

~~~~~~~~~~~~~~~~~~~~~~ Ask3.Ru ~~~~~~~~~~~~~~~~~~~~~~ 
Сервисы Ask3.ru: 
 Архив документов (Снимки документов, в формате HTML, PDF, PNG - подписанные ЭЦП, доказывающие существование документа в момент подписи. Перевод сохраненных документов на русский язык.) 
✰ https://arc.ask3.ru ✰
 Ответы на вопросы (Сервис ответов на вопросы, в основном, научной направленности) 
✰ https://ask3.ru/answer2question ✰
 Товарный сопоставитель (Сервис сравнения и выбора товаров) ✰✰
✰ https://ask3.ru/product2collation ✰
 Партнеры 
✰ https://comrades.ask3.ru ✰


Совет. Чтобы искать на странице, нажмите Ctrl+F или ⌘-F (для MacOS) и введите запрос в поле поиска.
Arc.Ask3.ru: далее начало оригинального документа

IPsec — Википедия Jump to content

IPsec

Из Википедии, бесплатной энциклопедии
IPsec
Безопасность интернет-протокола
Год начался 1996
Организация Целевая группа по интернет-инжинирингу
Базовые стандарты Различные, см. главу документации IETF.
Набор интернет-протоколов
Прикладной уровень
Транспортный уровень
Интернет-слой
Слой связи

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

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

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

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

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

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

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

Первоначальный пакет IPv4 был разработан с небольшим количеством мер безопасности. В рамках усовершенствования IPv4 IPsec представляет собой уровня 3 модель OSI или интернет-уровня схему сквозной безопасности . Напротив, в то время как некоторые другие широко используемые системы интернет-безопасности работают выше сетевого уровня , такие как 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] используя технику скользящего окна и отбрасывая старые пакеты.

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

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

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

заголовка аутентификации Формат
Смещения Октет 16 0 1 2 3
Октет 16 Бит 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Следующий заголовок Полезная нагрузка Лен Сдержанный
4 32 Индекс параметров безопасности (SPI)
8 64 Порядковый номер
С 96 Значение проверки целостности (ICV)
...
... ...
Следующий заголовок (8 бит)
Тип следующего заголовка, указывающий, какой протокол верхнего уровня был защищен. Значение берется из списка номеров IP-протокола .
Полезная нагрузка Len (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, инкапсулирующей полезную нагрузку безопасности (ESP) в туннельном и транспортном режимах

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

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

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

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

Инкапсуляция формата полезных данных безопасности
Смещения Октет 16 0 1 2 3
Октет 16 Бит 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Индекс параметров безопасности (SPI)
4 32 Порядковый номер
8 64 Данные полезной нагрузки
... ...
... ...    
... ...   Заполнение (0–255 октетов)  
... ...   Длина колодки Следующий заголовок
... ... Значение проверки целостности (ICV)
...
... ...
Индекс параметров безопасности (32 бита)
Произвольное значение, используемое (вместе с IP-адресом назначения) для идентификации ассоциации безопасности принимающей стороны.
Порядковый номер (32 бита)
увеличивающийся порядковый номер Монотонно (увеличиваемый на 1 для каждого отправленного пакета) для защиты от атак повторного воспроизведения . Для каждой ассоциации безопасности имеется отдельный счетчик.
Данные полезной нагрузки (переменная)
Защищенное содержимое исходного IP-пакета, включая любые данные, используемые для защиты содержимого (например, вектор инициализации для криптографического алгоритма). Тип защищенного содержимого указывается в поле «Следующий заголовок» .
Заполнение (0–255 октетов)
Заполнение для шифрования, чтобы расширить полезные данные до размера, соответствующего шифрования размеру блока , и выровнять следующее поле.
Длина площадки (8 бит)
Размер заполнения (в октетах).
Следующий заголовок (8 бит)
Тип следующего заголовка. Значение берется из списка номеров IP-протокола .
Значение проверки целостности (кратное 32 битам)
Проверочное значение переменной длины. Он может содержать дополнения для выравнивания поля по границе в 8 октетов для IPv6 или по границе в 4 октета для IPv4 .

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

Основная статья: Ассоциация безопасности

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

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

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

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

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

Keepalive [ править ]

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

Обнаружение мертвого узла (DPD) — это метод обнаружения неработающего узла обмена ключами в Интернете (IKE). Этот метод использует шаблоны трафика IPsec, чтобы минимизировать количество сообщений, необходимых для подтверждения доступности узла. DPD используется для восстановления потерянных ресурсов в случае, если одноранговый узел оказывается неработающим, а также для выполнения аварийного переключения однорангового узла IKE.

Поддержка активности UDP является альтернативой DPD.

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

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

Режимы IPsec

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

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

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

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

Основная статья: Протокол туннелирования

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

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

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

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

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

Подробности см. в RFC 8221.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кроме того, сети IPsec VPN, использующие настройки «агрессивного режима», отправляют хэш PSK в открытом виде. Это может быть целью АНБ, которая, по всей видимости, нацелена на использование автономных атак по словарю . [45] [50] [51]

Документация 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 : Использование режима счетчика расширенного стандарта шифрования (AES) с инкапсуляцией полезных данных безопасности IPsec (ESP)
  • RFC 3947 : Согласование NAT-обхода в IKE
  • RFC 3948 : UDP-инкапсуляция пакетов IPsec ESP
  • RFC 4106 : Использование режима Галуа/счетчика (GCM) в инкапсуляции полезных данных безопасности IPsec (ESP)
  • RFC 4301 : Архитектура безопасности для интернет-протокола.
  • RFC 4302 : заголовок IP-аутентификации.
  • RFC 4303 : IP-инкапсуляция полезных данных безопасности
  • RFC 4304 : Дополнение к расширенному порядковому номеру (ESN) к домену интерпретации IPsec (DOI) для ассоциации безопасности Интернета и протокола управления ключами (ISAKMP).
  • RFC 4307 : Криптографические алгоритмы для использования в обмене ключами в Интернете, версия 2 ( IKEv2 )
  • RFC 4308 : Криптографические наборы для IPsec.
  • RFC 4309 : использование расширенного стандарта шифрования (AES) режима CCM с IPsec, инкапсулирующей полезную нагрузку безопасности (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 : Использование алгоритмов шифрования с проверкой подлинности с зашифрованной полезной нагрузкой протокола обмена ключами в Интернете версии 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 : Аутентификация подписи в обмене ключами через Интернет, версия 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 : Заявление о проблеме и применимости для системы безопасности «лучше, чем ничего» (BTNS)
  • RFC 5856 : Интеграция надежного сжатия заголовков в ассоциации безопасности IPsec.
  • RFC 5930 : Использование стандартного режима счетчика расширенного шифрования (AES-CTR) с протоколом обмена ключами в Интернете версии 02 (IKEv2).
  • RFC 6027 : Постановка проблемы кластера IPsec
  • RFC 6071 : Дорожная карта документа IPsec и IKE
  • RFC 6379 : Suite B для IPsec Криптографические пакеты
  • RFC 6380 : Профиль Suite B для безопасности интернет-протокола (IPsec)
  • RFC 6467 : Структура безопасных паролей для обмена ключами в Интернете версии 2 (IKEv2)

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

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

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

  • RFC 1825 : Архитектура безопасности для интернет-протокола (устарело из-за RFC 2401).
  • RFC 1826 : заголовок IP-аутентификации (устарело из-за RFC 2402).
  • RFC 1827 : Полезная нагрузка безопасности, инкапсулирующая IP (ESP) (устарело из-за RFC 2406)
  • RFC 1828 : Аутентификация IP с использованием ключа MD5 (исторический)
  • RFC 2401 : Архитектура безопасности для интернет-протокола (обзор IPsec) (устарело из-за RFC 4301)
  • RFC 2406 : Полезная нагрузка безопасности, инкапсулирующая IP (ESP) (устарело из-за RFC 4303 и RFC 4305)
  • RFC 2407 : домен интерпретации IP-безопасности Интернета для 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).

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

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

  1. ^ Перейти обратно: а б с Кент, С.; Аткинсон, Р. (ноябрь 1998 г.). Полезная нагрузка безопасности, инкапсулирующая IP (ESP) . IETF . дои : 10.17487/RFC2406 . РФК 2406 .
  2. ^ Дхалл, Хитеш; Дхалл, Долли; Батра, Соня; Рани, Пуджа (2012). «Реализация протокола IPSec» . 2012 Вторая международная конференция по передовым вычислительным и коммуникационным технологиям . ИИЭЭ . стр. 176–181. дои : 10.1109/ACCT.2012.64 . ISBN  978-1-4673-0471-9 . S2CID   16526652 .
  3. ^ Гилмор, Джон. «Сетевое шифрование – история и патенты» . Архивировано из оригинала 3 сентября 2014 г. Проверено 18 февраля 2014 г.
  4. ^ Перейти обратно: а б «Страница распространения IPv6 + IPSEC + ISAKMP» . web.mit.edu .
  5. ^ «ЕЖЕГОДНАЯ ТЕХНИЧЕСКАЯ КОНФЕРЕНЦИЯ USENIX 1996 ГОДА» . www.usenix.org .
  6. ^ «Протокол IP-безопасности (ipsec) —» . datatracker.ietf.org .
  7. ^ Со, Карен; Кент, Стивен (декабрь 2005 г.). Архитектура безопасности Интернет-протокола . Сетевая рабочая группа IETF. п. 4. дои : 10.17487/RFC4301 . РФК 4301 . Написание «IPsec» является предпочтительным и используется в этом и всех связанных стандартах IPsec. Все другие варианты написания IPsec [...] с заглавной буквы устарели.
  8. ^ «Достижения NRL ITD — IPSec и IPv6» (PDF) . Исследовательские лаборатории ВМС США . Архивировано (PDF) из оригинала 15 сентября 2015 г.
  9. ^ Тайер, Р.; Дорасвами, Н.; Гленн, Р. (ноябрь 1998 г.). Дорожная карта документа по IP-безопасности . IETF . дои : 10.17487/RFC2411 . РФК 2411 .
  10. ^ Хоффман, П. (декабрь 2005 г.). Криптографические пакеты для IPsec . IETF . дои : 10.17487/RFC4308 . RFC 4308 .
  11. ^ Перейти обратно: а б Кент, С.; Аткинсон, Р. (ноябрь 1998 г.). Заголовок IP-аутентификации . IETF . дои : 10.17487/RFC2402 . РФК 2402 .
  12. ^ Перейти обратно: а б с д Это Кент, С. (декабрь 2005 г.). Заголовок IP-аутентификации . IETF . дои : 10.17487/RFC4302 . РФК 4302 .
  13. ^ Интернет -обмен ключами (IKE), RFC 2409, §1 Аннотация
  14. ^ Харкинс, Д.; Каррел, Д. (ноябрь 1998 г.). Интернет-обмен ключами (IKE) . IETF . дои : 10.17487/RFC2409 . РФК 2409 .
  15. ^ Кауфман, К. (ред.). ИКЕ версии 2 . IETF . дои : 10.17487/RFC4306 . RFC 4306 .
  16. ^ Сакане, С.; Камада, К.; Томас, М.; Вилхубер, Дж. (ноябрь 1998 г.). Керберизованное Интернет-согласование ключей (KINK) . IETF . дои : 10.17487/RFC4430 . РФК 4430 .
  17. ^ Перейти обратно: а б Ричардсон, М. (февраль 2005 г.). Метод хранения данных ключей IPsec в DNS . IETF . дои : 10.17487/RFC4025 . РФК 4025 .
  18. ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация сетей Интернет . ИЭПП. п. 270. ИСБН  9780852969823 .
  19. ^ Р. Ширей (август 2007 г.). Глоссарий по интернет-безопасности, версия 2 . Сетевая рабочая группа. дои : 10.17487/RFC4949 . РФК 4949 . Информационный.
  20. ^ Перейти обратно: а б «Номера протоколов» . ИАНА . 27 мая 2010 г. Архивировано из оригинала 29 мая 2010 г.
  21. ^ «Инкапсуляция полезной нагрузки безопасности SIPP» . Рабочая группа IETF SIPP. 1993. Архивировано из оригинала 9 сентября 2016 г. Проверено 7 августа 2013 г.
  22. ^ Диринг, Стив Э. (1993). «Проект спецификации SIPP» . IETF. п. 21.
  23. ^ Белловин, Стивен М. (1996). «Проблемные области протоколов IP-безопасности» ( PostScript ) . Материалы шестого симпозиума по безопасности Usenix Unix . Сан-Хосе, Калифорния. стр. 1–16 . Проверено 9 июля 2007 г.
  24. ^ Патерсон, Кеннет Г.; Яу, Арнольд К.Л. (24 апреля 2006 г.). «Криптография в теории и практике: случай шифрования в IPsec» (PDF) . Eurocrypt 2006, Конспекты лекций по информатике, том. 4004 . Берлин. стр. 12–29 . Проверено 13 августа 2007 г.
  25. ^ Дегабриэль, Жан Поль; Патерсон, Кеннет Г. (9 августа 2007 г.). «Атака на стандарты IPsec в конфигурациях только с шифрованием» (PDF) . Симпозиум IEEE по безопасности и конфиденциальности, Компьютерное общество IEEE . Окленд, Калифорния. стр. 335–349 . Проверено 13 августа 2007 г.
  26. ^ Кент, С. (декабрь 2005 г.). Полезная нагрузка безопасности, инкапсулирующая IP (ESP) . IETF . дои : 10.17487/RFC4303 . RFC 4303 .
  27. ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация сетей Интернет . ИЭПП. п. 271. ИСБН  9780852969823 .
  28. ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация сетей Интернет . ИЭПП. стр. 272–3. ISBN  9780852969823 .
  29. ^ RFC 2406, §1, стр. 2
  30. ^ Томас, М. (июнь 2001 г.). Требования к керберизованному согласованию ключей в Интернете . дои : 10.17487/RFC3129 . РФК 3129 .
  31. ^ К. Кремерс (2011). Возвращение к обмену ключами в IPsec: формальный анализ IKEv1 и IKEv2, ESORICS 2011 . Конспекты лекций по информатике. Спрингер. стр. 315–334. дои : 10.1007/978-3-642-23822-2_18 . hdl : 20.500.11850/69608 . ISBN  9783642238222 . S2CID   18222662 .
  32. ^ Уильям С. и Столлингс В. (2006). Криптография и сетевая безопасность, 4/Э. Пирсон Образовательная Индия. п. 492-493
  33. ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация сетей Интернет . ИЭПП. п. 266. ИСБН  9780852969823 .
  34. ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация сетей Интернет . ИЭПП. п. 267. ИСБН  9780852969823 .
  35. ^ RFC 2367, API управления ключами PF_KEYv2 , Дэн Макдональд, Бао Фан и Крейг Мец (июль 1998 г.)
  36. ^ Хамад, Мохаммед; Превелакис, Василис (2015). «Внедрение и оценка производительности встроенного IPsec в микроядерной ОС». Всемирный симпозиум по компьютерным сетям и информационной безопасности (WSCNIS) 2015 г. IEEE. стр. 1–7. дои : 10.1109/wscnis.2015.7368294 . ISBN  9781479999064 . S2CID   16935000 .
  37. ^ RFC 6434, «Требования к узлу IPv6», Э. Янкевич, Дж. Лоуни, Т. Нартен (декабрь 2011 г.)
  38. ^ «Устав ipsecme» . Проверено 26 октября 2015 г.
  39. ^ «статус ipsecme» . Проверено 26 октября 2015 г.
  40. ^ «Секретные документы раскрывают кампанию АНБ против шифрования» . Газета "Нью-Йорк Таймс .
  41. ^ Джон Гилмор. «Re: [Криптография] Вступительная дискуссия: Спекуляции на тему «BULLRUN» » .
  42. ^ Тео де Раадт. «Обвинения относительно OpenBSD IPSEC» .
  43. ^ Джейсон Райт. «Обвинения относительно OpenBSD IPSEC» .
  44. ^ Тео де Раадт. «Обновленная информация по обвинению в бэкдоре OpenBSD IPSEC» .
  45. ^ Перейти обратно: а б Адриан, Дэвид; Бхаргаван, Картикеян; Дурумерик, Закир; Годри, Пьеррик; Грин, Мэтью; Халдерман, Дж. Алекс; Хенингер, Надя; Спринголл, Дрю; Томе, Эммануэль; Валента, Люк; Вандерслот, Бенджамин; Вустроу, Эрик; Занелла-Бегелен, Сантьяго; Циммерманн, Пол (2015). «Несовершенная прямая секретность» . Материалы 22-й конференции ACM SIGSAC по компьютерной и коммуникационной безопасности . стр. 5–17. дои : 10.1145/2810103.2813707 . ISBN  9781450338325 . S2CID   347988 .
  46. ^ Гудин, Дэн (16 августа 2016 г.). «Подтверждено: утечка хакерского инструмента произошла от «всемогущей» группы, связанной с АНБ» . Арс Техника . Проверено 19 августа 2016 г.
  47. ^ Томсон, Иэн (17 августа 2016 г.). «Cisco подтверждает, что две уязвимости «АНБ» Shadow Brokers реальны» . Регистр . Проверено 16 сентября 2016 г.
  48. ^ Паули, Даррен (24 августа 2016 г.). «Эксплойт Equation Group поражает новую версию Cisco ASA, Juniper Netscreen» . Регистр . Проверено 16 сентября 2016 г.
  49. ^ Чиргвин, Ричард (18 августа 2016 г.). «Fortinet следует за Cisco в подтверждении уязвимости Shadow Broker» . Регистр . Проверено 16 сентября 2016 г.
  50. ^ «Обмен ключами. Каковы проблемы агрессивного режима IKEv1 (по сравнению с основным режимом IKEv1 или IKEv2)?» . Обмен стеками криптографии .
  51. ^ «Пока не прекращайте использовать IPsec» . Никаких шляп . 29 декабря 2014 г.

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

Retrieved from "https://en.wikipedia.org/w/index.php?title=IPsec&oldid=1223337655"
Arc.Ask3.Ru: конец оригинального документа.
Arc.Ask3.Ru
Номер скриншота №: 889705D9A405D9C263D2CF0AE5DA440F__1715422140
URL1:https://en.wikipedia.org/wiki/IPsec
Заголовок, (Title) документа по адресу, URL1:
IPsec - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть, любые претензии не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, денежную единицу можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)