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 پروتکل، حالت و الگوریتم‌های انجمن نصب‌شده را نشان می‌دهد، و ناسازگاری هیچ چیز نصب نمی‌کند، که شکستی پاک‌تر از تونلی است که بدون حفاظت مورد نظر بالا می‌آید.

شکست‌های احراز هویت، پوشش انتخابگرها و خطاهای مسیریابی را از این انتخاب جدا نگه دارید. آن‌ها نشانه‌های متفاوتی می‌دهند، و سرزنش پروتکل برای مشکل انتخابگر راهی مطمئن برای گذراندن یک روز با تغییر بی‌دلیل هش‌هاست.