
- •Содержание
- •1. Введение. Предпосылки появления iPv6 …………………………………………… 3
- •2. АдресацияPv6.......................................................................................................................... 4
- •3. Формат iPv6-дейтаграмм......................................................................................................14
- •4. Заключение............................................................................................................................31
- •1. Введение.
- •2.1 Представление адресов в iPv6
- •2.2 Типы адресов
- •2.3 Unicast-адреса
- •IPv6 адреса с вложенными iPv4 адресами
- •IPv4-compatible addresses
- •IPv4-mapped addresses
- •2.5 Multicast-адреса
- •2.6 Доля адресов в адресном пространстве
- •3.1 Основные изменения в дейтаграмме iPv6
- •3.2 Общая структура iPv6 дейтаграммы
- •3.3 Формат основного заголовка iPv6
- •3.4 Конкатенация заголовков iPv6 при помощи поля Next Header
- •3.5 Заголовки расширения, содержащие опции
- •3.6 Заголовок маршрутизации
- •3.7 Размер и фрагментация iPv6-дейтаграмм
- •3.9 Протокол обеспечения конфиденциальности
- •1. Вычисление и размещение esp Header
- •2. Вычисление и размещение esp Trailer
- •3. Вычисление и размещение esp Authentication Field
- •3.10 Возможные схемы шифрования и аутентификации
- •4. Заключение
- •4.1 IPv6 в мире и в России
- •4.2 Выводы и итоги
- •IPv6 has a bright future. The question is when, not if. The when begins now.
- •Список использованных источников
3.9 Протокол обеспечения конфиденциальности
[RFC 2406]
Основная цель протокола обеспечения конфиденциальности (Encapsulating Security Payload or ESP) – обеспечивать конфиденциальность IP путём шифрования дейтаграмм. Также у него если собственная схема аутентификации аналогичная той, что используется в AH, или же он может ис-пользоваться в связке с AH.
Поля ESP
Поля ESP отчасти совпадают с полями AH, но располагаются совсем по-другому. Вместо того чтобы просто составлять заголовок, они разделены на три части:
o ESP Header: содержит два поля, SPI и Sequence Number, и располагается перед зашифро-ванными данными. Его расположение зависит, от того, какой используется режим – транс-портный или туннельный.
o ESP Trailer: располагается после зашифрованных данных. Содержит пустые байты (Pad-ding), используемые для выравнивания шифруемых данных, а также поля Pad Length и, что интересно, Next Header.
o ESP Authentication Data: имеет место в случае, когда ESP обеспечивает аутентификацию, содержит Integrity Check Value (ICV), вычисляемое аналогично тому, как это делается в AH.
Существует две причины такого разбиения на части. Первая - это то, что некоторые алгоритмы шифрования требуют, чтобы данные состояли из блоков определенного размера, потому вырав-нивающие байты (и ESP Trailer) должны идти после данных, а не перед ними. Вторая – что ESP Authentication Data выделяется в отдельную часть, потому что это поле должно обеспечить аутен-тификацию дейтаграммы после шифрования данных. Это означает, что оно не может входить в состав ESP Header или ESP Trailer.
1. Вычисление и размещение esp Header
ESP Header размещается в дейтаграмме в качестве заголовка расширения. В транспортном режи-ме он находится перед заголовком Destination Options, но после всех остальных заголовков рас-ширения. В туннельном режиме он находится в IP-дейтаграмме, которая инкапсулирует исходную
2. Вычисление и размещение esp Trailer
ESP Trailer присоединяется к концу шифруемых данных, после чего ESP выполняет процедуру шифрования. Полезная нагрузка (TCP/UDP сообщение или инкапсулированная IP-дейтаграмма) и ESP trailer шифруются, а ESP Header – нет. Обратите внимание, что любые другие заголовки ме-жду ESP header и полезной нагрузкой также шифруются (в IPv6 это может быть заголовок Desti-nation Options).
По установившимся традициям поле Next Header должно было бы появиться в ESP header и свя-зывать его с заголовком, следующим за ним. Однако Next Header в ESP появляется в Trailer, а не в Header. Он идёт после зашифрованных данных и указывает «назад» на один из следующих заго-ловков: заголовок расширения Destination Options (если он присутствует), либо заголовок TCP/UDP (в транспортном режиме) или заголовок IPv4/IPv6 (в туннельном режиме).
3. Вычисление и размещение esp Authentication Field
В случае если ESP должен обеспечивать аутентификацию, значение поля аутентификации высчи-тывается на основе ESP header, полезной нагрузки и ESP trailer (см. рисунок).
Формат Encapsulating Security Payload
-
Секция
Название по-ля
Размер (байт)
Описание
ESP Header
Security Pa-rameter Index (SPI)
4
32-битное значение, которое вместе с ад-ресом получателя, а также типом прото-кола безопасности, используемого ESP, идентифицирует контекст безопасно-сти, используемый для данной дейтаграм
Sequence Number
4
Это поле инициализируется нулем при формировании контекста безопасности (SA) и увеличивается на единицу для ка-ждой дейтаграммы, посылаемой в этом SA. Это уникальным образ идентифици-рует каждую дейтаграмму в пределах SA и используется для защиты от атаки пу тем перепосылки перехваченных дейта-грамм.
Payload
Payload Data
переменный
Содержит полезную нагрузку - данные от вышележащего протокола или инкапсу-лированную IP-дейтаграмму. Также мо-жет содержать инициализационный век-тор, необходимый для работы некоторых алгоритмов шифрования.
ESP Trailer
Padding
переменный (0-255)
Пустые байты, необходимые для вырав-нивания шифруемых данных.
Pad Length
1
Размер поля Padding.
Next Header
1
Содержит тип следующего заголовка или тип вышележащего протокола. Исполь-зуется, как было описано выше, для со-единения заголовков.
ESP Authentication Data
переменный
Содержит Integrity Check Value, вычис-ленное алгоритмом аутентификации ESP.