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 нет способа связать возвращаемый пакет с конкретным соединением.