ข้อเสนอ IPsec ประกอบด้วยอะไรบ้าง? ฟิลด์ IKE และ ESP
ข้อเสนอคือข้อเสนอเดียวที่สมบูรณ์ ไม่ใช่ถุงอัลกอริทึม ดูว่าฟิลด์ใดเป็นของ IKE และฟิลด์ใดเป็นของ ESP และทำไมความไม่ตรงกันเพียงจุดเดียวจึงปฏิเสธทั้งชุด
IKE เริ่มทำงาน ทั้งสองฝ่ายประกาศ AES แต่ทันเนลก็ยังล้มเหลวด้วย NO_PROPOSAL_CHOSEN บันทึกระบุชื่อข้อเสนอแต่ไม่ได้ระบุฟิลด์ที่ไม่ตรงกัน ข้อเสนอคือข้อเสนอเดียวที่สมบูรณ์ และฟิลด์ที่ไม่เข้ากันเพียงฟิลด์เดียวทำให้ทั้งชุดเป็นโมฆะ ไม่ใช่แค่บรรทัดนั้น การอ่านมันเป็นถุงของการเลือกอัลกอริทึมที่เป็นอิสระต่อกันคือเหตุผลปกติที่ทำให้ความไม่ตรงกันยังคงมองไม่เห็น
การเจรจาสองรอบที่มีรายการข้อเสนอแยกกัน
IKEv2 สร้างสมาคมความปลอดภัยสองรายการ รายการแรกคือ IKE SA ซึ่งปกป้องการแลกเปลี่ยนควบคุมเอง และรายการที่สองคือ CHILD SA ซึ่งขนส่งทราฟฟิกของคุณผ่าน ESP แต่ละรายการมีรายการข้อเสนอของตัวเอง และฝ่ายหนึ่งสามารถยอมรับรายการหนึ่งและปฏิเสธอีกรายการได้
การแยกนี้อธิบายความสับสนที่พบบ่อย: IKE SA ที่ทำงานได้พิสูจน์เพียงว่าอัลกอริทึมของช่องควบคุมตรงกัน หากข้อเสนอ CHILD ล้มเหลว ทันเนลจะไม่ขนส่งแพ็กเก็ตแม้แต่แพ็กเก็ตเดียว แม้ว่าระยะแรกจะเสร็จสิ้นและบันทึกด้านบนดูปกติ
ลำดับภายในแต่ละรายการก็สำคัญเช่นกัน ผู้ตอบเลือกจากข้อเสนอที่เรียงลำดับของผู้เริ่ม ดังนั้นการย้ายรายการที่เข้ากันได้กว้างขึ้นไปไว้เหนือรายการที่แคบกว่าจึงเปลี่ยนชุดที่จะติดตั้ง โดยไม่เปลี่ยนชื่ออัลกอริทึมใดเลย ปักหมุดลำดับนั้นในการกำหนดค่าแทนการพึ่งพาค่าเริ่มต้น ลำดับที่มั่นคงยังทำให้การเปรียบเทียบบันทึกระหว่างไซต์มีความหมาย
ฟิลด์ใดเป็นของข้อเสนอใด
ชุดฟิลด์มีขนาดเล็ก แต่ไม่เหมือนกันในการเจรจาทั้งสองครั้ง อ่านตารางทีละแถว เพราะฟิลด์ในคอลัมน์หนึ่งอาจไม่มีในอีกคอลัมน์หนึ่ง ไวยากรณ์แตกต่างกันตามการใช้งาน; เอกสารข้อเสนอของ strongSwan เป็นข้อมูลอ้างอิงที่ชัดเจนหนึ่งรายการ
| Field | IKE SA proposal | CHILD SA proposal |
|---|---|---|
| Encryption | Required | Required |
| Integrity | Required unless AEAD | Required unless AEAD |
| PRF | Required | Not present |
| DH group | Required | Only for PFS |
| ESN | Not present | Optional |
ฟิลด์การเข้ารหัสระบุรหัสลับและความยาวคีย์ในไวยากรณ์ส่วนใหญ่ ฟิลด์ความสมบูรณ์ระบุแฮชที่ใช้พิสูจน์อักษรข้อความที่เข้ารหัส และ PRF ระบุฟังก์ชันที่สร้างวัสดุกุญแจสำหรับ IKE SA กลุ่ม DH สร้างวัสดุลับร่วมใหม่ จึงปรากฏทั้งสองฝ่ายแต่เพื่อวัตถุประสงค์ต่างกัน
หมายเลขลำดับแบบขยายเป็นของเส้นทางข้อมูลเท่านั้น มันขยายพื้นที่ลำดับและถูกเจรจาเป็นส่วนหนึ่งของข้อเสนอ CHILD ดังนั้นความไม่ตรงกันตรงนั้นจะปฏิเสธข้อเสนอ CHILD โดยที่ IKE SA ไม่ถูกแตะต้อง
ข้อเสนอเดียวที่สมบูรณ์ถูกเลือกอย่างไร
แต่ละข้อเสนอคือชุด และผู้ตอบมองหาชุดที่ทุกฟิลด์ที่จำเป็นเป็นที่ยอมรับ สองรายการอาจมีทั้ง AES และ SHA-256 แต่ยังไม่มีรายการที่เข้ากันได้ เพราะความยาวคีย์ PRF หรือกลุ่ม DH ต่างกัน การเปรียบเทียบเกิดต่อข้อเสนอ ไม่ใช่ต่ออัลกอริทึม
เมื่อไม่มีอะไรตรงกัน ผู้ตอบจะส่ง NO_PROPOSAL_CHOSEN พร้อมประเภท SA ที่ล้มเหลว อ่านว่าการแจ้งเตือนอ้างถึงรายการข้อเสนอใดก่อนแก้ไขการกำหนดค่า การเปลี่ยนอัลกอริทึม ESP เมื่อข้อเสนอ IKE ถูกปฏิเสธทำให้เสียรอบการแก้จุดบกพร่องหนึ่งรอบ
พฤติกรรมการเลือกควรรู้เมื่อปรับโปรไฟล์ การใช้งานบางส่วนชอบลำดับของผู้เริ่ม ส่วนอื่นจัดเรียงใหม่ตามนโยบายท้องถิ่น ดังนั้น ชุดที่ทำงานระหว่างผู้จำหน่ายสองรายอาจหายไป เมื่อคุณสลับว่าฝ่ายใดเริ่มการเชื่อมต่อ
AEAD นำฟิลด์ออกแทนที่จะเพิ่มเข้าไป
AES-GCM และ ChaCha20-Poly1305 พิสูจน์และเข้ารหัสในการดำเนินการเดียว เมื่อเลือกหนึ่งในนั้นสำหรับ ESP อัลกอริทึมความสมบูรณ์จะไม่ถูกเจรจาแยก เพราะโครงสร้าง AEAD ครอบคลุมอยู่แล้ว ดังนั้นข้อเสนอที่จับคู่ AES-GCM กับ SHA-256 จึงซ้ำซ้อนอย่างดีที่สุดและถูกปฏิเสธอย่างแย่ที่สุด
PRF ยังแยกอยู่ฝั่ง IKE เพราะมันสร้างกุญแจสำหรับช่องควบคุมแทนการปกป้องเพย์โหลด นี่คือเหตุผลที่ข้อเสนอ IKE สามารถรวมรหัสลับ AEAD กับ PRF และกลุ่ม DH ได้อย่างชอบธรรม ขณะที่ข้อเสนอ ESP ที่สอดคล้องระบุเพียงรหัสลับ AEAD และกลุ่ม PFS ที่ไม่บังคับ
ความยาวคีย์เป็นส่วนหนึ่งของโทเค็นการเข้ารหัส ดังนั้น AES-128-GCM และ AES-256-GCM จึงเป็นข้อเสนอที่ต่างกัน โปรไฟล์ที่คัดลอกจากคู่มือซึ่งถือว่าคีย์ 256-bit จะไม่ตรงกับปลายทางที่กำหนดค่าสำหรับ 128-bit แม้ว่าทั้งสองบรรทัดจะบอกว่า AES-GCM สองฝ่ายอาจตกลงเรื่องตระกูลรหัสลับได้และยังปฏิเสธกันเพราะตัวเลขหลังขีดกลาง
อ่าน SA ที่ติดตั้งไว้ ไม่ใช่การกำหนดค่า
รายการข้อเสนอที่กำหนดค่าไว้คือข้อเสนอ ส่วน SA ที่ติดตั้งไว้คือผลลัพธ์ บน strongSwan และเคอร์เนล Linux มีทั้งสองมุมมอง:
sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policyswanctl --list-sas พิมพ์อัลกอริทึมที่เจรจาต่อ SA รวมถึงว่า CHILD ใช้ AEAD หรือไม่ ip xfrm state แสดงสิ่งที่เคอร์เนลติดตั้งจริง และที่นั่นคือจุดยืนยันว่าการต่ออายุคีย์ไม่ได้ถอยกลับไปยังชุดอื่นที่ไม่ใช่ชุดที่คุณบันทึกไว้
เก็บเอาต์พุตนั้นไว้ข้างการกำหนดค่าหลังการแก้ไข เมื่อการอัปเดตไคลเอนต์เปลี่ยนค่าเริ่มต้น ชุดที่บันทึกไว้จะให้เส้นฐานสำหรับการเปรียบเทียบ และการเปรียบเทียบชี้ไปที่ฟิลด์ที่ขยับแทนที่จะเริ่มการสอบสวนใหม่ตั้งแต่ต้น