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 แสดงโปรโตคอล โหมด และอัลกอริทึมของสมาคมที่ติดตั้งไว้ และความไม่ตรงกันจะไม่ติดตั้งสิ่งใดเลย ซึ่งเป็นความล้มเหลวที่สะอาดกว่าอุโมงค์ที่ขึ้นมาโดยไม่มีการป้องกันที่ตั้งใจ

แยกความล้มเหลวในการพิสูจน์ ขอบเขตของตัวเลือก และข้อผิดพลาดในการกำหนดเส้นทางออกจากทางเลือกนี้ พวกมันให้อาการต่างกัน และการโทษโปรโตคอลสำหรับปัญหาตัวเลือกคือวิธีที่แน่นอนในการเสียเวลาหนึ่งวันเปลี่ยนแฮชโดยไม่มีเหตุ