AH или ESP? Одлучете според тоа што пакетот мора да го заштити
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 го покажува протоколот, режимот и алгоритмите на инсталираната асоцијација, и неусогласеноста не инсталира ништо, што е почист неуспех од тунел што се крева без предвидената заштита.
Држете ги неуспесите при автентикација, покриеноста на селекторите и грешките при рутирање одвоени од овој избор. Тие даваат различни симптоми, и обвинувањето на протоколот за проблем со селектор е сигурен начин да се помине ден менувајќи хаш без причина.