AH या ESP? यह तय करें कि पैकेट को किसकी सुरक्षा चाहिए

दो IPsec प्रस्ताव एक ही SHA-आधारित अखंडता एल्गोरिद्म बताकर भी अलग सुरक्षा प्रोटोकॉल मांग सकते हैं; AH और ESP एक ही प्रमाणीकरण सेटिंग की दो वर्तनियाँ नहीं हैं। पहले प्रोटोकॉल, फिर उसके एल्गोरिद्म, फिर उसका मोड पढ़ें और अधिकांश अस्पष्टता मिट जाती है। AH पैकेट को प्रमाणित करता है, जिनमें रास्ते में अपरिवर्तित रहने वाले IP हेडर फ़ील्ड भी हैं, जबकि ESP भीतर समेटी सामग्री को प्रमाणित और एन्क्रिप्ट करता है और बाहरी हेडर छोड़ देता है। यही अंतर किसी भी हैश नाम से अधिक तय करता है।

AH क्या ढकता है जो ESP नहीं

AH अखंडता, डेटा-स्रोत का प्रमाणन और अपनी परिभाषित पुनरावृत्ति-रोधी सेवा देता है, गोपनीयता नहीं। इसका दायरा ऊपरी परत के डेटा और IP हेडर के उन फ़ील्ड तक है जिन्हें उसके नियम अपरिवर्तनीय मानते हैं, यानी वही हिस्सा जो ESP ट्रांसपोर्ट मोड में बाहर छोड़ता है। जब आवश्यकता कहे कि IP हेडर स्वयं प्रमाणित हो, तो उत्तर AH है।

यही दायरा AH को व्यवहार में नाज़ुक बनाता है। TTL, हेडर चेकसम और कुछ विकल्प जैसे परिवर्तनशील फ़ील्ड प्रमाणित नहीं हो सकते, क्योंकि राउटर उन्हें फिर लिख सकते हैं, इसलिए प्रोटोकॉल चेक की गणना से पहले उन्हें शून्य कर देता है। इसलिए पते फिर लिखने वाला हर काम गणना तोड़ता है, केवल नीति नहीं।

NAT चुनाव को बाधा बना देता है

पता अनुवाद उस IP हेडर में स्रोत या गंतव्य फिर लिखता है जिसे AH ने अभी प्रमाणित किया, इसलिए दूसरे छोर पर अखंडता जाँच विफल होती है, और पढ़े जा सकने वाले संदेश के रूप में नहीं, प्रोटोकॉल त्रुटि के रूप में विफल होती है। ESP बाहरी हेडर प्रमाणित नहीं करता, इसलिए NAT पार करने के साथ ESP चलता है और NAT के पीछे AH नहीं। दोनों सिरे सामान्य राउटर के पीछे हों तो यह वहीं पहले दिखता है। इसलिए पहला प्रश्न यह नहीं कि कौन मज़बूत है, बल्कि यह कि सिरों के बीच अनुवादक है या नहीं।

अगर है, तो 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 स्थापित संबंध का प्रोटोकॉल, मोड और एल्गोरिद्म दिखाता है, और बेमेल पर कुछ भी स्थापित नहीं होता, जो इच्छित सुरक्षा बिना उठने वाली सुरंग से अधिक स्वच्छ विफलता है।

प्रमाणन विफलताओं, सिलेक्टर कवरेज और रूटिंग दोषों को इस चुनाव से अलग रखें। वे अलग लक्षण देते हैं, और सिलेक्टर की समस्या के लिए प्रोटोकॉल को दोष देना बिना कारण हैश बदलते हुए दिन बिताने का भरोसेमंद तरीका है।