Технология IPsec

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

Режим туннеля реализует функциональность VPN, где IP пакет целиком инкапсулируются в другой пакет и в таком виде доставляются адресату.

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

На рис. 17.4 показано преобразование форматов заголовков в туннельном режиме IPsec. Слева на рисунке размешен формат исходной дейтограммы с инкапсулированным ТСР-сегментом. Закрашенные области защищены аутентификационными данными АН.

Рис. 17.4. Преобразование форматов в туннельном режиме АН IPsec

Когда пакет туннельного режима приходит адресату, он проходит ту же аутентификационную проверку, что и пакет AH-типа, после чего удаляются заголовки IP и AH и восстанавливается первоначальный формат пакета.

Большинство реализаций рассматривает оконечную точку туннеля в качестве сетевого интерфейса.

Реконструированный пакет может быть доставлен локальной машине или маршрутизован куда-либо еще (согласно IP-адресу места назначения в инкапсулированном пакете). Дальнейшая его транспортировка уже не обеспечивается средствами безопасности IPsec.

В то время как транспортный режим используется исключительно для обеспечения безопасной связи между двумя компьютерами, туннельный режим обычно применяется между шлюзами (маршрутизаторами, сетевыми экранами, или отдельными VPN устройствами) для построения VPN (Virtual Private Network).

Следует заметить, что в пакете IPsec нет специального поля "режим": которое бы позволяло разделить транспортный режим от туннельного, эту функцию выполняет поле следующий заголовок пакета AH.

Когда поле следующий заголовок соответствует IP, это означает, что пакет инкапсулирует всю IP-дейтограмму (туннельный режим), включая независимые адреса отправителя и получателя, которые позволяют реализовать маршрутизацию после туннеля.

Любое другое значение поля (TCP, UDP, ICMP и т.д.) означает транспортный режим (безопасная транспортировка по схеме точка-точка).

IP-дейтограмма верхнего уровня имеет ту же структуру вне зависимости от режима, и промежуточные маршрутизаторы обрабатывают трафик, не анализируя внутреннее содержание IPsec /AH.

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

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

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

AH содержит ICV (Integrity Check Value) в аутентификационной части заголовка, и эта контрольная сумма формируется обычно (но не всегда) с помощью стандартного криптографического хэш алгоритма, например, MD5 или SHA-1.

Здесь используется не традиционная контрольная сумма, которая не может предотвратить намеренное искажение содержимого, а алгоритм HMAC (Hashed Message Authentication Code), который при вычислении ICV применяет секретный ключ. Несмотря на то, что хакер может заново вычислить хэш, без секретного ключа он не сможет корректно сформировать ICV. Алгоритм HMAC описан в документе RFC 2104.

Заметим, что IPsec /AH не определяет, какой должна быть аутентификационная функция, вместо этого предоставляются рамки, в которых можно реализовать любую функцию, согласованную отправителем и получателем. Можно использовать для аутентификации цифровую подпись или криптографическую функцию, если оба участника их поддерживают.

AH и NAT

Именно потому, что AH обеспечивает хорошую защиту содержимого пакета, так как этот протокол покрывает все, что только нужно защитить, эта защита приводит к несовместимости с NAT (Network Address Translation).

Протокол NAT применяется для установления соответствия между частными IP-адресами (например, 19.125.1.X) и легальными IP. При этом IP-заголовок модифицируется устройством NAT путем замены IP-адресов отправителя и получателя.

Когда изменяются IP-адреса, нужно заново вычислить контрольную сумму заголовка. Это нужно сделать в любом случае. Так как устройство NAT обычно размещается в одном шаге между отправителем и получателем, это требует, кроме того, декрементации значения TTL (Time To Live).

Так как поля TTL и контрольная сумма заголовка всегда модифицируются на пролете, AH знает, что эти поля следует исключить из зоны защиты, но это не касается IP-адресов. Адреса включены в область вычисления ICV, и любая модификация вызовет сбой при проверке ICV получателем. Так как вычисление ICV требует знания секретного ключа, который неизвестен промежуточным узлам, маршрутизатор NAT не сможет заново вычислить ICV.

Аналогичная проблема возникает при использовании протокола PAT (Port Address Translation), который устанавливает соответствие нескольких частных IP адресов одному внешнему IP. В этом случае изменяются не только IP-адреса, но и коды портов в UDP и TCP пакетах (а иногда и в поле данных). Это требует много большей адаптивности со стороны устройства NAT, и более серьезных модификаций всей IP дейтограммы.

По этой причине протокол AH в туннельном или транспортном режиме полностью несовместим с NAT.

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

Протокол NAT транслирует IP адреса "на пролете" — но он должен отслеживать то, с каким соединением происходит работа, чтобы корректно связывать отклики с источником пакетов. При использовании TCP или UDP это обычно делается с привлечением номеров порта, но IPsec не оставляет такой возможности.

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