AH или ESP? Одлучите према томе шта пакет мора да заштити

Два IPsec предлога могу навести исти алгоритам интегритета заснован на SHA, а ипак тражити различите протоколе заштите; AH и ESP нису два правописа једног подешавања аутентификације. Прво прочитајте протокол, затим његове алгоритме, затим његов режим, и већина нејасноћа нестаје. AH проверава пакет, укључујући поља IP заглавља која остају непромењена на путу, док ESP проверава и шифрује оно што инкапсулира и оставља спољашње заглавље на миру. Та разлика одлучује о више имплементација него било које име хеша.

Шта AH покрива, а ESP не

AH пружа интегритет, аутентификацију порекла података и услугу заштите од понављања коју сам дефинише, и никакву поверљивост. Његов обухват укључује податке горњег слоја и поља IP заглавља која његова правила сматрају непромењивим, тачно онај део који ESP у транспортном режиму оставља изван. Када захтев каже да се само IP заглавље мора аутентификовати, AH је протокол који на то одговара.

Тај обухват је и разлог зашто је AH крхак у пракси. Променљива поља попут TTL-а, контролне суме заглавља и неких опција не могу се аутентификовати јер их рутери могу преписати, па их протокол нулира пре израчунавања провере. Зато све што преписује адресе квари израчунавање, а не само политику.

NAT претвара избор у ограничење

Превођење адреса преписује извор или одредиште у IP заглављу које је AH управо аутентификовао, па провера интегритета пада на удаљеној страни, и то као грешка протокола, а не као порука која се може прочитати. ESP не аутентификује спољашње заглавље, зато ESP са проласком кроз NAT ради, а AH иза NAT-а не. Тунел чије су обе стране иза обичних рутера управо је место где се то прво појављује. Зато прво питање није који је протокол јачи, него постоји ли преводилац између страна.

Ако постоји, AH испада, а разговор прелази на ESP и његов избор алгоритама. То је ограничење, а не склоност, зато му је место на врху одлуке, а не на крају.

Режим умножава питање

ESP у транспортном режиму штити терет горњег слоја и не дира IP заглавље; у тунелском режиму инкапсулира цео унутрашњи пакет, укључујући унутрашње IP заглавље, и штити га. AH има иста два режима, па је AH или ESP заправо четири комбинације пре него што се изабере било који алгоритам.

Алгоритми ESP у комбинованом режиму затим решавају интегритет без другог протокола. AES-GCM и ChaCha20-Poly1305 аутентификују и шифрују у једној конструкцији, па додавање AH-а одозго не купује ништа, али кошта још једно заглавље и још једно преговарање. Архитектура допушта AH и ESP заједно, а практично питање је да ли ваша капија и ваше издање подржавају ту комбинацију и може ли је неко после одржавати.

Искрена замена за само AH

Варијанта ESP само са интегритетом задржава алгоритам и одустаје од тврдње о шифровању уместо да је глуми, и пролази кроз NAT. Ако је наслеђени дизајн користио AH јер је била потребна аутентификација без поверљивости, та варијанта је директан превод, а не шифровани тунел са приложеном напоменом.

Видети ESP у предлогу такође није доказ шифровања. Прочитајте алгоритам шифровања: унос NULL значи само интегритет, а унос комбинованог режима значи обоје.

Одлучите у три питања

Питајте да ли је потребна поверљивост, постоји ли преводилац на путу и која поља заглавља морају да се аутентификују. Та три одговора показују на један протокол и један режим, а њихово записивање траје мање времена него касније поновно читање RFC-ова.

Затим проверите шта је прихваћено, а не шта је предложено. ip xfrm state показује протокол, режим и алгоритме инсталиране асоцијације, а неусклађеност не инсталира ништа, што је чистији неуспех од тунела који се подигне без заштите коју сте намеравали.

Држите неуспехе аутентификације, покривеност селектора и грешке рутирања одвојено од овог избора. Они дају различите симптоме, а кривити протокол за проблем са селектором поуздан је начин да проведете дан мењајући хешеве без разлога.